|
Objective 4.1 - Configure Virtual Machine Clustering |
 |
 |
|
Written by Matthijs van den Berg
|
|
Tuesday, 24 March 2009 23:58 |
KNOWLEDGE
- Explain the different methods of clustering virtual machines (more info: http://www.vmware.com)
There are three option to create a software cluster on OS level (like MSCS Cluster). You can use two VM on the same host, two VMs on separate hosts and one VM and one physical host. Below there is an explanation for each of those cluster types.
- Cluster in a box
Cluster in a box means that the Virtual Machines of the cluster on OS level reside on the same ESX host.
There are some requirement to set up a cluster in a box. The ESX servers needs:
- An ESX Server host with two physical network adapters: one for the service console and one for communication between the two virtual machines and the clients of the clustered applications.
- Access to SAN storage (recommended) or to a shared local disk.
- A local SCSI controller.
You can set up shared storage for a cluster in a box using either a virtual disk or a remote LUN using raw device mapping (RDM) in virtual compatibility mode (non-pass-through RDM).
For the VM you need to configure:
- Two virtual network adapters.
- At least two virtual hard disks that are shared among the two virtual machines (one quorum disk and one data disk).
- Cluster across boxes
Clustering across boxes means that either node of the cluster resides on a different ESX host (preferably always separated by a DRS Affinity Rule).
The prerequisites for clustering across boxes are similar to those for cluster in a box. You must have:
- ESX Server host. VMware recommends three network adapters per host for public network connections. The minimum configuration is:
- ESX Server 3 – An ESX Server host configured with at least two physical network adapters dedicated to the cluster, one for the public and one for the private network, and one network adapter dedicated to the service console.
- ESX Server 3i – An ESX Server host configured with at least two physical network adapters dedicated to the cluster, one for the public and one for the private network, and one network adapter dedicated to the VMkernel.
- Shared storage must be on an FC SAN.
- You must use an RDM in physical or virtual compatibility mode (pass-through RDM or non-pass-through RDM). You cannot use virtual disks for shared storage.
- Physical to Virtual clustering (N+1 clusters)
Physical to Virtual clustering means a cluster existing of (at least) one VM and (at least) one physical host.
This is also called Standby Host Clustering. For a simple clustering solution with low hardware requirements, you might choose to have one standby host. Set up your system to have a virtual machine corresponding to each physical machine on the standby host, and then create clusters, one each for each physical machine and its corresponding virtual machine. In case of hardware failure in one of the physical machines, the virtual machine on the standby host can take over for that physical host.
The prerequisites for standby host clustering are similar to those for clustering across boxes. You must have:
- ESX Server host. VMware recommends three network adapters per host for public network connections. The minimum configuration is:
- ESX Server 3 – An ESX Server host configured with at least two physical network adapters dedicated to the cluster, one for the public and one for the private network, and one network adapter dedicated to the service console.
- ESX Server 3i – An ESX Server host configured with at least two physical network adapters dedicated to the cluster, one for the public and one for the private network, and one network adapter dedicated to the VMkernel.
- You must use RDMs in physical compatibility mode (pass-through RDM). You cannot use virtual disk or RDM in virtual compatibility mode (non-pass-through RDM) for shared storage.
- You cannot have multiple paths from the ESX Server host to the storage.
- Running third-party multipathing software is not supported. Because of this limitation, VMware strongly recommends that there only be a single physical path from the native Windows host to the storage array in a configuration of standby-host clustering with a native Windows host. The ESX Server host automatically uses native ESX Server multipathing, which can result in multiple paths to shared storage.
- Use the STORport Miniport driver for the FC HBA (QLogic or Emulex) in the physical Windows machine.
- Describe how shared storage is configured with clustering
For the cluster to function you need shared storage. Shared storage can be either a Virtual Disk or a Raw Device Mapping (RDM). This RDM comes in two flavors, physical compatibility mode (also Pass-Through RDM) and virtual compatibility mode (Non Pass-Through RDM). VMware published a compatibility table crossing the three clustering types with the three storage types:
TABLE!
iSCSI and NFS are not supported for the quorum disk in Physical or Virtual Compatibility mode.
- Understand HBA configuration options
There are several options you can change on the HBA level. Some of them are:
-
- Queue Depth
The number of outstanding transactions on a HBA queue
- Boot from SAN
Boot the ESX server directly from the SAN, no internal disk necessary.
Skills and Abilities
- Configure bus sharing options
When configuring a VM you can choose to share this disk with other servers. To configure this go into the VMware Virtual Center Client and change the properties of the SCSI Controller:
-
- Power down the Virtual Machine
- Edit the settings of a virtual machine
- Select the SCSI Controller
- Select the Bus Sharing type you need
- Physical
Disk controlled via a SCSI controller in Physical compatibility mode can be accessed by any (physical) server. The downside is that you cannot snapshot disks in Physical Bus mode. Because the disk is accessed by two servers (possible one physical, so out of control of the VI) taking a snapshot of one server would mean the other server could still be writing to the RDM disk. The disk is passed through the vrtualisation layer, to the Virtual Machine.
- Virtual
Disk controlled via Virtual Compatibility mode allow for the same benefits as virtual disk in a VMFS file system like advanced file locking and the creation of snapshots. The disk is accessed via the virtualization layer.
- Configure Raw Device Mappings (RDMs)
Edit the .vmx file to point to the RDM instead of the shared file:
- Pass-through
- Non pass-through
scsi<X>:<Y>.filename ="/vmfs/volumes/vol2/<myVMDir>/<rdm-for-vm1>/<myrdm.vmdk>"
scsi<X>:<Y>.deviceType = "scsi-passthru-rdm"
Configure HBA options (http://www.vmware.com/pdf/esx25_san_cfg.pdf)
- Queue depth
I have written an article about adjusting the queue depth of HBAs. You can find I here.
- Device/LUN Reset
A cluster failover in Microsoft Cluster Services causes a formerly passive node to take over for a failed active node. This process involves issuing a bus reset before taking ownership of the LUN. The effect of a bus reset on the SAN is to reset all LUNs. You can restrict the reset to the LUN that belongs to the virtual machine that is taking the active role in the cluster. To do so, configure the VMkernel to translate a bus reset on the virtual SCSI adapter into a LUN reset on the physical adapter. Perform the following from the VMware Management Interface:
- Click the Options tab.
- Click the Advanced Settings link.
- Set Disk.UseDeviceReset to 0. (Click the value to open a new window where you can enter a replacement value.)
- Set Disk.UseLunReset to 1.
Note: If the Shared LUNs are raw device mapping to LUNs, enable LUN reset on HBA failover. Set Disk.ResetOnFailover to 1.
- Timeout value
Change the timeout value with the following command (see here hoe to lookup you HBA device: Change Queue Depth) :
/usr/sbin/esxcfg-module -s qlport_down_retry=14 qla2300_7xx
Tools
- CLI
- esxcfg-advcfg
- esxcfg-module
- VI client
|
