Sunday May 17, 2015

New white paper available: Providing High Availability to the OpenStack Cloud Controller on Oracle Solaris with Oracle Solaris Cluster

Oracle Solaris delivers a complete OpenStack distribution which is integrated with its core technologies such as Oracle Solaris Zones, the ZFS file system, and its image packaging system (IPS). OpenStack in Oracle Solaris 11.2 helps IT organizations to create an enterprise-ready Infrastructure as a Service (IaaS) cloud, so that users can quickly deploy virtual networking and compute resources by using a centralized web-based portal.

Of course any enterprise-class OpenStack deployment requires a highly available OpenStack infrastructure that can sustain individual system failures.

Oracle Solaris Cluster is deeply integrated with Oracle Solaris technologies and delivers high availability to Oracle Solaris based OpenStack services through a rich set of features.

The primary goals of the Oracle Solaris Cluster software are to maximize service availability through fine-grained monitoring and automated recovery of critical services and to prevent data corruption through proper fencing. The services covered include networking, storage, virtualization used by the OpenStack cloud controller and its own components.

Our team has created a new white paper to specifically explain how to provide high availability to the OpenStack cloud controller on Oracle Solaris with Oracle Solaris Cluster.

After describing an example for a highly available physical node OpenStack infrastructure deployment, a detailed and structured walk-through over the high availability cloud controller configuration is provided. It discusses each OpenStack component that runs on the cloud controller, with explicit steps on how to create and configure these components under cluster control. The deployment example achieves secure isolation between services, while defining all the required dependencies for proper startup and stopping between services which is orchestrated by the cluster framework.

The white paper is linked from the OpenStack Cloud Management page as well as from the Oracle Solaris Cluster Technical Resources page on the Oracle Technology Network portal.

Thorsten Früauf
Oracle Solaris Cluster Engineering

Thursday Jan 15, 2015

Managing a remote Oracle Database instance with "Geographic Edition"

Another new feature of Oracle Solaris Cluster Geographic Edition

A few weeks ago I wrote about a new feature for Geographic Edition: DR Orchestration, which we added in Oracle Solaris Cluster 4.2.  With the latest update to 4.2, SRU1, we've completed the testing of another Geographic Edition feature which can make DR Orchestration even more useful - we can now support Oracle Data Guard replication control for a remote database.

As I described before, a multigroup can combine several protection groups so that they can be switched together in a coordinated manner. That enables a service constructed out of multiple tiers, on multiple clusters, to be managed as a unit.

Since each tier is represented by a protection group it might seem necessary that each tier be running Oracle Solaris Cluster, which could be inconvenient if one of the tiers is running only an Oracle RAC database. There is no absolute requirement to use Oracle Solaris Cluster in that configuration; the systems might not be running any cluster software, or perhaps running Oracle RAC Clusterware.  An example of such a configuration is the Oracle SuperCluster Engineered System.

In practice, however, we can use some features of Oracle Solaris Cluster and the Oracle Database to include such a tier in an orchestrated Geographic Edition configuration.  The two features we're using are:

  • The Oracle Solaris Cluster data service for Oracle External Proxy (HA for Oracle External Proxy)
  • Remote database connectivity

HA for Oracle External Proxy

This is a data service which can be used to reflect the status of an Oracle database which is running on a remote system, so that local Oracle Solaris Cluster resources and resource groups can associate dependencies with it.  You can find more information about it at:

Remote Database Connectivity

This is a standard feature of the Oracle Database.  A service name that is configured in the TNSNAMES.ORA file can identify a database that is running on a remote system, so that control operations from local sqlplus and dgmgrl (Data Guard broker) commands will operate on the remote database instance.  To take advantage of this you don't even need to install a full Oracle database locally, you can just install the Oracle Database Client software, see:

Put these together, and...

By using these two features together you can now create a local Geographic Edition protection group (PG) that uses Oracle Data Guard replication, but which manages a database instance on a remote system.  You just need to provide the name of a resource group that contains an external proxy resource, instead of an Oracle RAC or failover database resource.  As far as the cluster configuration is concerned, this behaves just like an ordinary local protection group, and so it can be included in a multigroup as part of a DR Orchestration configuration. When you switch over that multigroup, the software will contact all the systems configured in the protection group, local and remote.

