Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Cluster Geographic Edition Data Replication Guide for Sun StorageTek Availability Suite |
1. Replicating Data With Sun StorageTek Availability Suite Software
2. Administering Sun StorageTek Availability Suite Protection Groups
3. Migrating Services That Use Sun StorageTek Availability Suite Data Replication
Detecting Cluster Failure on a System That Uses Sun StorageTek Availability Suite Data Replication
Detecting Primary Cluster Failure
Detecting Secondary Cluster Failure
Migrating Services That Use Sun StorageTek Availability Suite With a Switchover
How to Switch Over a Sun StorageTek Availability Suite Protection Group From Primary to Secondary
Actions Performed by the Geographic Edition Software During a Switchover
Forcing a Takeover on Systems That Use Sun StorageTek Availability Suite
How to Force Immediate Takeover of Sun StorageTek Availability Suite Services by a Secondary Cluster
Actions Performed by the Geographic Edition Software During a Takeover
Recovering Sun StorageTek Availability Suite Data After a Takeover
How to Resynchronize and Revalidate the Protection Group Configuration
Recovering From a Sun StorageTek Availability Suite Data Replication Error
How to Recover From a Data Replication Error
A. Geographic Edition Properties for Sun StorageTek Availability Suite
After a successful takeover operation, the secondary cluster, cluster-newyork, becomes the primary for the protection group and the services are online on the secondary cluster. After the recovery of the original primary cluster, the services can be brought online again on the original primary by using a process called failback.
Geographic Edition software supports the following two kinds of failback:
Failback-switchover. During a failback-switchover, applications are brought online again on the original primary cluster, cluster-paris, after the data of the primary cluster has been resynchronized with the data on the secondary cluster, cluster-newyork.
For a reminder of which clusters are cluster-paris and cluster-newyork, see Example Geographic Edition Cluster Configuration in Oracle Solaris Cluster Geographic Edition System Administration Guide.
Failback-takeover. During a failback-takeover, applications are brought online again on the original primary cluster and use the current data on the primary cluster. Any updates that occurred on the secondary cluster are discarded.
If you want to leave the new primary, cluster-newyork, as the primary cluster and the original primary cluster, cluster-paris, as the secondary after the original primary starts again , you can resynchronize and revalidate the protection group configuration without performing a switchover or takeover.
This section provides the following information:
Use this procedure to resynchronize and revalidate data on the original primary cluster, cluster-paris, with the data on the current primary cluster, cluster-newyork.
Before You Begin
Before you resynchronize and revalidate the protection group configuration, a takeover has occurred on cluster-newyork. The clusters now have the following roles:
If the original primary cluster, cluster-paris, has been down, confirm that the cluster is booted and that the Geographic Edition infrastructure is enabled on the cluster. For more information about booting a cluster, see Booting a Cluster in Oracle Solaris Cluster Geographic Edition System Administration Guide.
The protection group on cluster-newyork has the primary role.
The protection group on cluster-paris has either the primary role or secondary role, depending on whether cluster-paris could be reached during the takeover from cluster-newyork.
The cluster cluster-paris forfeits its own configuration and replicates the cluster-newyork configuration locally. Resynchronize both the partnership and protection group configurations.
# geopg stop -e Local protectiongroupname
Specifies the scope of the command.
By specifying a local scope, the command operates on the local cluster only.
Specifies the name of the protection group.
If the protection group is already deactivated, the state of the resource group in the protection group is probably Error. The state is Error because the application resource groups are managed and offline.
Deactivating the protection group results in the application resource groups no longer being managed, clearing the Error state.
# geops update partnershipname
Specifies the name of the partnership
Note - You need to perform this step only once, even if you are resynchronizing multiple protection groups.
For more information about synchronizing partnerships, see Resynchronizing a Partnership in Oracle Solaris Cluster Geographic Edition System Administration Guide.
Because the role of the protection group on cluster-newyork is primary, this step ensures that the role of the protection group on cluster-paris is secondary.
# geopg update protectiongroupname
Specifies the name of the protection group
For more information about synchronizing protection groups, see Resynchronizing a Sun StorageTek Availability Suite Protection Group.
# geopg validate protectiongroupname
Specifies a unique name that identifies a single protection group
For more information, see How to Validate a Sun StorageTek Availability Suite Protection Group.
When you activate a protection group, its application resource groups are also brought online.
# geopg start -e Global protectiongroupname
Specifies the scope of the command.
By specifying a Global scope, the command operates on both clusters where the protection group is deployed.
Specifies the name of the protection group.
Caution - Do not use the -n option because the data needs to be synchronized from the current primary, cluster-newyork, to the current secondary, cluster-paris. Because the protection group has a role of secondary, the data is synchronized from the current primary, cluster-newyork, to the current secondary, cluster-paris. For more information about the geopg start command, see How to Activate a Sun StorageTek Availability Suite Protection Group. |
First, confirm that the state of the protection group on cluster-newyork is OK.
phys-newyork-1# geoadm status
Refer to the Protection Group section of the output.
Next, confirm that all resources in the replication resource group, AVSprotectiongroupname-rep-rg, report a status of OK.
phys-newyork-1# clresource status -v AVSdevicegroupname-rep-rs
Use this procedure to restart an application on the original primary cluster, cluster-paris, after the data on the cluster has been resynchronized with the data on the current primary cluster, cluster-newyork.
The failback procedures apply only to clusters in a partnership. You need to perform the following procedure only once per partnership.
Before You Begin
Before you perform a failback-switchover, a takeover has occurred on cluster-newyork. The clusters now have the following roles:
If the original primary cluster, cluster-paris, has failed, confirm that the cluster is booted and that the Geographic Edition infrastructure is enabled on the cluster. For more information about booting a cluster, see Booting a Cluster in Oracle Solaris Cluster Geographic Edition System Administration Guide.
The protection group on cluster-newyork has the primary role.
The protection group on cluster-paris has either the primary role or secondary role, depending on whether cluster-paris could be reached during the takeover from cluster-newyork.
The cluster cluster-paris forfeits its own configuration and replicates the cluster-newyork configuration locally. Resynchronize both the partnership and protection group configurations.
phys-paris-1# geops update partnershipname
Specifies the name of the partnership
Note - You need to perform this step only once per partnership, even if you are performing a failback-switchover for multiple protection groups in the partnership.
For more information about synchronizing partnerships, see Resynchronizing a Partnership in Oracle Solaris Cluster Geographic Edition System Administration Guide.
phys-paris-1# geoadm status
phys-paris-1# geopg stop -e local protectiongroupname
Specifies the scope of the command.
By specifying a local scope, the command operates on the local cluster only.
Specifies the name of the protection group.
If the protection group is already deactivated, the state of the resource group in the protection group is probably Error. The state is Error because the application resource groups are managed and offline.
Deactivating the protection group results in the application resource groups no longer being managed, clearing the Error state.
phys-paris-1# geoadm status
Because the local role of the protection group on cluster-newyork is now primary, this steps ensures that the role of the protection group on cluster-paris becomes secondary.
phys-paris-1# geopg update protectiongroupname
Specifies the name of the protection group
For more information about synchronizing protection groups, see Resynchronizing a Sun StorageTek Availability Suite Protection Group.
A protection group cannot be started when it is in a error state. Ensure that the protection group is not in an error state.
phys-paris-1# geopg validate protectiongroupname
Specifies a unique name that identifies a single protection group
For more information, see How to Validate a Sun StorageTek Availability Suite Protection Group.
When you activate a protection group, its application resource groups are also brought online.
phys-paris-1# geopg start -e Global protectiongroupname
Specifies the scope of the command.
By specifying a Global scope, the command operates on both clusters where the protection group is deployed.
Specifies the name of the protection group.
Caution - Do not use the -n option when performing a failback-switchover because the data needs to be synchronized from the current primary, cluster-newyork, to the current secondary, cluster-paris. Because the protection group has a role of secondary, the data is synchronized from the current primary, cluster-newyork, to the current secondary, cluster-paris. For more information about the geopg start command, see How to Activate a Sun StorageTek Availability Suite Protection Group. |
First, confirm that the state of the protection group on cluster-newyork is OK.
phys-newyork-1# geoadm status
Refer to the Protection Group section of the output.
Next, confirm that all resources in the replication resource group, AVSprotectiongroupname-rep-rg, report a status of OK.
phys-newyork-1# clresource status -v AVSdevicegroupname-rep-rs
# geoadm status
# geopg switchover [-f] -m clusterparis protectiongroupname
For more information, see How to Switch Over a Sun StorageTek Availability Suite Protection Group From Primary to Secondary.
cluster-paris resumes its original role as primary cluster for the protection group.
Verify that the protection group is now primary on cluster-paris and secondary on cluster-newyork and that the state for “Data replication” and “Resource groups” is OK on both clusters.
# geoadm status
Check the runtime status of the application resource group and data replication for each Sun StorageTek Availability Suite protection group.
# clresourcegroup status -v resourcegroupname # clresource status -v AVSdevicegroupname-rep-rs
Refer to the Status and Status Message fields that are presented for the data replication device group you want to check. For more information about these fields, see Table 2-1.
For more information about the runtime status of data replication, see Checking the Runtime Status of Sun StorageTek Availability Suite Data Replication.
Use this procedure to restart an application on the original primary cluster, cluster-paris, and use the current data on the original primary cluster. Any updates that occurred on the secondary cluster, cluster-newyork, while it was acting as primary are discarded.
The failback procedures apply only to clusters in a partnership. You need to perform the following procedure only once per partnership.
Note - Conditionally, you can resume using the data on the original primary, cluster-paris. You must not have replicated data from the new primary, cluster-newyork, to the original primary cluster, cluster-paris, at any point after the takeover operation on cluster-newyork.
Before You Begin
Before you begin the failback-takeover operation, the clusters have the following roles:
If the original primary cluster, cluster-paris, has failed, confirm that the cluster is booted and that the Geographic Edition infrastructure is enabled on the cluster. For more information about booting a cluster, see Booting a Cluster in Oracle Solaris Cluster Geographic Edition System Administration Guide.
The protection group on cluster-newyork has the primary role.
The protection group on cluster-paris has either the primary role or secondary role, depending on whether the protection group could be reached during the takeover.
cluster-paris forfeits its own configuration and replicates the cluster-newyork configuration locally.
phys-paris-1# geops update partnershipname
Specifies the name of the partnership
Note - You need to perform this step only once per partnership, even if you are performing a failback-takeover for multiple protection groups in the partnership.
For more information about synchronizing partnerships, see Resynchronizing a Partnership in Oracle Solaris Cluster Geographic Edition System Administration Guide.
phys-paris-1# geoadm status
phys-paris-1# geopg stop -e local protectiongroupname
phys-paris-1# geoadm status
If the protection group has been activated, deactivate the protection group by using the geopg stop command. For more information about deactivating a protection group, see How to Deactivate a Sun StorageTek Availability Suite Protection Group.
phys-paris-1# geopg update protectiongroupname
Specifies the name of the protection group
For more information about synchronizing protection groups, see How to Resynchronize a Sun StorageTek Availability Suite Protection Group.
Ensure that the protection group is not in an error state. A protection group cannot be started when it is in an error state.
phys-paris-1# geopg validate protectiongroupname
Specifies a unique name that identifies a single protection group
For more information, see How to Validate a Sun StorageTek Availability Suite Protection Group.
Because the protection group on cluster-paris has a role of secondary, the geopg start command does not restart the application on cluster-paris.
phys-paris-1# geopg start -e local -n protectiongroupname
Specifies the scope of the command.
By specifying a local scope, the command operates on the local cluster only.
Prevents the start of data replication at protection group startup.
Note - You must use the -n option.
Specifies the name of the protection group.
For more information, see How to Activate a Sun StorageTek Availability Suite Protection Group.
Replication from cluster-newyork to cluster-paris is not started because the -n option is used on cluster-paris.
phys-paris-1# geopg takeover [-f] protectiongroupname
Forces the command to perform the operation without your confirmation
Specifies the name of the protection group
For more information about the geopg takeover command, see How to Force Immediate Takeover of Sun StorageTek Availability Suite Services by a Secondary Cluster.
The protection group on cluster-paris now has the primary role, and the protection group on cluster-newyork has the secondary role.
Because the protection group on cluster-newyork has a role of secondary, the geopg start command does not restart the application on cluster-newyork.
phys-newyork-1# geopg start -e local [-n] protectiongroupname
Specifies the scope of the command.
By specifying a local scope, the command operates on the local cluster only.
Prevents the start of data replication at protection group startup.
If you omit this option, the data replication subsystem starts at the same time as the protection group.
Specifies the name of the protection group.
For more information about the geopg start command, see How to Activate a Sun StorageTek Availability Suite Protection Group.
To start data replication, activate the protection group on the primary cluster, cluster-paris.
phys-paris-1# geopg start -e local protectiongroupname
For more information about the geopg start command, see How to Activate a Sun StorageTek Availability Suite Protection Group.
# geoadm status
# clresourcegroup status -v resourcegroupname # clresource status -v AVSdevicegroupname-rep-rs
Refer to the Status and Status Message fields that are presented for the data replication device group you want to check. For more information about these fields, see Table 2-1.
For more information about the runtime status of data replication, see Checking the Runtime Status of Sun StorageTek Availability Suite Data Replication.