Key Technical Considerations for Dual‑Active Data Center Architecture

Active‑active (dual‑active) is the preferred solution for critical business disaster recovery. Currently most dual‑active data‑center solutions are based on SAN block storage because SAN performance and latency meet the requirements of applications such as databases, ERP, SAP, etc., making SAN dual‑active widely adopted and supported by many vendors. However, technology is not a limitation; NetApp FAS and IBM GPFS also provide NAS dual‑active capabilities, mainly because many databases (e.g., Oracle RAC, IBM PureScale) can be deployed directly on NAS.

Dual‑active is the highest‑level disaster‑recovery requirement, thus its deployment imposes basic requirements on applications, network, storage, and virtualization.

Distance requirements: because dual‑active uses a dual‑write mechanism to ensure strong data consistency, the acceptable distance is typically 100–300 km within the same city; although I/O latency and timeout can be tuned, user experience must be considered. Data‑sync links usually use FC switch cascading, and when the straight‑line distance exceeds 30 km, DWDM wavelength‑division multiplexing equipment with repeaters and dispersion compensation is needed; DWDM can support up to 3000 km.

Network requirements: latency, bandwidth, and bit‑error rate all affect dual‑active. Since data is replicated in real time between the two sites, link bandwidth must exceed the peak I/O bandwidth; latency impacts overall application response; a high error rate reduces network efficiency because retransmissions consume additional bandwidth.

Performance requirements: dual‑active demands high performance, so storage and servers at both sites must be comparable; a bottleneck at one site degrades the other. In gateway dual‑active designs, the gateway must also avoid becoming a performance bottleneck.

True active‑active versus pseudo active‑passive: many vendors define true active‑active as a pair of mirrored LUNs across the two data centers that can simultaneously receive read/write I/O from a clustered application, with consistency ensured by both storage and application clusters. In practice, this depends heavily on storage and application types; both must support true active‑active to be meaningful. If storage is active‑active but the application (e.g., VMware) is not, the solution effectively becomes active‑passive.

Multipathing: storage‑based dual‑active typically requires multipathing to switch between sites, so many vendors develop proprietary multipathing optimizations. VMware offers a PSA interface for storage vendors to implement custom multipathing modules to optimize paths and I/O. However, proprietary multipathing is not mandatory; vendors can use native OS multipathing, albeit with lower performance. For example, XenServer/Citrix lacks a VMware‑like PSA interface, so it cannot support third‑party multipathing, but its built‑in multipathing can support ALUA if the array also supports ALUA, enabling path optimization.

A comprehensive guide titled "Dual‑Active Data Center Technology" is provided for download, covering data layer, storage layer, access/application layer, virtualization/platform layer, and key technologies.