This section provides guidelines for planning and preparing the following components for Geographic Edition software installation:
Ensure that you have available all necessary license certificates before you begin software installation. Geographic Edition software does not require a license certificate. However, each node that is installed with Geographic Edition software must be covered under your Geographic Edition software license agreement.
For licensing requirements for data replication software and application software, see the installation documentation for those products.
The Geographic Edition framework uses the logical hostname of a cluster for intercluster management communication and heartbeat communication. The IP address for a cluster name must be available for the Geographic Edition framework to wrap a logical hostname around the IP address when the framework is started by using the geoadm start command.
To find the name of the cluster when you need to verify that the cluster name is suitable for use as a hostname, run the following command:
# cluster list
For more information, see the cluster(1CL) man page.
In some Geographic Edition 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 Geographic Edition 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 Geographic Edition 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.
Data replication requirements – Zone clusters can be cluster partners in a Geographic Edition configuration that meets either of the following conditions:
Application-based data replication is used. Geographic Edition supports Oracle Data Guard, Oracle GoldenGate, MySQL, and Geographic Edition script-based plug-ins application-based data replication.
EMC Symmetrix Remote Data Facility storage-based replication is used.
No data replication is used.
Mixed cluster types – The partnership can use other zone clusters or a combination of zone clusters and global clusters.
Framework package – The Geographic Edition framework package is required in the global zones in all cases, even if Geographic Edition is going to be enabled only in the zone clusters. The Geographic Edition framework package is ha-cluster/geo/geo-framework.
Storage-based replication – If storage-based replication is used, with the exception of Oracle ZFS Storage Appliance replication, all members of a cluster partnership must be global clusters. Zone clusters can exist in a global-cluster partnership that uses storage-based replication, but the zone clusters themselves cannot be members of a partnership that uses storage-based replication.
If Oracle ZFS Storage Appliance replication is used, members of a cluster partnership can be global clusters, zone clusters, or a combination of the two.
Starting the framework – You can start the Geographic Edition framework from within a zone cluster node, but not from within any other type of non-global zone.
Oracle Solaris Cluster Manager – You cannot use the Oracle Solaris Cluster Manager browser interface to manage Geographic Edition components of a zone cluster that is a partnership member.
You can create 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 a partnership between two specific clusters by using the geops(1M) command. After you have created a partnership, you can use this command to modify the properties of the 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 Geographic Edition 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.
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 Geographic Edition framework propagates protection group configurations between partners.
Data replication – You can specify a data replication type in the protection group to indicate the mechanism to use 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.
Each data replication product has its own additional requirements when configuring a protection group. For more information, see the appropriate Geographic Edition manual for the data replication software that you will use:
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 be performed only 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 by using the geopg command.
Protection group dependencies – You can configure one or more protection groups 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. 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.