Mastering VMware vSphere 6. Marshall Nick
Чтение книги онлайн.
Читать онлайн книгу Mastering VMware vSphere 6 - Marshall Nick страница 9
Название: Mastering VMware vSphere 6
Автор: Marshall Nick
Издательство: John Wiley & Sons Limited
Жанр: Зарубежная образовательная литература
isbn: 9781118925164
isbn:
vSphere HA Improvements from vSphere 5
vSphere HA received a few notable improvements in the vSphere 5.0 release. First, scalability was significantly improved; you could run up to 512 VMs per host (up from 100 in earlier versions) and 3,000 VMs per cluster (up from 1,280 in earlier versions). Second, vSphere HA integrated more closely with the intelligent placement functionality of vSphere DRS, giving vSphere HA greater ability to restart VMs in the event of a host failure. The third and perhaps most significant improvement is the complete rewrite of the underlying architecture for vSphere HA; this entirely new architecture, known as Fault Domain Manager (FDM), eliminated many of the constraints found in earlier versions of VMware vSphere.
By default, vSphere HA does not provide failover in the event of a guest OS failure, although you can configure vSphere HA to monitor VMs and restart them automatically if they fail to respond to an internal heartbeat. This feature is called VM Failure Monitoring, and it uses a combination of internal heartbeats and I/O activity to attempt to detect if the guest OS inside a VM has stopped functioning. If the guest OS has stopped functioning, the VM can be restarted automatically.
With vSphere HA, it’s important to understand that there will be an interruption of service. If a physical host or storage device fails, vSphere HA restarts the VM, and while the VM is restarting, the applications or services provided by that VM are unavailable. For users who need even higher levels of availability than can be provided using vSphere HA, vSphere Fault Tolerance (FT), which is described in the next section, can help.
vSphere Fault Tolerance
Although vSphere HA provides a certain level of availability for VMs in the event of physical host failure, this might not be good enough for some workloads. vSphere Fault Tolerance (FT) might help in these situations.
As I described in the previous section, vSphere HA protects against unplanned physical server failure by providing a way to automatically restart VMs upon physical host failure. This need to restart a VM in the event of a physical host failure means that some downtime – generally less than 3 minutes – is incurred. vSphere FT goes even further and eliminates any downtime in the event of a physical host failure. For a single vCPU VM, the older vLockstep technology is used that is based on VMware’s earlier “record and replay” functionality, vSphere FT maintains a mirrored secondary VM on a separate physical host that is kept in lockstep with the primary VM. vSphere’s newer Fast Checkpointing technology supports FT of VMs with one to four vCPUs. Everything that occurs on the primary (protected) VM also occurs simultaneously on the secondary (mirrored) VM, so that if the physical host for the primary VM fails, the secondary VM can immediately step in and take over without any loss of connectivity. vSphere FT will also automatically re-create the secondary (mirrored) VM on another host if the physical host for the secondary VM fails, as illustrated in Figure 1.4. This ensures protection for the primary VM at all times.
Figure 1.4 vSphere FT provides protection against host failures with no downtime experienced by the VMs.
In the event of multiple host failures – say, the hosts running both the primary and secondary VMs failed – vSphere HA will reboot the primary VM on another available server, and vSphere FT will automatically create a new secondary VM. Again, this ensures protection for the primary VM at all times.
vSphere FT can work in conjunction with vMotion. As of vSphere 5.0, vSphere FT is also integrated with vSphere DRS, although this feature does require Enhanced vMotion Compatibility (EVC). VMware recommends that multiple FT virtual machines with multiple vCPUs have 10GbE networks between hosts.
vSphere Storage APIs for Data Protection and VMware Data Protection
One of the most critical aspects to any network, not just a virtualized infrastructure, is a solid backup strategy as defined by a company’s disaster recovery and business continuity plan. To help address organizational backup needs, VMware vSphere 6.0 has two key components: the vSphere Storage APIs for Data Protection (VADP) and VMware Data Protection (VDP).
VADP is a set of application programming interfaces (APIs) that back up vendors leverage in order to provide enhanced backup functionality of virtualized environments. VADP enables functionality like file-level backup and restore; support for incremental, differential, and full-image backups; native integration with backup software; and support for multiple storage protocols.
On its own, though, VADP is just a set of interfaces, like a framework for making backups possible. You can’t actually back up VMs with VADP. You’ll need a VADP-enabled backup application. There are a growing number of third-party backup applications that are designed to work with VADP, and VMware also offers its own backup tool, VMware Data Protection (VDP). VDP leverages VADP and technology based on EMC Avamar to provide a full backup solution for smaller VMware vSphere environments.
Using VMware Data Recovery?
In vSphere 5.1, VMware phased out its earlier data protection tool, VMware Data Recovery (VDR), in favor of VMware Data Protection. Although VDR was provided with vSphere 5.0, VDR is not supported with vSphere 5.1 and later, and you should use VDP instead.
Virtual SAN (VSAN)
VSAN is a major new feature included with, but licensed separately from, vSphere 5.5 and later. It is the evolution of work that VMware has been doing for a few years now, building on top of the work of the vSphere Storage Appliance (VSA). VSAN lets organizations leverage the internal storage found in individual compute nodes and turn it into – well, a virtual SAN.
VSAN requires at least three ESXi hosts (or nodes) but will scale to as many as 64. VSAN also requires solid-state storage in each of the compute nodes providing VSAN storage; this is done to help improve I/O performance given that most compute nodes have a limited number of physical drive spindles present. (Note that the solid-state storage in the servers used by VSAN is separate from solid-state storage that would be used by vSphere’s vSphere Flash Read Cache caching functionality. See the section vSphere Flash Read Cache later in this chapter for more details on using solid-state storage for caching.) VSAN pools the storage across the compute nodes, allowing you to create a datastore that spans multiple compute nodes. VSAN employs algorithms to help protect against data loss, such as ensuring that the data exists on multiple participating VSAN nodes at the same time.
More information on VSAN is found in Chapter 6, “Creating and Configuring Storage Devices.”
vSphere Replication vSphere Replication brings data replication, a feature typically found in hardware storage platforms, into vSphere itself. It’s been around since vSphere 5.0, when it was only enabled for use in conjunction with VMware Site Recovery Manager (SRM) 5.0. In vSphere 5.1, vSphere Replication was decoupled from SRM and enabled for independent use without VMware SRM.
vSphere Replication enables customers to replicate VMs from one vSphere environment to another vSphere environment. Typically, this means from one data center (often referred to as the primary or production data center) to another datacenter (typically the secondary, backup, or disaster recovery [DR] site). Unlike hardware-based solutions, vSphere Replication operates on a per-VM basis, so it gives customers very granular control over which workloads will be replicated and which workloads won’t be replicated.
You can find more information about vSphere Replication in Chapter 7.
vSphere Flash Read Cache
Since СКАЧАТЬ