This section provides guidelines for planning and preparing the following components for Disaster Recovery framework software installation:
Ensure that you have available all necessary license certificates before you begin software installation. The Disaster Recovery framework software does not require a license certificate. However, each node that is installed with Disaster Recovery framework software must be covered under your Oracle Solaris Cluster software license agreement.
For licensing requirements for data replication software and application software, see the installation documentation for those products.
The Disaster Recovery framework uses the logical hostname of a cluster for inter-cluster management communication and heartbeat communication. The IP address for a cluster name must be available for the Disaster Recovery framework to wrap a logical hostname around the IP address when the software is started by using the geoadm start command.
You can use the cluster command to find the name of the cluster when you need to verify that the cluster name is suitable for use as a hostname. To find the name of the cluster, run the following command:
# cluster list
For more information, see the cluster(8CL) man page.
In some Disaster Recovery framework configurations, a zone cluster can be configured as a cluster partner. Observe the following guidelines for the use of zone clusters in a cluster partnership.
Public-network IP addresses - A zone cluster that is configured in a Disaster Recovery framework configuration must meet the following public-network requirements:
Each zone-cluster node must have a public-network IP address that corresponds to the zone-cluster node's hostname.
The zone-cluster node's public-network IP address must be accessible by all nodes in the Disaster Recovery framework configuration's partner cluster.
Each zone-cluster node must have a failover IP address that maps to the hostname that corresponds to the zone-cluster name.
Mixed cluster types – The partnership can use other zone clusters or a combination of zone clusters and global clusters.
Framework packages – The Disaster Recovery framework packages are required in the global zones in all cases, even if the Disaster Recovery framework is only going to be enabled in the zone clusters. The Disaster Recovery framework group package is ha-cluster/geo/geo-framework.
Starting the infrastructure – You can start the disaster recovery framework from within a zone cluster node, but not from within any other type of non-global zone.
The Disaster Recovery framework enables clusters to form partnerships between clusters to provide mutual protection against disasters. The clusters in a partnership monitor each other by sending heartbeat messages to each other in the same way that nodes of a single cluster do. Unlike local clusters, the clusters in a partnership use the public network for these messages, but support additional, plug-in mechanisms as well.
You create only one partnership between two specific clusters by using the geops(8) command. After you have created a partnership, you can use this command to modify the properties of this partnership.
Observe the following guidelines:
Unique cluster names – When creating partnerships, ensure that the name of all the clusters in the partnership are unique. For example, if you have a cluster wholly within the domain .france, you can use hostnames like paris and grenoble. However, if you have a cross-domain cluster, you must specify the hostnames with enough qualification to identify the host on the network. For example:
You can link paris and munich with hostnames paris.france and munich.germany, and the cluster names remain paris and munich.
You cannot create a partnership between clusters paris.france and paris.texas because of a collision on the cluster name paris.
Application resource group names – The names of the application resource groups that are managed by the Disaster Recovery framework must be the same on both partner clusters. You can configure the names of these resource groups manually.
Single partnership between cluster pairs – You can define only one partnership between two specific clusters. A single cluster can participate in other partnerships with different clusters.
Device groups – You cannot add device groups to a protection group that does not use data replication.
Protection groups enable a set of clusters to tolerate and recover from disaster by managing the resource groups for services. A protection group contains application resource groups and properties for managing data replication for those application resource groups.
Observe the following general guidelines when you configure a protection group:
Partnerships – You must create a partnership before you can create a protection group for that partnership. Protection groups can exist only in a partnership.
Unique naming – Protection groups must have unique name across partnerships. If this is not the case the protection group will go to mismatch state.
Duplicate application resource group configuration – You can duplicate the application resource group configuration on partner clusters. The configuration for a protection group is identical on partner clusters, so partner clusters must have the application resource groups of the protection group defined in their configuration. The Disaster Recovery framework propagates protection group configurations between partners.
Data replication – You can specify a data replication type in the protection group to indicate the mechanism that is used for data replication between partner clusters. When a service is protected from disaster by data replication, the protection group also contains replication resource groups. Protection groups link an application in a resource group with the application data that should be replicated. This linkage and replication enable the application to fail over seamlessly from one cluster to another cluster.
Replicating the Oracle Solaris boot environment – Do not replicate an Oracle Solaris boot environment between two systems. Doing so is not appropriate for disaster recovery environments, as it might introduce instability in the target boot environment.
Application resource groups – Certain rg_affinities settings, such as the "++" affinity will disallow the dependee resource group from going to the unmanaged state if the dependent resource group is not in unamanaged state. Some resource dependencies (such as resource_dependencies_offline_restart) will result in the dependee resource going offline if the dependent resource is brought offline. A protection group switchover disables application resources in the resource groups it contains, then offlines these resource groups and lastly, it unmanages these resource groups. If any of these operations fail, the switchover will fail. If you must keep dependent resource groups outside of the protection group managing dependee resource group(s), the protection group's External_Dependency_Allowed property must be set to true. In addition, consider the following options:
Put dependent resource groups in other protection group(s), then put these protection groups in the same multigroup as the dependee protection group with dependency from protection group that contains dependent resource group(s) on this dependee protection group. To initiate a switchover use the geomg command with the multigroup and not geopg with the individual protection groups.
If you keep the dependent resource groups outside of protection groups, you will always always need to bring them to the unmanaged state before initiating the switchover of the protection groups containing the dependee resource groups.
Each data replication product has its own additional requirements when configuring a protection group. For more information, see the appropriate Oracle Solaris Cluster guide for the data replication software that you will use:
Oracle Solaris Cluster Data Replication Guide for Oracle Data Guard
Oracle Solaris Cluster Data Replication Guide for ZFS Snapshots
Oracle Solaris Cluster Remote Replication Guide for Oracle ZFS Storage Appliance
A site is a group of clusters for which you want to manage sets of protection groups, or multigroup, in a single operation. When you perform a switchover or takeover of a multigroup, a site is specified as the target.
Observe the following general guidelines when you configure a site:
First site controller – The cluster from which you create a new site is automatically configured as a site controller.
Multiple controllers – To avoid a single point of failure, configure at least two controller clusters in a site.
Zone clusters – A zone cluster can be a site member.
Remote management of an Oracle Data Guard database – A cluster can be configured with a protection group to manage a remote Oracle Data Guard Database instance that is not running on an Oracle Solaris Cluster configuration.
A multigroup is a set of protection groups that you can manage in a single operation.
Observe the following general guidelines when you configure a multigroup:
Single site – All protection groups in a multigroup must be configured on clusters that are part of the same site.
Unique name – Multigroup names must be unique throughout the site. In addition, if multiple sites share a common cluster, those sites cannot contain multigroups of the same name.
Site-to-cluster configurations – A multigroup can consist of protection groups where one of the partner clusters is not configured in a site. In such a configuration, multigroup operations can only be performed from a cluster that is in a site. To manage protection groups from the partner cluster that is not in a site, you must manage the protection groups individually using the geopg command.
Protection group dependencies – One or more protection groups can be configured to have a strong dependency on a third protection group in the multigroup. When the protection groups in a multigroup are taken offline for a switchover or takeover, the depended-on protection group is taken offline after the protection groups that depend on it are taken offline. And when a multigroup is brought online, the depended-on protection group is brought online before the protection groups with a dependency on it are brought online.
Nested protection group dependencies – A protection group that other protection groups depend on can itself have a dependency on another protection group.
Single dependency – A protection group cannot have a direct dependency on more than one protection group.