Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to analyze vSphere HA clustering and migration. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have some understanding of the relevant knowledge after reading this article.

In the practice of virtualization, we often encounter vSphere HA cluster setup and virtual machine, storage migration. Here is an analysis of these two problems.

A collection of multiple computers is called a cluster, and the purpose of a cluster is to distribute the burden of computers to multiple hosts, or to let another server take over these services when there is a problem with the physical server running one service.

VMware vSphere High availability (HA) is a cluster function based on a group of ESXi servers, which is mainly designed to transfer the host in time when the host running the virtual machine fails, so as to avoid long downtime. VSphere HA leverages multiple ESXi hosts configured as clusters to provide fast outage recovery and cost-effective high availability for applications running in virtual machines. VSphere HA prevents server failures by restarting virtual machines on other hosts within the cluster, continuously monitoring virtual machines and resetting them when failures are detected to prevent application failures. Unlike other clustering solutions, vSphere HA provides the infrastructure and uses it to protect all workloads without the need to install special software within applications or virtual machines, all workloads are protected by vSphere HA, and after vSphere HA is configured, new virtual machines are protected without action, and they are automatically protected.

VSphere HA configuration method:

Before setting up HA, make sure that each ESXi host has management network redundancy and that the number of vSphere HA detection signal data stores is 1, with a few requirements. If its requirements are not met, configuration issues are prompted during the configuration of HA. To ensure management network redundancy, you can also use multiple management networks. Verify that all virtual machines and their configuration files reside on shared storage, verify that the host is configured to have access to the shared storage, so that virtual machines can be powered on using different hosts in the cluster, and when the management network and storage are set up, let's set up a HA cluster configuration.

In vSphere Center, right-click the data center and select New Cluster from the pop-up shortcut menu

In the Settings dialog box for the cluster, you can modify the vSphere HA (and other) settings for the cluster. On the Cluster Features page, select to open vSphere HA.

Set host monitoring status, access control, virtual machine options, virtual machine monitoring, and data storage detection signals for the cluster configuration vSphere HA as needed.

a. Host monitoring: monitoring network signals between cluster hosts, setting access control to specify the number of cluster capacity reserved for virtual machine failover, and setting access control policies.

b. Virtual machine options: set to control the restart order of virtual machines (virtual machine restart priority) and how vSphere HA responds when network connectivity is lost between hosts (host isolation response). These settings apply to all virtual machines in the cluster in the event of host failure or host isolation. In addition, exceptions can be configured for specific virtual machines. If you do not receive a VMware Tools detection signal for a single virtual machine within the set time, virtual machine monitoring restarts the virtual machine. Similarly, if you do not receive a detection signal from an application that the virtual machine is running, application monitoring can restart the virtual machine.

C, virtual machine monitoring: you can enable virtual machine monitoring function, and configure the sensitivity of vSphere HA monitoring when there is no response. The level of monitoring sensitivity can be configured in the default cluster settings. High sensitivity monitoring can draw the conclusion that a fault has occurred more quickly. However, if the monitored virtual machine or application is actually still running, but the detection signal is not received due to factors such as resource constraints, high-sensitivity monitoring may mistakenly assume that the virtual machine has failed. Low-sensitivity monitoring prolongs the time of service outage between the actual failure and the virtual machine reset. When a fault is detected, vSphere HA resets the virtual machine. Resetting ensures that these services are still available. "to avoid repeatedly resetting the virtual machine due to non-transient errors, by default, the virtual machine is reset only three times in a configurable interval." "after performing three resets on the virtual machine, vSphere HA does not attempt to reset the virtual machine further after a subsequent failure until the specified time expires." You can configure the number of resets using a custom setting of the maximum number of resets per virtual machine. When the monitoring sensitivity is high, the failure time interval is 30 (seconds) and the reset period is 1 hour. When the monitoring sensitivity is in progress, the failure interval is 60 (seconds) and the reset period is 24 hours. When the monitoring sensitivity is low, the failure interval is 120 (seconds) and the reset period is 7 days. In the default cluster setting, adjust the button left and right to control the monitoring sensitivity.

d. Data storage detection signal: when the preferred host in the vSphere HA cluster is unable to communicate with the slave host through the management network, the preferred host uses the data store detection signal to determine whether the secondary host has failed, is in a network partition, or is isolated from the network. The number of detection signal data stores selected by vCenter Server for each host.

VSphere HA High availability Test:

"when the vSphere HA cluster is set up, all virtual machines in the cluster receive failover support without additional configuration." Since RedHat7 is saved on shared storage and simulated ESXi2 host shutdown, test whether the RedHat7 virtual machine can be migrated to the ESXi1 host and started. If the HA fails, we can quickly find the problem by testing it this way, or we can reconfigure the HA on the ESXi host.

Migrate virtual machines and Stora

Migration is the process of moving a virtual machine from one host or storage location to another.

In vCenter Server, the following migration options are available:

Cold migration: move a powered-down virtual machine to a new host. (optional) configuration files and disk files can be repeated

New location to the new storage location. You can use cold migration to move virtual machines from one data center to another.

Migrate suspended virtual machines: move suspended virtual machines to a new host. (optional) configuration files and disk files can be redefined

Bit to the new storage location. Suspended virtual machines can be migrated from one data center to another.

Migrate via vMotion: move the powered-on virtual machine to the new host. With vMotion migration, it is possible to uninterrupt the virtual

Move a virtual machine to a new host when the machine is available, but you cannot use vMotion to move a virtual machine from one data center to another.

