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)
  • 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)
  • Re: Clustering Newbie - SAN Advice
    ... A SAN generally has gigabtes of cache and uses large internal block sizes ... The SAN or Smart array will dictate what internal connection the disks have. ... Senior SQL Infrastructure Consultant ... single-instance cluster. ...
    (microsoft.public.sqlserver.clustering)