Considerations for High Availability of Server Clusters: DNS and Failover

Even if virtualization matures gradually, HA is still one of the most difficult components in the cluster. A server cluster can enable high availability. It is a hypervisor function that limits the downtime when a virtual machine crashes. VMware vSphere, Microsoft Hyper-V and Citrix XenServer both provide high availability features to mitigate disaster recovery tasks in virtual architectures.

Too many people implement virtualization projects without understanding high availability. Worse, the Administrator ignores high availability during the implementation of the server cluster, leading to the change from a solution to a problem that needs to be solved.

In fact, high availability solves some column problems. It is a simple service. No matter what type of hypervisor you use, restart the virtual machine after the host fails. Continuous availability is an ideal target, but virtual machines still experience downtime.

High Availability is usually related to hot migration, such as XenMotion and vMotion, but it is not. I have seen a lot of problems in the server cluster after the first host failure, the two concepts are obfuscated.

High Availability technology is becoming more intelligent, but note that the following problems may cause your server cluster to crash.

How does DNS affect high availability?

Combined with VMware HA, DNS resolution becomes a serious problem. To allow the server cluster nodes to communicate with each other, VMware takes an important responsibility for DNS resolution. Generally, this is not a problem. However, nowadays, many IT staff are used to the concept that DNS is a service and do not need to be managed.

This non-intervention policy is partly due to Windows's Dynamic DNS function. Many administrators do not take DNS as seriously as they used to, because Dynamic DNS now automatically executes most tasks. However, the VMware Server does not use dynamic DNS.

If you use VMware HA in a server cluster, make sure that your managed network IP address and related host names are in the DNS. Manual operations and maintenance are required when changing or adding attachments to a virtual environment. If the DNS is not correctly configured, VMware will display a clear description, but it is easy to ignore this prompt if it is found too late.

DNS resolution in a multi-site server cluster

DNS resolution problems also affect multi-site Hyper-V clusters. Hyper-V's Windows Failover Clustering service can now span subnets. In some ways, this architecture is good, because you no longer need to use complex network technologies to manage across different locations. On the other hand, virtual machines that fail over to the second site usually need to process new subnets.

This is not a big problem on the server side, but it causes problems on the client side. The client configures the survival time value, which determines how long it will take to cache DNS reports. These reports are outdated after failover. In physical disaster recovery, it is usually not a problem because you may need to deal with more important problems, such as "the data center is crashing !" However, in a virtual architecture, problems may occur when the virtual machine is accidentally migrated to another site that can be replaced.

High Availability issues do not occur in Hyper-V clusters. Disaster recovery Server clusters that start virtual machines in different subnets will experience similar problems.

Importance of fault recovery commands

The DNS problem highlights the importance of the fault recovery command in server cluster management. Some server clusters organize fault recovery commands better than others. For example, VMware HA allows the server cluster to handle the fault recovery command by itself. For others, such as Hyper-V, the Administrator manually determines where the virtual machine is migrated after a fault occurs.

What you don't want to see is the migration of virtual machines to unsuitable server cluster nodes, such as to the other end of a multi-site cluster or an overloaded node. Pay special attention to your fault recovery command to ensure that the Cluster load is balanced.

What should I do when host isolation occurs?

When the server cluster host is still online, the host is isolated, but it cannot communicate with other nodes. The problem with host isolation is that the isolated host still runs virtual machines. In VMware HA isolation events, these virtual machines usually run on different vswitches without being isolated. The cluster may want to recover these virtual machine faults out of the isolation zone, but it cannot be implemented if an isolated host lacks the disk files of the virtual machine.

There are several ways to fix this problem. Obviously, it is the best solution to rerecall isolated hosts online. But if you cannot do this, you need to shut down the virtual machine so that the surviving cluster nodes can failover these virtual machines. Pay attention to the isolation response settings of High-Performance Solutions to determine which settings can meet your special needs. When the host is isolated, many features allow you to choose to continue or shut down the VM.

High Availability is a useful component in the virtual architecture, but it cannot bypass important settings in the server cluster to manage exciting Server Load balancer functions. Otherwise, there will be many difficult problems.