Global Active Device: The 20 ms Rule Behind Hitachi GAD

Global active device is Hitachi Vantara’s active-active, synchronous storage replication technology, and its most important 2026 design limit is easy to miss: supported links can reach 500 km only when round-trip delay stays at 20 ms or less. I treat that number as a ceiling, not a performance promise, because every synchronous write depends on the remote path before the application receives completion.

That distinction is what separates GAD from a simple copy feature. Hitachi presents the paired primary and secondary volumes through a virtual storage machine so hosts can treat them as the same logical storage identity. Both sides can receive I/O, while multipathing and cluster software decide which physical path should carry application traffic. A quorum mechanism helps prevent both sides from independently accepting writes when the storage systems lose contact with each other (Hitachi Vantara, 2025a; Hitachi Vantara, 2026a).

For teams already evaluating broader enterprise storage infrastructure, the practical question is not whether active-active mirroring sounds attractive. It is whether the application, network, SAN, multipathing stack, quorum location, and recovery plan all agree on what should happen when one component fails. This guide follows that failure path from normal I/O through site loss, explains the 20 ms constraint, compares GAD with asynchronous replication and backup, and shows where migration and cloud quorum fit without treating vendor marketing claims as guaranteed outcomes.

What Global Active Device Actually Does

At its core, GAD maintains a synchronous pair between a primary volume and a secondary volume on two supported Hitachi storage systems. The paired volumes use the same virtual LDEV identity inside a virtual storage machine, which lets the host see a single logical storage identity even though the data exists on two arrays. In the mirrored state, read and write operations are permitted on both sides of the pair (Hitachi Vantara, 2026b).

The active-active label matters because traditional synchronous replication often keeps the remote copy passive until a failover. GAD instead supports host access from both sites while maintaining consistency between the paired volumes. Hitachi’s current documentation lists continuous server I/O, server failover and failback without storage impact, and virtual-machine migration without storage impact among the intended benefits (Hitachi Vantara, 2025a).

The storage layer is only one part of that outcome. Hosts need alternate-path software, and metro designs should use ALUA-aware multipathing or Hitachi Dynamic Link Manager so the preferred path stays local where possible. Without path preference, a server can send ordinary I/O across the inter-site link even when a local path is healthy. That adds avoidable latency and makes a stretched design look worse than the storage technology itself.

This is the first important information-gain point: active-active storage does not mean every path should be equally active all the time. The best-performing steady state is usually locality-aware. Each host uses the closest optimized path, while the remote path remains immediately available for failover.

The Write Path: Why 20 ms Matters More Than 500 km

Hitachi’s current VSP One Block requirements specify a maximum 500 km distance and a maximum 20 ms round-trip delay for the physical paths between the two storage systems. Long-distance configurations also bring protocol, topology, firmware, and host-mode requirements that must be checked against the exact platform and release (Hitachi Vantara, 2026a).

The physics are straightforward. Synchronous replication cannot acknowledge a protected write as if the remote system did not exist. The inter-site round trip becomes part of the storage response path, so added latency can appear directly in application I/O. The 20 ms figure is therefore an interoperability boundary, not an endorsement that a latency-sensitive database will be happy at 19.9 ms.

A useful design exercise is to separate three numbers: the vendor-supported maximum, the measured storage-to-storage round-trip time, and the application’s own latency budget. A trading system, transaction database, virtual desktop farm, and archive workload can tolerate very different storage response times. Production acceptance should test the actual write mix, failover state, and recovery state rather than rely on a distance map.

Network engineering also goes beyond raw bandwidth. Congestion, buffer behavior, packet loss, routing changes, encryption appliances, and packet-processing limits can change tail latency even when a circuit has ample nominal capacity. Perplexity AI Magazine’s guide to network performance and packet-processing constraints is a useful companion when validating the WAN and security devices that sit between replicated storage systems.

Jonathan De La Torre of Hitachi Vantara recommends teams “maintain two independent SANs” and use ALUA to avoid nonoptimized paths in his 2024 GAD best-practices guidance. That advice captures the operational reality: redundancy must be independent enough that one fabric fault does not become a two-site event (De La Torre, 2024).

GAD Design Guardrails at a Glance

Design factor	Verified guidance	Operational meaning
Maximum paired-system distance	500 km	A topology ceiling, not a guarantee of acceptable application latency.
Maximum round-trip delay	20 ms	Measure under peak and degraded network conditions, not only idle ping tests.
Long-distance path design	Switches or channel extenders, platform-specific requirements	Firmware, protocol, topology, and link engineering must match the exact model.
Host path behavior	ALUA or HDLM recommended for metro preferred paths	Keep normal I/O local and reserve remote paths for resilience.
Physical redundancy	Independent paths recommended	Avoid a single SAN or network device becoming a two-site outage.

