The NSX Multi-site Architecture
By – Adnan Hussain (VCIX – NV)
Hi there, If you are looking for Multisite topologies based on applications availability across sites, may be in the form of stretch clusters or in the form of Active/Active Sites or Active/Stand-by sites architecture then you are at the right place.
I am writing this article in series / episodes to have a connection with you all and can discuss different aspects using this portal to address your understanding and to learn more
In-order to have Applications available across multiple sites even from on-premise to public cloud tenancies, you keep your infrastructure ready and expandable or responsive to difference architectural challenges and changes.
VMware being pioneer in providing Infrastructure relevant software like
All above technologies run on top of software logics with no dependency on Hardware make and model (only needed x86 architecture).
I will discuss all above listed technologies individually in detail but first of all let’s start with NSX and its Multisite capability.
NSX-Multisite is still basically divided into two major topological Structures that you can choose one depending on your need or requirement.
1. Multisite – Traditional architecture
2. Federation – Advanced architecture
Multisite – Traditional Architecture
This is simple to understand and deploy with maximum of upto 3 sites having two options to adapt in this topology implications
1. Single-site NSX Manager Architecture
2. Multi-site NSX Manager Architecture
So let’s discuss, single-site NSX Manager Architecture in more details.
In this case, all the instances of NSX Manager are required to be in the same site and Data Plane is needed to be spanned across multiple (Three) sites including ESXi Hosts and Edge Nodes.
- The Round Trip Time (RTT) between NSX Managers must not go beyond 10 millisecond if stretched across sites or Rack or Datacenter(s).
- The Round Trip Time (RTT) amongst Transport Nodes must not go beyond 150 milliseconds if stretched across sites or racks or DC(s).
- And, in this topology (Multi-site) you must follow to configure MTU 1700+ end to end.
Below diagram can illustrate a high level construct of physical and virtual network binding with NSX provided traditional multi-site requirement.
In the light of above explanation, let’s dig-out some more options and probabilities.
Let’s say, we have a requirement of high bandwidth (consumption) based application with Active/Active Instance requirement on two different sites located far off from each other of having 5000+ KM approx. (across countries).
What would be the plan or deployment strategy of infrastructure services and network design in this case. Though the Applications are core internal business apps and are not required to be published through 3rd party ISP/Cloud services.
In the above explained example, application provided infrastructure should be designed as below or close to below design solution and justifications.
Above information is derived from VMware online resources for VCF.
There are more things to discuss with this design, which we can talk about one by one slowly to make up the pace and digest this information easily.
My Next topic in continuation to this series would be site resiliency models and their impact using multi-site architecture. Stay Tuned 😊 …
Follow me on LinkedIn: www.linkedin.com/comm/mynetwork/discovery-see-all?usecase=PEOPLE_FOLLOWS&followMember=adnan-hussain-69750823
