m/c service guard and apps 11i

[Syed Fahimuddin]

We have a production set up on a rp8400 with two hard partitions.

One partition is the DB/Concurrent node and the other one is Forms/Web node.

It is on HP-UX 11.11. It is a 11.5.7 fresh install.

We are considering implementing m/c service guard cluster between the two partitions.

I want to know, in an existing installation like ours, where we have used the different hostnames, ip addresses and ports for so many service required by apps 11i already defined, how do we proceed?

Is this a feasible solution?

If the DB node fails, it should move to Forms node and bring up the database there.

If the Apps node fails, it should move to DB node and the application should work.

Has anyone done this before? I am sure lot of people would have done this before.

Are there any standard procedures to follow to move into this kind of environment.

Need some expert advice.

HP local team is unable to give clear cut picture of how it can be done.

Similarly, I do not find much info on Oracle metalink site.

Please help

Any clarifications required, I will provide

[Duncan Edmonstone]

Hi,

I don't have an answer for you - I've never done it myself, but I can give you some advice...

Go back to your local HP team and tell them they should be speaking to the HP/Oracle Cooperative Technology Center in Boeblingen, Germany - These guys are responsible for providing 'best practice' architectures for just this kind of thing - I'm sure they will have some info on how to acheive exactly what you are after...

HTH

Duncan

[Syed Fahimuddin]

Hi Duncan

Thanks for the reply.

I was trying the same thing.

Somehow, I have a feeling, they do not have a clear idea of this thing. Or they are reluctant to contact the HP/Oracle cooperative team.

Requesting other forum members to give me some idea of how to achieve this.

Now they say, it is HP services which can do this.

Hi All,

I just want to know over all conceptual idea of how to do this. Then we shall definitely seek some services from HP/Oracle to do this.

Can someone from HP team on the forum answer my queries or take it up with the right guys.

Thanks

[melvyn burnard]

This is certainly feasible, and provided you take the necessary steps to ensure each partition has the resources to run both sets of applications if it has to, then it can be done.
A word of warning, however!
You are talking about what is referred to as "ServiceGuard in a box", which has inherent dangers.
If you lose the whole system, you have lost everything.
If a fan fails on a rp8400, and you go to replace it and pull the WRONG fan, you have lost too many fans, so the box halts, again you have lost your cluster.
May I suggest you read the following manual at :
http://docs.hp.com/hpux/onlinedocs/B3936-90058/B3936-90058.html

ServiceGuard Cluster Configuration for Partitioned Systems

[Michael Steele_2]

Question: Aren't you using vpars and virtual or soft partitions in your rp8400? Aren't hard partitions superdome only? This makes a big different since hard partitions in superdome have a single point of failure along the backplane. Regardless of this, HW redundancy is your first consideration and one that every implementation of SG takes into consideration. For example, your rp8400 will have 3 power packs or power sources, and each "plug" should go into an independent power node within your building. This is done in order to eliminate a single point of failure caused when one power node goes out. The rp8400 only needs one of the three power supplies in order to operate IF CONFIGURED CORRECTLY!

Your path forward becomes fault tolerance and the implementation of a fairly "standard" SG configuration since package failovers between SG nodes is standard form at the software level.

I would pay particular attention to the cluster lock disk if using the two node cluster that your two virtual partitions seem to indicate. This is the common disk used by both nodes. A 3 node cluster avoids this problem with a quorum policy but falls into it if two of three nodes fail.

Also I've read Melvin's link and have copied and pasted some points that stuck out to me. In reading this document I don't see anything that shouldn't allow for a common place service guard implementation from a software level. Again, your consideration is one everyone has to plan for and that is HW fault tolerance. I did note that there's a master cell in these boxes that coordinates or traffic cops the other cells. Please investigate this since this document seemed to imply more than the usual latency in cluster reforming during a failover. Partitioned nodes seem to require a longer than usual heartbeat time out period. I found this of particular interest and bring it to your attention.

Here are those pasted points of interest:

Due to the nature of the hardware/firmware sharing between VPARS, it is possible for one partition to induce latency in other partitions. For example, during bootup, when the booting partition requests the system firmware to initialize its boot disk, it is possible for other partitions running in the same machine to become blocked until the initialization operation completes.

For a cluster configuration to contain no single points of failure, it must extend beyond a single hardware cabinet,

Since the I/O chassis represents a potential unit of failure,

A cluster in-a-box configuration consisting exclusively of VPARS is susceptible to a wider variety of possible failures that could result in a complete cluster failure,

[melvyn burnard]

As the rp8400 is cell-based, it is designed to use hard partitions, so it may not involve vpars at all!
If you are in any doubts, I strongly advise you to involve HP consultants, and also Oracle wher erequired.

[Sridhar Bhaskarla]

Hi,

"Serviceguard in a box" is usually referred to partitions within a single cabinet. However, the risk of running into hardware failures in v-partitions like on RP7400 is much greater than n-partitions on an RP8400. N-partitions are done at the hardware level with each partition containing it's own hardware resources. However, still a single cabinet can have single points of failures like UGUY board that can cause the entire cabinet to go down.

If you follow the N+1 configuration for the other resources like fans, you should be ok to configure an RP8400 into two cells consisiting of a cluster. This is my order of preference for a cluster.

1. Systems that are physically seperate.
2. N-pars located on different cabinet in a superdome.
3. N-pars in a single cabinet <- your case
4. V-pars

-Sri

[Michael Steele_2]

Thanks for clearing that up.

[Syed Fahimuddin]

Thank you very much to all of you for sharing your views and helping us.

I would like to add, we are already running on 2 hard partitions.

There are two single points of failure in this box in terms of h/w (my understanding)

1) The backplane

2) The smaller power supply which supplies power to the root disks and the core i/o.

The 2nd one is a SPOF, if the rp8400 is configured in two partitions. It is not a SPOF if it is one partition.

I understand the risks involved in running in the same box. It is to give some amount of high availability to these partitions.

I would still like someone to deal with the points, I discussed in the initial questions

It is how can we move into cluster with the existing configuration explained earlier.

[melvyn burnard]

See the second part of my second response.