Forum Discussion

Jimb2k's avatar
Jimb2k
Level 4
10 years ago

Migration of VCS Cluster to new servers

Hello,

I have a two nodes veritas cluster with SQL & file shares ressources.

The goal is to migrate the data and ressources to a new servers.

How can I create first a standalone node and trasport the data and configuration of the cluster.

And recreate the cluster as the original one.

Thank you in advance for your help.

 

  • Hello Jim,

    I believe the steps what I gave are still valid only change is now you would go with setup of single node..

    1. Setup OS, Storage Foundation High Availability, SQL etc on one node. You would need to make sure all the applications & dependency packages are installed on new machine.

    2. Once VCS run is tested on new node (as single node cluster), shut the cluster component down in new server.

    3. Copy of all the data from old cluster shared storage & ship it to new shared storage. Make sure you create similar filesystems so that cluster configuration can be straight away imported. If drive configurations or application directories are changing, VCS configuration will need to modified as well.

    4.Once shared storage on new setup is ready with all data copied. Copy VCS configuration files from old cluster to new cluster

    /etc/VRTSvcs/conf/config/main.cf

    /etc/VRTSvcs/conf/config/types.cf

    /etc/llttab   (ONLY if any specific tunables are configured, else leave this file)

    5. Once all the above files are copied, shutdown the cluster in old machines. Ensure all the IP addresses used are removed so that no IP conflict happens.

    6. Start the cluster on new single node (hastart -oneenode). This should start the cluster on new server as single node cluster using the data from shared storage.

    7. Post a successful run, you can setup 2nd node & join the cluster with VCS.

    Let me know if any doubts ..


    G

  • I think steps are:

    1. Agree with Gaurav, that Setup OS, Storage Foundation High Availability, SQL and better to start off with a 1-node to 1-node GCO cluster (or a 2-node RDC) rather than adding later.  But you need to think about what name to install SQL as so doesn't conflict with existing cluster - a few things you could try:
      a. Use same SQL server name, but use a local host entry to use a different IP
      b. Isolate new cluster on the network
      c. The SQL install procecure in a cluster used to be to change the virtual name as the last step by running an SQL command to delete physical node name and add virtual name so you may be able to use a temporary name and change to real name when you go live
       
    2. How you configure VCS depends on how comfortable you are editing main.cf and how wizard driven current SQL installation is.  I haven't setup an SQL cluster since 5.x and then you could create main.cf manually rather than using wizards which was the better option when creating mulitple instances as you could create first one using wizard and then just copy main.cf entries for subsequent instances.  So personally I would copy main.cf entries from old cluster to new cluster rather than re-running wizard, but do which ever you feel more comfortable doing.
      Note also the main.cf will be different as you will now be using array based replication so you will need to consult SnapMirror agent docs together with SQL solutions guide for DR
       
    3. For migrating storage from old SAN to new SAN, then you can copy data or backup and restore if downtime is not an issue, or you could install a temporary VVR licence and use replication over IP and remove VVR once migration is complete if you need as little down time as possible

    For the migration I would do a test run first - so do a hotbackup and restore to new cluster and then test failing over etc.

    Mike

     

     

  • Hello,

    I am little unclear, are you saying you want to temporary move the cluster to standalone node, allow it to run there till you upgrade servers, once done restore the configuration ?  OR  you have 2 brand new nodes, you want to migrate entire VCS cluster to these 2 new nodes ?

    Do you have shared storage connected to both the new & old servers ?


    G

  • Sorry for been unclear.

    I have two new brand servers and I want to migrate the cluster configuration and data to them.

    There are on other storage array, so for that I ask which mecanism I need to use.

    I want to start with one standalone server to hold all ressources, and then add the second to the cluster.

    Thank you again

  • Ok, its much clear now .. can you also mention windows & VCS versions in your current environment ?

    So again, first question would be, can you have same shared storage between old & new servers ? or they are geographically apart ? If they are apart, do you have new array with new servers which can replicate to old array ? If this is possible, lot of time & effort can be saved.

    If this is not possible, I would think of following high level steps ..

    1. Setup OS, Storage Foundation High Availability, SQL etc on new cluster. This would be better to create 2 nodes at one go as it will save time for cluster join later on. If you have VCS setup on new cluster, it will be easy to change configuration parameters in new cluster. You would need to make sure all the applications & dependency packages are installed on new machines.

    2. Once VCS run is tested on new cluster, shut the cluster down in new servers.

    3. Copy of all the data from old cluster shared storage & ship it to new shared storage. Make sure you create similar filesystems so that cluster configuration can be straight away imported. If drive configurations or application directories are changing, VCS configuration will need to modified as well.

    4.Once shared storage on new setup is ready with all data copied. Copy VCS configuration files from old cluster to new cluster

    /etc/VRTSvcs/conf/config/main.cf

    /etc/VRTSvcs/conf/config/types.cf

    /etc/llttab   (ONLY if any specific tunables are configured, else leave this file)

    5. Once all the above files are copied, shutdown the cluster in old machines. Ensure all the IP addresses used are removed so that no IP conflict happens.

    6. Start the cluster on new nodes.

    these are very high level steps, there might be finer details which may be required based on environment.

     

    G

  • Thank you Gaurav for you repley.

     

    VCS version : 6.0.02

    Windows Version : Windows 2012 Standard

    Volume Storage Manager : 6.0.2

     

    The goal is to go from our old cluster to a new Geo-Cluster.

    So First I'll create a first node on the first site, after I want to copy the data and ressources and configuration from the old cluster to this standalone node.

    Finally I'll create the second node on the other site, and join it the new cluster.

    So how can I do that, and what's the required steps.

    Thank you again.

     

  • A few questions:

    1. Is the first node of new cluster on the same site and same subnet as the old cluster and will it use the same virtual IPs
    2. Is the new SAN for the first node of new cluster connected to the old cluster and if not can it be SAN connected
    3. Is the 2nd node of the new cluster in the same subnet as the 1st node
    4. How far apart are the nodes in the new cluster and what do you intend to use to replicate the storage between sites (example VVR or SRDF)

    Mike

  • Thank you mike, my answers below :

    1. Is the first node of new cluster on the same site and same subnet as the old cluster and will it use the same virtual IPs --> YES
    2. Is the new SAN for the first node of new cluster connected to the old cluster and if not can it be SAN connected --> NO, There is no connection between the old SAN arrays and new ones.
    3. Is the 2nd node of the new cluster in the same subnet as the 1st node --> YES
    4. How far apart are the nodes in the new cluster and what do you intend to use to replicate the storage between sites (example VVR or SRDF) --> I think around 50KM, And the storage replication they will use arrays replication like SnapMirror
  • Hello Jim,

    I believe the steps what I gave are still valid only change is now you would go with setup of single node..

    1. Setup OS, Storage Foundation High Availability, SQL etc on one node. You would need to make sure all the applications & dependency packages are installed on new machine.

    2. Once VCS run is tested on new node (as single node cluster), shut the cluster component down in new server.

    3. Copy of all the data from old cluster shared storage & ship it to new shared storage. Make sure you create similar filesystems so that cluster configuration can be straight away imported. If drive configurations or application directories are changing, VCS configuration will need to modified as well.

    4.Once shared storage on new setup is ready with all data copied. Copy VCS configuration files from old cluster to new cluster

    /etc/VRTSvcs/conf/config/main.cf

    /etc/VRTSvcs/conf/config/types.cf

    /etc/llttab   (ONLY if any specific tunables are configured, else leave this file)

    5. Once all the above files are copied, shutdown the cluster in old machines. Ensure all the IP addresses used are removed so that no IP conflict happens.

    6. Start the cluster on new single node (hastart -oneenode). This should start the cluster on new server as single node cluster using the data from shared storage.

    7. Post a successful run, you can setup 2nd node & join the cluster with VCS.

    Let me know if any doubts ..


    G

  • Thank you Gauvar,

    I'll test that before, and tell you after if I'll face any problems.

    Thank all of you guys. (You rock)

  • I think steps are:

    1. Agree with Gaurav, that Setup OS, Storage Foundation High Availability, SQL and better to start off with a 1-node to 1-node GCO cluster (or a 2-node RDC) rather than adding later.  But you need to think about what name to install SQL as so doesn't conflict with existing cluster - a few things you could try:
      a. Use same SQL server name, but use a local host entry to use a different IP
      b. Isolate new cluster on the network
      c. The SQL install procecure in a cluster used to be to change the virtual name as the last step by running an SQL command to delete physical node name and add virtual name so you may be able to use a temporary name and change to real name when you go live
       
    2. How you configure VCS depends on how comfortable you are editing main.cf and how wizard driven current SQL installation is.  I haven't setup an SQL cluster since 5.x and then you could create main.cf manually rather than using wizards which was the better option when creating mulitple instances as you could create first one using wizard and then just copy main.cf entries for subsequent instances.  So personally I would copy main.cf entries from old cluster to new cluster rather than re-running wizard, but do which ever you feel more comfortable doing.
      Note also the main.cf will be different as you will now be using array based replication so you will need to consult SnapMirror agent docs together with SQL solutions guide for DR
       
    3. For migrating storage from old SAN to new SAN, then you can copy data or backup and restore if downtime is not an issue, or you could install a temporary VVR licence and use replication over IP and remove VVR once migration is complete if you need as little down time as possible

    For the migration I would do a test run first - so do a hotbackup and restore to new cluster and then test failing over etc.

    Mike