What You See Is What You Get Element

How Oracle Solaris Cluster Geographic Edition Simplifies the Upgrade Process

Part VIII of How to Upgrade to Oracle Solaris Cluster 4.0

by Tim Read

Published May 2012

Part I - Overview of the Example Configuration
Part II - Configuring the Oracle Database for Clustering
Part III - Installing the Target Cluster
Part IV - Creating the Zone Cluster
Part V - Installing the New Application Software Stack
Part VI - Creating the Standby Database
Part VII - Creating the Oracle Solaris Cluster Geographic Edition Configuration
Part VIII - How Oracle Solaris Cluster Geographic Edition Simplifies the Upgrade Process

This article describes the advantages of Oracle Solaris Cluster Geographic Edition. For more information about Oracle Solaris Cluster, see the Oracle Solaris Cluster Website.

Advantages of Oracle Solaris Cluster Geographic Edition

Legal, financial, or customer satisfaction and loyalty reasons determine whether an application must be part of a disaster recovery strategy. In addition, the diversity of application components, data center technology standards, and replication technology determine how data from each application tier is replicated.

The Oracle Solaris Cluster software has a layered component called Oracle Solaris Cluster Geographic Edition, which supports a wide range of host-based replication, storage-based replication, and application-based replication technologies, including Oracle Active Data Guard for Oracle databases.

Oracle Solaris Cluster Geographic Edition software provides a consistent interface for the process of switching over data processing between data centers. A manually initiated, automated process orchestrates the orderly shut down of the resource groups that contain the application components on the cluster in the main data center. Then the software reverses the direction of data replication before bringing the resource group back online at the second (backup) data center. In the event of a real disaster, the software can also forcibly take over control of a resource group and safely bring it online on at the second data center; however, the software does not reverse the data replication in this case. Two possible recovery options are then available.

Unlike the stretched clusters in Oracle Solaris Cluster configurations, Oracle Solaris Cluster Geographic Edition configurations consist of two or more distinct clusters, and the software does not perform automatic failovers. Instead, a decision must be made as to whether taking over the production workload at the backup data center is the most appropriate course of action. When asynchronous replication is used, there is a high probability that data will have been lost, because it might not have been replicated prior to the disaster. By not switching operations immediately, you have the option of manually entering any lost transactions prior to restarting the service.

By simplifying to a single command the multiple steps that would normally be involved in switching over a configuration, Oracle Solaris Cluster Geographic Edition enables you to rehearse recovery procedures regularly and with greater confidence, so you can implement your disaster recovery plan if the need arises.

Supported Replication Technologies

Oracle Solaris Cluster Geographic Edition supports a range of host-based, application-based, and storage-based replication technologies including the following:

  • StorageTek Availability Suite from Oracle
  • Oracle Active Data Guard
  • MySQL replication
  • EMC Symmetrix Remote Data Facility (SRDF)
  • Hitachi Data Systems TrueCopy and Universal Replicator

These technologies enable you replicate data continuously to a second site, either synchronously or asynchronously.

Two business objectives can help you determine whether to use synchronous or asynchronous replication:

  • The Recovery Point Objective (RPO), which is how much data you can afford to lose if a disaster occurs
  • The Recovery Time Objective (RTO), which is how much delay you can tolerate before recovery is complete

The sum of your RPO plus your RTO is the Maximum Tolerable Period of Disruption (MTPD).

Using synchronous replication might constrain the distance between the primary and backup sites, because the additional I/O latency incurred due to the intersite link can have a significant impact on application performance. Therefore, you might be forced to make some trade-offs between the business objectives and the need to protect against disasters.

Extensibility: Supporting New Data Replication Mechanisms

Given the broad range of technologies in any data center, it is always possible that a data replication mechanism needs to be supported for which no Geographic Edition replication module exists. The Script-Based Plugin (SBP) module was developed to meet this need.

The SBP module is the Geographic Edition equivalent of the Generic Data Service (GDS) component of Oracle Solaris Cluster, except that many more scripts or programs must be defined to enable it to function properly. These scripts enable the SBP module to start, stop, and reverse the direction of the replication, among other things.

This module has already been used to develop new Oracle Solaris Cluster Geographic Edition modules for MySQL replication and storage-based replication for a third-party storage array for which no module existed. By using the SBP module, the replication module developers did not have to be familiar with the internals of the Oracle Solaris Cluster Geographic Edition software, enabling them to focus on the replication technology instead.


This eight-part article described some of the important features of the Oracle Solaris Cluster and Oracle Solaris Cluster Geographic Edition software. It provided a step-by-step example of how a relatively simple cold-failover Oracle database can be upgraded from an Oracle Solaris 10 and Oracle Solaris Cluster 3.3 5/11 cluster to an Oracle Solaris 11 and Oracle Solaris Cluster 4.0 configuration. The procedure reduced the impact on the original database service to an absolute minimum and also provided a back-out option in case any problems were discovered in the new configuration.

Although the example demonstrated how Oracle Solaris Cluster Geographic Edition can be used for upgrade purposes, the primary role of the product is to provide data centers with disaster recovery capabilities. By implementing this upgrade process, the example upgrade provided the ideal starting point for deploying full disaster recovery capabilities. All that remains for achieving this goal is to remove the original cluster from the Oracle Solaris Cluster Geographic Edition configuration, upgrade it to the Oracle Solaris 11 and Oracle Solaris Cluster 4.0 software, and then re-introduce it into the Oracle Solaris Cluster Geographic Edition configuration. Once again, this upgrade can be achieved with minimal impact on your applications and will result in a system that has full disaster recovery protection.

See Also

Here are URLs for the resources referenced earlier in this series of articles:

And here are some additional resources:

About the Author

Tim Read has worked in the UK computer industry since 1985. He joined Sun Microsystems in 1990 and now works as a software developer in Oracle's Solaris Availability Engineering group. He has written and coauthored many Sun BluePrints and white papers, including "Designing Enterprise Solutions with Sun Cluster 3.0." He holds a joint honours degree in physics with astrophysics from the University of Birmingham. When not working, he enjoys running, tandem riding, and exploring the islands of the Outer Hebrides in northwest Scotland.

Revision 1.0, 05/01/2012

Follow us on Facebook, Twitter, or Oracle Blogs.