Now you can fully orchestrate all tiers of a service and control them from a system that is part of an Oracle Solaris Cluster configuration, even if the database tier is on a system that isn't running Oracle Solaris Cluster.

Geographic Edition team
Oracle Solaris Cluster Engineering

Tuesday Nov 25, 2014

Disaster Recovery Orchestration

With the increasing use of virtualization and cloud-based services, a service might no longer be confined to a single cluster. Disaster Recovery Orchestration enables an administrator to control multiple service tiers, on multiple clusters, with a single command.[Read More]

Tuesday Sep 16, 2014

Oracle Solaris Cluster and Oracle GoldenGate

Detlef Ulherr

With Oracle Solaris Cluster we provide an agent for Oracle GoldenGate. This agent provides high availability for the GoldenGate application.  With the Oracle Solaris Cluster GoldenGate agent you can configure the GoldenGate software to replicate databases controlled by Oracle Solaris Cluster. The replication partner can be located either on a cluster node of the same cluster, on a different cluster, or a non clustered system. The Oracle Solaris Cluster agent for GoldenGate does not impose any restriction on the possible Oracle GoldenGate replication topologies, so there is no difference in regards of Oracle GoldenGate replication topologies between a clustered and a non clustered system.

With this new agent you can integrate Oracle GoldenGate together with the replication source or replication target database in Oracle Solaris Cluster. To accomplish this you must make the database highly available using an Oracle Solaris Cluster agent for your database. If no agent is available for this database you can easily create one using the Generic Data Service Version 2 shipped by Oracle Solaris Cluster 4.2.

The Oracle Solaris Cluster agent for GoldenGate can be configured in failover and multiple master configurations. Beside the obvious shared storage topologies for failover configurations, you can implement shared nothing topologies with multiple master configurations, if the Oracle GoldenGate replication satisfies your requirements.

The documentation for the GoldenGate agent is available at:

One possible configuration would be:

Friday Sep 12, 2014

Oracle Database 12c Agent: new features

The Oracle Solaris Cluster 4.2 release contains several enhancements to the Oracle Database-related agents. These enhancements improve availability by allowing finer-grained dependencies and by enabling new Oracle Database features.

Support for Policy-Managed Databases

Policy-managed databases is a feature that was introduced in Oracle Real Applications Clusters 11g release 2. This feature enables the database administrator to establish policies that govern how many database instances are running in the cluster and on which nodes.

We have enhanced the existing SUNW.scalable_rac_server_proxy resource type to support policy-managed databases, in addition to the traditional administrator-managed databases. These changes do require that existing resources of the SUNW.scalable_rac_server_proxy resource type be upgraded, to accommodate the changes that have been made. Also, a manual step must be performed prior to the resource-type upgrade.

See "Upgrading Resources in Support for Oracle RAC" in Oracle Solaris Cluster Data Service for Oracle Real Application Clusters ( for procedures to recreate the Oracle Grid Infrastructure sun.storage_proxy_type resource type and resources, and then upgrade the SUNW.scalable_rac_server_proxy resource type.

Support for the Oracle RAC Services Feature

Enhancements have been made to the existing HA for Oracle External Proxy agent to enable the agent to work with the services feature of Oracle RAC. These changes enable an Oracle RAC service to be represented by a proxy resource in Oracle Solaris Cluster, so that other resources can establish dependencies at a finer granularity than the database.

Support for CDBs and PDBs

Another benefit to the enhancement to support Oracle RAC services is the ability to now support multitenant container databases (CDB) and pluggable databases (PDB), new features that were introduced in Oracle Database 12c. The PDBs are represented as a database service, which means that they can be used by creating an HA for Oracle External Proxy resource to represent them in the Oracle Solaris Cluster configuration.

Bob Bart
Oracle Solaris Cluster Engineering


Oracle Solaris Cluster Engineering Blog


« October 2015