Sergey Galushko - Fotolia

VMware vSphere cluster requirements and challenges

A vSphere cluster provides virtual data centers with superior application availability and rapid recovery.

Modern data centers are shifting focus from recovery to availability. Instead of struggling to recover corrupt, damaged or inaccessible applications, organizations are employing technologies intended to preserve application availability when trouble occurs. Virtualized data centers are employing server clusters to create shared computing pools that can quickly restart troubled virtual machines (VMs). But clustering poses several new challenges for the virtual data center.  IT professionals should understand the impact on requirements, storage networks, hypervisor and operating system implications, and configuration preferences.

Support for iSCSI and FCoE

VMware vSphere 5.5 adds native support for iSCSI and Fibre Channel over Ethernet (FCoE) protocols for server clustering, but there are some deployment rules and limitations that IT planners should be aware of.

For example, iSCSI supports the three principal server cluster configurations: cluster across boxes (CAB), cluster in box (CIB) and N+1. The cluster can support both software and hardware iSCSI initiators at the same time (known as mixed mode iSCSI) using software-based iSCSI storage adapters, as well as hardware iSCSI adapters from QLogic, Emulex and Broadcom. However, all server nodes within the cluster must run the same version of ESXi, and all server nodes must use the same storage protocol. For example, you cannot create a cluster where one server uses ESX 5.1 with iSCSI and another server node uses ESX 5.5 with FCoE -- consistent hardware and software inventories are important for clustered servers.

FCoE also supports CAB, CIB and N+1 clusters using various software and hardware FCoE adapters, but FCoE clusters cannot mix CIB and CAB clusters together. And unlike iSCSI, mixed mode initiators are not supported, so one server cannot use a software FCoE initiator while another server node uses a hardware FCoE initiator. All servers in the cluster must use the same FCoE initiator. Protocols and hypervisors also cannot be mixed with FCoE. For example, each server node must use the same version of ESXi and the same storage protocol (Fibre Channel and FCoE do not mix within the same cluster).

Clustering alternatives for a Microsoft environment

VMware vSphere provides a variety of clustering options for Microsoft-based data centers, though most options are focused on major enterprise applications. For example, two primary approaches support generic server clustering using Microsoft Cluster Server (MSCS) using shared storage, as well as clustering for network load balancing. IT planners can use MSCS for high-availability deployments, and use load balancing in locations where traffic can be unpredictable or demanding.

VSphere also supports clustering options for SQL. Conventional clustering can help to improve performance, while support for "always-on availability" can be the preferred approach for mission-critical SQL deployments.

Finally, vSphere supports clustering options for Exchange. A simple single-copy cluster offers a clustered mailbox server using shared storage so more than one server can manage a single copy of the storage. Cluster continuous replication helps Exchange deployments avoid single points of failure and recover quickly using failover and replication features. Clustering also works for Exchange database availability groups intended to cluster and support availability for Exchange Mailbox servers.

When to apply affinity or anti-affinity rules

Although workload mobility is a vitally important benefit of virtualization, that same mobility can potentially cause problems when workloads are migrated to the same server -- or to different servers -- as a response to high-availability or Distributed Resource Scheduler (DRS) activity. Management tools like DRS provide affinity rules that can stipulate the VMs that should be kept on the same physical server, along with anti-affinity used to define VMs that should never appear on the same server. IT planners should use affinity and anti-affinity rules to maintain relationships between workloads on and across server nodes within a cluster.

For example, suppose a group of MSCS VMs were configured on the same server as a CIB. It would be undesirable to see those VMs failover to more than one other server node within the cluster. So affinity rules can be used to ensure those VMs all mode to the same node during a failover. Conversely, when a group of VMs are configured across several servers as a CAB, it would be undesirable to see those VMs failover to a single server node in the cluster. 6In this case, anti-affinity rules can be used to prevent those VMs from moving to the same server node.

Remember that clustering technologies can be challenging to implement and maintain. Clustering requires careful interoperability between the application versions being protected, the hypervisor version, the operating system versions and the enterprise storage infrastructure. It is critically important to evaluate cluster architectures and behaviors before moving cluster services to a production environment. In addition, it is important to test and re-evaluate cluster behavior after any change is made to applications, hypervisors, operating system components or storage to prevent unintended consequences for the business.

Dig Deeper on Virtualized clusters and high-performance computing