Information:
The following is a procedure you can use to convert your existing MSCS failover clusters from the traditional thick disk VMDK files, to a more manageable RDM. The table below highlights the supported configurations of RDMs versus Thick VMDK files.
|
Storage Type
|
Clusters in on physical machine (cluster in a box)
|
Clusters across physical machines (cluster across boxes)
|
Clusters of physical and virtual machines (standby host clustering)
|
|
|
Win2003
|
Win2008
|
Win2003
|
Win2008
|
Win2003
|
Win2008
|
|
Thick VMDK
|
Yes
|
No
|
No
|
No
|
No
|
No
|
|
Physical RDM
|
No
|
No
|
Yes
|
*Yes
|
Yes
|
*Yes
|
|
Virtual RDM
|
*Yes
|
Yes
|
*Yes
|
No
|
No
|
No
|
* = recommendation
Thick VMDK: is a Virtual disk created using the -d thick -a lsilogic options in the vmkfstools command.
Virtual RDM: is an RDM in virtual compatibility mode also known as a non-pass-through RDM.
Physical RDM: is an RDM in physical compatibility mode also know as a pass-though RDM.
The main advantage of RDMs over Thick VMDK files is the ability to more easily add disk space. Using Thick VMDK files requires a procedure be used to migrate the data from one VMDK to a larger VMDK as disk space needs increase. This can be a time consuming process. By using RDMs we can leverage the SAN backend storage to more dynamically increase the size of the LUN used in the clusters.
Note: You can not expand Thick disks used by a cluster. You must create a new disk and copy the data to it.
Here is an easy procedure to follow to migrate data from Thick VMDK files to Virtual RDMs. You can adjust the process as needed to support other migration paths as well.
1) Power off all Nodes of the cluster
2) Create the new Quorum LUN on the storage array to replace the existing Thick VMDK Quorum Drive.
a. Create the RDM LUN on the storage array as required in your environment.
b. Assign the RDM LUN to the ESX servers
i. These should be presented as Windows LUNs not VMWare LUNs
c. Assign the Quorum drive to the First Node of the cluster.
i. Add Hard disk
ii. Select Raw Device Mapping
iii. Select the appropriate LUN
iv. Store mapping file with the Virtual Machine
v. Select Virtual or Physical RDM as needed for your requirements
vi. Change the default SCSI ID to 2:0.
1. This will install an new SCSI controller into the VM
vii. Change SCSI Controller type depending on OS
1. Win2003: LSI Logic Parallel
2. Win2008: LSI Logic SAS
viii. Set SCSI Bus sharing to Physical
d. Review the RDM mapping file location.
i. Edit the properties of the new Quorum drive and note the location of the associated VMDK mapping file. It is this file you will assign to the other nodes of the cluster.
e. Assign the Quorum drive to the other nodes of the cluster
i. Add Hard disk
ii. Select use existing virtual disk
iii. Browse to the location of the VMDK mapping file and select the appropriate file.
iv. Change the default SCSI ID to 2:0.
1. This will install an new SCSI controller into the VM
2. You must select the same SCSI ID as used on the first node.
v. Change SCSI Controller type depending on OS
1. Win2003: LSI Logic Parrallel
2. Win2008: LSI Logic SAS
vi. Set SCSI Bus sharing to Physical
3) Repeat the above procedure for creating and assigning the shared RDM disks to the Cluster
a. Adjust SCSI ID as needed for additional LUNs.
4) Power on all nodes of the cluster
a. Verify the first node comes up before the others nodes are powered on.
5) Verify all nodes have access to the Quorum and all Share disks.
6) Convert the Quorum drive over to the RDM
a. Use the following article that describes how to change the Quorum drive in MSCS.
i. How to change the Quorum Disk Resource in MSCS
7) Migrate the Share drives data
a. Power On only one of the clustered VM’s
i. Shutdown all other cluster nodes.
b. In Cluster Administrator Take Offline the applications
i. You must leave the clustered disks online
c. Assign Drive letters to new disks as needed.
i. Partition and Format as needed
d. Copy data between LUNS as needed
i. Copy security as required as well.
e. Remove assigned drive letter from new lun(s)
f. Power Off VM
g. Remove original Thick VMDK files from all the clustered Nodes
i. Optional: Delete during the removal
h. Power On only one Node of the cluster
i. The original disk cluster resources will fail, but the applications are offline anyway.
i. Assign the original drive letter(s) to the new drive
8) Power on all other clustered VMs
a. Verify the original Thick VMDK files have been removed from the VMs before powering on.
b. All cluster nodes must be powered on to modify the cluster configuration.
9) Correct the cluster configuration
a. On the first node of the cluster start the Cluster Admin
i. The original cluster disk resource(s) are now failed.
ii. Remove the disks as a dependency from any other resources
1. Make note of these dependencies for future use.
iii. Delete the old disk resources
iv. Add the new disk(s) as a resource
v. Re-configure the disk dependencies recorded earlier
vi. Bring all resources online
vii. Test cluster failover
10) If not done already delete the original Thick VMDK files