How to migrate running cluster from existing two node.

[danand]

HI ,

We have a two node Windows cluster  running on windows 2003 standard edition.Heartbeat connected by a cross over cable.we are planning to do a refresh to existing hardware .Please suggest what is the best way to migrate the running cluster from existing two nodes ( running windows 2003 ) to two new nodes ( that will be now installed with Windows 2008 Standard edition)..

Your prompt reply will be much appreciated.

Regards

Deepak

[Marianne]

What is your existing SFW/HA version? (Assuming you are using VCS?)

Are you also intending to install newer SFW/HA software on new hardware?

What are you clustering on existing 2-node cluster? Are you going to install newer version of application software on new servers?

[danand]

Existing version is 5.1 SP2( its a file share cluster)

If installing a new version on new servers requires less down time then we will got with it

Regards

Deepak

[Wally_Heim]

Hi Deepak,

What are you clustering?  The application being clustered might alter your transition steps.

Thanks,

Wally

[Marianne]

Deepak, just a File Server cluster and no database or application?

I would approach the migration as follows:

Prepare the new nodes with new hostnames, install and configure SFW/HA 5.1 SP2.  Check multipathing software on existing cluster and ensure that it is installed on new nodes. If you are using MPIO with SF DSM, ensure that Windows 2008 MPIO is installed before you start SFW/HA installation.

Make a note of all existing configuration/resource attributes for the Fileshare Service Group (can be found in %VCS_HOME%\conf\config\main.cf ).

Offline the Service Group on the existing cluster.

Zone the current shared disks for the existing cluster to the new nodes. Ensure that the disks are visible at OS level and in SF GUI.

Use the wizard to create a new Service Group. Please see this article:
https://www-secure.symantec.com/connect/articles/creating-fileshare-cluster-using-veritas-storage-foundation-51-windows-high-availability

Skip the steps to create the diskgroup and volume(s), just import and mount them to the same drive letters /paths as the original cluster.

Skip to page 12 to start the initial cluster config wizard.

The file-share wizard is described from p. 27 onwards.  Provide resource attributes same as original cluster when prompted in the wizard.

Be sure to use the SAME virtual IP address and hostname as on the old cluster to ensure that users can access fileshares as before.

If all of this is planned carefully, you should be able to have the fileshare(s) on the new cluster up and running in less than 30 minutes.

Your failback/back-out will be reverting to old cluster nodes.

If you are confident with copying Service Group definition from old main.cf, you should be able to switch to new cluster in even shorter time. Don't try this if you haven't had any hands-on experience in a training class or in a lab.

WALLY - please check and see if you agree. Any suggestions from your side will be appreciated.

[Wally_Heim]

Hi Marianne and Deepak,

My only concerns is that Deepak mentioned using "existing hardware".  Does this mean that you are going to use the same hardware as the current 2 node cluster? Or does it mean that you are going to use different hardware that you already have in your environment that is different than the two node cluster is currently using?

Marianne's steps are right on track if you are using new hardware that is different than the existing cluster.

If using the same hardware, AKA reinstalling the OS on them, then please backup the cluster configuration files first.  You can use hasnap or hagetcf commands or just copy the main.cf file (gets your service group configuration.) Then build the cluster based on Marianne's guidelines.  This method does not offer any failback to a known good if something goes wrong.  Because of this I typically don't recommending this approach to customers unless there is no other options.  You might be better off doing a phased transition working with one node at a time.

Thanks,

Wally

[Marianne]

I see the 'existing hardware' in original post. I got stuck on "from existing two nodes .... to two new nodes".

Deepak should be helping us here - two new servers (new hardware, new OS) using existing storage? Or exsting servers to be upgraded/reinstalled with new OS?

[danand]

Hello All,

First of all I would like to thank you for your recommendation.These are really valuable for me.

Let me clear some doubt over here.

1. We want to move cluster configuration from two old servers to two new servers.Later on will be decommissioning the old servers.

2. Old servers are running with Windows 2003 Std edition 32 bit , new servers will be running with Win 2008 Std edition 32 bit .Pls let us know if this is going to cause some issue while doing migration.

I have some doubt so pls help me out here.

1.  Once we install Os , SF HA SP2 and HP MPIO software on new servers and Zone the storage from old to new and then copy the main.cf from old cluster to new one ( both nodes) will it automatically recognize my Dynamic disk and volumes or I have to manually create the dynamic disk with same name and volumes and assign the drvie letters manually.

2.  Is there any way I can skip the SG creating part and copy the configuation setup /Registry from old servers to new one(because we have lot of file service SG.)I know it will require some changes in configuration file.If you can guide me over here it would be really helpful.

We are Migrating the cluster for first time to pls excuse me If I am asking some silly question.

With Best Regards

Deepak

[Wally_Heim · Accepted solution]

Hi Deepak,

Thank you for clearing up what you are trying to do.  It helps us to better provide you steps for your specific situation.

Here are the answers to your questions 1 and 2.

1.  Yes, once you zone the disks to be seen by the new servers the diskgroup and volume configuration will be visable by the new nodes.  The disk group configuration is stored on the disks themselves and not on the nodes directly.  There are some gothas with this but they are minor.  If you are using SCSI 2 reservations then the disk group will need to be deported on the old server and a rescan performed on the new servers in order to see the disks group(s).  If you are using SCSI3 reservations then the disk group config will be visable on the new nodes with just a rescan after the zoning operations are done.

2. Yes you can copy the service group configuration to the new cluster as long as you modify it first.  The service group configuration is stored in the main.cf on the old cluster nodes.  You should copy only the service group configuration to a temp text file.  Then you will need to do a few find and replace operations and you should be good.  You will need to replace the server names from the older cluster with the server names in the new cluster.  You will also need to change out the MAC addresses in the IP and NIC resources so that they use the MACs from the new nodes.  Then just stop the cluster on all of the new nodes "hastop -all", copy the modified service group configuration to the bottom of the main.cf of all nodes (you can do it with just one node but trust me do it to all of them) and restart the cluster using "hastart -all".  Then it is just a matter of starting the service group (if it did not auto start.)

You can zone the disks to all 4 servers and leave them that way to a quick backup plan if things go wrong with the new cluster.  I would recommend that you set the old cluster to not auto start the service group when you switch over to the new cluster. 

If you want to copy the service group configuration over before your actual cut over time, then don't forget to turn off the autostart of the service group on the new cluster.  Then switch which cluster auto starts the service group on your cut over date.

Keep in mind that if you have any problems or questions, please contact Symantec Technical Support and open a support case.  We will assist you with getting your service group moved over and ensure that you have minimal downtime.  And for most customer support contracts we are available 24x7x365.

Thanks,

Wally

[danand]

Thanks a lot Wally , Your suggestion are  really valuable to me.

Regards

Deepak