Adding a disk into an enhanced concurrent VG 3

[khalidaaa]

Hi all,

I have an HACMP cluster with enhanced concurrent resource group. What is the best way to add a (LUN) disk to it?

Can i do this on the fly without effecting the cluster? I usually extendvg the new disk to the VG but then when I sync it says that the VGDA is different so what i usually do to avoid any headache is to stop the cluster, sync it then start it again. But i feel that as long as it is an enhanced concurrent, i shouldn't do that! It should be seamless!

Your comments is appreciated.

Regards,
Khalid

 

[dial8d]

Hi

Once the lun is visible on your cluster nodes, you definately should be using HACMP C-SPOC in order to add the new lun to an enhanced concurrent volume group.

smitty hacmp > System Management (C-SPOC) > HACMP Logical Volume Management > Shared Volume Groups > Set Characteristics of a Shared Volume Group > Add a Volume to a Shared Volume Group > <select your VG>

Rule of thumb is always use C-SPOC for manipulating enhanced concurrent volume groups (or cluster in general).

 

[khalidaaa]

Thanks dial8d.

I remember trying the C-SPOC but i couldn't find the option to add the LUN!

I don't have access to my cluster for now to try it but i will check it again once i be there.

Thanks again for your comment.

Regards,
Khalid

 

[khalidaaa]

Hi dial8d,

I just tried your suggestion but it gave me an error while doing so! I managed to see the resource group when i went into "Add a Volume to a shared volume group" but it gave me an error after doing so!

                             ERROR MESSAGE
Press Enter or Cancel to return to the application.                                               1800-051 There are no items of this type.

Any Idea why?

Regards,
Khalid

 

[dial8d]

Is the lun you are allocating coming from a DS4000 san by any chance ?

If so, i found a note in the FastT best practises redbook that says;

HACMP C-SPOC cannot be used to add a FAStT disk to AIX via the 'Add a Disk to the
Cluster' facility.

However, a quick test on my test cluster showed a way round this without taking the cluster down. This is the procedure i used.

1. Allocate the lun to both cluster nodes.

2. Run cfgmgr on 1st node to pick up the new lun.

3. Set a pvid on the new lun

chdev -l hdiskx -a pv=yes

4. Set the no reserve attribute

chdev -l hdiskx -a reserve_policy=no_reserve

5. On the 2nd cluster node, run cfgmgr to pick up the new lun. Ensure it picks up the correct pvid as created on node 1 step 3

6. Set the no reserve attribute on your hdisk on node 2

chdev -l hdiskx -a reserve_policy=no_reserve

Now when you go into C-SPOC, you should see the new lun when you goto add a new volume to a shared volume group.

7. smitty hacmp > System Management (C-SPOC) > HACMP Logical Volume Management > Shared Volume Groups > Set Characteristics of a Shared Volume Group > Add a Volume to a Shared Volume Group > <select your VG>

8. Once the lun has been added, check on your cluster node 2 that the VG has the new lun associated.

lsvg -p <vgname>

9. I would also recommend that you schedule a test failover as well to ensure failover works as expected. I had no issues with failover on my test cluster after following this procedure.

Hope that helps.

Alex

 

[khalidaaa]

Thanks alex for your nice comment. Its my first time to know about the reserve_policy=no_reserve!

I'm trying to apply this to a production system. Would that be of any problem to the cluster or the data on that cluster later on?

Regards,
Khalid

 

[dial8d]

Hi Khalid

the reserve_policy=no_reserve allows the 2 cluster nodes to see the lun, without 1 locking the lun from the other.

You should see that this attribute is already set on the existing luns in the enhanced concurrent volume groups.

What SAN and MPIO are you using ?

If you have the opportuntity to test this process, or a development cluster, i would encourage you to do so.

I would also recommend that you take all the usual precautions before implementing on production. ie, make sure you have backups of your data, a cluster snapshot, and a copy of the volume group structure (savevg -r).

Cheers

Alex

 

[khalidaaa]

I have a SAN DS4500! we are not implementing MPIO!

Regards,
Khalid

 

[Pinho]

Hi, I had the same problem while adding two new disks to a HACMP concurrent vg.

The solution was a little simple:
cfgmgr -vl <fiber adapter>
chdev -l <new_hdisk> -a pv=yes
Steps above, on BOTH NODES!!!
ps: May be the cfgmgr be unnecessary on the second node


smitty hacmp
System Management (C-SPOC)
HACMP Concurrent Logical Volume Management
Concurrent Volume Groups
Set Characteristics of a Concurrent Volume Group
Add a Volume to a Concurrent Volume Group
<select your VG>
<select your disk>
DONE!!!

Luis Henrique Pinho
No Orkut - Unix Brasil

http://www.orkut.com/Community.aspx?cmm=678135

 

[khalidaaa]

If i could give you more than a Star i would Pinho!

Thank you very much for the solution! I just tried your suggestion and it is working like a charm

With slight differences than your sequence:

smitty hacmp
System Management (C-SPOC)
HACMP Logical Volume Management
Shared Volume Groups
Set Characteristics of a Shared Volume Group
Add a Volume to a Shared Volume Group
<select your VG>
<select your disk>
DONE!!!

I run the above from one node (the node that had the resource group by that time) and then i had to run the verify and synchronize to sync with other nodes!

Thanks again for that.

Regards,
Khalid

 

[ogniemi]

Pinho, why are you going to pv=yes twice - once on node 1 and later on node 2 when pvid was already set on node 1?

I would rather do dial8d proposed - cfgmgr on node 1, pv=yes on node 1 and then on node 2 cfgmgr would be enough to get the new logical disk with the pvid which already set in step before on node 1.

star for dial8d.

 

[khalidaaa]

ogniemi That's what i did actually!

fair enough

Regards,
Khalid