By rickramsey on Aug 03, 2012
This gets complicated, so stop watching motoGP crash compilation videos for a sec.
We have Oracle Real Application Clusters (RAC). RAC lets you deploy a single Oracle Database across different servers. If the server in your Des Moines data center gets picked up by a tornado that hates you and dropped off in East Texas, the other servers pick up the load, and the database continues to operate without interruption. That's easy to understand.
We also have Oracle Solaris Cluster. It lets you deploy the Oracle Solaris operating system across different servers. If the server in your Barbados data center gets washed away by a hurricane that hates you and dropped off in West Africa, the other servers pick up the load, and the operating system continues to operate without interruption. A good quote:
White Paper: Extending Oracle Solaris for Business Continuity
"Oracle Solaris Cluster offers comprehensive and robust capabilities for keeping your business IT, including those running Oracle Database and Applications, up and running in the face of nearly every conceivable situation."
That's easy to understand, as well.
So why would somebody complicate our sysadmin lives by suggesting we install Oracle RAC on Oracle Solaris Cluster? What would that be, highly-available high availability?
Turns out that's not what they're suggesting. They're suggesting we install Oracle RAC not on Solaris Clusters, but on zone clusters. What's a zone cluster, you ask?
A zone cluster is a cluster created from Solaris zones that are physically located on different servers. That's similar to a regular cluster, but it uses zones instead of entire OS instances. Don't confuse a zone cluster with a failover cluster. Instead, read this white paper:
White Paper: Zone Clusters: How to Deploy Virtual Clusters and Why
This paper introduces the zone cluster, a virtual cluster in which an Oracle Solaris Zone is configured as a virtual node. The zone cluster supports the consolidation of multiple cluster applications on a single cluster.
That's all very interesting, but what about our original question:
Why would someone want to complicate our sysadmin lives by suggesting we install Oracle RAC on a zone cluster?
Turns out there two good reasons:
- It's a better high-availability solution for a multi-tier application environment
- It lets you isolate your database development, test, and deployment environments from each other.
How the Oracle RAC/Zone Cluster Combo Is Better For Multi-Tier Applications
Let's say that you are using your Oracle database as one tier in two different application environments. The first one is an HR application, the one second is an e-business suite. Both access the same database. Well, Oracle RAC would give you the high-availability for that database. But the applications would not be highly available. However, if you installed the database with Oracle RAC inside one zone cluster, and each application inside its own zone cluster, you'd make both application environments highly avaiable. And, if you limit the administrative privileges for each zone cluster, you'd get administrative isolation, as well.
How the Oracle RAC/Zone Cluster Combo Is Safer for Deployment
You've probably heard by now about Knight Capital Group's trading glitch that dropped the company's value by 50% in one day. I don't know exactly what happened, but I wonder if they didn't deploy either their development or their test environment instead of the one that was ready for prime time.
I suppose it's a sysadmin's duty to learn from another sysadmin's misfortune. So, if you divide your zone clusters into development, test, and deployment environments, you might have a better shot at avoiding a similar catastrophe. For example, install Oracle RAC with an Oracle DB into your development zone cluster, and keep it isolated from your test and deployment zone clusters. One sysadmin controls the development cluster. Another the test cluster. And the biggest, baddest sysadmin controls the deployment cluster. When the development environment is ready for testing, the test admin must OK the migration. That goes double for the deployment environment. And all the while, each environment remains highly available.
Turns out that Oracle and the portion of Oracle that was once Sun Microsystems have been collaborating on Oracle RAC/Solaris Cluster solutions for a long time. Customers like this approach so much that we just published three articles explaining how to do it. Each article covers a different version of the software:
|Article||RAC Version||Solaris Version||Cluster Version|
|How to Deploy Oracle RAC 188.8.131.52 on Oracle Solaris Zone Clusters||184.108.40.206||10||3.3|
|How to Deploy Oracle RAC 220.127.116.11 on Oracle Solaris Zone Clusters||18.104.22.168||10||3.3|
|How to Deploy Oracle RAC 22.214.171.124 on Oracle Solaris 11 Zone Clusters||126.96.36.199||11||4.0|
And if you want more, we also have a page full of links to all our Solaris Cluster how-to articles and background white papers:
Don't be the sysadmin who bankrupts your company in one day. Get educated.