Failover Clustering and Network Load Balancing Team Blog
Hi Cluster Fans,
Windows Server 2008 R2 has been our most popular release by far, with quick adoption for some of the great new features like Cluster Shared Volumes, PowerShell and live migration. With all the hype, I’ve been seeing a lot of questions about migration, which is our way to move to the 2008 R2 Failover Clustering platform. This week I wanted to tell you about a little-known migration trick which allows you to tell if a resource has been migrated or gives you the ability to perform custom actions on a newly migrated resource.
Migration using the ‘Migrate a Cluster’ Wizard is our way to move resource groups from a Failover Cluster running Windows Server 2003, Windows Server 2008 or Windows Server 2008 R2 to Windows Server 2008 R2. Details and a step-by-step guide can be found here: http://technet.microsoft.com/en-us/library/ff182314(WS.10).aspx
We support migration for most in-box workloads, however DFS-Replication, Exchange, Hyper-V, Print and SQL all have their cluster-aware migration utilities, which can be found here: http://technet.microsoft.com/en-us/library/ee791924(WS.10).aspx.
You should note that Server Migration, the Server Manager utility, does not support clustering, so it should not be considered in a cluster migration.
The easiest way to tell if a cluster resource has been migrated is to look in the registry at the cluster resource information. If a group has been migrated, the resource will have an extra registry key added to it. We created this key as some groups need a one-time setup operation performed, since migration tends to be performed infrequently. This flag allows you to realize that a group has been migrated, take actions on that group, then reset the key so that the actions are only performed once.
I opened RegEdit and browsed to HKLM\Cluster\Resources and found a regular File Server which was created on my new 2008 R2 cluster. I see the following four fields:
If I look at another File Server resource which was created on my old 2008 cluster, and migrated to this cluster, I see five fields, including a new Migrated entry.
For a migrated resource this will be set to 1 unless the user changes it back to zero or deletes it. You will only see the Migrated entry on resources which were migrated to the 2008 R2 cluster using the Migrate a Cluster Wizard.
Migration may not always be perfect as there can be manual steps, generally when moving the data on the SAN to the new cluster. The Migrate a Cluster Wizard will give you both a pre- and post-migration report telling you what was expected to happen, what happened, if any resources were renamed and any manual steps you need to perform. You should always review these reports when performing a migration, and the post-migration reports are automatically saved for you in your C:\Windows\Cluster\Reports folder. If you do not want to browse through the migration reports to figure out if a resource had been migrated, you can open up RegEdit. Browsing to the cluster resource section and checking for the Migrated registry key can help you quickly determine that this group was migrated, which may help you troubleshoot the problem.
I’ve seen some customers that want to automatically trigger an event after they have migrated a resource. This may include sending a notification to an administrator, delaying the resource from onlining or automatically deleting that resource from the source cluster. I strongly recommend that you test your migration first to be very sure it will succeed before doing anything which impacts your in-production groups.
Some admins will run a script in the background which crawls the cluster registry settings every 15 minutes. It specifically looks at all the resources checking for the Migrated = 1. If it finds a resource with that setting it will trigger an event which writes information about the resource and the disk it is using into an email and sends it to the IT department so they can better track their storage usage. The script then set Migrated = 0 so that the script only executes this event once.
Other customers will want to prevent a migrated resource from coming online until an admin has looked at it to make some customizations. This can be a problem for customers who use a monitoring service like System Center to try to automatically online any offline resources. However, you can add a clause to the online script which would ignore the resource if Migrated = 1. After the admin make their changes they could set Migrated = 0, so that the resource could online automatically in the future. Generally you would not need to worry about both the old and new groups being online at the same time since both have the same Network Name, so they would conflict and the one which is offline would be unable to come online.
There are users who are confident in their automation, so they set it to clean up their old cluster by deleting their migrated resource, allowing their newly migrated resource to immediately come online while avoiding the Network Name conflict. They monitor the cluster events and look for any onlining attempt events. When they see that a resource with Migrated = 1 is trying to come online they execute a script which waits for the online attempts to all fail, then takes the resource and resource group information and parses that to map the group to the currently online resources on the source cluster. The script then offlines the source cluster’s resource group and re-masks the LUNs from the old cluster to the new cluster so the new group can access the data. It resets Migrated = 0 so that it won’t trigger these events again. The script will then online the newly migrated group successfully and check the data can be accessed, and finally the script will delete that resource group on the old cluster.
I’d be interested in hearing how you have used the Migrated flag in different ways on your cluster. Click the email link in the upper-right corner of the page to send an email.
Program Manager IIClustering & High-Availability