No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

OceanStor 9000 V300R005C00 File System Feature Guide 11

Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Managing Remote Replication Tasks

Managing Remote Replication Tasks

This section describes how to manage remote replication tasks.

Enabling/Disabling Write Protection for a Secondary Directory

Enabling write protection for secondary directory ensures that only the data of primary directory can be written into the secondary directory. You can also disable write protection for secondary directory when it needs to take over services from the primary directory during a failover.

Prerequisites

  • A remote replication pair has been created.
  • You cannot disable write protection for a secondary directory if initial synchronization does not complete.
  • Before enabling write protection for a secondary directory, ensure that the write protection status of the secondary directory is Read-write.
  • Before disabling write protection for a secondary directory, ensure that the write protection status of the secondary directory is Read-only and Pair Running Status is Split or Interrupted.
NOTE:

When the replication pair status is neither split nor interrupted, split the replication pair only after data synchronization is complete for the pair; otherwise, write protection cannot be diabled for the secondary directory in the replication pair.

When the local and remote clusters are working and communicating with each other correctly, you can enable or disable write protection for the secondary directory in either cluster.

When the cluster where the primary directory resides is faulty or has down links, you can only enable or disable write protection in the cluster where the secondary directory resides.

Context

If you want to replicate data from the primary directory to the secondary directory, ensure that the secondary directory is write protected; otherwise, data cannot be replicated. By default, the secondary directory in a replication pair is write protected after the pair is created.

When the secondary directory needs to take over services from the primary directory, disable write protection for the secondary directory to make it readable and writable to service applications. During service takeover, the roles of the primary and secondary directories in a replication pair stay unchanged, but the primary directory stops synchronizing data to the secondary directory.

  • Enabling or disabling write protection for a secondary directory will roll back the secondary directory to the state at the latest snapshot point in time. Data written after the snapshot point in time will be lost. Therefore, exercise caution when enabling or disabling write protection for a secondary directory. If the rollback does not complete, it is not allowed to do other operations on the pair.
  • You can check the progress of snapshot rollback in Task Management.
  • You can check the value of Secondary Directory Write Protection to tell whether the rollback completes or not. After the rollback completes, the read/write permission of secondary directory will change.

Procedure

  • Enable write protection for the secondary directory.
    1. Log in to DeviceManager.
    2. Choose Data Protection > Remote Replication.
    3. In the remote replication pair list, select a remote replication pair for whose secondary directory you want to enable write protection.
    4. Choose More > Enable Secondary Directory Write Protection.

      The Danger dialog box is displayed.

    5. Carefully read the contents of the dialog box and select I have read and understand the consequences associated with performing this operation.
    6. Click OK.

      The Success dialog box is displayed, indicating that the operation succeeded.

    7. Click OK. The remote replication management page is displayed.

      Secondary Directory Write Protection of the remote replication pair is Read-only.

  • Disable write protection for the secondary directory.
    1. Log in to DeviceManager.
    2. Choose Data Protection > Remote Replication.
    3. In the remote replication pair list, select a remote replication pair for whose secondary directory you want to disable write protection.
    4. Choose More > Disable Secondary Directory Write Protection.

      The Danger dialog box is displayed.

    5. Carefully read the contents of the dialog box and select I have read and understand the consequences associated with performing this operation.
    6. Click OK.

      The Success dialog box is displayed, indicating that the operation succeeded.

    7. Click OK. The remote replication management page is displayed.

      Secondary Directory Write Protection of the remote replication pair is Read-write.

Performing a Primary/Secondary Switchover for a Remote Replication

The primary/secondary switchover exchanges the roles of the primary and secondary directories, so that the synchronization direction of a remote replication pair changes. However, the primary/secondary switchover does not change the read/write properties of primary and secondary directories.

Prerequisites

  • A remote replication pair has been set up.
  • The remote replication Pair Health Status is Normal, and the replication link is normal.
  • Write protection has been disable for the secondary directory.

Context

You can switch the roles of the primary and secondary directories in a replication pair when necessary. After directory roles are switched, a new replication pair is created and shares the same ID and the original pair, but data is replicated from the new primary directory to the new secondary directory. Only data is replicated, while directory quotas, snapshots, and network configurations are not replicated. You need to manually configure them for service failover.

Note the following when switching directory roles:
  • Roles of directories cannot be switched in a replication pair whose replication type is one-to-many.
  • Roles of directories cannot be switched in a replication pair where initial synchronization is in progress between the directories.
  • You can only switch roles of directories in one replication pair each time. If there are multiple replication pairs, switch directory roles in each pair one by one.

