AIX

Hi All,
I have a vg that consists of 2 physical disks (PV), To migrate the vg into these 2 new disks (presented from different SAN Storage), I use the mirrorvg command, but I am not sure the command I use is correct.

Code:

 hdisk1  appvg
 hdisk2  appvg
 hdisk3  none    
 hdisk4  none

  mirrorvg appvg hdisk3 hdisk4

Could someone assists me to verify this ? logically it will automatically distribute the source to target disks accordingly.

Thanks

Hi All,
I have a db2 DPF database running in active/active using HACMP.
Would like to migrate the vol into different hdisk using mirrorvg. But I understand that HACMP require to use its own mirror method to mirrorvg not AIX mirrorvg command.

Could someone share the steps to perform the HACMP mirrorvg ?

Thanks.

Close, but not quite:

First, use extendvg <VG> <hdisk> to add the disk(s) to the VG. You can only mirror to disks already present in the VG.

Second: use the command you suggested. Note, however, that you have to watch out for some gotchas:

You may need to change the quorum of the VG. The quorum is the number of PVs needed to be available for a varyonvg to succeed. Additional restrictions apply if the VG is part of a resource group in a HA-cluster, but i suggest you do NOT try to configure such a cluster if you have no firm grasp of AIX concepts. Do yourself a favor and hire an expert for such a task or - if you have enough time for this - first learn AIX/HACMP concepts to the point where you are familiar with these. It's like driving a car: in principle not too complicated, but try to do it without training and you are likely to cause some damage. There are a lot of valuable resources for this (i suggest reading the freely available "IBM Redbooks", which can be downloaded in PDF-format) but you need to get familiar with these first, everything else is asking for trouble.

Basically, the LVM works like this: you have "physical volumes" (PVs), which are logical disks. Each PV is member of one and only one VG. Upon adding the disk to the VG (by which it becomes a PV) it is chopped into small pieces (PPs - "physical partitions") and these pieces can be added to "logical volumes" (LVs). Onto LVs filesystems or all other sorts of things can be put: swap devices, JFSlog devices, ... .

In principle these LVs consist of "logical partitions" (LPs), which are the same size as PPs. Every LP is represented by one PP. In case of mirroring you have a 2:1 ratio and every LP is represented by 2 (or even 3) different PPs, each with the same content. Mirroring is done on LV level and you can have mirrored alongside unmirrored LVs within the same VG. A mirrorvg command just executed the mirror process for each LV automatically.

Also in principle, PPs are anonymous and you do not have to care from which disk (PV) they come from. However, the selection process for allocation as well as mirroring can be influenced (i.e. allow/forbid all copies of a LP to be on the same disk) in the LV properties ("Intra-policy" and "Inter-policy", quite a poor choice of naming).

Now, this was a (very very short) introduction to LVM concepts, but it probably left more questions than it provided answers. For LVM too there is a redbook which i suggest you read.

I hope this helps.

bakunin

Hello to answer the question of your 1st post,
Make sure the disk attributes are set same as existing PVs
1st you need to extend the vg

Code:

extendvg appvg hdisk3 hdisk4
mirrorvg appvg hdisk3 hdisk4  (also you can use -S flag to sync in the background)

Answer to 2nd post
To the best of my knowledge HACMP is active/passive, never worked on PowerMirror7.1, and not sure if it has active/active feature.

If I am not mistaken you will find it in C-SPOC feature with in HACMP, currently I have no cluster(s) to exactly point where you can do so.

Moreover I don't remember doing a mirrorvg from HACMP.


I hope this helps.

HACMP (all versions, regardless of their name) have "rotating" and "cascading" resource groups.

"rotating" is active/passive: NodeA has RgA, NodeB is passive, you can switch this state, but the other node will be passive in this case.

"cascading" is active/active: NodeA has RgA, NodeB has RgB, if NodeB fails, nothing happens, if NodeA fails then NodeB will take over RgA and either shut down RgB or not.

The latter setup is for instance used in SAP setups, where you run production on one system and Test/Development on the other. Prod is HA, Test/Dev is not. Of course all this is possible with more than two nodes too, adding more complexity.

I hope this helps.

bakunin

About the First post, AIX gurus there, could migratepv be an alternative (because the thread owner is talking of migrating PVs...)? (just adding some salt...) then I suppose the next step would have been to remove the old PVs...

Yes, migratepv would work, but it is easier to do the mirroring in one run, then remove the mirror in a second run. Doing it with "migratepv" is more hassle.

You are right about removing the old PVs afterwards if you want to do a migration. When i wrote my first answer i got somewhat carried away and forgot the last part:

after mirroring the whole volume (check with lsvg -l <VG>, all LVs have to be in status "syncd". Depending on sizes and SAN speed this may take some while.) use "unmirrorvg" to remove the copies residing on the old disks.

Lastly, when this is done and the disks are indeed free, use reducevg to remove the old disks from the VG.

Finally you might use rmdev -dl <hdiskN> to remove the disk devices, unattach the LUNs from the system and then run cfgmgr again to update the configuration.

I hope this helps.

bakunin