Metro Volume supports a diverse range of configuration options. Modify or expand on the examples and use cases in this section to suit your needs.
Single Site
A simple Metro Volume configuration at a single site might consist of a single Windows server host or Hyper-V host, or a failover cluster or Hyper-V cluster.
Use Cases:
- Move a workload from PowerStore A to PowerStore B as part of an upgrade.
- Move a workload to PowerStore B temporarily to perform offline maintenance on PowerStore A.
- Load-balance between PowerStore A and PowerStore B.
Figure 67. Metro Volume with a single Windows host at one site
Figure 68. Metro Volume with a Windows Server failover cluster/Hyper-V cluster at one site with a file witness
Configure a witness disk as a quorum disk as an alternate way for your cluster to achieve quorum with failure scenarios.
Figure 69. Metro Volume with a Windows Server failover cluster/Hyper-V cluster at a single site with a quorum disk witness
Configuration notes:
- All components are in the same building or data center.
- A Microsoft file share witness or quorum disk witness is not needed if you have a single-server host.
- A Microsoft witness is recommended if you have an even number of server cluster nodes (two, four, six, and so on).
- Configure a Microsoft file share witness as a best practice.
- A quorum disk will also work well as a witness when all components are local (in the same data center).
- Server hosts/nodes are uniformly mapped to both PowerStore clusters.
- A Metro Volume witness increases resiliency but is optional. Place it locally, or remotely.
- All Metro Volume data paths are local, so they are equidistant and experience similar latency and bandwidth.
- Choose the PowerStore Host Connectivity Option: Metro Connectivity – Co-located with both systems.
- A single site offers no protection against a site failure such as an unexpected disaster or power outage.
Multisite with a stretched failover cluster/Hyper-V cluster
Configure a second site within metro distance to take advantage of additional Metro Volume functionality, such as site-specific disaster avoidance. When you configure a second site, careful planning is required because it introduces complexity. If you configure a second site and use Metro Volume, use witnesses to increase resiliency.
- A third site is recommended for the Microsoft file share witness (optional) and the Metro Volume witness (optional) to avoid site bias.
- Place witnesses at the preferred site if a third site is not available.
Windows failover clustering and Hyper-V are not aware of Metro Volume and the abstraction that masks the underlying architecture. Failover clustering and Hyper-V behavior are a function of the availability and state of the data storage paths, and the ability of surviving nodes to achieve quorum given an outage. Careful planning is required to ensure wanted behavior with failure scenarios. Carefully review the impact of where you place critical components such as cluster disks and the quorum witness. A continual focus on maintaining situational awareness is required to avoid unexpected results.
Use cases:
- Move a workload from PowerStore A to PowerStore B as part of an upgrade.
- Move a workload to the PowerStore at Site B temporarily to perform offline maintenance of the PowerStore at Site A.
- Load balance between PowerStore A and PowerStore B.
- Disaster Avoidance.
- Disaster avoidance requires that you have enough time to invoke your contingency plan.
When Site A will suffer an outage due to a planned event such as a power outage.
When Site A is at risk of a service-impacting natural event such as an approaching hurricane.
- Recover at Site B if Site A suffers an unexpected and extended outage.
Note: Test your disaster recovery and disaster avoidance plans regularly. Make sure they will work when they are needed.
Figure 70 shows a stretched cluster with uniform server mappings, a Microsoft file share witness at a third site (optional), and a Metro Volume witness at a third site (optional).
Figure 70. Metro Volume with a stretched cluster over metro distance with uniform server mappings.
Figure 71 is the same as Figure 70, except that it is configured to use nonuniform server mappings.
Figure 71. Metro Volume with a stretched cluster with nonuniform server mappings
Figure 72 and Figure 73 show the impact of site bias that favors Site A when a third site is not available.
Figure 72. Metro Volume with uniform mappings and site bias for Site A.
Figure 73. Metro Volume with nonuniform mappings and site bias for Site A
Figure 74 and Figure 75 show configuration examples with a Microsoft quorum disk witness (optional) instead of a file share witness, along with a Metro Volume witness (optional) at a third site.
Figure 74. Uniform mappings with a quorum disk and Metro Volume witness
Figure 75. Nonuniform mappings with a quorum disk and Metro Volume witness
Figure 76 and Figure 77 show configuration examples with a Microsoft quorum disk witness (optional) instead of a file share witness, along with a Metro Volume witness (optional) at Site A (site bias).
Figure 76. Site bias that favors Site A with uniform server mappings and a quorum disk
Figure 77. Site bias that favors Site A with nonuniform mappings and a quorum disk