VMware vsphere 5.1 cluster Walkthrough (eight) Integration/rollup

Eighth Chapter Integration

Now that you know how HA works from the inside out, we're going to have to explain different points in Ha,drs,sdrs and other components or functions, and we think it's worth mentioning, although admitting that some of the information isn't mature enough, we think it's a very important part of the book.

Ha and stateless ESXi

Vsphere 5.0 introduces a very cow-snapping feature-stateless esxi, stateless ESXi means no boot disk, that is, no USB disk, SD disk, local disk, or San boot, ESXi can boot through PXE, and directly load files into memory. However, it also adds some interesting challenges when the host is restarted and the HA agent starts, what about the HA configuration information they need? For stateless ESXi hosts, we rely on the auto Deploy server to store configuration information for the HA agent, and when the host is turned on or restarted, the HA agent will reinitialize, vsphere 5.1 automatically deploy the mirror, mirroring includes the default Ha vib file, and And the HA agent does not need to be installed after the host is turned on or restarted.

We described the configuration file in chapter II, where the auto Deploy server caches the required configuration files for Ha, vcenter version files are required for HA because these files are constantly changing, so the automated deployment Management host requires the correct cache copy files.

HA and Storage DRS

In the event of a failure, vsphere ha notifies the storage DRS to prevent the migration of ha-protected virtual machines, that is, a virtual machine that turned on power fails because of insufficient usable capacity and does not restart immediately, in addition to the virtual machines that are executed by the vcenter notification, Storage DRS does not allow storage to migrate other virtual machines, because in this case, HA does not protect the virtual machine until vcenter server locks the data store again.

Storage migrations and HA

There have been some revisions to storage migrations in Vsphere 5.0, we describe it in detail in chapter second to third, but to discuss the consolidation of HA in this section, if HA is enabled, a virtual machine needs to be restarted, the virtual machine fails during storage migration, and the restarted process does not trigger until Vcenter notifies master that the storage migration task completes, or the storage task is rolled back, and if the resource host fails, the virtual machine will start as part of a normal workflow, and during the storage migration, the agent of the host where the storage migration resides will be initialized to overwrite the virtual machine's failure status. If, for whatever reason, Vcenter is unavailable, the virtual machine will be overwritten in 15 minutes to ensure that the virtual machine is restarted.

Also noting the vsphere 5.0 U1 and above, when the storage migration is complete, vcenter reports that the virtual machine is unprotected until the master reports that the virtual machine is protected again under the new path.

Ha and DRS

The HA feature of Vsphere 4.1, which integrates DRS at multiple levels, is a great step forward, and what we want to emphasize is that HA has changed in behavior and reliability.

Ha and resource fragmentation

When a failover is triggered, ha first checks to see if resources are available on the target host. For example, a particular virtual machine has a very large reserve resource, and the access control strategy is based on percentages, for example, it may occur that resources are distributed across multiple hosts (see section 7th for a more detailed description of this scenario), in vsphere Ha, 4.1, will ask DRS about debris resources to accommodate the needs of virtual machines, although the fragmentation resources required by HA cannot be guaranteed, so additional integration, when it comes to resource fragmentation, should be kept cautious.

Share Share

Before the vsphere 4.1, when a client sets up a virtual machine resource share, a problem may occur when the HA-enabled cluster virtual machine fails, it opens the virtual machine in the other resource pool, but the user configures the share of the virtual machine instead of the resource pool for automatic adjustment, This may cause the virtual machine to receive too many or too few quota resources.

The following scenarios may occur: There are VM1 and resource pools in the cluster A,VM1 1000 resources, 2000 resources Pool A, but resource Pool A has 2 virtual machines, each virtual machine occupies 50% of "2000", this scenario is described below:

Figure 34: Share Share record