Dell Storage, PowerStore, PowerFlex PowerMax & PowerScale, Virtualization & Containers Technologies
So far, we have covered the following aspects of Dell EMC PowerStore: High Level Overview, Hardware, AppsON, vVols, File Capabilities, User Interface , Importing external storage And In the previous post, we […]
So far, we have covered the following aspects of Dell EMC PowerStore:
High Level Overview, Hardware, AppsON, vVols, File Capabilities, User Interface , Importing external storage
And In the previous post, we explained how PowerStore local protection works.
Data is one of the most valuable assets to an organization. It is accessed constantly by various applications and users, and is sometimes accessed directly by customers. This occurrence makes data a crucial part of day-to-day operations. Outages can occur at any time and can be restricted to a single system or an entire data center or location. Whether they are planned outages such as regular maintenance, or unplanned events such as a power outage, it is a top priority to ensure that critical data is always available. A business continuity plan for critical data can prevent these costly outages. To protect against different scenarios, an organization should plan and implement a data-protection strategy that includes a data-replication solution. Asynchronous replication can be used to protect against a storage-system outage by creating a copy of data to a remote system. Replication is a software feature which synchronizes data to a remote system within the same site or a different location. Replicating data helps to provide data redundancy and safeguards against storage system failures at the main production site. Having a remote disaster recovery (DR) site protects against system and site-wide outages. It also provides a remote location that can resume production and minimize downtime due to a disaster. The PowerStore platform offers many data-protection solutions that can meet disaster recovery needs in various environments. Asynchronous replication is primarily used to replicate data over long distances, but it can be used to replicate to systems within the same location also. The asynchronous replication for PowerStore is designed to have minimal impact on host I/O latency. Host writes are acknowledged once they are saved to the local storage resource, and no additional writes are needed for change tracking. Because write operations are not immediately replicated to a destination resource, all writes are tracked on the source. This data is replicated during the next synchronization. With protection policies, asynchronous replication uses the concept of a recovery point objective (RPO). The RPO is the acceptable amount of data, which is measured in units of time, that may be lost due to an outage. This delta of time also affects the amount of data which must be replicated during the next synchronization. It also reflects the amount of potential data loss in a disaster scenario.
PowerStore asynchronous replication features can be configured using PowerStore Manager, PowerStore CLI, or REST API. RecoverPoint for Virtual Machines supports VM replication for PowerStore and is configured using the Unisphere Manager for RecoverPoint user interface.
PowerStore Replication
PowerStorePowerStore achieves new levels of operational simplicity and agility. It uses a container-based microservices architecture, advanced storage technologies, and integrated machine learning to unlock the power of your data. PowerStore is a versatile platform with a performance-centric design that delivers multidimensional scale, always-on data reduction, and support for next-generation media. PowerStore brings the simplicity of public cloud to on-premises infrastructure, streamlining operations with an integrated machine-learning engine and seamless automation. It also offers predictive analytics to easily monitor, analyze, and troubleshoot the environment. PowerStore is highly adaptable, providing the flexibility to host specialized workloads directly on the appliance and modernize infrastructure without disruption. It also offers investment protection through flexible payment solutions and data-in-place upgrades.
PowerStore replication is asynchronous replication that provides all required capabilities for customers:
Best Protection
PowerStore supports a low RPO and near-zero RTO, which allows to perform all recovery operations easily and instantaneously.
The recovery supports planned and unplanned failover instantaneously using PowerStore snapshots capabilities. The recovery operation is a single command that performs all the required tasks to expose the data to the DR host.
VMWare SRM integration is supported to orchestrate the recovery from SRM.
Highly efficient
With PowerStore replication the data is replicated very efficient. In data is fully replicated only one in the initial copy, but for every following cycle only the changes are replicated. This is true also in case a failover is performed, and the replication is initiated to the remote side, PowerStore replication replicates only the difference between the sites.
Simple to use:
Ease-of-use is one of the top design characteristics of PowerStore and this is true also for replication.
Defining replication for a volume, or for any storage resource, requires just to assign a protection policy that includes replication to the volume. By assigning the protection policy the system will automatically:
A protection policy may include one or more snapshot-rules for local protection or a replication rule for remote protection or both.
For instance, a protection policy “Tier1” can be defined for the tier-1 applications as follows:
When the policy is assigned to a volume or volume-group, the replication and snapshots scheduler will be defined automatically according to the assigned policy.
“Tier1” Protection Policy
Flexible
The replication scales automatically with the system. PowerStore system can start with a single appliance and scale-out up to 4 appliances. When the system scale-out, the replication scale with the system.
The replication can be defined between any PowerStore models including between PowerStoreX, which has the “AppsOn” option and PowerStore-T.
Copy Data Management Integration:
The replication is fully integrated with PowerStore Copy Data Management features.
At the destination system any snapshot of the replication can be used for creating one or more environments for repurposing. For instance, when test environments are located on a different system, the production can easily be replicated to the test system and any snapshot at the destination can be cloned as a new environment.
Just select any snapshot at the target and by clicking on the “More Actions” in the actions menu and selecting “Create thin Clone Using Snapshot” the environment will be created.
Supported Replication Configurations
The PowerStore native asynchronous replication features allow supported storage resources to be replicated remotely between systems. This section outlines the supported configurations for asynchronous replication., The native asynchronous replication feature is supported in many different topologies, and deployment
models vary depending on the configuration requirements. At a system level, the following configurations are supported:
1. One-directional: A single-source system replicating to a single-destination system
2. Bi-directional: A two-system topology in which each system acts as a replication destination for the peer production resources
3. One-to-many: A system topology in which a single system replicates multiple resources, each to a different remote system
4. Many-to-one: A system topology in which multiple systems replicate their respective resources to a single system
The screenshot shows these supported topologies. The figure uses volumes to represent the storage resources.
Asynchronous replication allows for many different deployment models to meet the needs of an organization.
The bi-directional replication topology is typically used when production I/O must be spread across multiple systems or locations. The systems may exist within a single data center or in different, remote locations. With this replication topology, production I/O from each system is replicated to the peer system. During an outage, one of the systems can be promoted as the primary production system, and all production I/O can be sent to it. Once the outage is addressed, the replication configuration can be changed back to its original configuration. This replication topology ensures that both systems are in always use by production I/O.
The one-to-many replication topology is usually deployed when production exists on a single system, but replication must occur to multiple remote systems. This replication topology can be used to replicate data from a production system to a remote location to provide local data access to a remote team. At the remote location, thin clones can be used to provide host access to the local organization or test team. The many-to-one replication topology is deployed when multiple production systems exist and are replicating to a single system to consolidate the data. This topology is useful when multiple production data sites exist, and data must be replicated from these sites to a single DR data center. One example of this configuration is a remote office branch office (ROBO) location.
Replication connection
The screenshot, shows an example configuration of an asynchronous replication connection between two physical systems. In the figures, the source of the replication session is the Production System, and the destination is the DR System. For each of these example systems, the default port configuration is used as replication ports. The screenshot shows cabling for a pair of PowerStore T model appliances using system bond0.
The screenshot below, shows cabling between PowerStore X model and PowerStore T model appliances. With PowerStore X model arrays, ports are used for replication management and replication data traffic.
Remote systems
Once the replication interfaces are created and cabled to the network on both systems, the remote system connection between the arrays can be made. Once a remote system is configured on one of the systems participating in replication, it is automatically created on the peer system. The verify and update operation is used to update the replication connection information about the system that it is issued on. This operation is performed on the replication connection itself, as opposed to an individual replication session. Verify and update can be used to test a replication connection to a remote system or update the replication information if changes to the system have been made. Verify and update should be issued to reestablish the replication connection to a remote system after an outage. A use case for verify and update is if a storage network IP address pool has been changed on the system.
Protection policies with replication rules
Remote replication between PowerStore systems uses policy-based protection. Asynchronous replication configuration is defined in replication rules. Protection policies allow the user to configure remote and local protection using replication, snapshot rules, or both. The policies combine one or more rules to fulfill the protection requirements for a storage resource on PowerStore. For a valid configuration, a protection policy must contain at least one protection rule, regardless if it is a local or remote protection rule. Each protection policy can contain up to one replication rule and up to four snapshot rules.
The replication rule defines the parameter for the asynchronous replication on PowerStore and is set up on the source array. Even when the rule is synchronized to remote systems when it is added to a protection policy, it is not possible to edit a replication rule on the remote system. It is also not possible to view it in the
replication rule overview in PowerStore Manager. The required information for creating a rule includes the partner remote system, RPO, and alert threshold for the planned replication session. Once a protection policy with a replication rule is assigned to a storage resource, the configured RPO in the rule will be used to set up the internal event scheduler for recurring replication of the storage resource. For minimal RPO compliance issues, replication cycles are scheduled at 50% of the RPO value and based on the hour. For example, a one-hour RPO leads to a replication event every 30 minutes to ensure enough overlapping to meet the target of a one-hour RPO. The scheduled RPO events for the example are at x:00, and x:30 every hour. The events for the RPO are based on the configured time and not on the amount of data which is written on the source storage resource. Each storage resource can only have one active replication synchronization at a time. For example, the event scheduler cannot initiate a replication at a given time because replication is paused or a previous replication has not finished. In this case, the schedule is skipped and replication continues with the next planned replication.
The alert threshold defines the time when an alert is triggered after a target RPO is missed during continuous replication. There is no event that is triggered when the initial replication needs more time to complete. When a compliance alert is raised for replications using an RPO of more than five minutes, it is cleared when the next replication cycle finishes successfully. The following example shows a storage resource that is scheduled with a target RPO of one hour and an alert threshold of zero minutes. See the following steps and Figure 3.
1. The initial synchronization completed successfully within the 30-minute RPO window and the first schedule RPO synchronization cycle begins.
2. An RPO snapshot for the second regular replication cycle is performed at 11:00, and the synchronization finishes successfully within 30 minutes. The replicated snapshot meets the RPO target until 12:00.
3. The next replication cycle at 11:30 is not finished replicating to the target after reaching the 12:00 limit for the 11:00 RPO schedule (step 2). An RPO compliance alert is raised, and the 12:00 scheduler event is skipped.
4. When the 11:30 replication finishes at 12:10, the RPO target is achieved again until 13:10. Since the raised alert needs at least one successful replication within the timeframe to be cleared, the alert remains active until it is cleared. This occurs after the 12:30 replication finishes at 13:00.
Replication session
Assigning a protection policy with replication rule to a storage resource creates the replication session. The replication session operates the scheduling and replication from the source volumes to the target storage resources. When a replication session is created in PowerStore, a storage resource of the same size and type is created on the destination system. PowerStore creates individual RPO schedules for each storage resource in that replication session. Scheduled or manual user snapshots of storage resources in a replication session are also replicated in chronological order to the destination during initial and continuous synchronizations.
Asynchronous replication synchronizations are triggered by a user-defined RPO or at any time manually by the user. The following characteristics define asynchronous replication:
• Writes to a storage resource are saved to the source storage resource and acknowledged to the host before being replicated to the destination storage resource. Changes are retrieved using a snapshotdiff operation and are replicated later.
• A user defined RPO defines the maximum time between scheduled synchronizations.
• Between synchronizations, new data is only saved on the source storage resource. The RPO is themaximum amount of data that the user is willing to lose in a disaster, which is measured in time. The RPO determines how often synchronizations occur at a minimum.
• Manual replication between RPOs operates the same as scheduled asynchronous replication. When an asynchronous replication session is created, and before the incremental cycles begin, a full synchronization of the source and destination storage resource occurs. If replication is configured when a new resource is created, the synchronization is quick because no data must be copied to the destination storage resource. If a protection policy with replication is added to an existing storage resource, a full synchronization occurs between the source and destination storage resource. Writes occurring during the initialsynchronization period are not copied to the destination storage resource, but remain in the snapshot diff for a later synchronization.
Once the initial synchronization is complete, a common base is established between the source storage resource and the destination. Host-write operations that occur after the initial synchronization are acknowledged with the host, and no data is replicated to the destination until the next synchronization. On any recurring cycle, a new snapshot is created and all changes between the current and previous snapshots are replicated to the destination. A new common base is then established. If another replication is still running, either manually triggered or by the RPO event scheduler, the replication is skipped.
Asynchronous replication in PowerStore uses snapshots to maintain the common base images explained previously. The following steps and Figure 4 show how snapshots are used with asynchronous and manually triggered replication.
1. When a replication session is created on a storage resource, a read-only internal RPO1 on the source system is created. On the destination system, a storage resource with same characteristics is created with an associated shadow read/write snapshot.
2. Data is replicated from the source RPO1 snapshot to the newly created destination shadow read/write snapshot. This replication is the initial synchronization of the source and destination storage resources and is a full copy of all the data.
3. When the remote read/write shadow snapshot is synchronized with the local RPO1 snapshot, an RPO1 snapshot is triggered on the destination. The RPO1 snapshots that are on the source and destination storage resources contain the same information and represent the point when the synchronization started. Snapshot RPO1 on each system is now a common base for the replication session. The remote storage resource is refreshed from the RPO1 snapshot, and the initial synchronization is completed.
4. Over time, the host application writes new data to the source storage resource.
5. The next update is either manually started or by the RPO with asynchronous replication. During the update, a new RPO2 snapshot is triggered to reflect the current, point-in-time view of the source storage resource. All changes that were made since the last update of the destination are copied to the destination shadow read/write snapshot.
6. After the incremental copy is complete, an RPO2 snapshot on the destination is created. This snapshot defines the new common base, and the remote storage resource is refreshed from that base.
7. Because the old, common-base compound of RPO1 snapshots on the source and destination are not relevant for upcoming replication cycles, the RPO1 snapshots are deleted. Only the RPO2 snapshots and shadow read/write snapshots remain.
Each time the replication interval (half of the RPO setting) is reached or a manual update is started, the common base image updates with the latest RPO snapshots. Snapshots that are used for asynchronous replication operate the same as user snapshots and are based on redirect-on-write technology. Although user snapshots and replication snapshots share the same technology, replication snapshots have use restrictions. Although replication snapshots can be viewed in the PowerStore Rest-API and PowerStore CLI, user operations such as restore operations are not allowed. Snapshots that are allocated for replication purposes do not count toward user-snapshot maximums. In PowerStore, native asynchronous replication is supported on the following storage resources:
• Volumes
• Thin clones
• Volume groups
Asynchronous replication operates in the same way for volumes and thin clones on PowerStore. When asynchronous replication is configured on a volume in PowerStore Manager, a single replication session is created, and the destination storage resource is created with the same size and type as the source storage resource. When configuring a replication session on a thin clone, the destination storage resource is a regular volume and not a thin clone. While replication is configured, the volumes and thin-clone size can be extended, and the changes are reflected on the destination storage resource after the next sync. On PowerStore, a volume group is a storage resource which contains one or more volumes within a storage system. Volume groups help organize storage resources allocated for a particular host, hosts, or host groups. Volume groups are treated as a single entity when they are replicated. This behavior means that a single replication session is created for the entire volume group no matter how many volumes it contains. When replication is configured in PowerStore Manager for a volume group, the destination storage resource and its contents are created automatically. While a volume group is part of an asynchronous replication session, volumes within the volume group can be expanded. All changes to volumes within a volume group are reflected on the destination image after the next completed synchronization. When replication is paused or resumed on a volume group, the replication operation affects the entire group. Check the Write consistency order option for the volume group to have a consistent replica at the volume-group level.
Manage Replications – Failover
Failover
A failover is executed after an unplanned event, including source system failures, or an event on the source system that leads to down time for production access. Failover is run from the destination storage resource.
A failover promotes the destination replica to production, that has a data state consistent to the last successful RPO
Recovery point objective (RPO) indicates the acceptable amount of data, which is measured in units of time, that may be lost in a failure.
synchronization state.
To start failover:
With asynchronous replication, the PLANNED FAILOVER option allows a failover without losing data .The replication session fails over after completing a synchronization between the images. The planned failover option is available on the source storage resource when the replication session is operating normally or a synchronization is in progress. It makes a short period of data unavailable during the failover operation. Before the Planned Failover operation is issued, it is suggested to issue a manual sync first. This action reduces the amount of data to copy during the planned failover with sync. When issuing a planned
failover, it is suggested to quiesce I/O to the source image first. After the synchronization completes, the destination storage resource is available for production I/O and the original source no longer allows read/write I/O. If host access is configured on the destination resource, hosts can access the data currently. If Reprotect after failover is not selected when initiating the failover, replication does not resume in either direction when a planned failover is used. Once created, replications can be synchronized, paused, removed, or used during planned failover.
Planned Failover
Examples of when to use a planned failover include:
During a planned failover, a replication session is manually failed over from the source system to the destination system. The destination system is fully synchronized with the source system before the failover and there is no data loss.
Planned failover is run from the source prior to a planned outage. Both source and destination systems must be available.
During a planned failover, you can:
To start planned failover:
Unplanned failover
The unplanned failover option is only available on the destination of the replication session. This failover type fails over to the latest available common base image that exists at the target without any synchronization occurring beforehand. An unplanned failover assumes that a disaster has occurred on the production system, and the destination image is made read/write available. When FAILOVER is selected on a destination resource of a replication session (Figure 9), read/write access is removed from the original source if the source is available to receive management commands. The replication session also pauses and does not automatically switch the direction for replication. The replication session is left in this state until the user issues another replication operation. If I/O occurs to the original destination resource while in this state, the
data must be replicated to the original source when the source becomes available. PowerStore allows initiating an unplanned failover operation when the replication is in a Paused, Failing Over, or Failed Over state. Any changes made on the source system while the session is in these states might not be replicated to the destination. Since no final synchronization is performed, an unplanned failover can result in data inconsistency or data loss. It should be only initiated when the source system is not available anymore. Use a planned failover whenever possible.
Reprotect
After the Planned Failover or Failover option is used, the REPROTECT option becomes available on the new source system. It is also triggered after a planned failover with the reprotect operation is initiated. The reprotect operation starts the replication session and synchronization to the original source system. Since there might not be synchronized changes after an unplanned failover on the destination, it is recommended to take a snapshot on the remote system before the reprotect operation is initiated.
Manage Replications – Synchronization
Synchronization updates the destination with the changes on the source from the previous synchronization cycle. Any size or membership changes are synchronized on the source.
Synchronization occurs automatically according to a schedule, or manually.
Replication sessions may be synchronized in the following states:
During replication synchronization, the following actions may be taken:
To start synchronization:
Manage Replications – Pause and Resume
Pause and Resume
The Pause and Resume functions are available in PowerStore Manager from the Protection drop-down menu. Pause pauses the replication session and Resume resumes the replication session.
To Pause and Resume a replication session:
Manage Replications – Remove
Remove Replication Session
If a replication session no longer meets the business needs, it may be removed. To remove a replication session, unassign the protection policy from the replicating volume. Only remove the protection policy from the source volume, an error may occur if you try to remove the protection policy from the destination system.
Note: When a replication session is removed, the destination replica is still present.
To Unassign a Protection Policy:
Below, you can see a demo how it all works
or the one below
you can also download the following white papers:
1 Comment »