The Quorum Disk Is an Arbiter, Not a Data Copy

The quorum disk exists to help the two storage systems decide which side should continue serving I/O when they cannot communicate normally. Both systems access the quorum resource as a shared arbitration point. Hitachi documents that the quorum can be an external volume or a disk presented by a supported iSCSI server, including a cloud-based virtual server such as Microsoft Azure (Hitachi Vantara, 2026c).

That role is frequently misunderstood. The quorum does not contain a third synchronized copy of the protected application volume. Losing the data on both GAD arrays cannot be repaired from the quorum. Its job is decision support during failure, especially split communication conditions where two active sides must not diverge.

Hitachi also publishes an Azure cloud-quorum implementation guide that uses an Azure virtual machine as an iSCSI target. The architecture can remove the need for a third physical storage array solely for arbitration, but it replaces that appliance cost with networking and cloud dependencies. The VPN path, Azure VM availability, iSCSI configuration, security rules, and reachability from both storage sites become part of the high-availability design (Hitachi Vantara, 2025b).

This creates the second hidden trade-off. Cloud quorum can reduce hardware friction, yet the quorum path must fail differently from the two data sites. Placing all three decision domains behind the same carrier, firewall cluster, identity dependency, or routing policy can preserve a logical single point of failure even when the resources sit in different locations.

What Happens During a Failure

In a healthy mirrored state, hosts can reach the paired volumes through their configured paths. If one host path or storage system becomes unavailable, alternate-path software can redirect I/O to the surviving side. In a server-cluster configuration, Hitachi states that cluster failover and failback can occur without suspending or resynchronizing the GAD pair itself (Hitachi Vantara, 2026d).

The harder case is loss of communication between the storage systems. The quorum process helps decide ownership so only the appropriate side continues accepting writes. Hitachi’s documentation describes a sequence of status checks through the quorum and notes that if confirmation is not obtained within its defined failure handling window, the pair can be suspended while I/O continues on the owner side. The exact behavior depends on failure type, pair status, I/O mode, and configuration.

This is why fault testing must go beyond powering off an array. Teams should test host-path loss, remote-path loss, storage-controller failure, quorum loss, WAN partition, site isolation, and combinations such as a primary-volume access failure during a remote-path fault. Some GAD settings exist specifically to avoid unintended failover behavior in clustered environments.

A mature operating model documents not just ‘site A failed’ but who owns I/O after each fault, which alarms appear, how the surviving site is verified, when resynchronization begins, and what conditions must be true before failback. The same discipline appears in strong managed IT strategies, where availability depends on repeatable operations rather than on a single resilient product.

GAD vs Asynchronous Replication vs Backup

Global active device solves a different problem from long-distance asynchronous replication and from backup. GAD is optimized for immediate availability and synchronous consistency across supported metro distances. Hitachi Universal Replicator, by contrast, uses asynchronous journal-based transfer so the primary write can be acknowledged before the remote copy is updated. That design tolerates longer distance and latency but introduces a nonzero recovery-point window (Hitachi Vantara, 2026e).

Backup solves another problem again. A synchronous mirror can reproduce an accidental deletion, corrupted block, malicious encryption, or bad application write on both sides. CISA therefore recommends offline, encrypted backups and regular restoration testing for ransomware resilience. High availability is not historical recovery (Cybersecurity and Infrastructure Security Agency, 2023).

Perplexity AI Magazine’s business continuity and backup guide makes the same operational distinction: a backup answers whether data can be recovered, while continuity asks how quickly the business can keep operating. A resilient architecture often needs both. GAD can reduce infrastructure interruption, asynchronous replication can extend geographic recovery, and independent backups can provide clean historical restore points.

Comparison Table

Approach	Write behavior	Typical role	Main strength	Main limitation
GAD synchronous active-active	Remote synchronization is part of protected write flow	Metro high availability and workload mobility	Very low data-loss window with both sides active	Latency, distance, and path complexity
Asynchronous replication	Primary write can complete before remote update	Long-distance disaster recovery	Tolerates higher latency and geographic separation	Possible recovery-point gap
Independent backup	Point-in-time copies outside live replication path	Historical and cyber recovery	Can restore earlier clean versions	Does not itself keep production I/O continuously online

When GAD Fits, and When It Does Not

GAD is strongest when downtime has a high business cost, the two active sites can stay inside a strict latency budget, hosts and applications support the required multipathing behavior, and the organization is willing to test failure scenarios as part of normal operations. Database clusters, virtualization estates, and other stateful services can benefit when storage needs to remain reachable while compute moves between sites.

It is a weaker fit when the secondary site is too far away for synchronous latency, the application is already latency-sensitive, the network is not under disciplined operational control, or the main requirement is cyber recovery rather than continuous I/O. In those cases, asynchronous replication, application-level replication, immutable backup, or a layered combination may provide a cleaner risk model.

Public list pricing for GAD licensing and the full surrounding architecture is not consistently available, so this article does not invent a cost-per-terabyte figure. The relevant cost model is broader than a license anyway: two storage systems, replication links, SAN fabrics, multipathing, quorum, implementation, testing, monitoring, and support all contribute. The decision threshold should therefore be the value of avoided interruption versus the total cost and operational complexity of sustaining the metro design.

For organizations with mixed generations of storage, lifecycle details can become as important as feature capability. Our guide to legacy array management illustrates the wider lesson: firmware state, management tooling, interoperability, and support ownership can determine whether a theoretically sound storage architecture remains operable years later.

Migration and Workload Mobility Without Moving the Storage Identity

One of GAD’s most practical uses is nondisruptive migration. Because the paired volumes can present the same virtual storage identity across two systems, servers can shift their active paths while data is already synchronized. Hitachi’s current VSP One Block documentation describes using GAD for online data migration, while warning that host I/O may still need to stop briefly if the operating system or multipathing stack cannot recognize the alternate path as redundant (Hitachi Vantara, 2026f).

That caveat matters. ‘Nondisruptive’ is an end-to-end property, not a storage-only flag. A storage pair can be healthy while an unsupported host configuration, stale device identifier, path policy, cluster timeout, or application dependency causes interruption during cutover. Migration rehearsals should therefore include host rescan behavior, path ownership, cluster state, application transactions, and rollback.

Virtual-machine mobility is especially attractive because compute can move without a separate storage migration event. Yet the performance design still matters after the VM lands. If the moved workload continues using a nonoptimized cross-site path, the migration may succeed functionally while leaving the application with higher steady-state latency. ALUA preference and site-aware host configuration prevent that quiet failure mode.

A Practical Design Checklist Before Production

A production review should start with supported models, firmware, licenses, and the exact GAD configuration documented for the storage generation. Then measure the replication path under peak and degraded conditions, including round-trip latency, loss, jitter, and failover routing. Do not certify the design from an unloaded ping test.

Next, verify path independence. Separate fabrics, redundant host adapters, redundant remote connections, and a quorum path that does not share the same failure domain reduce correlated outages. Confirm ALUA or HDLM behavior from every host and verify that normal I/O remains local when both sites are healthy.

Finally, rehearse recovery. Capture pair status, I/O mode, cluster state, application checks, alarm handling, and the exact failback sequence. Confirm that backup restoration remains independent of GAD. A successful failover test proves availability for the tested fault; it does not prove recoverability from data corruption or compromise.

The Future of Global Active Device in 2027

The credible 2027 direction is not that synchronous metro storage suddenly becomes distance-insensitive. Physics will continue to make latency the limiting resource. The more important trend is simplification around the edges: cloud-hosted quorum, automated configuration, better observability, broader mixed-platform support, and tighter integration with stretched compute clusters.

Hitachi’s current materials already position GAD within VSP One and three-data-center designs that combine synchronous metro availability with asynchronous replication for longer-distance disaster recovery. That layered architecture is likely to remain more useful than trying to make one replication mode solve every failure class (Hitachi Vantara, 2026g).

Cloud quorum is also likely to become more operationally attractive as enterprises normalize private connectivity to hyperscalers. Even so, its value depends on preserving failure-domain independence. A cloud VM is not automatically safer than an on-premises quorum if both storage sites reach it through the same fragile network edge.

The open question for 2027 is therefore operational, not conceptual: how much of GAD design, validation, and failover testing can be automated without hiding the dependencies that matter during a real partition? The strongest implementations will make state easier to observe while keeping ownership, latency, and recovery decisions explicit.

Takeaways

• Global active device provides active-active synchronous volume replication across supported Hitachi storage systems, but the complete availability outcome depends on hosts, networks, quorum, and cluster behavior.
• The 500 km maximum is bounded by a 20 ms round-trip requirement, so application latency testing matters more than the geographic headline.
• Quorum is an arbitration service, not a backup copy; cloud quorum can reduce third-site hardware but adds network and cloud dependencies.
• ALUA-aware path preference is central to keeping normal I/O local and avoiding unnecessary cross-site latency.
• GAD and asynchronous replication solve different distance and RPO problems, while backup remains necessary for clean historical recovery.
• Nondisruptive migration must be validated end to end because host multipathing or device recognition can still force interruption.
• The best GAD decision starts with the business value of avoided downtime and ends with repeated failure testing, not with a feature checklist.

Conclusion

Global active device is most valuable when an organization needs storage to remain continuously reachable across two metro sites and is prepared to engineer the surrounding system with the same care as the arrays themselves. Hitachi’s architecture can present synchronized volumes through a shared virtual identity, redirect I/O during failures, support clustered failover, and enable workload or data migration without a conventional storage outage.

The constraints are just as important as the benefits. Synchronous writes inherit network latency. Quorum determines ownership but does not protect historical data. Multipathing must prefer local routes. A clean storage failover can still be undermined by host, cluster, network, or application behavior.

That is why the most defensible design is layered. Use GAD for the failure classes where immediate metro availability matters, add asynchronous replication when geographic recovery demands it, and preserve independent backups for corruption and cyber events. When those layers are tested together, GAD becomes a precise availability tool rather than a vague promise of zero downtime.

Frequently Asked Questions

How does the quorum disk function in a GAD configuration?

The quorum disk acts as a shared arbitration point that both storage systems can access. When the arrays lose normal communication, quorum information helps determine which side can continue accepting host I/O. It is not a third copy of the application data, so it cannot restore a lost GAD volume.

What are the latency limitations for metro distances in GAD?

Current VSP One Block documentation lists a maximum 500 km distance and a maximum 20 ms round-trip delay between paired storage systems. That is a support boundary, not an application-performance target. Teams should measure workload latency under normal, degraded, and failover conditions before production.

How does GAD cloud quorum on Azure work?

Hitachi’s implementation guide uses an Azure virtual machine as an iSCSI target that presents a supported quorum volume to both on-premises storage systems. The design can replace a third physical quorum array, but VPN connectivity, VM availability, firewall rules, iSCSI security, and independent network paths become part of the availability model.

What is the difference between GAD and asynchronous replication?

GAD mirrors writes synchronously and keeps both paired volumes active, which supports very low RPO and fast failover inside a latency-controlled metro design. Asynchronous replication acknowledges primary writes before the remote update completes, allowing greater distance and latency at the cost of a possible recovery-point gap.

Does GAD replace backups?

No. Synchronous mirroring can copy accidental deletion, corruption, or ransomware changes to both sides. Independent backups remain necessary for clean historical recovery. CISA recommends offline, encrypted backups and regular restore testing, which addresses a different risk from storage high availability.

How does virtual machine migration work without storage impact?

GAD can present the same virtual storage identity from both arrays while the data remains synchronized. A VM can move to compute at the other site without a separate storage copy. The host multipathing and ALUA policy still need to select the optimized local path after migration.

Can GAD be used without a quorum disk?

Some Hitachi configurations support GAD pairs without a quorum volume for specific migration use cases. Hitachi warns that server I/O might stop if a path or storage failure occurs in that arrangement. For high-availability production designs, quorum requirements should be checked against the exact platform and intended failure behavior.

Methodology

Our desk reviewed Hitachi Vantara’s current GAD documentation for VSP One Block and Ops Center, including requirements, components, failover behavior, replication types, migration workflows, and the Azure cloud-quorum implementation guide. Current 2026 documents were prioritized, while the 2024 practitioner guidance was used only for operational best-practice context.

Claims about the 500 km distance ceiling, 20 ms round-trip delay, active-active volume behavior, quorum options, failover clustering, and migration were checked against Hitachi documentation. The distinction between high availability and backup was validated against CISA ransomware-recovery guidance. Five internal links were verified as live Perplexity AI Magazine pages and inserted only where they extend the reader’s understanding.

This article does not reproduce a production benchmark, does not claim that every Hitachi model supports every GAD topology, and does not provide unverified pricing. Real performance depends on storage model, firmware, SAN design, network latency, host multipathing, workload pattern, and application behavior. The exact support matrix should be checked before deployment.

This article was drafted with AI assistance and reviewed by the Perplexity AI Editorial Team. All data, citations, and claims have been independently verified against primary sources.

References

• Cybersecurity and Infrastructure Security Agency. (2023). #StopRansomware guide.
• De La Torre, J. (2024, September 9). Global-Active Device best practices. Hitachi Vantara Community.
• Hitachi Vantara. (2025a). About global-active device. Ops Center Administrator High Availability User Guide, version 11.0.x.
• Hitachi Vantara. (2025b). Global-Active Device Quorum on Azure Cloud: Configuration and specifications.
• Hitachi Vantara. (2026a). Requirements and restrictions. Global Active Device for VSP One Block, version 10.5.x.
• Hitachi Vantara. (2026b). About Global-Active Device replication. Protector concepts and data flow.
• Hitachi Vantara. (2026c). Global-active device components. Global Active Device for VSP One Block, version 10.5.x.
• Hitachi Vantara. (2026d). Failover clustering without storage impact. Global Active Device for VSP One Block, version 10.5.x.
• Hitachi Vantara. (2026e). Replication types. VSP 360 Protect documentation.
• Hitachi Vantara. (2026f). Migrating volumes using GAD. Global Active Device for VSP One Block, version 10.5.x.
• Hitachi Vantara. (2026g). Hitachi Virtual Storage Platform One Global-Active-Device: Continuous Operations [Data sheet].