Solutions

How to Build a Three-Tier Active-Active Data Center with Arcfra AECP?

Published on 2026-10-14 by Arcfra Team

Last edited on 2026-10-14

Key Takeaways:

Infrastructure-layer active-active: Active-active data centers should be interconnected via dark fiber, with an RTT of less than 5 ms. The witness node only requires a standard Layer 3 IP network with an RTT of less than 100 ms. Virtual machine high availability (HA) and distributed firewalls can also be used to further improve availability.
Application-layer active-active: The implementation and RTO target should be planned according to the application architecture (Web-APP-DB three-tier, monolithic, or hybrid).
Access-layer active-active: This is the most commonly overlooked layer. High availability should be ensured for both client access and communication between business systems. Active-active can be implemented through external switches, VPCs, and other approaches.
Two-city, three-center architecture: Building on an active-active architecture, an off-site disaster recovery (DR) cluster can be introduced to provide tiered protection for business services. Planning and implementation should be guided by three principles: design the architecture as a whole, implement capabilities as needed, and ensure a smooth switchover.

When planning active-active data centers, enterprises often focus only on whether the underlying infrastructure supports active-active operation, while overlooking whether applications can meet their recovery objectives and whether access paths are equally highly available. A truly effective active-active solution should be a systematic effort spanning the infrastructure, application, and access layers.

In the following sections, we draw on Arcfra’s solutions and practical experience to explain how to build a three-layer active-active data center based on Arcfra Enterprise Cloud Platform (AECP), its key considerations, and the implementation roadmap from active-active clusters to a two-site, three-center architecture.

Why Active-Active Still Matters When You Have Backup and Disaster Recovery Solutions

Backup, disaster recovery, and active-active may sound similar, but they address different priorities.

Backup focuses on data security. It primarily prevents data loss by creating copies of data.
Disaster recovery focuses on recovering from disasters. Like insurance, it is mainly concerned with what happens after a disaster and the measures taken to compensate for the resulting losses.
Active-active focuses on business continuity. It takes a proactive approach by setting limits on potential business disruption and losses before a disaster occurs.

IT system’s DR construction can be classified into six levels:

Levels 1–2: Typical data backup scenarios, including local and off-site backup. Data copies must be available to meet these requirements.
Levels 3–4: Ranging from partial to full disaster recovery, these levels require a certain degree of equipment redundancy, with full equipment redundancy in place to complete recovery from disaster.
Level 5: Real-time disaster recovery for data loss or interruption. At the data protection layer, RPO=0 is achieved, while recovery within minutes is acceptable.
Level 6: Application active-active clusters for business continuity. On top of RPO 0, they significantly shorten RTO, enabling zero data loss and failover within seconds.

It can be seen that active-active solutions represent the highest level of the overall disaster recovery framework.

A Three-Tier Active-Active Solution Based on Arcfra AECP

Active-active solutions for on-premises data centers are relatively complex and typically involve three layers: infrastructure, application, and access. Arcfra’s active-active data center solution based on AECP is likewise structured around these three layers.

Infrastructure-Layer Active-Active: Building a Cross-Data-Center Stretched Cluster

The infrastructure layer includes full infrastructure clusters for compute, storage, network security, and related resources. Active-active deployment at this layer is a key focus for many enterprises. Arcfra achieves this by deploying a stretched cluster: Arcfra AECP nodes are deployed in two data centers and integrated into a single logical cluster, with data synchronously written across both sites.

1. Physical Distance

Active-active deployments have stringent requirements and are subject to limits on the physical distance between the two data centers. Although the speed of light is extremely high, data writes are sensitive to latency. Given the propagation delay of light, the theoretical distance limit between two active-active data centers is generally considered to be 100 kilometers. In practice, however, the distance should generally be kept within 50 kilometers to account for link quality and other factors.

2. Links

Because the two data centers must be integrated into a single logical cluster, dark fiber is required to ensure real-time and reliable data synchronization. Carrier-provided private lines can also provide connectivity, but they often involve multiple network hops and intermediate devices. Their parameters are difficult to control, and latency can fluctuate significantly, making them unsuitable for carrying the underlying synchronization traffic for active-active operations.

