Home > Storage > PowerStore > Data Protection > Dell PowerStore: Metro Volume > Host connectivity
In a Metro Volume configuration, PowerStore supports uniform and non-uniform host access. During host registration, the operator can choose the host connectivity which also sets the ALUA states for the individual paths.
In a non-uniform host connectivity configuration (shown below), each host has paths to only a single PowerStore appliance. For instance, hosts in Site-A are mapped to only the PowerStore cluster in Site-A, and hosts in Site-B are mapped to only the PowerStore cluster in Site-B. Since the Metro Volume is spanned across both PowerStore clusters, the mapped Metro Volume is the same to all hosts in the cluster. The following sections use the terms Site-A and Site-B to identify the different sites when running Metro Volume across different locations (two fault domains). However, PowerStore Metro Volume is also supported when the participating PowerStore systems are installed in a single location side by side (single fault domain).
In a setup with uniform host connectivity (shown below), each host has active paths to both PowerStore clusters. For instance, all hosts in Site-A and Site-B are mapped to PowerStore in Site-A and Site-B. This configuration provides extra resilience. If there is an array failure or link-loss situation, VMs can continue running on any hosts by using paths to the non-affected array with the preferred volume.
PowerStore Manager enables you to select the host connectivity type when registering a new host. The following diagrams show the possible host configuration.
Local connectivity: This configuration provides host and application access to standard volumes and to the Metro Volume exclusively in this storage system. Use this configuration for standard volumes, and for Metro Volumes on the PowerStore in a non-uniform host setup. The following example shows that host H1 is connected to the PowerStore cluster PS1 in a non-uniform host configuration.
Host is co-located with local system: Use this option with Metro Volumes that have non-equidistant paths in a uniform storage presentation when the host and PowerStore are local to each other. In other words, the host and PowerStore are in the same data center or are connected optimally. Use this option for local hosts with lower latency than the remote hosts. In this configuration, hosts always attempt to send I/O to the metro volume on this system except in failure situations, and it results in an active-optimized path for the hosts. As shown below, you can use this configuration for a uniform host connection on PowerStore cluster PS1 for host H1 which is in the same location.
Host is co-located with the remote system: Use this option with Metro Volumes that have non-equidistant paths in a uniform storage presentation when the host and PowerStore are not local to each other. In other words, the host and PowerStore are in different data centers with significant latency in between. Use this option for the hosts which are remote to the PowerStore cluster with a higher latency than the local hosts. The host only sends I/O to the Metro Volume on this system in failure situations and results in active-non-optimized paths for the hosts. As shown below, you can use this configuration for a uniform host connection on PowerStore cluster PS1 for host H2 which is in the remote location with higher latency.
Host is co-located with both systems: Use this option with Metro Volumes that have equidistant paths in a uniform storage presentation when the host and both PowerStore clusters are local to each other. In other words, the host and both PowerStore clusters are in the same data center or are connected optimally. The host uses its own multipath configuration to determine the best path for I/O. This option is useful for configurations when all hosts have same latency to the PowerStore cluster. If you use this option for both PowerStore clusters, it results in active-optimized paths to both ends of a Metro Volume. You can use this option when hosts H1 and H2 and PowerStore clusters PS1 and PS2 are in the same location with the same latency.
With different metro connectivity options for hosts in a uniform setup, the paths are presented to the hosts with the following ALUA states. PowerStore uses implicit ALUA to provide optimized-path information for connected hosts. For load-balancing, PowerStore selects one node of the appliance as the optimized node for a volume with node affinity. The assigned node affinity information for each volume is available in the Volume overview after adding you add the column Node Affinity. The PowerStore CLI and PowerStore REST API enable you to manually change the node affinity setting.
Note: It is required to use consistent LUN numbers for standard volume mappings and Metro Volume mappings across hosts within the same vSphere cluster, hosts within other vSphere clusters, or hosts not in a cluster. For additional information, please see the following references:
Dell KB Article 000191503 PowerStore: Inconsistent Logical Unit Numbers between hosts could result in data access or data consistency issues
VMware vSphere Product Documentation: vSphere Storage | Setting LUN Allocations | Storage provisioning
Starting with PowerStoreOS 3.5, user interface enhancements in PowerStore Manager provide diagrams for each of the host connectivity options. The diagrams describe the locality of the host and the I/O pattern that can be expected relative to the PowerStore appliances configured for Metro Volume. A solid line between the host and PowerStore indicates an optimized path. A dotted line between the host and PowerStore indicates a non-optimized path.
The following table outlines the valid metro host connectivity configuration possibilities.
Physical/Virtual HostA instance Definition |
| |
HostA registered with specific connectivity type on PStoreA (Preferred role for MetroVolume1) | HostA registered with specific connectivity type on PStoreB (Non-Preferred role for MetroVolume1) | Connectivity |
Uniform-Local | Uniform-Remote | Valid |
Uniform-Remote | Uniform-Local | Valid |
Uniform-Equidistant | Uniform-Equidistant | Valid |
Non-Uniform | --- not mapped to same physical/virtual host instance as metro peer | Valid |
--- not mapped to same physical/virtual host instance as metro peer | Non-Uniform | Valid |
The configuration in the following table assumes that the volume has selected node A for volume node affinity with Metro Volume role preferred on site B.
Metro connectivity | PowerStore cluster site-A | PowerStore cluster site-B | |||
Host site-A | Host site-B | Node A | Node B | Node A | Node B |
Co-located with | Co-located with both systems | Active-optimized | Active-non-optimized | Active-optimized | Active-non-optimized |
Co-located with | Co-located with remote system | Active-optimized | Active-non-optimized | Active-non-optimized | Active-non-optimized |
Co-located with remote system | Co-located with local system | Active-non-optimized | Active-non-optimized | Active-optimized | Active-non-optimized |
During failure scenario, or standard volumes1 | |||||
Co-located with local system | Co-located with remote system | Unavailable | Unavailable | Active-optimized | Active-non-optimized |
During node failure PowerStore node A at site-A | |||||
Co-located with local system | Co-located with remote system | Unavailable | Active-non-optimized2 | Active-non-optimized | Active-non-optimized |
Co-located with remote system | Co-located with local system | Unavailable | Active-non-optimized | Active-optimized | Active-non-optimized |