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 V300R006C00 File System Feature Guide 12

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).
Principle Description

Principle Description

This section describes the functions and principle of InfoReplicator.

Basic Concepts

This section describes the basic concepts of InfoReplicator, including pair, synchronization, and split.

Pair

InfoReplicator pairs the replication source and destination and defines the frequency and other replication rules for each pair.

You must specify the replication source and destination when creating a replication pair. Normally, a local directory serves as the source (primary directory) and a remote directory serves as the destination (secondary directory). Neither the source nor destination can be a root directory (the / directory). The destination directory must be empty.
Figure 6-1  Pair
Synchronization

Synchronization is an operation InfoReplicator performs to copy the contents of the source directory to a destination directory. InfoReplicator uses a bi-directional replication pair to define the source and destination and synchronize data in between.

InfoReplicator supports two types of synchronization:
  • Full synchronization: copies all contents of the source directory (primary directory) to a destination directory (secondary directory).
  • Incremental synchronization: copies only the data that has changed in the source directory since the beginning of the last synchronization.

The incremental synchronization requires a full copy only once. This full copy is called an initial synchronization. An initial synchronization must be manually started before subsequent incremental updates. After the initial synchronization, only data changes are synchronized to the destination directory each time. Incremental synchronization greatly reduces the replication time, improving the replication efficiency. Data changes in the source directory include new data write, modification, and deletion. All these changes can be synchronized to the destination directory.

Also, InfoReplicator allows you to replicate source directory attributes to the destination directory together with directory contents. These attributes can be basic attributes, extended attributes, access control lists (ACLs), and write once read many (WORM) attributes. In addition, you can export NAS configurations (such as NFS and CIFS shares) from the source directory and import them to the destination directory to take over for the source directory in case the source directory fails.

Split

InfoReplicator allows you to split a pair to suspend replication between directories in the pair. You can split a pair to suspend replication for the purposes of link maintenance, bandwidth expansion, and directory data archive.

After a pair is split, its source and destination directory roles are not switched, nor is the access permission for these directories. If you want to resume synchronization between the directories in a split pair to keep directory data consistent, manually start synchronization for the pair again. By so doing, the suspended synchronization resumes instead of starting at the beginning. This resumable data transmission improves the synchronization efficiency.

The flexible pair split and synchronization enable you to effectively control remote replication progress.

Snapshot-based Replication

InfoReplicator asynchronously replicates the contents of snapshot of the source directory (primary directory) to the destination directory (secondary directory).

When data is replicated for the first time from the primary directory to the secondary directory in a replication pair, the storage system automatically creates a snapshot for the primary directory at the replication point in time. When data is replicated from the primary directory to the secondary directory again, the storage system creates a new snapshot for the primary directory, compares it with the last one, analyzes differences between the two snapshots, and synchronizes the changed data to the secondary directory. In this way, the storage system can easily locate the changed data without the need to traverse all its directories, improving data synchronization efficiency. Because only changed data is synchronized, the other data of the primary directory can be normally accessed during each incremental data synchronization. The snapshot-based replication is called asynchronous replication, because data changed on the primary directory after the previous replication point in time is only synchronized to the secondary directory upon the next replication.

For example, the user starts to replicate data from primary directory /data at 14:00 and modifies file A under this directory at 14:05, before the replication is complete at 14:10. The data change at 14:05 is not recorded to the primary directory snapshot created at 14:00, and therefore will not be synchronized to the secondary directory until the user starts the next replication.

The storage system creates a snapshot for the secondary directory each time after synchronization is complete. You can check whether data synchronization is complete by checking the snapshot of the secondary directory. Figure 6-2 shows the process that InfoReplicator performs snapshot-based asynchronous replication.
Figure 6-2  Snapshot-based replication
To ensure that data can be quickly recovered from snapshots, the latest two snapshots are reserved for the primary and secondary directories each. After data replication is complete each time, newly created snapshots will overwrite the earlier ones created during the last replication. The administrator can configure a snapshot retention period for the secondary directory. Snapshots created for the secondary directory after each replication will be retained in this specified period. When the storage system is faulty, the latest snapshot can be used to restore system data.
NOTE:
At least two snapshots must be reserved for the secondary directory. If a snapshot retention period is set and only one or no snapshot is created for the secondary directory, expired secondary directory snapshots will not be deleted.

Snapshots created during a replication session are stored under the primary directory specified by the replication pair. Each of these snapshots is named in the format of RepSnapPair-xxxxxxxx-PairID-xx. PairID indicates the globally unique ID automatically generated by the system upon the pair creation, helping you quickly identify the pair for which a snapshot directory is created.

