Dell PowerStore 3.0, Part1 - Metro Volumes

During Dell Tech World 2022, we announced PowerStore 3.0

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

Preventing the loss of data or transactions requires a reliable method of continuous data protection and high availability. For disaster avoidance and planned outages, applications and services must be made available at an alternate site. A variety of data mobility methods, including asynchronous replication, can accomplish the task of providing offsite replicas.

PowerStoreOS v3.0 introducing Synchronous replication with Metro Volumes which differentiates itself apart from the other methods by guaranteeing transactional consistency between PowerStore clusters during normal operation.

PowerStore’s new native metro synchronous replication lets our customers create a high availability shared storage environment across a metro area distance, with no additional equipment or software purchase required.

First of all, it’s an active/active configuration which means that multiple ESXi hosts can write to either PowerStore appliance.
This new functionality allows us to create a stretched “metro volume” across sites, supporting ZERO RPO, RTO and DTO requirements.
The capability is currently for VMware hosts only, and provides flexible topologies both uniform (zero impact) and non-uniform configurations with auto-failover capability provided via VMware HA
Metro replication is 100% software-based, and extremely simple to set up and it can actually be configured in as few as 5 clicks – or under one minute, as you can see in the demo below.

Synchronous replication with Metro Volumes ensures data is written and committed to the replication source volume and the replication destination volume in real time and during normal operation. In some implementations, if data cannot be written to either the source or destination, then the write I/O will not be committed to either location, ensuring transactional consistency, and a write I/O failure will be issued to the storage host and application where the write request originated. In this type of implementation, the benefit synchronous replication provides is guaranteed consistency between replicated volumes.

In other implementations, if data cannot be written to the replication destination, then the write I/O will be committed to the replication source volume and the destination volume will be taken offline to prevent a “split brain” situation. In this type of implementation, the benefit synchronous replication provides is guaranteed consistency between replicated volumes during normal operation and high availability for workloads during a planned or unplanned outage. Metro Volume is built on this type of implementation.

With synchronous replication, any source of latency which impacts the source or destination volume, or the replication link in-between, will adversely impact applications in terms of latency and availability. This applies to Metro Volumes built on top of synchronous replications as well. For this reason, appropriate performance sizing is paramount for the source and destination storage, as well as the replication bandwidth and any other upstream infrastructure that the storage is dependent on.

The figure below demonstrates the write I/O sequence of synchronous replication:

The application or server sends a write request to the source volume.
The write I/O is mirrored to the destination volume.
The mirrored write I/O is committed to the destination volume.
The write commit at the destination volume is acknowledged back to the source volume.
The write I/O is committed to the source volume.
The write acknowledgement is sent to the application or server.

The process is repeated for each write I/O requested by the application or server.

PowerStore Metro Volume is a high availability and data mobility feature for PowerStore storage and VMware vSphere. It provides symmetric active/active data access to Metro Volumes for proactive use cases between PowerStore clusters. The architecture also lays a foundation for VMware vSphere Metro Storage Cluster designs.

Metro Volume is a bi-directional synchronous replication stretched storage solution made available in PowerStoreOS and integrated within the nodes of each PowerStore cluster. It is designed to operate in a production environment that allows storage hosts and applications to remain operational for the duration of proactive use cases such as planned migrations, resource balancing, or disaster avoidance. Metro Volume improves operational efficiency and eliminates the need for planned storage outages.

Metro Volume is designed to fit into existing datacenter environments without disruption or significant changes to existing configurations or workflow. Storage hosts see a Metro Volume as a single device with a variety of path states depending on configuration. Metro Volume presentation to storage hosts is consistent throughout its lifecycle. The Metro Volume preferred role and its migration between clusters can be managed using PowerStore Manager. Metro Volume operates synchronously and is designed for application high availability during planned migration, resource balancing, disaster avoidance, and other types of proactive use cases.

More information about vSphere metro cluster configurations and best practices can be found here:
https://core.vmware.com/resource/vmware-vsphere-metro-storage-cluster-vmsc

PowerStoreOS v3.0 introducing new host connectivity options to advertise optimal ALUA states to the ESXi host on a per-volume basis for metro volumes.

Host is co-located with this system – This option is used with Metro Volumes having non-equidistant paths in uniform storage presentation when the host and PowerStore are local to each other. In other words, the host and PowerStore are in the same datacenter or very well connected.

Host is co-located with the remote system – This option is used with Metro Volumes having non-equidistant paths in uniform storage presentation when the host and PowerStore are not local to each other. In other words, the host and PowerStore are in different datacenters with significant latency in between.

PowerStoreOS v3.0 supports two different metro topologies:

Uniform storage presentation – Both standalone servers and clustered servers accessing a Metro Volume may use uniform storage presentation. Uniform storage presentation provides host to Metro Volume storage paths through both clusters. The Round Robin path selection policy can quickly and easily be configured with uniform storage presentation and the host connectivity feature. With the ALUA intelligence built into both the storage host and the PowerStore clusters, optimal MPIO paths will be used for I/O, the storage fabric will be both well utilized and well balanced, and workloads will have minimal latency.

Non-uniform storage presentation – Clustered servers accessing Metro Volumes may also use non-uniform storage presentation. Non-uniform means that each storage host will access a Metro Volume through one cluster or the other, but not both. Non-uniform typically applies to a stretched cluster configuration with some distance in between where each host in the cluster accesses the Metro Volume through paths that are local in fabric proximity only. Each storage host would have read/write access to the Metro Volume via the local PowerStore cluster only. In this design, front-end I/O remains local in proximity. Again, implementing the Round Robin path selection policy with non-uniform storage presentation is typically preferred to provide automated port and fabric balancing, but the Fixed path selection

By using Metro Volume with an ESXi host that has access to both PowerStore clusters in a Metro Volume configuration, multiple paths can be presented to the server across the arrays:

Single-site MPIO configuration – In a single-site or uniform configuration, vSphere hosts may have paths to both PowerStore clusters. If a Metro Volume is mapped over both clusters to the vSphere hosts, the volume can participate in an MPIO configuration involving both clusters. In a Metro Volume configuration, the optimal I/O path is through the node which owns the Metro Volume in each cluster. In this scenario, using the vSphere Round Robin MPIO policy in conjunction with host connectivity configured as Co-located with both systems, ALUA ensures I/O traffic goes through each node of each cluster which owns the Metro Volume. This is a preferred configuration because it requires minimal administrative effort and yields a well-balanced fabric.

Multi-site MPIO configuration – In a multi-site or non-uniform stretched cluster configuration, each vSphere host is zoned and mapped only to its local corresponding PowerStore cluster.

In this configuration, the path selection policy can be configured as either Round Robin (preferred) or Fixed.