Forum Discussion

posie80's avatar
posie80
Level 4
14 years ago

Seamless Veritas volume migration

Hi all,
I appreciate if any of you can offer me some advice on the following :

I have some Veritas volumes that are currently residing on local disks and I would to migrate these volumes to SAN.
Since these volumes are oracle data volumes and its almost impossible to get a downtime on the database instances using these volumes, I'd like to find a way (if possible) to migrate these volumes seamlessly  without any downtime/unmount/etc.

I'm not an expert with Storage foundation, but I did try to do the following :
1) Mirror the  local disk containing the diskgroups with the volumes with a SAN disk (new location)
2) Once mirroring completes, remove the local disk and let the SAN disk remain

Using this way, I was able to do the migration seamlessly. Unfortunately I discovered that I would have to migrate all volumes that are contained within the diskgroup that was mirrored, since all the volumes were 'sharing' the local disk. This is quite logical, however I do not want to migrate ALL volumes (I would like volume A and B to  migrate to SAN but volume C should stay on local disk).

Is there another way I could achieve this? My goal is to migrate volume A and B (residing on testdg diskgroup) to SAN, but not volume C (also on testdg diskgroup). And this migration must be seamless (no downtime or unmount of current filesystems).  The server is Solaris 9 and using Storage Foundation 5.0

Thanks!
Posie

  • Hello,

    What I said looks feasible .... you already have a mirror on oradata12 volume .... where first plex (oradata9-01) resides with c1t2d0 & second plex (oradata12-01) resides on c1t5d0 ...

    So here would be the precise steps:
    -- Make sure SAN disk is visible in  VxVM, also it should have size atleast equivalent to your volume size
    # vxdisk list

    -- If SAN disk is not initialized with VxVM , initialize it...
    # vxdisksetup -i <SAN_disk>               (default format would be cdsdisk)

    -- Add the SAN disk to diskgroup
    # vxdg -g  testdg adddisk  testdg03=<SAN_disk>

    -- Mirror the oradata12 volume
    # vxassist -g testdg mirror oradata12 <SAN_disk>

    -- check that sync in completed
    # vxtask list

    -- Verify from vxprint , you should see a new plex added to oradata12 volume...
    # vxprint -qthg testdg oradata12

    -- If above looks good, then go ahead & detach old plex
    # vxmend -g testdg off oradata9-01
    # vxplex -g testdg dis oradata9-01

    -- If you see vxprint command now, you should see plex oradata9-01 is disassociated... If looks OK, go & delete the plex
    # vxedit -g testdg -rf rm oradata9-1

    -- Repeat the previous two steps of another plex oradata12-01

    One more thing to notice, I see you have added a log plex, what was this log plex added for ? If it was DCO logs for snapshots, it would be advisable to move that also to SAN disk, also recommended to keep a mirror copy of log plex as well...

    Hope this helps..

    Gaurav