InfoReplicator uses the snapshot mechanism provided by InfoStamper (directory-level snapshot) to create snapshots for remote replication sessions, but does not require the license of InfoStamper. For details about the snapshot creation, access, deletion, and rollback, see OceanStor 9000 InfoStamper Feature Guide.

Synchronization Method

InfoReplicator employs full synchronization and incremental synchronization.

Full synchronization copies all the contents of the primary directory (source directory) to the secondary directory (destination directory). Incremental synchronization only copies the data changed since the last synchronization. An initial full synchronization is performed for a newly created synchronization pair and then only incremental synchronizations are required.
  • Full synchronization is bandwidth- and time-consuming, degrading system performance.
  • Incremental synchronization requires a small amount of data to be synchronized each time, so less bandwidth and time are consumed, posing a modest impact on system performance.
Figure 6-3 shows the process of an initial synchronization.
Figure 6-3  Initial synchronization
The process is as follows:
  1. The initial synchronization is manually started.
  2. The system creates a snapshot for the primary directory and scans the directory contents. This snapshot serves as the baseline snapshot.
  3. A secondary directory is created. This directory has the same structure as the primary directory.
  4. Copies all the contents of the primary directory to the secondary directory.
  5. The attributes (including the basic attributes, extended attributes, ACLs, and WORM attributes) of the sub-directories and directory files of primary directory are sent to the secondary directory and then written to the secondary directory and corresponding files.
  6. After the data replication is complete, a snapshot is created for the secondary directory.
InfoReplicator employs asynchronous replication, so data newly written to the primary directory will not be immediately synchronized to the secondary directory. The data can be manually synchronized by the administrator or automatically copied when the next synchronization starts. All data changed after the beginning of the last synchronization will be synchronized to the secondary directory at a time when the next synchronization starts. Figure 6-4 shows the process of incremental synchronization.
Figure 6-4  Incremental synchronization
The process is as follows:
  1. The client writes data N to the primary directory.
  2. After the data is successfully written, the primary directory returns a write success acknowledgement to the client and records a differential log.
  3. The administrator manually starts synchronization or the newly written data is automatically synchronized when the next synchronization starts.
  4. The system creates the baseline snapshot for the primary directory, analyzes the differential log, and identifies data increments.

    The differential log records the changed data and metadata in the primary directory. The changes include the creation, deletion, renaming, attribute modification, content change of files and directories.

  5. The differential log is packed to a message in the primary directory and the message is sent to the secondary directory for analysis. Then, the changed data is written into files or subdirectories of the secondary directory.
  6. When more than two baseline snapshots are created for the primary directory, the system deletes the earliest one to release system space. When the number of baseline snapshots is smaller or equal to two, existing baseline snapshots are not deleted.
  7. After the synchronization is complete, a snapshot is created for the secondary directory.
  8. Some snapshots of the secondary directory are deleted based on the snapshot retention policy.
    • If a snapshot retention period is not set, only snapshots created for the secondary directory after the latest two synchronizations are retained. Earlier snapshots are deleted to release system space.
    • If a snapshot retention period is set, the expired secondary directory snapshots will be automatically deleted. Snapshots within the retention period will not be deleted.
      NOTE:
      At least two snapshots must be reserved for the secondary directory. If a snapshot retention period is set and only one or no snapshot is created for the secondary directory, expired secondary directory snapshots will not be deleted.

InfoReplicator can track data changes and therefore only replicates the changed data to the secondary directory during incremental synchronization, without the need to traverse the entire directory tree. The minimum data block to be replicated can be as small as 16 KB, improving replication efficiency while reducing the bandwidth overhead. When a file is relocated or renamed in the primary directory, the system does not delete this file and then creates a new one in the secondary directory. Instead, the system tracks the file changes in the primary directory and then synchronizes the changes to the secondary directory. In this case, the corresponding file in the secondary directory is relocated or renamed in the same way as the source one. This way of synchronization eliminates repetitive replication.

Replication Link

InfoReplicator replicates data between replication zones over replication links. Physical replication links are logically represented as a replication channel.

A replication zone is a collection of nodes that participate in remote replication. A replication zone is automatically created after the InfoReplicator license is activated. This default replication zone does not contain any system nodes. You can add nodes to the replication zone by specifying front-end service IP addresses of the nodes in the replication zone. The number of nodes participating in remote replication is inversely proportional to the workload per node but directly proportional to the impact on the data access performance of a system cluster.

