Active‑Active Dual Data Center Architecture: Requirements and Technical Overview

Active‑active (dual‑active) is the preferred disaster‑recovery solution for critical business services; most existing implementations rely on SAN block storage because of its performance and latency characteristics, which suit databases, ERP, SAP, etc., making SAN‑based dual‑active widely adopted, while solutions like NetApp FAS and IBM GPFS demonstrate NAS‑based dual‑active capabilities thanks to databases such as Oracle RAC and IBM PureScale that can run directly on NAS.

Dual‑active is the highest‑level disaster‑recovery requirement, so its deployment imposes fundamental prerequisites on applications, networks, storage, and virtualization.

Regarding distance, dual‑active uses a dual‑write mechanism to guarantee strong data consistency, typically limiting acceptable separation to 100‑300 km within the same city; for longer spans, fiber‑optic links employ FC switch cascades, and when the straight‑line distance exceeds 30 km, DWDM wavelength‑division multiplexing with dispersion compensation is needed, supporting up to 3000 km.

Network requirements include low latency, sufficient bandwidth, and low bit‑error rate; because data is replicated in real time between sites, the link bandwidth must exceed peak I/O demand, latency affects overall application response, and high error rates increase retransmissions, degrading network utilization.

Performance demands are stringent: both data centers must have comparable storage and server capabilities, otherwise the slower side becomes a bottleneck; gateway designs must also avoid becoming performance limits.

True active‑active (Active‑Active) versus pseudo active‑passive (Active‑Passive) is distinguished by whether each site hosts a mirrored LUN pair that can simultaneously handle read/write I/O from a clustered application, requiring both storage and application layers to support true active‑active; otherwise, even with storage support, an application like VMware that is not active‑active forces an active‑passive configuration.

Multipathing is typically required for storage‑based dual‑active to enable seamless failover between sites; many vendors develop proprietary multipathing optimizations, while VMware offers a PSA interface for third‑party modules. Native multipathing can also be used, though with reduced performance; platforms lacking a PSA interface (e.g., XenServer, Citrix) rely on built‑in multipathing such as ALUA, provided the array supports it.

The article concludes with a downloadable guide titled “Dual‑Active Data Center Technology,” which comprehensively covers the data layer, storage layer, access/application layer, virtualization/platform layer, and key technologies.