Skip Navigation Links
Exit Print View
| Oracle Solaris Cluster Geographic Edition Remote Replication Guide for Sun ZFS Storage Appliance Oracle Solaris Cluster 4.1

Search Scope:

- This Document
- Entire Library

## Recovering Services to a Cluster on a System That Uses Sun ZFS Storage Appliance Replication

This section contains the following information:

- Overview of Recovering Services

- How to Resynchronize and Revalidate the Protection Group Configuration

- How to Perform a Failback-Switchover on a System That Uses Sun ZFS Storage Appliance Replication

- How to Perform a Failback-Takeover on a System That Uses Sun ZFS Storage Appliance Replication

### Overview of Recovering Services

After a successful takeover operation, the secondary cluster 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.

The Geographic Edition software supports the following kinds of failback:

- Failback-switchover. During a failback-switchover, applications are brought online again on the original primary cluster after the data of the original primary cluster was resynchronized with the data on the secondary cluster.

- Failback-takeover. During a failback-takeover, applications are brought online again on the original primary cluster and use the current data on the original primary cluster. Any updates that occurred on the secondary cluster while it was acting as primary are discarded.

If you want to leave the new primary as the primary cluster and the original primary cluster as the secondary after the original primary restarts, you can resynchronize and revalidate the protection group configuration without performing a switchover or takeover.

## How to Resynchronize and Revalidate the Protection Group Configuration

Use this procedure to resynchronize and revalidate data on the original primary cluster with the data on the current primary cluster.

Before You Begin

Before you resynchronize and revalidate the protection group configuration, a takeover has occurred on the current primary cluster. Ensure that the clusters now have the following roles:

- If the original primary cluster had been down, the cluster has been booted and 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 the current primary cluster has the `primary` role.

- The protection group on the original primary cluster has either the `primary` role or `secondary` role, depending on whether the protection group could be reached during the takeover.

This procedure uses the example names `cluster-paris` for the original primary cluster and `cluster-newyork` for the current primary cluster.

1. Resynchronize the original primary cluster with the current primary cluster.

   The `cluster-paris` cluster forfeits its own configuration and replicates the `cluster-newyork` configuration locally. Resynchronize both the partnership and protection group configurations.

   1. On `cluster-paris`, resynchronize the partnership.

          phys-paris-1# geops update ps-name

      ps-name

        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.

   2. On `cluster-paris`, resynchronize each protection group.

      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`.

          phys-paris-1# geopg update pg-name

      pg-name

        Specifies the name of the protection group.

      For more information about synchronizing protection groups, see Resynchronizing a Sun ZFS Storage Appliance Protection Group.

2. On `cluster-paris`, validate the cluster configuration for each protection group.

       phys-paris-1# geopg validate pg-name

   pg-name

     Specifies a unique name that identifies a single protection group.

   For more information, see How to Validate a Sun ZFS Storage Appliance Protection Group.

3. On `cluster-paris`, activate each protection group.

   When you activate a protection group, the protection group's application resource groups are also brought online.

       phys-paris-1# geopg start -e global pg-name

   `-e` `global`

     Specifies the scope of the command.

     By specifying a `global` scope, the command operates on both clusters where the protection group is located.

     Note - The property values, such as `global` and `local`, are not case sensitive.

   pg-name

     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, `cluster-newyork`, to the current standby cluster, `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 ZFS Storage Appliance Protection Group.

4. Confirm that the protection group configuration is OK.
   1. Confirm that the state of the protection group on `cluster-newyork` is `OK`.

          phys-newyork-1# geoadm status

      The protection group has a local state of `OK` when the Sun ZFS Storage Appliance components on `cluster-newyork` have a `Synchronized` pair state.

      Refer to the `Protection Group` section of the output.

   2. Confirm that all resources in the replication resource group, zfssa-rep-rg, report a status of `OK`.

          phys-newyork-1# clresource status -g zfssa-rep-rg

## How to Perform a Failback-Switchover on a System That Uses Sun ZFS Storage Appliance Replication

Use this procedure to restart an application on the original primary cluster, `cluster-paris`, after the data on this cluster has been resynchronized with the data on the current primary cluster, `cluster-newyork`.