Therefore, the safest and most reliable approach is to interconnect the two data centers via dark fiber and ensure an RTT of less than 5 ms. This target is readily achievable: over a distance of 30–40 kilometers, RTT can typically remain stable at 1–1.5 ms when link quality is good.

3. Witness Node

In an active-active architecture, a third site, the witness node, must be deployed in addition to the two data centers. The witness node serves as a tie-breaker to maintain strong data consistency. It cannot be placed inside data center A or B because active-active operates at the data-center level. If an entire data center fails due to a power outage, disaster, or other event, a witness node at the same site would fail as well, preventing the cluster from correctly determining its state.

Therefore, the witness node must be located outside and remain independent of two stretched sites. The witness node can be deployed on either a physical server or a virtual machine.

In terms of network requirements, the witness node does not need to be connected to two data centers and via dark fiber. A standard Layer 3 IP network is sufficient. Bandwidth in the hundreds of Mbps is enough, and an RTT of less than 100 ms meets the requirement, so the network requirements are relatively flexible.

4. Dual Protection: 3 Storage Replicas + VM High Availability

Once the active-active cluster is in place, Arcfra AECP further enhances system reliability through dual protection.

Three-Way Data Replication: In addition to two replicas stored locally at the VM’s site, a third replica is maintained at the remote site.
VM High Availability: When a host fails, the system first uses its local HA VMs to automatically take over the affected workloads. If an entire data center becomes unavailable, the workloads automatically fail over to the remote site and continue running.

5. Virtual Network East-West Firewall

For an active-active data center, many enterprises focus not only on compute, storage, and networking, but also on cloud security, particularly the security of east-west traffic in virtualized environments. With Arcfra Network Suite (ANS)’s distributed firewall, security policies are automatically synchronized and follow VMs as they move between data centers A and B, without manual intervention.

Application-Layer Active-Active: Meeting RTO Targets for Different Applications

Application-layer active-active is a higher-level goal in active-active data center design. The purpose is not simply to own an active-active platform, but to ensure the continuity of critical services, so core applications can keep running during failures and meet the expected RTO targets. Different application architectures can achieve significantly different RTO targets.

1. Web-APP-DB Architecture

For a typical Web-APP-DB three-tier application, if each layer supports clustered deployment or high-availability protection, such as application clustering or application HA, application failover can be completed in seconds, with the overall RTO approaching zero. Arcfra’s active-active solution provides shared resources across data centers, integrating infrastructure-layer active-active with application-layer clustering.

2. Monolithic Applications

the application follows a monolithic architecture, with the application and database running in the same VM and difficult to separate, it cannot be deployed as a cluster and typically lacks process-level monitoring and failover mechanisms.

With Arcfra AECP’s active-active solution, the RTO can typically be kept within 10–15 minutes. If the application starts quickly, for example, with a VM boot time of 3 minutes and application recovery within 2 minutes, the overall RTO can be reduced to 5 minutes. In this case, the application-layer RTO is determined by two factors: the VM HA recovery time and the time required for the application to resume service.

3. Hybrid Architecture: Coordinated Protection for Physical and Virtualized Workloads

For scenarios where databases (such as Oracle) still run on physical servers, Arcfra AECP can provide disaster recovery between physical and VM-based databases. The two databases can be synchronized in real time, while database sharding, read/write splitting, and other capabilities can also be supported. This improves performance while maintaining data consistency and high availability.

In short, different application architectures determine different RTO targets. During an active-active project, the IT infrastructure team should communicate fully with business teams to clarify each application’s architecture and achievable RTO target.

Access-Layer Active-Active: The Most Easily Overlooked Layer

When building an active-active data center, the access layer is often the easiest part to overlook. Even when the underlying architecture is resilient and the application layer has complete high-availability protection, business departments or end users may still be unable to access the service.

Scenario 1: Client Access Layer

