Forum Discussion

Christian_Akess's avatar
Christian_Akess
Level 3
10 years ago

Migrating to a new SAN

We're in the process of moving to new datacenters. All servers will be moved over but the SAN won't. The SAN will be replicated to a new SAN in the new datacenters by our SAN admins. That means, the LUNs in the new SAN will be identical to the old, also the LUN numbers.

Example output from 'vxdisk list' on the current host shows:

c1t50050768014052E2d129s2 auto:cdsdisk    somedisk01  somedg online

This disk will get same LUN nr, but the target name will probably differ as it's new hardware in the new DC.

 

Will this work with Veritas SFHA? If not, is there any way to do this the way the datacenter project wants to?

If I could choose to do this my way, I would present the LUNs on the new SAN to my servers so that I could do a normal host based migration. Add the new LUN to the diskgroup and mirror the data, then remove the old LUN. However, I'm told that the hosts in the current datacenter won't be able to see the new SAN.

Backing Up
Best Practice
business continuity
Configuring
Installing
Managing Backup Devices
Recovering
Restore
Solaris
Storage Foundation
  • mikebounds's avatar
    mikebounds
    10 years ago

    What you are planning should work  but there will be some additional steps and the issue will not be that the target numbers are different, but that the UDID in the private region will not be the same as the UDID of the new luns and therefore your new LUNS will show up as uuid mismatch or clone devices.  

    This issue is easily overcome by running  vxdisk updateudid and vxdisk set clone=off before importing diskgroups - see http://www.symantec.com/docs/TECH204069 

    Mike

  • mikebounds's avatar
    mikebounds
    Level 6
    10 years ago

    What you are planning should work  but there will be some additional steps and the issue will not be that the target numbers are different, but that the UDID in the private region will not be the same as the UDID of the new luns and therefore your new LUNS will show up as uuid mismatch or clone devices.  

    This issue is easily overcome by running  vxdisk updateudid and vxdisk set clone=off before importing diskgroups - see http://www.symantec.com/docs/TECH204069 

    Mike

  • Christian_Akess's avatar
    Christian_Akess
    Level 3
    10 years ago

    Thanks for your reply. Your solution is how I usually do these tasks.

    The problem is that the servers in our current datacenters will not be able to see/connect to the new SAN fabric in our new datacenters. Our SAN admins will replicate the data from the old SAN to the new SAN, we will then move the hardware physically to the new datacenter and connect the servers to the new SAN.

    My question is if Veritas SFHA can handle this situation. The LUN numbering will be the same, but the node/port name will be different since it's new hardware in the new datacenter.

  • Marianne's avatar
    Marianne
    Level 6
    10 years ago

    My suggestion is to use VxVM to migrate the data:

    Add new LUNs to diskgroup, mirror all volumes, break off mirrors for old storage, remove disks from dg, remove from OS.

    All of this can be done while storage remains online in the cluster without the need to change anything in VCS.

    Some documentation:

    How to migrate data one storage array another storage array 
    http://www.symantec.com/docs/TECH66011 

    Migrating volumes from one storage array to another using a mirror (plex) 
    http://www.symantec.com/docs/HOWTO36625

    How to migrate volumes to new disk enclosures using Veritas Storage Foundation 
    http://www.symantec.com/docs/TECH207540

     

    Using VOM for migration: 
    https://www-secure.symantec.com/connect/videos/storage-provisioning-and-array-migration-vom-sf