Procedure

  1. Log in to DeviceManager.
  2. Choose Data Protection > Remote Replication.
  3. In the remote replication list, select the remote replication pair for which you want to perform a primary/secondary switchover.
  4. Choose More > Primary/Secondary Switchover.

    The Danger dialog box is displayed.

  5. Confirm the primary/secondary switchover.
    1. Confirm the information in the dialog box and select I have read and understand the consequences associated with performing this operation.
    2. Click OK.

      The Success dialog box is displayed indicating that the operation succeeded.

    3. Click OK.

      The roles of the primary and secondary directories are exchanged.

Deleting a Remote Replication Pair

You can stop replicating data from a primary directory to a secondary directory by deleting the remote replication relationship between the two directories. This operation removes the replication relationship between the primary directory to the secondary directory.

Prerequisites

  • A remote replication pair has been set up.
  • The primary and secondary directories are in the health state.
  • A remote replication cannot be deleted when the secondary directory is being rolled back.
    NOTE:
    When enabling or disabling secondary directory write protection, the secondary directory will roll back based on the last consistency snapshot. This operation is triggered by the system automatically and it is invisible on DeviceManager GUI.

    If the snapshot of the secondary directory rollback fails, the system will trigger another rollback periodically and repeat indefinitely. Under this circumstance, you can use command change remote_replication invalid Pair ID to stop the snapshot rollback and set the pair running status as invalid, then you can delete this pair.

  • Determine whether a remote replication can be deleted based on Pair Running Status. Table 6-23 lists status requirements for deleting a remote replication.
    Table 6-23  Status requirements for deleting a remote replication

    Pair Running Status

    Remote Replication Deleted or Not

    Normal

    ×

    Split

    Interrupted

    To be recovered

    ×

    Synchronizing

    ×

    Invalid

    √: Able to operate.

    ×: Unable to operate.

Context

  • The essence of deleting a remote replication is to delete the remote replication configuration information of the primary and secondary directories, thereby, to cancel the replication relationship between the two directories. The configuration information is stored on both local and remote storage devices.
  • Remote replication configurations are automatically generated on the local and remote clusters when the remote replication pair is created.

Procedure

  1. Log in to DeviceManager.
  2. Choose Data Protection > Remote Replication.
  3. In the remote replication list, select the remote replication pair that can be deleted.
  4. Delete the selected pair.
    1. Click Delete.

      The Danger dialog box is displayed.

    2. In the Danger dialog box, select the parameter for deletion based on site requirements.

      Table 6-24 describes the related parameters.

      Table 6-24  Parameters for deleting a remote replication

      Parameter

      Description

      Delete the configuration information on the local cluster (only applicable when the local cluster is disconnected from the remote cluster)

      This option applies only when the local device is disconnected from the remote device. It must be selected. Otherwise, the deletion fails.

      To delete the configuration information of remote replication pair from the remote device, perform this operation on the remote device.

      NOTE:
      When local cluster connects to remote cluster normally, do not select this option. Otherwise, the deletion fails.

      Forcibly ensure data consistency for the secondary directory

      A rollback is initiated if secondary resource data is incomplete. The secondary resource data will be rolled back to the latest consistency snapshot status. Then delete the pair.

      If you do not select this option, the system will delete the remote replication pair directly. This may cause the secondary directory data inconsistent.

  5. Confirm the deletion.
    1. Confirm the information in the dialog box and select I have read and understand the consequences associated with performing this operation..
    2. Click OK.

      The Execution Result dialog box is displayed.

    3. Click Close to finish deleting a remote replication pair.

Deleting a Replication Channel

If the replication links between two clusters are no longer necessary. You can remove these links by deleting the replication channel between the two clusters.

Prerequisites

The replication channel that you want to delete has not been used by any replication pair.

Precautions

Deleting replication channel is to delete the channel configuration information saved on both local and remote clusters.

In one-to-many or many-to-one replication scenarios, when remote replication is not required between two clusters, you can delete the replication channel between the two clusters to release resources. After the replication channel is deleted, replication links are no longer available between the two clusters and there is no replication relationship between the two clusters.