Take a hospital customer as an example. In Campus A, business departments typically access the systems in Data Center A through the intranet. Traffic to Data Center B must first pass through Campus A’s core switch before traversing the inter-data-center link.

If the core switch or the entire equipment room in Campus A experiences a power outage, the systems in Data Center B may be quickly restored under the protection provided by the active-active platform. However, the business units, outpatient areas, and clinical departments across Campus A would still be unable to access the systems because their network path to Data Center B would be unavailable.

Arcfra AECP adds an external-switch layer to the existing network access architecture. Each business unit connects to Data Centers A and B through dedicated external switches and separate uplinks, creating two independent access paths. As a result, even if the core network or data center in Campus A fails, business departments can still access Data Center B directly through the redundant link provided by the external switches, ensuring high availability at the access layer.

Scenario 2: Inter-Service Access

Another key issue at the access layer is how business systems communicate with one another. In many use cases, the two data centers are built at different times, resulting in differences in network device models and subnet planning between the new and existing data centers. As a result, the two sites do not share a common gateway or network environment.

To connect the network layers of Data Centers A and B, enterprises can use a physical SDN solution or ANS’s VPC to extend a virtualized Layer 2 network across the two sites. This creates a unified virtual network across different physical networks and device architectures, enabling Layer 2 connectivity for business networks and gateway high availability.

Further Evolution: A Two-City, Three-Center System

After the three-layer active-active system is in place, the next step is to build a two-city, three-center system. This system consists of two components.

Metro active-active cluster: This includes Data Center A, Data Center B, and a witness node. The witness node does not need to be hosted in a dedicated data center; it can run on a standalone VM, as long as the VM is located outside both Data Centers A and B and remains physically independent of them.
Off-site disaster recovery cluster: This is typically deployed as part of a two-site, three-center system. Once active-active capabilities have been established within the same city or campus, a disaster recovery site can be deployed farther away to further improve overall disaster recovery capability.

Compared with a standalone active-active solution, a two-city, three-center architecture can provide tiered protection for applications with different criticality levels by combining active-active and disaster recovery.

For mission-critical workloads: They can be deployed in a metro active-active cluster to ensure the highest level of business continuity.
For general or edge workloads: Asynchronous disaster recovery can be used to prevent data loss, while allowing for brief interruptions and rapid recovery.

This tiered protection strategy provides differentiated protection levels and expands geographic coverage from within the same city to across cities. Although active-active deployments are subject to physical distance requirements, disaster recovery architectures are not subject to the same constraints and can be deployed across longer distances.

Therefore, under a two-city, three-center architecture, coordinated active-active and disaster recovery strategies can continuously protect data and maintain business continuity in the event of either a local site failure or a disaster at a remote site.

Implementation Strategy: Unified Platform, On-Demand Construction, and Smooth Transition

Many enterprises initially regard active-active architecture as a large and complex undertaking. It involves the infrastructure, application, and access layers, and may appear very different from the planning and implementation of a traditional data center. In fact, an active-active solution based on Arcfra AECP does not have to be implemented all at once as part of a greenfield project. It can be implemented in phases with a smooth transition.

Unified Platform: From an architectural perspective, Arcfra’s active-active solution is not fundamentally different from a non-active-active deployment. It is not a separate specialized solution, but part of Arcfra AECP’s built-in capabilities. Whether the deployment uses a single cluster, active-active, or a two-site, three-data-center architecture, it runs on the same Enterprise Cloud Platform foundation.
On-Demand Construction: Enterprises can invest in infrastructure capabilities as needed based on their stage of development. For example, they can start with a hyperconverged cluster in a single data center and gradually expand to partial active-active, full active-active, and even a two-city, three-center system.
Smooth Transition: In traditional IT environments, active-active deployments often depend on dedicated hardware, such as specialized storage gateways. For software-defined architectures centered on hyperconverged infrastructure, active-active is an optional capability within the overall architecture. Arcfra AECP has built-in active-active capabilities that can be enabled through configuration. Thus, moving from a non-active-active deployment to an active-active deployment does not require a fundamental change in the architecture.