24x7 setup and oracle instance

[Henrique Silva_3]

I am writing a proposal to have a reliable 24x7 world-wide enterprise model, and I am looking at how I could use MCSG.

We will define 4 regions in the world that will have this setup, and have oracle replication to get the data everywhere ( have not decided what kind of replication here yet, it all depends on SLAs which have not been defined by management yet ). The setup would be the same everywhere, so, let me describe one of them.

Will have two superdomes, two XP512s, which will house the app and the oracle database instance, and MCSG to control any downtime switching here. We will probably have an regional failover here as well, with possibly two more superdomes and MCSG, but I am still looking at over kill here. The idea is to have one setup that will take care of the app and the regional failover will have replicatred data and serve as a history server. I was thinking of have only ONE of these, and use the inactive server as the history server, meaning, I could replicate the data from the active server to the other one, by doubling the storage requirements, and basically mirroring the data on a different XP512, so the history queries will not contend for the non-historical data on the other XP512 !!!!

Since I have only used MCSG to simply switch from one node to another, and that second node right now is usuless doing nothing but waitig for the first node to fail, is is possible to have the setup describe above working here? Meaning, I can have the second node waiting for a failure in the package, but also, having an instance on its own, that would be used for history queries ? and if so, what are the drawbacks of it ? I can see right away that if the package switched from one node to another, we will ahve both the app server and the history server on the same box, until we are able to bring the other one back up.

Thanks,

Henrique Silva

[David Bell_1]

Henrique,

Yes you can have the setup described. You currently have an "active/passive" configuration as described. You can have an "active/active" configuration in which applications are active on both nodes. You could even consider failing over the packages to each other. However, make sure to take into consideration the performance degredation while waiting for the "repair" of the failed node.

HTH,

Dave

[Henrique Silva_3]

Thanks David.

I understand the implications of performance on these boxes once we have a problem. This will be an issue for the big weags later to decide how much money they want to throw at this implementation :-)))

So, given that I can have an active/active setup, I just want to make sure I understand this. By active/active, you mean I can have an instance running on node A and the historical data instance on node B, and have MCSG switch to a different system in case of failuer, so I could end up with with both instances on node A or on node b, correct ?

So, the worse case scenario here is if both servers went down OR the network access to that location went down. I would have no APP access for that region.

I am looking a total reliability, so, having a regional failover site, say, 200 miles from there, would be over kill ? I could have the same setup above, and then, have historical data on this other server and app data on the other one and simply have replication.

The drawback here again, is that I would have 4 servers, with 2 being active and 2 being inactive, doing nothing !!!!!

Is this overkill ? I think it is, but to give completely reliability, I do not see any other way.

That means if the 4 regions I am trying to implement this on, would have the same setup. Final numbers would be 16 superdomes, with 16 XP512s and 8 MCSG implementations.

Or, I could have the original setup with 2 superdomes per region plaus 2 XP512s, plus one MCSG implementation, bringing my total to half of the one above. Not overkill but there will be a scenarion when loss of access to the app is possible.

I guess the cost/benefit equation will have to come into here. My job os to present the options !!!

Thanks,

Henrique Silva

[David Bell_1 · Accepted solution]

Henrique,

Yes, you are understanding correctly. It is possible given a failure that you could have both instances running on one node. The MCSG Metro Cluster/Continental Cluster could work for you in this instance. This is where you would fail over to a completely different location. Without going into immense detail, data replication is accomplished via WAN. This keeps both sites up to date and should a failure occur, the application would be switched to a different Metro location or Continent. You coould also look at nPars or "partitions" to run the instances from. However, it is NOT recommended to run MCSG "in a box" or one Superdome. There are approximately 3 SPOF's that could leave you vulnerable.

I would highly recommend that you speak with an HP Pre-Sales representative to layout some possible scenarios for your specific requirements. Since they do this all the time and it sounds as though you have decided upon SD and XP512, they can give you the multitude of scenarios and pitfalls of each. It's possible that they may be able to come up with a more cost effective way to perform what you are requesting.

HTH,

Dave

[David Bell_1]

Henrique,

One last note. The amount of "overkill" is dependent on the level of uptime required. If it is absolutely imperative to have 24x7 uptime, your requirements will be more stout than if you can experience an outage. Further, how long that outage can be. If you don't have access to the Metro Cluster/Continental Cluster information, let me know, I'll gladly provide it. It has some VERY specific requirements and partners with Oracle, Brocade, etc.

HTH,

Dave

[Henrique Silva_3]

Thanks David.

I was not aware of the Metro or Continental ability to switch over to a failover server across the WAN with MCSG. I was inder the impression that it could only switch over to a server sitting on the same subnet, or close by, since it needed the heart bit nic card. Oh well, that is what we needed at the time, and that is waht was implemented. Now, the situation is different.

Now, I will call somebody within HP ( I actually work for HP, but it is hard to get info internally, if you can believe it. We do not have a clear path, such as a sales guy, but I will try to get some names ).

Can you point me to some links on the metro/continental implementation of SG ?? I am wondering about the WAN replication ? would that be more reliable than RDBMS replication ? I can not see how !!! SFOCs ? what are they ? I love acronyns :-))

Again, I am looking for pitfalls, learning from others that have suffered through an implementation of such port. I know we learned A LOT when implementing the atcive/passive MCSG setup that we have now on a couple of servers out there, and I try to share that info with anyone doing the same thing.

Thanks for you help again,

Henrique Silva

[David Bell_1]

Henrique,

Here's an excellent white paper on extended distance MC/SG. Since you are part of HP, you should be able to get to this. It is an "HP Restricted" document so I will simply provide the URL:

http://www.cpesp.hp.com:2000/nav24/programs/mktgprogs/ai/ha/ExtendedMCSGconfig.pdf

The SPOF's I mentioned was reference to "Single Points Of Failure". I will look for additional documentation and forward where possible.

HTH,

Dave

[Henrique Silva_3]

Thanks Dave.

But I can not get to this site. It is asking me to go via my "favorite secured reseller site" :-(((

Do you know which group supports this web site ? I can try to contact them directly. Do you work for HP ? Like I said, it is really hard to find these things out if you are in the inside :-)))

I have some buddies that work for sales, maybe they can help me here.

Thanks,

Henrique Silva

[David Bell_1]

Henrique,

No I don't work for HP. I'm a channel partner. I access the referenced website via partner.americas.hp.com. I think you have access to that or the equivalent if you're outside North America. From the partner site, it is accessed via ESP.

I believe the organization that is referenced is TCO.

If you have an e-mail address that you can place here, I'd be happy to forward the information to you.

HTH,

Dave

[David Bell_1]

Henrique,

You can also look at the public site:

http://docs.hp.com/hpux/ha/index.html

Under Continental Clusters there is some useful white papers as well as Release Notes, etc.

HTH,

Dave