Replication channel refers to a group of replication links between the replication zones of the primary and secondary OceanStor 9000 storage systems (replication source and destination). To minimize the impact of remote replication on other system services, you can specify an upper limit for the bandwidth of the replication channel to control the maximum bandwidth of each node in the replication zone. This upper limit applies only to nodes at originating end of the replication channel, and nodes at the receiver end are not affected.
NOTE:
Data is replicated from the originating end to the receiver end. Normally, you are advised to configure the primary OceanStor 9000 storage system as the originating end and the secondary OceanStor 9000 storage system as the receiver end.

You can create only one replication channel between two OceanStor 9000 storage systems. This channel is shared by all pairs that are used to replicate data between the two storage systems. This channel is also used to authenticate and control traffic for all replication links between the two storage systems.

In normal cases, observe the following rules to create replication links between nodes of the two storage systems and add the replications links to a replication channel for load balancing.
  • Create at least two replication links from between one primary node and its secondary nodes.
  • Ensure that all primary nodes have the same number of replication links.
  • Ensure that all secondary nodes have the same number of replication links.
  • Ensure that both the primary nodes and secondary nodes must use either IPv4 or IPv6.
Figure 6-5 shows example replication links between the primary and secondary storage systems. In this example, the primary and secondary storage systems each provide three nodes to participate in remote replication. The two storage systems have other nodes that are not added to replication zones and do not participate in remote replication, so replication links are not created for these nodes. This example only shows replication links between the nodes that participate in remote replication.
Figure 6-5  Replication links between normal nodes
When any faulty node exits a replication zone, or the administrator adds a node to or remove a node from a replication zone, InfoReplicator automatically adjusts replication links between the rest nodes in the replication zones for load balancing, as shown in Figure 6-6.
Figure 6-6  Replication links automatically adjusted between nodes upon faults
As long as each replication zone has at least one normal node, replication links are always available between the nodes for data transmission.
NOTE:
The administrator can adjust nodes in the replication zones of the primary and secondary storage systems to ensure that each replication zone has at least one available node. By so doing, when no replication links are available between the nodes, the replication channel is temporarily disconnected and an event is reported. After the faulty nodes heal themselves, the replication channel will be reconnected to restore the replication links. To ensure available remote replication pairs, do not remove nodes from replication zones of the primary and secondary storage systems at the same time.

Authentication and Access Control

InfoReplicator authenticates links and controls the client access to ensure the security of remote replication.

Link Authentication
Data is replicated over the replication channel during remote replication. For details about the replication channel, see Replication Link. To avoid the risks associated with network data transmission, InfoReplicator employs the link authentication mechanism to ensure the security of replication links. An authentication module is deployed and starts to work in each node after the storage system is installed. The authentication module uses TCP-based username/password authentication.
  • When a replication channel is created for the first time, a dedicated machine-machine account must be used for link authentication. A replication channel is created and available for data transmission only after the replication source and destination are authenticated.
  • When a replication channel restores from a fault such as a node restart, the system will automatically obtain the authentication user name and password from its database. There is no need to manually enter the user name and password again.
  • When the replication channel authentication password is changed, you need to update the new password on the replication channel management page to ensure that replication links are automatically authenticated after fault recovery. If the password is not updated, the replication channel will not be automatically restored after the links are reconnected.

Because link authentication cannot defend against external distributed denial of service (DDoS) attacks, you are advised to deploy firewall devices to prevent system communication from being interrupted by the memory exhaustion in a short time.

Client Access Control

Clients that access the OceanStor 9000 are authenticated and controlled to ensure system security. For details, see Authentication and Access Control in OceanStor 9000 Administrator Guide.

InfoReplicator allows you to export NAS protocol configurations (such as NFS/CIFS shares) from the primary directory while synchronizing data. When the primary directory (replication source) is unavailable, you can import the exported NAS configurations to the secondary directory (replication destination) so that clients can access this directory in the same way as the primary directory. The export of configuration information ensures business continuity.
  • Domain authentication
    The primary and secondary OceanStor 9000 storage systems must be added to the same domain so that the two storage systems can use the same domain authentication server to store user accounts and client credentials. Figure 6-7 shows this authentication mode.
    Figure 6-7  Client authentication (domain authentication)
  • Local authentication
    When CIFS clients (such as Windows clients) access the primary and secondary directories of the OceanStor 9000, the IDs of local authentication users and user groups must be the same on the primary and secondary storage systems. If any ID is different, the secondary storage system cannot take over for the primary storage system due to lack of permission. The OceanStor 9000 allows you to specify UIDs or GIDs when creating local users or user groups, ensuring that the primary and secondary directories are accessed by users or user groups of the same UIDs or GIDs. Figure 6-8 shows this authentication mode.
    Figure 6-8  CIFS client authentication (local authentication mode)

    When you use NFS clients (such as Linux clients) to access the OceanStor 9000, you only need to import the backup NAS protocol configurations to the secondary directory the case the primary directory is unavailable. By so doing, the secondary directory has the same permission as the primary directory and can be accessed by the clients in the same way.

