disk add in cluster

[prashanth]

Dear All,

I have 2 data center and two serveice guard clusters. one service guard cluster is running in one DC and another cluster is running in another DC.  suppose cluster1 and cluste2 running in differnet dc. There is a CA replication across the DC. now my query is when the DR will happen the packges of cluster1 will failover to DR DC and join the cluster2 . so during  starting the package on DR node it will import the vg on DR node. So my query is while importing the VG it will refer the VG ID or device path on DR node. Thanks . Please let me know if need more clarification

Thanks!!

[Matti_Kurkela]

The basic Serviceguard will never failover anything from one cluster to another. You would need another product (e.g. ContinentalCluster) for that. Or if you have a custom Disaster Recovery procedure to move services from one cluster to another, you should examine the procedure documentation and/or ask the people who built the procedure.

> So my query is while importing the VG it will refer the VG ID or device path on DR node.

It is not clear to me what the "it" in the above sentence refers to.

If "it" means Serviceguard, it won't import any VGs automatically, ever.

If "it" means something else, I would need to know what "it" is to know for sure (please expand your abbreviations: what do you mean with "CA replication"???)

But in general, when you are moving things between clusters, the device paths are never guaranteed to be equal, so it would be safer to use methods that won't assume the same device paths, but will use VGIDs or something similar to automatically make sure the right things will be imported.

[prashanth]

Hi ,

Thanks for reply. I will try to explain in details.

Two sites.

DC 1 --------------- cluster1

DC2 ----------------cluster2

Take a one example SAP package is currently a part of cluster1 in DC1 and DC2 is a DR site for sap package. There is a CA replication across the DC. Now suppose the DC1 down due to power outage then will start  SAP  package at DR site in DC2 and it will join the cluster2. So when the package will start then first it will actviate the vg and import it on DR site node. During that time it will refer the vgid or disk path.

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

The confusion is created because of symmetrical cluster concept.

Thanks !!!

---

@matti_Kurkela wrote:

The basic Serviceguard will never failover anything from one cluster to another. You would need another product (e.g. ContinentalCluster) for that. Or if you have a custom Disaster Recovery procedure to move services from one cluster to another, you should examine the procedure documentation and/or ask the people who built the procedure.

> So my query is while importing the VG it will refer the VG ID or device path on DR node.

It is not clear to me what the "it" in the above sentence refers to.

If "it" means Serviceguard, it won't import any VGs automatically, ever.

If "it" means something else, I would need to know what "it" is to know for sure (please expand your abbreviations: what do you mean with "CA replication"???)

But in general, when you are moving things between clusters, the device paths are never guaranteed to be equal, so it would be safer to use methods that won't assume the same device paths, but will use VGIDs or something similar to automatically make sure the right things will be imported.

---

[Matti_Kurkela]

With "CA replication", do you mean Continuous Access? It is a method for linking HP EVA or XP storage systems together for data replication. So, it implies you have two storage systems in your set-up.

A basic Serviceguard only covers clusters with a single storage system. Failover to another storage is outside its scope. To handle storage failover, you normally need MetroCluster.

But MetroCluster requires all the nodes forming a single cluster for coordination. You have two separate clusters, so your setup is outside the MetroCluster scope too.

Having things failover from one Serviceguard cluster to another is a ContinentalCluster concept.

But you did not say anything about ContinentalCluster, so I assume you don't have it.

The only remaining option is that you have some custom scripts in the package configuration of your clusters (at least cluster2, possibly both). In that case, the only way to find out how the VG is imported when the package starts up on DC2 is to either:

• ask the person(s) who originally set it up, or
• see if they documented their set-up and read the documentation if it exists, or
• read the package configuration to find the exact commands used to import the VG.

If your set-up is a standard ContinentalCluster, anyone with ContinentalCluster experience might be able to tell how the VGs are normally handled in it. But if your set-up is locally customized, nobody else in the whole world will know how it's done.

If your packages are configured using modular Serviceguard configuration style (available in Serviceguard A.11.18 and later), the VG import commands are probably in a script that is called from the package configuration file using the "external_pre_script" keyword.

If the legacy configuration style is used, the package control script may have been customized in unsupported ways: the best way to find the customizations is probably to use "cmmakepkg -s" to create a dummy package control script and run "diff" to find all the differences between it and the real DC2 SAP package control script.

[prashanth]

Hi ,

Thank you very much for your support.

One qury.

while importing the vg by using vgimport command it will refer disk paths or VG ID.

Thanks!!!

[prashanth]

Hi ,

Yes, we have to storage in our set up and CA replication is there across the two storage.

Thanks !!

[Matti_Kurkela]

> while importing the vg by using vgimport command it will refer disk paths or VG ID.

vgimport can do it both ways.

If you use "vgimport -s" with a map file that has been prepared with "vgexport -s", vgimport will read the VG ID listed in the map file and scan all the disks the system can access to find all the disks with that VG ID.

If your map file has been created by using vgexport without the -s option, or if you don't have a map file at all, then you must list the disk paths on the vgimport command line. However, vgimport will check that all the listed disks have the same VG ID, and will stop with an error message if some of the listed disks have a different VG ID than the others. It won't stop you if you miss one of the disk paths that would have the same VG ID.

[prashanth]

Hi ,

We have two storage and CA replication is happening across the storage .  It may give some idea about my query now.

ATTENTION: On systems using data replication products like BusinessCopy/XP, ContinousAccess/XP, EMC
SRDF or EMC Timefinder it may be impossible to reliably identify the correct list of PVs using this VG-ID
mechanism. You should specify the list of PVs explicitely here. The newly introduced –f option for vgimport
helps to specify large PV lists on the command line (see man page). The -f Option is only available as of UX
11.X. For UX 11.00 you need LVM commands patch PHCO_20870 or later.
MirrorDisk/

Thanks !!