Dual Data Center Architecture: Choosing the Right Fabric Model
Role: Lead Network Architect
Context: Enterprise data center relocation and secondary-site expansion
Status: Completed
Selected Architecture: Cisco ACI Multi-Pod
Overview
A data center relocation created an opportunity to reconsider the organization’s network architecture rather than simply reproduce the existing design in a new facility.
The decision was whether to retain a traditional network model or adopt a policy-based data center fabric that could improve segmentation, application policy, resiliency, and dual-site disaster recovery.
Cisco ACI was selected because its policy model and segmentation capabilities offered meaningful architectural advantages, while Multi-Pod provided a practical way to operate two geographically separate data centers as a coordinated fabric.
Evaluation Criteria
The architecture decision focused on several requirements:
- stronger segmentation and policy abstraction
- support for a resilient dual-data-center operating model
- consistent application connectivity across locations
- simplified disaster-recovery design
- scalability beyond the immediate relocation
- operational supportability for the network engineering team
- appropriate complexity for the size and needs of the organization
The evaluation considered both traditional network architecture and multiple ACI deployment models.
Fabric Model Decision
ACI Multi-Site was considered because it provides greater independence between fabrics and additional control-plane separation.
For this environment, however, those capabilities introduced complexity that was not justified by the requirements of a two-site enterprise.
Multi-Pod offered a better balance.
It provided centralized policy and management while allowing the two data centers to operate as distinct pods connected across the data center interconnect. The design also supported consistent addressing and application connectivity across locations, making disaster recovery and later active/active operating models easier to implement.
The decision was therefore not simply to adopt ACI.
It was to select the ACI deployment model whose complexity matched the actual business and operational requirements.
Architecture Risk
The primary risk was not the fabric technology itself.
ACI introduced a new operating model for engineers accustomed to traditional network architectures. Policy abstraction, endpoint learning, contracts, bridge domains, endpoint groups, and fabric-based troubleshooting required a different way of thinking about data center networking.
The architecture therefore had to account for both technical design and operational adoption.
That included implementation planning, troubleshooting practices, documentation, and knowledge transfer so that the platform could be supported after deployment.
Outcome
The Multi-Pod architecture was successfully deployed across the two data center locations and became the foundation for the organization’s evolving data center operating model.
Over time, the design supported more advanced use of the two sites, including enhanced disaster-recovery and active/active patterns.
That operational history provided useful validation of the original architecture decision: the organization gained the dual-site resiliency and policy consistency it needed without introducing the additional complexity of a more independent multi-fabric architecture.
I later applied the same fabric-model evaluation in two additional organizations, where the same balance of capability, operational complexity, and two-site requirements again favored Multi-Pod.
Architectural Lesson
The most feature-rich architecture is not necessarily the right architecture.
Architectural value comes from matching capability and complexity to the problem being solved.
Multi-Site offered additional independence and control-plane separation, but those benefits were not sufficient to justify the additional complexity for this environment.
Multi-Pod provided the better fit because it solved the actual business problem while keeping the operational model within a complexity level the organization could reasonably support.
The decision was not about choosing the most advanced option.
It was about choosing the architecture whose tradeoffs best matched the enterprise.