service guard Migration from Clariion to DMX and changing lock pv and lock VG to come fromDMXdatavgs

[sujit kumar singh]

systems are 2 node MCSG cluster running HPUX 11.23 and SG A.11.16

we have finished mirroring data from the existing clariion to new DMX.
lock pvs are currently coming from existing clariion

we shall be doing lvreduce to remove mirrors from existing clariion.
and after that reduce PVs from VGS coming from existing clariion.

what i am worried about is that i need also to change the lock pv and that has also from DMX.

i shall take the cluster down and
after that using cmquerycl cmcheckconf and cmapplyconf to have that new lock PV(from DMX) in configuration. but there is no dedictaed lock pv or lock VG here. and all disks have shall have production data.

just needed to ensure that once cmapplyconf is run to make a PV coming from DMX (which has production data in that) i do not end up overwriting the data on that while changing the lock disk.


regards
sujit

[Steven E. Protter]

Shalom sujit,

Under the circumstances, I would take the cluster down and do cmquerycl,cmcheckconf,cmapplyconf after changing to the new lock disk.

To do this hot may not be worth the trouble. System would need access to both disks at the same time.

SEP

[sujit kumar singh]

Hi SEP,

we shall be doing the queryck, checkconf as well as applyconf only halting the cluster.

i think i needed to be more clear.
say for example, i have present lock vg as /dev/vg01 and lock pv as /dev/dsk/c28t0d0.
c28t0d0 is from clariion.

this VG is also a part of a package and has production data on disk c28t0d0.

now i do lvextend to mirror the data of LV that has c28t0d0 to another PV that is c108t0d0 that is coming from DMX,


c108t0d0 is also presented and visible on the other node also.

after this i use lvreduce to remove the mirror extents of the LV fron c28t0d0 (clariion)

followed by

vgreduce/dev/vg01 /dev/dsk/c28t0d0 that is remove the disk from calriion from the VG vg01.

now VG vg01 has only c108t0d0 that is coming from DMX.


now i shall take down the cluster:

cmquerycl to generate new ascii file.

edit lock pv to point at c28t0d0
cmcheckconf ,
cmapplyconf


now as the lock pv comes on c1028t0d0, but that belongs to vg01, which is part of one of clusetr package Vgs and has data on it, are there chances that i shall end up loosing the data on c108t0d0 that is coming form DMX?



i shall ensure that the VG MAP files are properly scp-ed to the other node as well as import the VGs over there to refresh configurations, so that the VGS are identiacl in configration on both the nodes.

regards
sujit

[Steven E. Protter · Accepted solution]

Shalom again sujit,

>>
now as the lock pv comes on c1028t0d0, but that belongs to vg01, which is part of one of clusetr package Vgs and has data on it, are there chances that i shall end up loosing the data on c108t0d0 that is coming form DMX?
<<

Requirements for a cluster lock disk is it be visible to all nodes. In my production and hope SG setups, I stored data on a lock disk. There is no reason to leave the disk sit there empty.

I do not believe you will overwrite data.

There is no such thing as a local lock disk, as you describe it. A lock disk, must be on shared storage and visible to all nodes. There CAN be data on it.

SEP

[melvyn burnard]

when you makle a disk a cluster lock disk, it sets a bit in the Bad Block Relocation (BBR) area, and as thi sdoes not contain data, there is no problem doing what you wish to do.

[sujit kumar singh]

Thanks Melvyn and SEP. thanks i got the answers i was looking for...

thanks Forum AGAIN!!!

[sujit kumar singh]

Thanks Melvyn and SEP. thanks i got the answers i was looking for...

thanks Forum AGAIN!!!