You must follow requirements below when deleting replication channel, or it may cause incomplete deletion and follow-up channel creation failure.

  • If Health Status of replication channel is Normal and Running Status is Link up, you must delete a replication channel at the cluster-sender end of the replication channel.
  • If Health Status of replication channel is Normal and Running Status is Link down, you must perform the deletion operation on both local and remote clusters.
  • If Health Status of replication channel is Invalid and Running Status is either Link up or Link down, you must perform the deletion operation on both local and remote clusters, and you also must select Delete the configuration information on the local cluster (only applicable when the local cluster is disconnected from the remote cluster).

Procedure

  1. Log in to DeviceManager.
  2. Choose Data Protection > Remote Replication > Replication Channel.
  3. Select the replication channel that you want to delete and click Delete.

    The Warning dialog box is displayed.

  4. Carefully read the contents of the dialog box and select I have read and understand the consequences associated with performing this operation. If necessary, select the following and click OK.

    Delete the configuration information on the local cluster (only applicable when the local cluster is disconnected from the remote cluster): This item is mandatory when replication links are down between two clusters and the replication channel between two clusters is in Invalid state. After you select this item, the replication channel configurations will be deleted from the local cluster. If you want to delete the configurations from the remote cluster, delete the replication channel on the remote cluster.

Importing and Exporting the Configuration File of a Shared Directory

OceanStor 9000 allows you to export the configuration file of a shared directory at the primary end and import the configuration file at the secondary end for the secondary end to take over for the primary end in case the primary end fails.

Context

The configuration file of a shared directory contains the configuration information about the permission, share, access control lists (ACLs), and NAS protocol. You can import or export the configuration file of one shared directory each time. You are advised to export the configuration file of the shared directory after creating a pair.

If the NAS protocol configuration is modified when the secondary end takes over for the primary end, you need to export and import the configuration file again after the primary end resumes to work.

Procedure

  • Exporting the configuration file of a shared directory
    1. Log in to DeviceManager.
    2. Choose Settings > Import/Export Configuration.
    3. On the Export tab page, click Select and Export Directory in the Shared Directory Configuration File area.
    4. In the Select Directory dialog box that is displayed, select the directory whose configuration file you want to export, enter the encryption password, and click Export.

      The encryption password is used to ensure the security of a configuration file. You need to enter this password when importing the configuration file. Keep this password safe.

      This password is user-configurable and contains 8 to 32 characters, including at least two types of characters from uppercase letters, lowercase letters, and digits.

      After the configuration file is exported, the export progress is displayed as 100% and the export result is Succeeded.

    5. Click Save Configuration As and Save Exported Report As to save the configuration file and export report to the local terminal.
  • Importing the configuration file of a shared directory

    Before importing the configuration file, ensure that the configuration file of the secondary end and its encryption password have been obtained.

    1. Log in to DeviceManager.
    2. Choose Settings > Import/Export Configuration.
    3. On the Import tab page, click Browse on the right of Shared Directory Configuration File in the Directory area.
    4. In the Select Directory dialog box that is displayed, select the shared directory whose configuration file you want to import and click OK.
    5. Select Clear the share and permission configured for the selected directory and enter the configuration file encryption password in Password and click Browse on the right of Configuration File.
    6. In the dialog box that is displayed, select the configuration file you want to import and return to the Import tab page. Click Upload on the right of Configuration File.
    7. In the Succeeded dialog box that is displayed, click OK.
    8. Click Close.

Allocating an ID to a Local Authentication User or User Group Being Created

This section describes how to allocate a user ID (UID) or group ID (GID) when creating a local authentication user or user group.

Prerequisites

  • You have obtained a UID or a GID that is not used by any other user or user group.
  • You have obtained the management IP address of the primary and secondary OceanStor 9000 storage systems.
  • You have obtained the omuser account and its password for logging in to the node operating system.
  • You have obtained the admin account and its password for logging in to the CLI.

Context

When a Windows client uses a local authentication user to access the primary or secondary directory, the UID or GID of the authentication users on the primary and secondary storage systems must be the same. If any ID is different, access to the directory may be denied.