RPOs/RTOs

This section describes the factors that may affect the recovery point objectives (RPOs) and recovery time objectives (RTOs).

The international disaster recovery standard SHARE78 defines seven disaster recovery levels. InfoReplicator supports Tier 6 disaster recovery that achieves zero or near-zero data loss. RPOs and RTOs are important indicators for measuring the disaster recovery capability.
  • RPO defines the maximum amount of data that can be lost during disaster recovery. This indicator is used to measure the backup and recovery capability of a disaster recovery system. RPO measures the data lost during the period where a disaster recovery system restores data to a point in time before the disaster occurs. RPO is usually represented as a time period. A smaller RPO means less data loss.
  • RTO refers to a period of time during which business applications are recovered. This indicator is used to measure the business recovery capability of a disaster recovery system. It specifies the disaster recovery time. A smaller RPO means shorter service interruption.

RPOs are usually calculated based on the minimum synchronization period of an automatic synchronization. If the synchronization period is N, the range of the minimum RPO (T) supported by InfoReplicator is N ≤ T ≤ 2N.

Table 6-3 lists the major factors that affect RPOs. You can appropriately plan InfoReplicator based on these factors and site requirements to meet your disaster recovery requirements.
Table 6-3  Factors that affect RPOs

Category

Factor

Impact

Data

Changed data amount in the primary directory

InfoReplicator performs an initial synchronization to copy all contents of the primary directory and then performs incremental synchronization to copy the changed data. Therefore, the time spent in each replication after the initial synchronization is determined by the changed data amount. Under the same conditions, the replication time is inversely proportional to the changed data amount.

Number of files in the primary directory

When the same amount of data is replicated, the number of files in a small-file scenario is larger than that in a large-file scenario. Therefore, the system accesses the primary directory more frequently to scan for files in a small-file scenario. However, the access frequency of a large-file scenario is much lower.

External factors

Network bandwidth and latency

The network capacity is an important factor that affects the replication time. To meet RPO requirements, there must be sufficient bandwidth and low enough latency to ensure that all the changed data is replicated to the secondary directory at one time before the next synchronization. The next synchronization will not start until the one in progress is complete. Long synchronization time prolongs the synchronization interval and therefore increasing the RPO.

Workload

The system resources and performance decrease as the workload increases, prolonging data replication time.

Internal factors

Node performance

Under the same conditions, the performance of a node increases with its CPU and memory computing capability, and a high-performance node spends less time in transmitting the same amount of data.

the I/O capability of disks varies with disk types and the data replication time decreases as the I/O capacity increases. Disk I/O capability: SSD > SAS > SATA

Number of nodes

InfoReplicator allows you to configure the replication zone to specify the number of nodes that participate in remote replication. With the distributed architecture of the OceanStor 9000, the storage system nodes can transmit data in parallel. Therefore, the data replication time decreases as the number of nodes increases.

InfoReplicator configuration

Synchronization period

A synchronization period can be set to as short as possible to reduce the RPO as long as all data changes can be synchronized in this period.
NOTE:

If the bandwidth, workload, and replication rate meet requirement, the InfoReplicator supports a minimum synchronization period of 15 minutes, applicable to scenarios where the minimum RPO is 30 minutes.

Synchronization rate

InfoReplicator allows you to set the synchronization rate to strike a balance between the replication efficiency and impact on performance. The synchronization rate is directly proportional to the data transmission rate. The higher the synchronization rate is, the shorter time is spent in data replication.

Bandwidth limit

To reduce the impact of remote replication on system performance, you can set a bandwidth limit for the replication zone to limit the bandwidth of all nodes at the originating end of the replication channel.

As long as the system performance meets your requirement, you can shorten the replication time by canceling the bandwidth limit or setting a lower one to increase the data replication capacity of the nodes at the originating end of the replication channel.

InfoReplicator allows to you to export NAS configurations (such as NFS and CIFS shares) from the source directory and import them to the destination directory to take over for the source directory in case the source directory fails. To minimize the RTO, you can periodically export NAS configurations from the shared directories and import them when necessary for a failover.