Note - 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`. Ensure that the clusters have the following roles:

- If the original primary cluster had been down, the cluster has been 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 the current primary cluster has the `primary` role.

- The protection group on the original primary cluster has either the `primary` role or `secondary` role, depending on whether the original primary cluster can be reached during the takeover from the current primary cluster.

This procedure uses the example names `cluster-paris` for the original primary cluster and `cluster-newyork` for the current primary cluster.

1. Synchronize replication from the `newyork` appliance to the `paris` appliance.

   This task is necessary to finish recovery if the cluster had experienced a complete site failure or a takeover. Data stores at `cluster-newyork` will have changed and will need to be replicated back to `cluster-paris` when it is put back in service.

   Perform these steps for each project that is replicated.

   1. Access the Sun ZFS Storage Appliance browser user interface (BUI) on the `cluster-newyork` site.
   2. Navigate to Shares > Projects and select the project being replicated.
   3. Select Replication for the project and click Update now.

      This executes a manual replication to synchronize the two sites.

2. Ensure that the protection group is stopped at the `cluster-paris` site.
   1. Determine whether the protection group on the original primary cluster, `cluster-paris`, is active.

          phys-paris-1# geoadm status

   2. If the protection group on the original primary cluster is active, stop it.

          phys-paris-1# geopg stop -e local pg-name

      pg-name

        Specifies the name of the protection group

   3. Verify that the protection group is stopped.

          phys-paris-1# geoadm status

3. Remove obsolete projects from the appliance at the `cluster-paris` site.
   1. Access the BUI on the `cluster-paris` site.
   2. Navigate to Shares > Projects.
   3. If any projects in the protection group are listed, manually delete them.
4. Resynchronize the original primary cluster, `cluster-paris`, with the current primary cluster, `cluster-newyork`.

   The `cluster-paris` cluster forfeits its own configuration and replicates the `cluster-newyork` configuration locally. Resynchronize both the partnership and protection group configurations.

   1. On `cluster-paris`, resynchronize the partnership.

          phys-paris-1# geops update ps-name

      ps-name

        Specifies the name of the partnership

      Note - 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.

   2. On `cluster-paris`, resynchronize each protection group.

      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 pg-name

      For more information about synchronizing protection groups, see Resynchronizing a Sun ZFS Storage Appliance Protection Group.

5. On `cluster-paris`, validate the cluster configuration for each protection group.

   Ensure that the protection group is not in an error state. A protection group cannot be started when it is in a error state.

       phys-paris-1# geopg validate pg-name

   pg-name

     Specifies a unique name that identifies a single protection group

   For more information, see How to Validate a Sun ZFS Storage Appliance Protection Group.

6. On `cluster-paris`, activate each 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 global pg-name

   `-e` `global`

     Specifies the scope of the command. By specifying a `global` scope, the command operates on both clusters.

   pg-name

     Specifies the name of the protection group.

   Note - Do not use the `-n` option when performing a failback-switchover. The data must 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 ZFS Storage Appliance Protection Group.

7. Confirm that the data is completely synchronized.

   The data is completely synchronized when the state of the protection group on `cluster-newyork` is `OK`. The protection group has a local state of `OK` when the appliance data store on `cluster-newyork` is being updated to the `cluster-paris` cluster.

   To confirm that the state of the protection group on `cluster-newyork` is `OK`, use the following command:

       phys-newyork-1# geoadm status

   Refer to the `Protection Group` section of the output.

8. On both partner clusters, ensure that the protection group is activated.

       # geoadm status

9. On either cluster, perform a switchover from `cluster-newyork` to `cluster-paris` for each protection group.

       # geopg switchover [-f] -m cluster-paris pg-name

   For more information, see How to Switch Over Sun ZFS Storage Appliance Remote Replication From the Primary Cluster to the Secondary Cluster.

   `cluster-paris` resumes its original role as primary cluster for the protection group.

10. Ensure that the switchover was performed successfully.

    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 replication for each protection group.

        # clresourcegroup status -v pg-name

    Refer to the `Status` and `Status Message` fields that are presented for the replication component you want to check.

    For more information about the runtime status of replication, see Checking the Runtime Status of Sun ZFS Storage Appliance Remote Replication.

## How to Perform a Failback-Takeover on a System That Uses Sun ZFS Storage Appliance Replication

Use this procedure to restart an application on the original primary cluster and use the current data on the original primary cluster. Any updates that occurred on the secondary cluster while it was acting as primary are discarded.

The failback procedures apply only to clusters in a partnership. Perform the following procedure only once per partnership.

Note - To resume using the data on the original primary you must not have replicated data from the new primary to the original primary cluster, `cluster-paris`, at any point after the takeover operation on the current primary cluster. To prevent replication between the current primary and the original primary, you must have used the `-n` option whenever you used the `geopg start` command.

Before You Begin

Ensure that the clusters have the following roles:

- If the original primary cluster had been down, the cluster is booted and 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 the current primary cluster has the `primary` role.

- The protection group on the original primary cluster has either the `primary` role or `secondary` role, depending on whether the original primary can be reached during the takeover from the current primary.

This procedure uses the example names `cluster-paris` for the original primary cluster and `cluster-newyork` for the current primary cluster.

1. Log in to the Sun ZFS Storage appliance on the `cluster-paris` site.
2. On the `paris` appliance, remove the replication action for the project.
3. On the `paris` appliance, re-add the replication action and enable it with continuous mode.

   The package is created on the original primary appliance, `paris`. The corresponding package is created on the original secondary appliance, `newyork`.

4. On the original secondary cluster, `cluster-newyork`, stop the protection group locally.

       phys-newyork-1# geopg stop -e local pg-name

   `-e` `local`

     Specifies the scope of the command. By specifying a `local` scope, the command operates on the local cluster only.

   `pg-name`

     Specifies the name of the protection group.

   Note - Wait for the replica package to appear on `cluster-newyork` before you continue to the next step.

5. Make the protection group primary on `cluster-paris` and secondary on `cluster-newyork`.
   - If `cluster-paris` has the secondary role, run the following command from `cluster-paris`:

         phys-paris-1# geopg takeover pg-name

   - If `cluster-paris` has the primary role, run the following command from `cluster-newyork`:

         phys-newyork-1# geopg update pg-name

6. On `cluster-paris`, validate the configuration for each protection group.

   Ensure that the protection group is not in an error state. A protection group cannot be started when it is in a error state.

       phys-paris-1# geopg validate pg-name

   For more information, see How to Validate a Sun ZFS Storage Appliance Protection Group.

7. From either cluster, start the protection group globally.

       phys-paris-1# geopg start -e global pg-name

   The protection group on `cluster-paris` now has the `primary` role, and the protection group on `cluster-newyork` has the role of `secondary`. The application services are now online on `cluster-paris`.

   For more information, see How to Activate a Sun ZFS Storage Appliance Protection Group.

8. Remove obsolete projects from the `paris` appliance.
   1. Ensure that the protection group is activated and that all components are in the OK state on both clusters.

          # geoadm status

   2. Access the BUI on the `newyork` appliance.
   3. Navigate to Shares > Projects.
   4. If any projects in the protection group are listed, manually delete them.

Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |