What Is Dell PowerStore Active-Active Architecture? Guide (2026)

Dell PowerStore active-active architecture is often reduced to “two storage systems are active at the same time,” but the correct interpretation requires reading metro protection, witness, preferred system, fractured-session behavior, and host multipath together. The short answer is this: PowerStore active-active behavior is delivered through metro protection, which creates bidirectional synchronous replication between two PowerStore systems; hosts see the two physical copies as a single metro volume with multiple paths, but during failure scenarios the preferred system may continue host I/O while the nonpreferred side stops servicing I/O. This guide is written for teams that want to understand active-active as a real operational model rather than a marketing phrase.

This guide is especially useful for:

storage teams planning PowerStore metro across two data centers
architects trying to separate active-active metro from standard synchronous replication
system administrators formalizing witness and preferred-site decisions
organizations that need to read metro failure behavior together with host access

Quick Summary

According to Dell, metro protection provides bidirectional synchronous active/active replication across two PowerStore systems.
A metro volume is typically positioned up to 96 km or 60 miles apart across two data centers.
Hosts see the two physical volumes as a single volume with the same SCSI image and multiple paths.
A metro session requires two PowerStore systems and optionally a witness service; the witness should run on a separate host or VM.
When a metro resource becomes fractured or connectivity is lost, the nonpreferred system can stop host I/O while the preferred system continues servicing access.
Dell states that asynchronous and synchronous replication are not additionally supported on metro resources; protection policy integration is limited to snapshot behavior.

What Is PowerStore Active-Active Architecture?
How Does Metro Protection Build This Model?
Why Do Witness and Preferred Site Matter?
How Do Host I/O and Multipath Work?
How Should Fractured Sessions and Failure Scenarios Be Read?
What Mistakes Happen Most Often?
Related Content
Checklist
Next Step with LeonX
Frequently Asked Questions
Sources

Dell PowerStore active-active architecture image

Image: Wikimedia Commons - Cabinet Network Rear Tall.

What Is PowerStore Active-Active Architecture?

In PowerStore, active-active behavior refers to the dual-system access model created by metro protection. According to Dell’s metro protection documentation, two PowerStore systems cooperate on the same metro resource and expose the same data image to hosts.

The critical point is this:

active-active is not a loose model where both sides write independently under every condition
the design is synchronous and consistency-driven
the decision model depends on witness state, preferred-system choice, and connectivity status

That is why active-active cannot be summarized as “data exists on both sides.” The accurate reading is that the same logical storage object is exposed through two systems with multipath access and failure-aware control behavior.

How Does Metro Protection Build This Model?

According to Dell’s Metro protection documentation, metro:

provides bidirectional synchronous replication
maintains the same data on two systems
presents a single metro volume to hosts
supports availability, disaster avoidance, and migration use cases between data centers

This differs from classic replication in several important ways:

the session is not just one-way replication
hosts see two physical storage endpoints as one logical volume
protection policies can still add local snapshot behavior to the metro resource

Dell’s Using protection policies with metro documentation also states that the same protection policy is applied to the metro resource on both systems, that the remote-side policy is read-only, and that user-side changes are synchronized every 15 minutes.

This maps directly to Hardware & Software Services, especially NAS / SAN Storage Installation and Configuration, because metro is not just a storage-array setting; it must be designed together with host connectivity and pathing.

Why Do Witness and Preferred Site Matter?

Dell recommends placing the witness service on a separate host or VM. The reason is straightforward: if both metro systems are impacted, or if communication becomes unstable, the environment needs an external decision point.

Preferred-system choice is just as important. Dell explains that during certain failures:

the metro session can become fractured
the nonpreferred system can stop servicing host I/O
the preferred system continues serving access

So active-active does not mean “both sides always accept I/O in the same way forever.” During a failure, the design must already know which side continues service. Witness placement and preferred-site choice are therefore business-continuity decisions, not just storage settings.

How Do Host I/O and Multipath Work?

One of the most important statements in Dell’s metro documentation is that the two physical volumes are perceived by the host and application as a single volume with multiple paths, using the same SCSI image and data.

That leads to several practical conclusions:

host multipath configuration is a core part of active-active metro design
path availability is not just a storage topic, but a host behavior topic
the application usually sees one logical volume, not two separate arrays

According to Dell’s Configure a metro volume documentation, the metro-configured volume must also be mapped to a host on the remote system. If that step is skipped, the active-active design remains incomplete from the host perspective.

This also matters for Storage Capacity Planning and Performance Optimization, because metro design needs latency, path behavior, and performance to be evaluated together.

How Should Fractured Sessions and Failure Scenarios Be Read?

Dell’s documentation shows that when a metro resource becomes fractured or a metro session is paused, behavior changes:

snapshots are generated only on the active system
the nonpreferred system can stop host I/O
the preferred system continues access

Dell’s metro-availability KB also documents that after an appliance reboot or power outage, metro volumes may not immediately return to host-I/O availability and session state must be checked explicitly. This is an important reminder that active-active should not be interpreted as “both sides always come back automatically under every condition.”

The Pre-requisites and limitations documentation further states that metro is supported for volumes and volume groups, while more detailed limits should be validated through the support matrix.

What Mistakes Happen Most Often?

Treating active-active like unlimited dual-side write freedom

In reality, control behavior depends on witness state, preferred-system choice, and failure condition.

Treating witness as optional and therefore unimportant

Without a well-placed witness, decision integrity is weaker during split conditions.

Treating metro like normal synchronous replication

Metro changes host visibility and I/O behavior. Not every synchronous session is active-active.

Skipping remote-side host mapping

Metro host access requires correct host visibility on both systems.

Trying to combine metro with additional replication rules

Dell explicitly says metro resources do not support extra asynchronous or synchronous replication.

Treating fractured state as just a harmless alarm

In fractured state, active/passive behavior can change and host I/O impact must be investigated directly.

Checklist

two PowerStore systems and a remote-system connection were validated for metro
witness service was planned on a separate host or VM
preferred-system choice was aligned with business continuity policy
the metro volume was mapped properly on both sides
fractured-session behavior and host impact were documented in the runbook
no extra replication expectation was attached to the metro resource

Next Step with LeonX

Dell PowerStore active-active architecture is not just about linking two storage systems; it requires metro protection, witness placement, preferred-site logic, and host multipath to be designed together. LeonX supports this through Hardware & Software Services, especially NAS / SAN Storage Installation and Configuration and Storage Capacity Planning and Performance Optimization, where PowerStore metro design is evaluated through business continuity goals, latency behavior, and host access patterns together. To review your current environment or request a proposal, continue through the Contact page.

Relevant pages:

Frequently Asked Questions

Which feature provides PowerStore active-active behavior?

According to Dell, metro protection delivers the active-active model.

How does a metro volume look to the host?

The host and application see the two physical copies as one logical volume with multiple paths.

Why is witness needed?

Witness supports safe decision-making during connectivity loss or system failures and helps enforce preferred/nonpreferred behavior.

Can metro resources also use additional asynchronous or synchronous replication?

No. Dell states that metro resources do not support those extra replication types.

What should be expected during a fractured session?

Dell says the nonpreferred system can stop host I/O while the preferred system continues serving access.

Sources

Share this article

Facebook

Twitter