Split a 2 node cluster into 2 single nodes

[Kieran Wareing]

Hi
My 2 nodes are next to each other which is fine for business continuity but no good for disaster recovery. My company wants to move one node to a site some miles away and run as 2 single nodes. (No money to keep continuity!)

How easy is it to reconfigure both machines as single nodes?

Do I just need to...
1. Switch off the auto flag for cluster forming
2. Edit the cluster config to remove the 'other' node and then..
3. Recompile the cluster config

Or am I oversimplifying it??
Any advice would be much appreciated. Thanks.
Regards
Kieran Wareing

[Steven E. Protter]

Shalom,

If you don't want clustering any more why start the service at all. Run the applications in native mode.

Your plan in general will work except you will be trying to run two clusters that can talk to each other with the same name. You will need to make a few other changes to the config file prior to recompiling.

SEP

[A. Clay Stephenson]

You need to think through this a bit more. You seem to want to create two single-node clusters but note there is nothing now to prevent the same package from running on both nodes. That would cause an IP address conflict for your clients at the very least. You should also note that whereas now your data are somehow connected to both nodes; that will no longer be the case when you physically separate the nodes.

If this were me, I would push for a more logical approach that would give you the best of both worlds. Keep your existing cluster and purchase a smaller limp-along system for the remote site. It isn't clear how you plan to keep your data synchronized between the two sites but those costs will far exceed anything else including setting up a second remote cluster. It sounds as though, the DR plan is going to use restore from backup for data recovery.

In any event, your problem needs to be carefully thought out or you may find yourself moving from a high-availability environment with poor DR to a situation with both poor availability and poor DR.

This is one of those areas where you should really demonstrate your skills becuae I strongly suspect that your management does not know what it does not know.

[Sundar_7]

1) Halt the cluster
2) Use cmquerycl on individual nodes with only that particular node

This will create the cluster config file
3) cmgetconf the package ascii file and remove the reference to the second node
4) cmcheckconf and cmapplyconf the cluster and package configuration files.

But I ain't sure if this is a wise idea :-). In my opinon, local failovers happen more often than the site failovers.

[Kieran Wareing]

Wow!
I never expected to get so many replys so quickly.
You have all given me a lot to think about.

Note that one node is just idle, waiting for the main node to fail and has mirrors of the main node's disks. If it gets moved it will stay idle and be refreshed from backups. Management has already been informed that with all the Oracle DBs it will probably take a day to recover!

I will do points shortly when I have had time to digest what you have said. But don't let that stop you adding more opinions or advice if you have it. Thanks.
Kieran

[Emil Velez]

Well a single node cluster would give you local lan failover which I have seen people use serviceGuard for in the past.

unfortunately each node will need a local lock disk.

[A. Clay Stephenson · Accepted solution]

Now that I know that you don't plan to keep the data constantly synchronized, I would push for something similar to this:

Keep your existing MC/SG cluster as it is.

Search the used equipment market for a smaller system (e.g. an old L2000/rp5450 or so) and maybe some SC10 disk arrays (well more accurately JBOD's). I recently did something similar to this as was amazed at how cheaply I could put together a fairly
powerful system. When I did the math, for me, the L2000's were the price/performance sweet spot on the used market. You might also find that it makes more sense to purchase a few critical spares for the used equipment that to put iyt under a service contract. The other advantage of this plan is that you now have a fully isolated test/sandbox system so that you can safely deploy patches and changes before doing them "for real".

Again, I don't think your management is really seeing the big picture and it's your job to help them see it.

[Kieran Wareing]

Thanks everyone, in particular A. Clay Stephenson...

After your response yesterday I emailed my manager and suggested a second hand system. I am sure the cost would be covered, at least partly, by saving the cost of moving the second node and more importantly saving disruption to customer services (24 hour call handling system).

Thanks again. I think that about wraps it up.
Regards
Kieran