Procedure

  1. Use PuTTY to log in to a system node as user omuser through the management IP address of OceanStor 9000.
  2. Run the following command to log in to the CLI:

    cli_start -u admin

    Enter the password of user admin when prompted.

  3. Optional: Create a local authentication user group.

    If the local authentication groups on the primary and secondary storage systems use different GIDs, create local authentication groups with the same GID.

    1. Run the following command to query the information about all local authentication user groups.

      show local group all

      admin:/>show local group all
      ID   Name            Description 
      ---  -------------   -----------
      1    Administrators  Administrators 
      2    group02         group02
      3    group03         group03

    2. Run the following command to create a local authentication user group and allocating a GID to to it.

      create local group <name> [id=?]

      Where, <name> indicates the user group name. [id=?] cannot be a GID that has been allocated to a user group.
      admin:/>create local group test_group id=100000
      Commond execute successfully.

  4. Create local authentication users.
    1. Run the following command to query the information about all local authentication users.

      show local user all

      admin:/>show local user all
      ID Name Description PrimaryGroupId PrimaryGroupName GroupNames UserType StatusEnable
      --------------------------------------------------------------------------------------
      1 user01 user01 10000 default_group local true
      2 user02 user02 10000 default_group local true
      3 user03 user03 10000 default_group local true

    2. Run the following command to create a local authentication user and allocating a UID to to it.

      create local user <name> <primary_group_name> [id=?]

      Where, <name> indicates the user name and <primary_group_name> indicates the name of the user group to which the user belongs. [id=?] cannot be a UID that has been allocated to a user. After running this command, you need to specify a user password for accessing the OceanStor 9000. The user password is a string containing 8 to 32 characters. The complexity of the password depends on the user security policy. The password must contain any two types of characters from digits, uppercase letters, and lowercase characters, and must be different from the user name or reversed user name.
      admin:/>create local user test_user test_group id=1000
      Please input your password:*************
      Please input your password again:*************
      Command executed successfully.

  5. Repeat 1 to 4 to create other local authentication users and user groups.

Disaster Recovery Switchover

When disasters happen, the administrator must perform the disaster recovery switchover in a timely manner to enable the disaster recovery storage system to take over services.

Prerequisites

  • The OceanStor 9000 at the production site is faulty, and links between it and OceanStor 9000 at the disaster recovery site are down. The pair status is Interrupted or Split.
  • The shared directory configuration file and its encryption password of the OceanStor 9000 at the production site have been obtained.
  • The switchover has been allowed by the customer administrator.
    NOTE:
    Data on the client will be written into the disaster recovery site after the switchover. Do not perform the switchover if you are not allowed by the customer administrator.

Context

When disasters happen, services must be recovered in a timely manner to minimize the downtime. Meanwhile, recover the production site as soon as possible in case that data will be perpetually lost once the disaster recovery site fails. Switchover operations vary with the customer's needs. For details, see Failover and Failback. This chapter introduces how to enable the disaster recovery site to take over services quickly.

Procedure

  1. Log in to DeviceManager of the disaster recovery site.
  2. Choose Settings > Import/Export Configuration.
  3. On the Import tab page, click Browse on the right of Shared Directory Configuration File in the Directory area.
  4. In the Select Directory dialog box that is displayed, select the shared directory whose configuration file you want to import, and click OK.
  5. Select Clear the share and permission configured for the selected directory, enter the configuration file encryption password in Password, and click Browse on the right of Configuration File.

    While importing the configuration file, you have to enter the encryption password of the configuration file. Ensure that the password is correct.

  6. In the dialog box that is displayed, select the configuration file you want to import, and return to the Import tab page. Click Upload on the right of Configuration File.

    Import the configuration file of the OceanStor 9000 at the production site.

  7. Choose Data Protection > Remote Replication > Remote Replication Pair.
  8. Select the remote replication pair that you want to fail over, choose More > Disable Secondary Directory Write Protection, and then complete the operation according to the instructions.
  9. Mount the secondary directory on the client.

    Operation details vary depending on the client type. For details, see chapter File Sharing of OceanStor 9000 Administrator Guide.

    If you want to perform the disaster recovery switchover for multiple pairs, mount the secondary directories of these pairs.

  10. Test whether data can be written into the secondary directory on the client.

    • If yes, the disaster recovery storage system can take over services. The task has been completed.
    • If no, the disaster recovery storage system cannot take over services. Contact technical support engineers.

Follow-up Procedure

