Virtual server clustering can improve disaster recovery, load balancing, availability and management in your data...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
A virtual server cluster creates a boundary around virtual machines (VMs) and allows you to easily balance resources among hosts. Most importantly, server clustering boosts high availability (HA) because VMs can fail over to other cluster hosts with limited downtime.
But creating an HA cluster isn’t always easy. You need to decide how many hosts and VMs to fit in your virtual server cluster. Plus, you may encounter challenges with the network, domain name system and cluster performance. There are a few server clustering tools out there to make it easier, including Microsoft Hyper-V’s Windows Failover Clustering feature. If you configure a Hyper-V failover cluster correctly, server clustering can be an integral step in your disaster recovery plan.
The responses to these frequently asked questions about server clustering will help you understand the pros and cons of a virtual server cluster, the server failover calculations used in an HA cluster and how to configure a Hyper-V failover cluster.
What are the requirements for creating an HA cluster?
Hosts in a virtual server cluster must have access to the same shared storage, and they must have identical network configurations. Domain name system (DNS) naming is important too: All hosts must resolve other hosts using DNS names, and if DNS is not set correctly, you won’t be able to configure HA settings at all. HA cluster configuration is also critical. Server clustering depends on three settings: host failures allowed, admission control and VM options.
How many hosts and VMs should I put in my virtual server cluster?
Server cluster sizing is a critical step in planning your HA cluster. You have to consider your virtualization platform’s limitations and hardware restrictions. To provide redundancy and avoid a single point of failure, for instance, you would typically provide extra network interface cards (NICs) for VMs, but some hardware limits the number of NICs. As for the number of hosts, you need to find a middle ground for your virtual server cluster size. With too many, the load balancing calculations can get pretty complex, and with too few hosts, server clustering ends up wasting resources.
What’s a good way to ensure HA in my virtual server cluster?
To ensure that VMs fail over correctly and remain available, you need to reserve virtual server cluster resources. A cluster reserve should be equal to the full amount of resources that one server supplies, and it must go unused at all times. The major hypervisors allow you to set aside spare capacity, so you can choose any amount you want. You should also configure your server failover options to prioritize hosts in an appropriate failover order. That way, your most prized workloads reboot first after a failure.
What are some challenges around server clustering?
VMware HA relies heavily on DNS name resolution, because it allows cluster nodes to communicate. That means administrators of a VMware virtual server cluster have to pay particular attention to IP addresses and associated host names -- a manual and easily forgotten task. In a Hyper-V failover cluster, DNS poses problems if the HA cluster allows VMs to fail over to different subnets.
You may also encounter the problem of host isolation, when a host remains online but can’t communicate with other cluster nodes. In this case, you may need to power down its VMs so they can fail over. Most server cluster high-availability features include response settings for host isolation.
Is server clustering useful in test and dev environments?
Yes, a virtual server cluster can improve high availability in virtual testing environments, allowing your important test workloads to remain online. An HA cluster for test and dev allows admins to easily fail over VMs and manage VM patches or updates. Plus, server clustering reduces the risks of moving to production. You can test availability and ensure that your VMs will perform as expected.
How can I build a Hyper-V failover cluster?
A single cluster site is great for failing over VMs when a host goes down, but if a natural disaster or network or power outage occurs, you need a multi-site cluster. By extending your virtual server cluster to multiple physical sites, you can protect VMs and hosts from a site-wide failure. Through Windows Failover Clustering, the shared storage contents copy over to a secondary Hyper-V failover cluster site, and data replication ensures that you don’t suffer data loss.
To get the best Hyper-V cluster performance, configure VMs in multi-site clusters to respond to the IP addresses at both locations. You should also use Windows PowerShell commands to monitor latency between separate Hyper-V failover clusters.
How can I overcome network issues in a Hyper-V failover cluster?
If your Hyper-V failover cluster experiences a sudden network loss, numerous VMs will have to find and restart on other hosts. Sometimes, they’ll report that there is a duplicate IP address on the network, but you can solve this high-availability cluster issue by simply shutting down and restarting the VM manually. It’s also common to experience pinging problems after a VM reboot, but restarting the VM should do the trick here too. And to eliminate the problem in the future, try not to use legacy network adapters, which route traffic through the host partition.
What are the benefits of Hyper-V Cluster Shared Volumes?
Microsoft Hyper-V R2’s server clustering technology, Cluster Shared Volumes, grants read-and-write access to all Hyper-V failover cluster nodes and integrates with Live Migration. Cluster Shared Volumes simplifies storage provisioning by allowing you to create a larger logical unit number (LUN) instead of laboring over multiple LUN configurations. Creating a single LUN also means you can reduce the amount of buffer space on each VM in the virtual server cluster.