Virtualization and SAN upgrade on Windows 2003 cluster (part 1)

Recently we've got task that is not as frequent as we'd like on our territories. We needed to do virtualization and disk migration of two Windows 2003 clustered servers.

So in this and in my next blog I’ll describe how we approached this delicate task, without major downtime in this 24/7 production environment.

First of all we upgraded our HP DL360 g5 servers with additional processor, RAM and FC controller for VMware cluster. We also upgraded two HP DL360 g5, running Windows 2003 cluster, with FC controller. Then we installed, configured and presented LUNs on HP StorageWorks 2024fc G2 Modular Smart Array. And at the end we installed VMware ESX 4.1 cluster.

So now what? We have two VMware ESX clustered servers and two Windows 2003 clustered servers, we also have HP MSA2024fc and old HP MSA500 SCSI. We started Googling (useful link), testing different migration strategies and at the end we decided to do it like this:
- First we’ll migrate data from old SAN to new one (Blog - part 1).
- Virtualize Windows cluster nodes on by one (Blog - part 2).

Our MS Windows cluster has these resource groups that needed to be migrated to new disks:
- File Server resource group
- Print Perver resource group
- Quorum resource group
- MS SQL Server resource group
- Domino Server (Lotus Notes) resource group

Migrating data of different cluster resource groups from old SAN to new one was done in this order:
1) Quorum
- We added new cluster resource disk named NewQuorumDisk with drive letter X:

- Moved old Quorum to new resource named NewQuorumDisk like described in MS KB280353.

- Stopped cluster resource OldQuorumDisk and delete Q: drive from the cluster
- Opened Disk Management and change drive letter Q: to Y: and X: to Q:
- Before migration to second cluster node we deleted OldQuorumDisk on second cluster node
- Tested Quorum migration between nodes

- At the end we removed LUN mapping for OldQuorumDisk

2) File server (with as little as possible downtime)
- We notified users about migration and scheduled maintenance date and hour.
- We added new cluster resource disk named NewFSDisk with drive letter X:
- Started synchronizing data between OldFSDisk (S:) and NewFSDisk (X:). We did this with RoboCopy (download) and Total Commander - Synchronize Dirs command. We repeated synchronization for a few days until the D-day.

- Made print-screens from resources in file server cluster group, just to be sure we don’t forget some settings later.
- On scheduled maintenance we stopped all File Server resource group resources except disks.
- We run file synchronization for the last time.
- We checked if number of files and size in bytes are exactly the same on both disks.
- Then we changed “Dependencies” and “Parameters” on “File Share” resource with new NewFSDisk (X:) value.
- We also checked and if necessary replaced with NewFSDisk (X:) value all other resources in this group.
- We stopped cluster resource OldFSDisk and deleted OldFSDisk from cluster resource.
- In Disk Management we changed drive letters of OldFSDisk S: to Y: and NewFSDisk X: to S:
- Then we needed to changed “Dependencies” and “Parameters” on “File Share” again to fit new lettering NewFSDisk (S:).
- We also checked and if necessary replaced with NewFSDisk (S:) value all other resources in this group.
- Before migration to second cluster node we also changed lettering there OldFSDisk S: to Y:
- After all this we started all resources, checked if file sharing is OK and then we tested cluster group migration to another cluster node.
- At the end we removed LUN mapping for OldFSDisk.

3) Print Server disk migration is almost the same as File Server disk migration
- We added new cluster resource disk named NewPSDisk with drive letter X:
- Made print-screens from resources in Print Server cluster group, just to be sure we don’t forget some settings later.
- We stopped all Print Server resource group resources except disks.
- Started synchronizing data between OldPSDisk (P:) and Print Server (X:).
- We checked if number of files and size in bytes are exactly the same on both disks.
- Then we changed “Dependencies” and “Parameters” on “Print Spooler” resource with new NewPSDisk (X:) value.
- We stopped cluster resource OldPSDisk and deleted OldPSDisk from cluster resource.
- In Disk Management we changed drive letters of OldPSDisk P: to Y: and NewPSDisk X: to P:
- Then we changed “Dependencies” and “Parameters” on “Print Spooler” resource with new NewPSDisk (P:) value.
- Before migration to second cluster node we also changed lettering there OldpsDisk P: to Y:
- After all this we started all resources, checked if Print Server is OK, printers are printing and then we tested cluster group migration to another cluster node.
- At the end we removed LUN mapping for OldFPSDisk.

At the same time we also migrated MS SQL Server cluster resource group and Domino server (Lotus Notes) cluster resource group to new disks.

So as you can see from this blog, changing SAN in MS clustered environment is not so hard as it seems. But in real, you’ll see ;)

In my next blog, part 2 of these series, I’ll describe how we did Physical to Virtual (P2V) migratin of MS clustered servers with VMware vCenter Converter Standalone Client.

I think this is enough for this one. Have fun :)