Yavor,I'm not sure I am clear on your recommendation. You said you'd use a single 9-node cluster too, but then seem to bring up topics that appear to suggest that a single cluster is a Bad Thing.
To clarify, there is no planned downtime I can foresee that would affect the entire cluster. Clusterware upgrades are rolling. New ORACLE_HOMEs would just be added (no downtime) along side the existing ORACLE_HOMEs so that some databases could run on a newer version. Assuming all databases are either multi-instance or single-instance but could afford a short failover outage, no applications should have any extended outages. Obviously, if a database patch/upgrade is required then those databases would have planned outages to apply the patches (if the patch isn't rolling upgradable too). Of course, this is no different than if you were in 3, 3-node clusters.
In short, I can't find any reason to "break up" the nodes into multiple clusters. I'd put all of them in a single cluster which I think will ultimately increase the overall availability of the total environment.
Dan Yavor Ivanov wrote:
Usualy I would go with single 9-node cluster too. Same reasons. But
there are some more things to consider here.
Think about cluster upgrades. If you have one cluster to upgrade, this
sounds like single downtime window. But what if one database needs a newer
version (and newer clusterware), and the other cannot afford downtime at that
moment? This is something rare, but it's not bad to think of it.
Also, some influences may come from your backup / DR strategy. But this
goes too deep, and gives too little value.
But as I've said, I'd usually go to 9-node with every app running on
different nodes.
Regards,
Yavor Ivanov
Oracle Certified Master
-- //www.freelists.org/webpage/oracle-l