8 Replies


  • Hello

    If I understand this correctly, I think its possible ..... so for e.g you have a diskgroup called testdg which initially had 4 volumes for e.g  vol A, B C & D ... all the 4 lie on local disks...

    Now you wanted to migrate 2 of volumes to SAN lets say A & B ...

    Follow the steps which you mentioned above, i.e  mirror the A & B volumes using SAN disks.... once sync is complete, remove the old plex from local disk...

    now this leaves your diskgroup like A & B volumes are on SAN. C & D volumes on local disk ....  Is that OK ?

    Point here to note is, you are not mirroring disk, you have to mirror volumes .... you can do this by:
    # vxassist -g <diskgroup> mirror <vol> <san_disk>

    Check if sync in complete, using
    # vxtask list

    Once sync in complete, remove old plex (lying on local disk) from volume, to do this:

    # vxmend -g <diskgroup> off <plex-name>  --- offline plex from mirror
    # vxplex -g <diskgroup> dis <plex-name>   ---- Disassociate plex from volume
    # vxedit -g <diskgroup> -rf rm <plex-name>  --- delete the plex

    One thing to note here would be, you can't use this diskgroup in Cluster, because if diskgroup wants to failover to other node, it won't succeed since volumes on local disk will fail to import on other node..


    Gaurav



  • In addition to Gaurav's advice - please share diskgroup layout:
    vxprint -g <diskgroup> -htr

    Also see this TN: http://seer.entsupport.symantec.com/docs/316475.htm


  • Hi Gaurav and Marianne,
    Thank you for your advices! I will try Gaurav's suggestion and see whether thats possible in my case.

    Here is the vxprint output, let me know your comments?
    I would like to migrate only oradata12 volume and leave restore volume in its original place.

    vxprint output :
    -------------------

    DG NAME         NCONFIG      NLOG     MINORS   GROUP-ID
    ST NAME         STATE        DM_CNT   SPARE_CNT         APPVOL_CNT
    DM NAME         DEVICE       TYPE     PRIVLEN  PUBLEN   STATE
    RV NAME         RLINK_CNT    KSTATE   STATE    PRIMARY  DATAVOLS  SRL
    RL NAME         RVG          KSTATE   STATE    REM_HOST REM_DG    REM_RLNK
    CO NAME         CACHEVOL     KSTATE   STATE
    VT NAME         RVG          KSTATE   STATE    NVOLUME
    V  NAME         RVG/VSET/CO  KSTATE   STATE    LENGTH   READPOL   PREFPLEX UTYPE
    PL NAME         VOLUME       KSTATE   STATE    LENGTH   LAYOUT    NCOL/WID MODE
    SD NAME         PLEX         DISK     DISKOFFS LENGTH   [COL/]OFF DEVICE   MODE
    SV NAME         PLEX         VOLNAME  NVOLLAYR LENGTH   [COL/]OFF AM/NM    MODE
    SC NAME         PLEX         CACHE    DISKOFFS LENGTH   [COL/]OFF DEVICE   MODE
    DC NAME         PARENTVOL    LOGVOL
    SP NAME         SNAPVOL      DCO
    EX NAME         ASSOC        VC                       PERMS    MODE     STATE
    SR NAME         KSTATE
    dg testdg       default      default  22000    1124862954.47.server1
    dm testdg01     c1t2d0s2     auto     2048     143347008 -
    dm testdg02     c1t5d0s2     auto     2048     143347008 -
    v  oradata12    -            ENABLED  ACTIVE   104857600 SELECT   -        fsgen
    pl oradata9-01  oradata12    ENABLED  ACTIVE   104857600 CONCAT   -        RW
    sd testdg01-01  oradata9-01  testdg01 1056     104857600 0        c1t2d0   ENA
    pl oradata9-03  oradata12    ENABLED  ACTIVE   LOGONLY  CONCAT    -        RW
    sd testdg01-02  oradata9-03  testdg01 0        1056     LOG       c1t2d0   ENA
    pl oradata12-01 oradata12    ENABLED  ACTIVE   104857600 CONCAT   -        RW
    sd testdg02-01  oradata12-01 testdg02 0        104857600 0        c1t5d0   ENA
    v  restore      -            ENABLED  ACTIVE   76976128 SELECT    -        fsgen
    pl restore-01   restore      ENABLED  ACTIVE   76976128 CONCAT    -        RW
    sd testdg01-03  restore-01   testdg01 104858656 38488352 0        c1t2d0   ENA
    sd testdg02-02  restore-01   testdg02 104857600 38487776 38488352 c1t5d0   ENA
     

  • Hello,

    What I said looks feasible .... you already have a mirror on oradata12 volume .... where first plex (oradata9-01) resides with c1t2d0 & second plex (oradata12-01) resides on c1t5d0 ...

    So here would be the precise steps:
    -- Make sure SAN disk is visible in  VxVM, also it should have size atleast equivalent to your volume size
    # vxdisk list

    -- If SAN disk is not initialized with VxVM , initialize it...
    # vxdisksetup -i <SAN_disk>               (default format would be cdsdisk)

    -- Add the SAN disk to diskgroup
    # vxdg -g  testdg adddisk  testdg03=<SAN_disk>

    -- Mirror the oradata12 volume
    # vxassist -g testdg mirror oradata12 <SAN_disk>

    -- check that sync in completed
    # vxtask list

    -- Verify from vxprint , you should see a new plex added to oradata12 volume...
    # vxprint -qthg testdg oradata12

    -- If above looks good, then go ahead & detach old plex
    # vxmend -g testdg off oradata9-01
    # vxplex -g testdg dis oradata9-01

    -- If you see vxprint command now, you should see plex oradata9-01 is disassociated... If looks OK, go & delete the plex
    # vxedit -g testdg -rf rm oradata9-1

    -- Repeat the previous two steps of another plex oradata12-01

    One more thing to notice, I see you have added a log plex, what was this log plex added for ? If it was DCO logs for snapshots, it would be advisable to move that also to SAN disk, also recommended to keep a mirror copy of log plex as well...

    Hope this helps..

    Gaurav
  • Hi Gaurav,
    Wow, thats very much for the detailed steps!!

    I've simulated the same on a test server and confirmed that it was indeed feasible as you mentioned. Perfect!

    The log plex was added previously by somebody else and I *think* it was DCO logs for snapshot (is there any way to make sure this is the case?). I will move this log plex also to SAN and create a mirror copy as you suggested.

    Thanks again for your excellent guide,

    - Posie
  • Glad to have helped...

    You can use following command to find the log type..

    # vxprint -g testdg -mvphsr |grep -i log_type


    Gaurav
  • I see, thanks!
    I ran the command and saw the log types are all REGION.  In this case, do you think its worthwhile to move it to SAN and create a mirror copy of it?

    Thanks,
    Posie

  • It looks to be DRL...

    About DRL:

    Dirty region logging (DRL), if enabled, speeds recovery of mirrored volumes after a system crash. DRL keeps track of the regions that have changed due to I/ O writes to a mirrored volume. DRL uses this information to recover only those portions of the volume that need to be recovered.
    If DRL is not used and a system failure occurs, all mirrors of the volumes must be restored to a consistent state. Restoration is done by copying the full contents of the volume between its mirrors. This process can be lengthy and I/O intensive. It may also be necessary to recover the areas of volumes that are already consistent.

    Since you would be migrating the volume to SAN, I would recommend to move log to SAN only.. See VxVM admin guide for more details..

    Gaurav