Failover

InfoReplicator allows you to implement a manual failover for fast recovery, ensuring business continuity.

Failover means that the secondary directory takes over for the primary directory (that becomes unavailable upon a disaster or fault) to ensure hitless services.

InfoReplicator supports two failover methods.
  • Disabling write protection for the secondary directory

    By default, the secondary directory is write protected during remote replication. Upper-layer applications cannot write data to the secondary directory. When a failover starts, write protection is disabled for the secondary directory and upper-layer applications can write data to it. During a failover, 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. To ensure data integrity, the secondary directory is restored to the latest snapshot point in time as soon as it is no longer write protected.

  • Switching the roles of the primary and secondary directories

    You can switch the roles of the primary and secondary directories in a replication pair when necessary. Before switching the directory roles, you must disable write protection for the primary directory. Ensure that the new pair after a role switch uses the same ID as the pair before the switch. After the roles of the primary and secondary directories are switched, enable write protection for the new secondary directory to ensure that data is synchronized from the new primary directory to the secondary directory. To ensure data consistency, the new secondary directory will be rolled back to the latest snapshot point in time after enabling write protection for the secondary directory.

You can choose either method based on the application scenario.
Table 6-4  Failover methods
Failover Method Advantage Disadvantage Application Scenario
Disabling write protection for the secondary directory Easy to operate and time-saving Data cannot be synchronized and the reliability of newly written data is low. Temporary takeover after a short-term fault or offline maintenance, or disaster recovery testing.
Switching the roles of the primary and secondary directories Synchronization relationship is reestablished to ensure data reliability. Complex operations and time-consuming
  • Long-term takeover such as scheduled maintenance.
  • Mandatory for the failback that writes the new data back to the primary end.
Figure 6-9 shows the failover process. Figure 6-9 shows the failover process from disabling write protection for the secondary directory to the directory role switch. In actual application scenarios, the secondary directory takes over for the primary directory immediately after write protection is disabled for the secondary directory. Then, you can determine whether to switch the roles of the primary and secondary directories based on site requirements.
Figure 6-9  Failover process

Failover is performed between the primary and secondary directories in a replication pair. If multiple pairs are involved, failover must be performed for each pair one by one.

Failback

InfoReplicator allows you to manually implement a failback to switch services back to the primary directory that recovers from a fault.

Failback is also called switchback or fault recovery. It means that services are switched form the secondary directory back to the primary directory when the primary directory recovers from a failure.

You can choose a failback method based on the failover method that has been adopted. InfoReplicator provides two failover methods: disabling write protection for the secondary directory and switching the roles of the primary and secondary directories.

Failback after a directory role switch
After the roles of the primary and secondary directories are switched, upper-layer applications are taken over by the secondary directory and newly written data is synchronized from the new secondary directory to the new primary directory. After a failback, the primary directory will be rolled back to ensure data consistency. Therefore, you are advised to manually synchronize data between the primary and secondary directories before starting a failback. In this way, all the newly written data can be synchronized to the primary directory. Figure 6-10 shows the process.
Figure 6-10  Failback after a directory role switch
Failback After Write Protection Is Disabled for the Secondary Directory
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 a failback in this situation, choose a baseline from the primary and secondary directories.
  • Failback with the primary directory as the baseline: Directly restore the original synchronization relationship from the primary directory to the secondary directory without retaining the data newly written onto the secondary directory. Figure 6-11 shows the process.
    Figure 6-11  Failback with the primary directory as the baseline
  • Failback with the secondary directory as the baseline: Manually synchronize data from the secondary directory to the primary directory to make data consistent before performing a failback. Figure 6-12 shows the process.
    Figure 6-12  Failback with the secondary directory as the baseline

Status Monitoring

You can monitor the status of remote replication pairs to better manage remote replication sessions.

InfoReplicator allows you to monitor the status of replication pairs in real time, enabling efficient replication session management. By viewing the state of a pair, you can determine whether you need to perform synchronization, splitting, and role switch operations. After performing an operation, you can view the pair state to determine whether the operation succeeded. Figure 6-13 shows the status and role switch of a pair.
Figure 6-13  Pair status
In addition to the pair status monitoring, DeviceManager provides GUI-based replication management page that allows you to view the replication task progress and secondary site data integrity, based on which you can adjust replication tasks based on site requirements. Figure 6-14 shows this management page.
Figure 6-14  Remote replication management page
Translation
Download
Updated: 2019-06-27

Document ID: EDOC1000122519

Views: 80332

Downloads: 147

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