Array Migration using VxVM on Solaris VCS cluster

Answers inline:

The existing volumes have two plexes, one from each data centre each with one sub disk. Will vxassist automatically create the plex, attach it to the volume and start mirroring? Am I ok to repeat this command twice with different objects to get both new mirrors sync'ing at the same time?

--- yes, vxvm will automatically create the plex & start mirroring, you can view the progress in "vxtask list" output ....

-- Yes, multiple commands would be ok but the more you trigger, you are giving more job to vxconfigd so expect some degradation to mirroring & performance .... I usually practice to keep max of 5 sync at the same time  (my view) ...

From rest of the steps:

- check two new plex attached to testvol (vxprint -qthg testdg testvol)
- check sync state compleeted (vxtask list)
- Disassocaite EVA plex when sync state completed (vxmend -g testdg off testvol-01; vxplex -g testdg dis testvol-01)

- Delete EVA plex (vxedit -g testdg -rf rm testvol-01)

------------->> For safety, take a diskgroup backup here (take backup of /etc/vx/cbr/bk/ directory to some other location)

---------------->> Add a step here to remove the disk from diskgroup ....

# vxdg -g <diskgroup> rmdisk <disk>

Unmask EVA storage and cleanup using cfgadm on both nodes
- Take second channel from active node and plug to SAN fabric 2

 

 

VEA can do most of the job but would be difficult to explain, I would prefer to stick to command line ..

good luck

 

Gaurav

THanks. I've been able to get an export of some of the vxprint from one of the clusters and it seems they've possibly been configured using layered volumes.

What do I need to check on this layout and which volume do I add the plexes to?

For example in the VEA GUI I see only one volume relating to oarch01vol but fron a vxprint I see what I think is a layered volume.

vxprint
TY NAME          ASSOC   KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
dg db01dg      db01dg   -        -        -        -        -       -
dm dm1oarch01    c0t2d0s2  -        52360448 -        -        -       -
dm dm2oarch01    c0t3d0s2  -        52360448 -        -        -       -

v  oarch01vol  fsgen   ENABLED  52359168 -        ACTIVE   -       -
pl oarch01vol-03 oarch01vol  ENABLED  52359168 -    ACTIVE   -       -
sv oarch01vol-S01 oarch01vol-03  ENABLED  52359168 0    -        -       -

v  oarch01vol-L01 fsgen   ENABLED  52359168 -        ACTIVE   -       -
pl oarch01vol-P01  oarch01vol-L01 ENABLED  52359168 -     ACTIVE   -       -
sd dm1oarch01-02  oarch01vol-P01 ENABLED  52359168 0        -        -       -
pl oarch01vol-P02 oarch01vol-L01 ENABLED  52359168 -     ACTIVE   -       -
sd dm2oarch01-02 oarch01vol-P02 ENABLED  52359168 0        -        -       -

Thanks in advance.

 

In above case, actual volume is oarch01vol only ... rest are subvolumes & its components (L-01 /P01 etc)...

I would expect that this volume is played around in past ... if I see the size above, its completely a mirror only .. each & every component is of same size ...

Also, interestingly, only 1 disk is used in above structure .... i.e dm1oarch01 ... other disk dm1oarch02 is not at all used ...

You can think of an alternative to "relayout" this volume into a simple structure & then proceed with your plan ... see man page for "vxrelayout"

https://sort.symantec.com/public/documents/sf/5.0/solaris/manpages/vxvm/vxrelayout_1m.html

 

G

Without having to go through a relayout before the migration could I use the same process and add the new plexes to the oarch01vol-L01 volume, sync them up and drop the old ones? I'm under pressure to carry this out at the weekend so want to avoid another step if possible.

What would I issue as a relayout?

Ta,

Sarah.

After you remove the old disks from Veritas control (some suggest inserting "vxdiskunsetup -C emcpowerxx" before the vxdisk rm) and unmask them from being seen by the server, you will need to run "powermt check."  It will answer with messages about the dead paths, and ask whether you want to remove them from PowerPath.  Say yes, of course.  If it tells you it can't remove the paths because the device is in use, there is probably some leftover Veritas association.  This is not a showstopper and, if you're trying to get this done in an outage window, I would simply move on.  It will, however, prevent you from cleaning up the old entries via cfgadm, devfsadm, or luxadm, so your messages file will be a little more crowded going forward.

Also, you say you are using native Sun HBA drivers, and then you mention rescanning with the QLogic driver - if you mean you're using the Leadville stack, which I assume you are since you include extensive use of cfgadm, you shouldn't need to rescan with any QLogic utility.

Oh, if you have any trouble finding the vxdiskunsetup command, it's under /etc/vx/bin.

Hope this helps!

David