In actual application scenarios, the disaster recovery site can take over services immediately after write protection is disabled for the secondary directory. When the production site becomes normal, you can choose whether to take over services back to the production site based on site requirements.
  • Performing a Primary/Secondary Switchover for Remote Replication.

    After the primary/secondary switchover is performed, upper-layer applications are taken over by the disaster recovery site, which synchronizes newly written data to the production site. To avoid losing the data generated since the synchronization is completed to Enable Secondary Directory Write Protection is selected, you are suggested to first finish one data synchronization before continuing any other operations.

    1. Log in to DeviceManager of the production site.
    2. Choose Data Protection > Remote Replication > Remote Replication Pair.
    3. Choose More > Primary/Secondary Switchover.

      The Danger dialog box is displayed.

    4. Confirm the primary/secondary switchover.
      1. Confirm the information in the dialog box and select I have read and understand the consequences associated with performing this operation.
      2. Click OK.

        The Success dialog box is displayed indicating that the operation has succeeded.

      3. Click OK.

        The roles of the primary and secondary directories are exchanged. Then, the secondary directory functions as the primary directory to process services.

    5. Select the pair for which you want to perform switchover, choose More > Enable Secondary Directory Write Protection, and then complete the following operations as instructed.
    6. If you need to perform switchover for multiple pairs, repeat 2 to 5 for these pairs.
  • Switching Services Back to the Secondary Site

    After you disable write protection for the secondary directory, upper-layer applications write data to the secondary directory. As a result, data becomes inconsistent between the primary and secondary directories. If you want to perform switchover in this situation, choose a baseline from the primary and secondary directories. Therefore, you are advised to manually synchronize data between the primary and secondary directories before starting switchover. For details, see Failback.

    1. Log in to the DeviceManager of the production site.
    2. Choose Data Protection > Remote Replication > Remote Replication Pair.
    3. Select the pair for which you want to perform switchover, choose More > Enable Secondary Directory Write Protection, and then complete the following operations as instructed.
    4. If you need to perform switchover for multiple pairs, repeat 2 to 3 for these pairs.

Disaster Recovery Testing

In the disaster recovery scenarios, you are advised to perform disaster recovery testing plans to ensure the disaster recovery functions well.

Prerequisites

  • The primary and secondary OceanStor 9000 systems are normal and can communicate with the clients.
  • The initial synchronization has been completed.
  • The testing has been allowed by the customer administrator.

Context

Disaster recovery testing is a scheduled test that make the disaster recovery end takes over the business. You have to test whether the disaster recovery end can take over successfully, to avoid that the disaster recovery end are unavailable when the disaster happens. Disaster recovery testing will not switch the primary and secondary role relations.

Procedure

  1. Perform failover on the production storage system.
    1. Log in to the DeviceManager of the production storage system.
    2. Choose Settings > Import/Export Configuration.
    3. On the Export tab page, click Select and Export Directory in the Shared Directory Configuration File area. Then export the configuration file according to the tips.

      While importing the configuration file, you have to enter an encryption password of the configuration file. You need to enter this password when importing the configuration file. Save the configuration file to the local terminal.

    4. Choose Data Protection > Remote Replication > Remote Replication Pair.
    5. Select the remote replication pair that you want to failover, click More > Split, then split the pair according to the tips.
    6. Click More > Disable Secondary Directory Write Protection, then complete the operation according to the tips.

    If you want to perform the disaster recovery testing for several pairs, perform 1.e to 1.f for these pairs.

  2. Perform the testing on the disaster recovery storage system.
    1. Log in to the DeviceManager of the disaster recovery storage system.
    2. Choose Settings > Import/Export Configuration.
    3. On the Import tab page, click Browse on the right of Shared Directory Configuration File in the Directory area. Then import the configuration file exported to in 1.c.

      While importing the configuration file, you have to enter the encryption password of the configuration file. Ensure that the password is correct.

    4. Mount the secondary directory on the backup client of the disaster recovery end.

      The operation details differs according to the client type. For more details, see chapter File Sharing of OceanStor 9000 Administrator Guide.

      If you want to perform the disaster recovery testing for several pairs, please mount all the secondary directories of these pairs.

    5. Test whether data can be written into the secondary directory on the client, to check whether the disaster recovery storage system can take over the business.

      • If yes, the disaster recovery storage system can take over the business. Go to 3.
      • If no, the disaster recovery storage system cannot take over the business. Contact technical support engineers.

  3. Failback when the disaster recovery testing completes.

    NOTE:
    During the disaster recovery testing, test data written from the secondary directory will be deleted.

    1. Log in to the DeviceManager of the production storage system.
    2. Choose Data Protection > Remote Replication > Remote Replication Pair.
    3. Select the remote replication pair that you want to failback, click More > Enable Secondary Directory Write Protection, then complete the operation according to the tips.
    4. Click Synchronize to synchronize the primary directory data to secondary directory.

      If you want to perform the disaster recovery testing for several pairs, perform 3.c to 3.d for these pairs.

Translation
Download
Updated: 2019-03-30

Document ID: EDOC1000101823

Views: 15871

Downloads: 97

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next