AIX

Hi all,

I am new to HACMP. So sorry for the newie question. But I did search the forum and it seems that no one asks this before.

So if a 2-node cluster runs in active-active mode (and the same application), what is the benefit of using HACMP ?

If it runs in active-stanby, it is easy to understand because you need HACMP to do failover; but for active-active mode, no failover (right ?), then why do we need HACMP ?

Besides, I find HACMP documents do not use the term "active-active" or "active-standby" (cold standby or hot standby) often. So does "concurrent resource group" mean "active-active" and "cascading/rotating resource group" mean "active-standby" ? Is there a cold standby ?

And what is the relation between "concurrent resource group" and "concurrent shared disk access"; what's the relation between "Cascading/Rotating resource group" and "non-concurrent shared disk access" ?

Thanks!

HACMP terminology changed now and then. Some terms were used with older HACMP versions 3 and 4, some came into existence with the current HACMP Version 5 while others ceased to exist. The same is true with certain functions/possibilities. IBM Speak itself can be a bit challenging but when you mix up words from different times you end up in a mess.

An active-active cluster has (at least) two nodes and two Resource Groups RG. So there is one RG per node and only during takeover/failover two RG are on one node. This is a very good setup because during normal operation the RG (its application) has its dedicated CPU/RAM/IO. Furthermore not everybody can afford running (i.e. paying for) two servers but using only one. It does not at all mean that there is no takeover / failover possible.

A concurrent HACMP RG means Oracle RAC. I am not aware of another application that is able to run as a concurrent HACMP cluster. While there are two or more nodes active at a time this is not usually called an active-active configuration as no takeover is involved. In a concurrent cluster a node may die but the other(s) keep on working regardless.

Cascading / rotating is related to RG behaviour. If there is a fixed order of how the RG is taken over from node to node (usually in a Cluster with 3+ nodes that are different so that using certain nodes is perferable) this is a cascading behaviour. If the RG does not care on what node it is active, i.e. it can be active on any node a rotation of the RG might be OK.

Concurrent volume group are rarely used these days. Today you are likely to use Enhanced Concurrent Mode VG. And Oracle RAC can use an ECM VG in a Concurrent Cluster.

As you might have guessed by now already: some reading might be required. If you are an absolute beginner with HACMP you might start by reading the HACMP cookbook from December 2005 followed by the PowerHA cookbook (yes, the name changed with 5.5 ....) from September 09.

Thanks for answering my question!

But back to my original question, if concurrent HACMP RG means Oracle RAC and since no takeover is involved (and RAC10g has its own clusterware), what is the benefit of using HACMP with RAC ?

The other question is if like you said during failover for the active-active cluster, 2 RGs would be on one node. Then I think these 2 RGs should contain different applications. Because if they are the same application (like RAC) I don't see the value of running two same applications on one node, right ?

Thanks.

That was your original question?

As always ... The decision on whether to use HACMP or not could be based on what filesystem you want to use. For Oracle RAC you neither need HACMP when using ASM nor when using GPFS. However IIRC you need ECM VG if you use Oracle datafiles on concurrent raw LV.
What also might count is your IT personnels expertise. Do your administrators have good knowledge of GPFS / ASM? Then use it. However if your administrators have good knowledge of HACMP then ECM might be preferable.

One application cannot be member of two RGs.

Thanks for the answerd and looks like I have got a lot of reading to do! Man

BTW my original question was "what is the benefit of running HACMP for an active-active cluster with the same app running" and it looks like RAC may be the only one in this case, right?

And I did find out another term HACMP uses, "mutual takeover", which seems to be relevant to my question. So my understanding of "mutual takeover" is an active-active cluster with different app running (shared-nothing mode). It makes sense to using HACMP here. (and it also makes sense why they don't use the term "active-active" now). But is my understanding correct or I totally got it wrong ?

Hi,

there is Sybase Cluster Edition that works similar to Oracle RAC.
In addition there are a lot of Vendor applications out there that have built in ha-facilities and can run / should run in a concurrent resource group - not for availability - but for load balancing reasons. And here the cluster facilities are not used for the applications themselves but for the infrastructure that points to the application. If one node goes down, the service IP just starts pointing to the other node - the application - though down on the previous node - remains available. Great solution for any kind of application that doesnt produce volatile data at all.
We have several clusters where Websphere and MQ are running active on both nodes - serving different functions - and again failover to the other node when required - serving different clients, different applications - and yes we want different instances of the same application being up on one node if the other node dies.
We have as well lots of sybase databases in a hacmp setup that have the same content but serve different purposes. Sybase replication server replicates the content of database 1 into database 2. As long as both nodes are up, database 1 is used for trading, database 2 for reporting - when one of the nodes dies, it fails over to the other node - replication remains running - and you still can use both databases for these different purposes - nothing in the listeners, pointer files or anything has to change because the IP of the application doesn't change ... and additional resources are just added via dlpar scripts if required - so nothing is starving ...
Possibilities are countless and so are the benefits of having live-live clusters

Kind regards
zxmaus

Thanks for the reply! Man, "possibilities are countless" but the learning curve is just

So another newie question. When failover happens, should I let the failed node auto-reboot or should I reboot it manually, say in a production environment?

And if I choose auto-reboot, can HA software like HACMP help ?