During the vMotion migration, the virtual machine worker process can continue throughout the migration. If necessary, the entire virtual machine condition and its configuration files are moved to the new host, while the associated virtual disk remains in the same location on the shared storage between the two hosts. After the virtual machine condition is migrated to an alternate host, the virtual machine runs on the new host. The virtual host health information includes the contents of the current memory and all information that defines and identifies the virtual machine. The content of memory includes transaction data and operating systems and applications with any number of bits in memory. The definition and identification information stored in the posture includes all data mapped to virtual machine hardware elements (such as BIOS, devices, and CPU), the MAC address of the Ethernet card, chipset status, registers, and so on.

When migrating a virtual machine through vMotion, the new host of the virtual machine must meet the compatibility requirements before the migration can continue.

VSphere vMotion migrates virtual machines from one physical server to another in real time through three basic technologies:

a. The entire state of a virtual machine is encapsulated by a set of files stored on shared storage, such as fibre Channel or iSCSI Storage area Network (SAN), or Network attached Storage (NAS). VSphere's virtual machine file system (VMFS) allows multiple vSphere hosts to access the same virtual machine files in parallel.

b. The active memory and precise execution status of the virtual machine are quickly transferred over a high-speed network, allowing the virtual machine to immediately switch from running on the source vSphere host to running on the target vSphere host. VMotion ensures that users are not aware of the transmission period by continuously tracking ongoing memory transactions in the bitmap. Once the entire memory and system state have been copied to the target vSphere host, vMotion halts the operation of the source virtual machine, copies the contents of the bitmap to the target vSphere host, and resumes the operation of the virtual machine on the target vSphere host. The whole process takes less than two seconds on Ethernet.

c. The underlying vSphere host virtualizes the network used by the virtual machine. This ensures that the virtual machine network identity and network connectivity are retained even after migration. Because virtual machine migration using vMotion preserves precise execution status, network identity, and active network connections, the result is zero downtime without disrupting user operations.

Suspended migration of virtual machines and migration through vMotion are also called "hot migrations" because they allow virtual machines to be migrated without powering off the virtual machines.

Network requirements for vMotion:

1. VMotion needs a dedicated VMkernel network to migrate virtual machines, so it is necessary to configure a private network for VMotion on each ESXI host, and considering the performance, it is best to bind a private Nic to the VMotion network.

Note: the VMkernel network interface provides network connectivity for hosts and handles VMware vMotion, IP storage and Fault Tolerance

Moving virtual machines between hosts is called migration. With vMotion, you can migrate virtual machines that are powered on without downtime. The VMkernel network connection must be set up correctly to accommodate vMotion.

IP memory refers to any form of memory that uses TCP/IP network ESXi. Because these memory types are network-based, they can use the same VMkernel interface and port group

2. VMotion requires network bandwidth to be at least gigabit, so 100 megabit bandwidth is not allowed (hard limit)

3. VMotion requires that the source and destination hosts have the same network configuration, including the network type and network label.

Storage vMotion:

Storage vMotion is a great feature when you need to migrate virtual machines between data stores. For example, you may need to migrate all virtual machines to a newly purchased array. You can use Storage vMotion for the above migration with just a few mouse clicks and no downtime. Another application of Storage vMotion is to convert workloads from thick standby to thin configuration, and of course the opposite can be done.

How does Storage vMotion work? On the face of it, the process may be quite simple, but a lot of complex work is going on in the background. In vSphere 4.1 and previous versions, this process was called change Block tracking (CBT), which first copied all blocks of data, and then used the information in CBT to copy blocks that had changed since the first copy.

In version 5. 0 and later, storage vMotion uses mirror mode. The mirrored mode separates the Icano between the source and destination, which means that the migration process will be faster because the data block will only be replicated once. Another cool thing is that if the storage array supports VAAI, then Storage vMotion can also use this feature.

Let's break down the execution of Storage vMotion:

1. The source working directory (vmx, logs, and so on) is copied to the target data store.

two。 Use the replicated files to create a shadow virtual machine on the destination data store and start it, but the virtual machine is paused and ready to receive replication fast. In order to prevent the home directory of the virtual machine from being transferred, the virtual machine is created in failure protection mode.

3. The mirrored drive starts copying the write Imax O block that has been copied to the target data store.

4. The disk files of the virtual machine are copied to the target data store, and the operation is completed when Imax O is mirrored in single-channel mode.

5. The source virtual machine is in a suspended state and the operation is re-performed on the shadow virtual machine.

6. The directory and disk files of the source virtual machine are deleted from the source data store.

How to use Storage vMotion? The process is quite simple. All you need to do is right-click the virtual machine and select migrate-> change the data store, select the virtual disk format (if you want to change it), select the new data store, click next and finish.

Migrate through Storage vMotion: move the virtual disk or configuration file of the powered-on virtual machine to the new data store. With Storage vMotion migration, the storage of a virtual machine can be moved without disrupting the availability of the virtual machine.

Suspended migration of virtual machines and migration through vMotion are sometimes referred to as "hot migrations" because they allow virtual machines to be migrated without powering off them. Migrating through vMotion is sometimes referred to as "live migration". You can move the virtual machine manually or you can set up scheduled tasks to perform a cold migration.

New virtual machines can be created by cloning virtual machines or copying their disks and configuration files, but cloning is not a form of migration.

So much for the analysis of vSphere HA clustering and migration. I hope the above content can be of some help and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.