Cluster lock vg

[N Ward]

I'm recreating one side of a cluster as a DR exercise and I have restored vg00 from tape. Currently waiting for SAN storage to be presented. I feel I may have overlooked something, the cluster lock vg.

How is that backed up for the purposes of DR, or does it need to be?

Can I just recreate a new one and amend the configuration accordingly?

[Steven E. Protter]

Shalom,

Its a cluster lock disk, or physical volume, not a volume group.

It is part of cluster configuration. If it needs to change in DR, due to different disk layout, that step can reasonably be left in the activation document for the DR site.

SEP

[N Ward]

Hi, thanks for your reply. I am ACTUALLY at the DR site now. The disk identification will change since we presenting different disks prior to a restore. For the cluster to bring up the packages after the restore will I need to specify a new cluster lock vg and create it? Is it necessary when creating one side of the cluster? Should I have saved anything before this DR test? Thanks in advance...

[Mel Burslan]

When you are on the DR site, serviceguard rules changes a bit. Assuming your DR site is in another data center, in another city or in a distant location in the same metropolitan area, so the metro or wide area serviceguard cluster configurations, more than likely play a role on your implementation.

On the other hand, cluster lock disk or volume group, is unique per cluster. After all, it is there to break a tie, in case it happens. If you used a cluster lock in a volume group, as a regular cluster exercise, after you build your system, you need to import your VG's exported out of your other cluster member. During this exercise, the cluster lock vg should be imported as well.

Since it is very hard to guess your exact configuration, this is as much as I can say.

Since you are dealing with DR using serviceguard, did you think about the network link speed between the main site and the DR site. Also, how is the storage being handled ? Any think short of an OC-3 or so link is going to cause you storage synchronization problems. In my opinion, you have a bumpy road ahead. Good luck

[N Ward]

Thanks for the reply. To make it easier to understand what is going on I'll explain the set up. It pretty simple.

I am recreating the primary node of what was originally a two node cluster (primary and standby). The Primary is being recreated from backups. I have an ignite backup of the node which has now been restored ok, so vg00 is there now. I am waiting for storage to be presented to the node to allow me to recreate the filesystems / volume groups for the cluster. I am unsure if I can start the cluster once they have been created without the cluster lock vg? I didn't factor this in when considering what I needed to do to recreate the node. Did I need to since I am only rebuilding the Primary node? Hope this helps explain things better, sorry for any confusion. This is a rebuild primary node only exercise I am carrying out.

[Mel Burslan]

As long as you can import the cluster lock vg with the right disk information, the answer is, "no, you do no need to re-create".

Having said that, I am assuming you will have access to storage where this lock disk is located. If you are trying to create the primary node only, without having access to the secondary node in the cluster, to be a single node cluster, then the answer is "yes, you need to create the vglock (or whatever you named it) volume group together with any other volume groups and logical volumes needed.

HTH

[N Ward]

Sorry I am new to this. All I have to go on is the disk name for the cluster lock vg in the configuration file, and this I believe will be different because we are using different hardware/SANs. Are you saying that had this been the same hardware name I could have used vgimport and presumably an old config file and that would have been sufficient?

So because I can't do this, I will have to recreate the cluster lock vg? Thanks in advance...

[Kirby A. Joss · Accepted solution]

IIRC, only a 2-node cluster requires a cluster lock VG/disk. Also SG will be unhappy trying to start the cluster without the presence of the secondary node. I believe your best course of action is to simply comment out the cluster lock AND the secondary node in your *ascii file and cmapplyconf at the DR site. You can then start the DR single node SG cluster without hassle.