Building Up to High Availability

[ray.wurlod]

One of my clients has asked this intriguing question. Is it possible to build up to an active-active high-availability configuration in four phases? The metadata repository is Oracle RAC 11g.

Phase 1 - Stand-alone machines for WAS, MDM, IIS Engine ("the three").

Phase 2 - Like phase 1 but with an additional installed, unused set of three used only for DR.

Phase 3 - Convert the live and DR systems to active-passive high-availability configuration.

Phase 4 - Convert the active-passive to an active-active high-availability configuration.

All machines will be identical VMs.

If you've done this (or even if you haven't) and would like to address the "how" question that they'll ask if the answer is "yes", I'd appreciate having that knowledge and vicarious experience as well.

[johnboy3]

Bump.

Question: Is bump encouraged, or discouraged?

[chulett]

Discouraged. If you have something to add to the conversation, add it. If you have an interest in the subject or some aspect of it, state it. Just saying "bump" to get it back to the top of the forum? No.

Ray - I'm unclear why this is in this forum. Knowing you it was intentional but I don't see this as a forum for new questions, it has (had?) a very specific and limited purpose IMHO. Any problem is this goes... elsewhere?

[ray.wurlod]

I thought that the Dads and Grads would have been more likely to have had this particular experience if anyone had.

Alas 'twould seem that no-one has.

[chulett]

Decided to move this out into GenPop with all of the unwashed masses.

[asorrell]

I would think the WebSphere piece would be very problematic. The stand-alone WebSphere installation is quite different from installing as a WebSphere cluster.

-However-

If you knew this was the plan long term, you could install your first WebSphere system as a cluster of "one". Then the second system could be added to the existing cluster later.

There are additional logistics to consider. For instance most WebSphere clusters use a front-end load balancer to distribute incoming connections. Again, it would be easier to put that in place early, then just update it to add the second system when required. Adding a load-balancer afterwards could also be done but it would be very tricky since you'd either have to educate people to start using a different "URL" to connect, or have it usurp the existing hostname / ports (risky).

Since XMETA would be "on the RAC", you'd think that it could be expanded fairly easily (especially since a smart Oracle admin can setup the TNS entries in a manner that is fairly transparent in terms of back-end systems).

(Again) - However-

Some parts of the installation (JDBC if I remember correctly) doesn't handle Oracle RAC well and must be installed to a single "node". Then you let Oracle "synch" the other node back into shape. Afterwards, JDBC syntax needs to be re-adjusted to re-point to the RAC. Forget that step and you are down if the primary node fails.

Again, the piece for the Engines could be made easier if you plan it in advance. All systems should have an alias that can be re-assigned (Canonical Names "CNAMES"). Those are the names used for the installation and the APT files. They make fail-over much easier since you can dynamically re-assign the "bad" hostname to point to the "good" server in a fail-over.

Over-all, do-able, but painful. Especially since at any point, if you screw up, you could take an existing system down.

Since they are VM's, I'd much rather set them up as tiny systems and setup the entire thing in parallel. That way you can re-install, re-configure, test fail-over without impacting existing systems. Then once the kinks are worked out, re-size the VM's and start porting jobs over to the new systems.

Can't address MDM specifically - I've not looked at that.

By the way - do they have an enterprise license? Because otherwise, going active-active on the engines will double their PVU's...