Re: Updating VGs that are part of a cluster

It may not be documented at your ML level. It is on mine, but, we are
bleeding edge ;)

John T Mills

-LVolumeGroup
Takes a volume group and learns about possible changes
performed to that volume group. Any new logical volumes created as a
result of this command emulate the ownership, group
identification, and permissions of the /dev special file for
the volume group listed in the -y flag. The -L flag performs the
functional equivalent of the -F and -n flags during
execution.

-F
Provides a fast version of importvg that checks the Volume
Group Descriptor Areas of only the disks that are members of the same
volume group. As a result, if a user exercises this
flag, they must ensure that all physical volumes in the
volume group are in a good and known state. If this flag is used on a
volume group where a disk may be in missing or removed
state, the command may fail or the results may be
inconsistent.
-n
Causes the volume not to be varied at the completion of the
volume group import into the system.



________________________________

From: IBM AIX Discussion List [mailto:aix-l@xxxxxxxxxxxxx] On Behalf Of
Sunder Iyengar
Sent: Tuesday, March 18, 2008 10:49 PM
To: aix-l@xxxxxxxxxxxxx
Subject: Re: Updating VGs that are part of a cluster



Frank,



I asked the last question since the importvg command with -L option does
not complain (as in, invalid option). It does work so I thought maybe -L
is some funky undocumented option!



Thanks,



Sunder.



From: IBM AIX Discussion List [mailto:aix-l@xxxxxxxxxxxxx] On Behalf Of
F. Even
Sent: Wednesday, 19 March 2008 1:48 PM
To: aix-l@xxxxxxxxxxxxx
Subject: Re: Updating VGs that are part of a cluster



Thought I'd replied (must not have made it through yet). Sorry...that
was a typo of mine.

Primary:
varyonvg -bu $VG # break reserves on VG/disks.

Secondary:
probe for new disks (or fix-up for pvids, etc.).
importvg -L $VG # learns changes from disks/VG

Primary:
varyonvg $VG # restores reserves

On Tue, Mar 18, 2008 at 9:37 PM, Sunder Iyengar
<sunder_iyengar@xxxxxxxxxxxx> wrote:

Thank you all for your very helpful responses.



The -L option with varyonvg is not documented (at least on AIX 5.3).
Does it do something similar to -L option for importvg?



Regds,



Sunder.



From: IBM AIX Discussion List [mailto:aix-l@xxxxxxxxxxxxx] On Behalf Of
F. Even
Sent: Wednesday, 19 March 2008 1:06 PM


To: aix-l@xxxxxxxxxxxxx

Subject: Re: Updating VGs that are part of a cluster



If you don't have both nodes active in the cluster, you could always
remove the disks and reprobe them to get the proper PVID information,
etc. But the chdev -l $disk pv=yes should set it just fine (to what it
is on the other node...always double-check though).

If you are not using CSPOC commands you don't necessarily need to take
an outage.

Steps:

Primary:
varyonvg -bu $VG # break reserves on VG/disks.

Secondary:
probe for new disks (or fix-up for pvids, etc.).
importvg -L $VG # learns changes from disks/VG

Primary:
varyonvg -L $VG # restores reserves

Then sync up cluster. Should be good.

Frank

On Tue, Mar 18, 2008 at 9:24 AM, Mills, John T <John.Mills@xxxxxxx>
wrote:

The important gotcha for any clustering is to have complete disk
definitions on both boxes that match before you do the addition.



John T Mills



Something similar to what you have could be:



Initial work

----------------------

Node 01:

cfgmgr

lspv | grep None # determine new disk

chdev -l newdisk0 -a pv=yes



Node 02:

cfgmgr

lspv | grep None # determine new disk

chdev -l newdisk0 -a pv=yes



Final work

----------------------

Node01:

Use CSPOC type LVM process to extendvg. Cluster remains up for all the
work.



-or-



Stop clustering software 01/02 (will varyovff the VG)

Node01:

varyonvg VG

extendvg VG newdisk0

varyoffvg VG

Choose method A or B:

Node02: (Method A)

varyonvg VG (Method A)

importvg -L VG (Method A)

varyoffvg VG (Method A)

Node02: (Method B)

exportvg VG hdisk (Method B)

importvg -V MajorNum VG (Method B)

varyoffvg VG (Method B)



Run a cluster synchronization.

Start the cluster on 01.

Start the cluster on 02.




________________________________

From: IBM AIX Discussion List [mailto:aix-l@xxxxxxxxxxxxx] On Behalf Of
Sunder Iyengar

Sent: Tuesday, March 18, 2008 12:47 AM


To: aix-l@xxxxxxxxxxxxx
Subject: Updating VGs that are part of a cluster



Dear All,



I am talking of cases where maybe HACMP is not involved - but other
clustering software like VERITAS Cluster Server is (for sake of
simplicity, assume two cluster nodes).



If you have an AIX VG that needs to be accessible from both cluster
nodes - not concurrently but varyed on on any one cluster node at any
time. In this scenario, how do you handle addition of disks to the VG?



So the VG is imported in to both cluster nodes but only varyed on one
one node. On that node, you run a series of commands to expand the VG
and add one or more new PVs.



What actions would you take on other cluster node to ensure that when
the VG is varyed on on that node at some point, it will see and
recognize the newly added disks?



I know the synclvodm command can be used to ensure newly added volumes
are updated in the node's ODM, but what about PVs?



Perhaps this applies to HACMP environment also - not sure how this is
handled by it.



Any pointers/steps will be greatly appreciated.



P.S. This is what I had to do to get it to work properly.

Say new disks have been added to node where VG is currently active.



On active node - varyoff the VG

On second node - ensure PVid for new PVs is set (if not already set,
will set same PVid as set on other cluster node (chdev -l hdiskxx -a
pv=yes)

Export VG and importvg again. Now the VG is complete on this node too.



Any alternative to the above steps?



Thanks in advance,



Sunder.









Relevant Pages

  • Re: Updating VGs that are part of a cluster
    ... Think the real issue was I accidentally put a -L in the "varyonvg" command ... Group Descriptor Areas of only the disks that are members of the same volume ... Then sync up cluster. ...
    (AIX-L)
  • Daily Report #4165
    ... The resultant cleaned cluster CMDs will ... well-understood host galaxy environment. ... The Nature of the Halos and Thick Disks of Spiral Galaxies ... ACS, NICMOS, and WFPC2 in parallel. ...
    (sci.astro.hubble)
  • Re: Clustering Newbie - SAN Advice
    ... Senior SQL Infrastructure Consultant ... SAN/Smart array or through a fibre channel switch. ... The SAN or Smart array will dictate what internal connection the disks ... single-instance cluster. ...
    (microsoft.public.sqlserver.clustering)
  • Re: Updating VGs that are part of a cluster
    ... The -L option with varyonvg is not documented. ... Does it do something similar to -L option for importvg? ... If you don't have both nodes active in the cluster, ... probe for new disks ...
    (AIX-L)
  • changed WWID on cluster member boot disk
    ... single-member cluster; the second member has not yet been added to ... The disks containing the cluster root, ... but an attempt to boot the DS20E as a single-member cluster failed; ... the boot of the stand-alone system, a number of new special device files ...
    (Tru64-UNIX-Managers)