NSX-T offers two technical solutions for Multi-Locations On-Prem Data Centers:
This NSX-T Multi-Location Design Guide offers guidance and best practices for Network & Security services in your On-Prem locations.
FYI there is also some other nice documents on this use case:
Note: This document may be updated in the future so always check you have the latest version.
The Design Guide version for NSX-T 4.1 release is 1.5 done on 11/13/2023.
The Design Guide version for NSX-T 4.0 release is 1.10 done on 08/22/2023.
The Design Guide version for NSX-T 3.2 release is 1.19 done on 08/22/2023.
The Design Guide version for NSX-T 3.1 release is 1.31 done on 06/21/2023.
questions: "deactivate cluster" could be supported in 2.x? this will be a check box or something in the future, meaning make it easy, os could be invoked thru API call?
Yes "deactivate cluster" is also supported in NSX-T 2.x releases.
Question on multisite Management plane recovery with SRM (220.127.116.11.1, option 2 - SRM):
I am assuming that on p.44 the document talks about vSphere replication, quote: "SRM replicates it to the secondary location at specific intervals (default 1 hour and minimum is 5 minutes)".
Also it looks like NSX-T 3.1 documentation no longer mentions the guideline of disabling vSphere snapshots on the NSX-T Manager VM.
Would this mean that NSX-T management cluster nodes in 3.1 can support some level of asynchronous replication / restore? Would vSphere Replication be supported (since it can not provide consistency / synchronicity across multiple replicated VMs) in the SRM scenario mentioned above?
Thank you so much .
You are correct about the SRM / vSphere Replication comment. I just fixed it in the lasted Design Guide.
And about your asynchronous replication question, you're also correct. It's supported since NSX-T 3.0.2 (https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.0/administration/GUID-F3A0A27E-88C0-4A64-8754-....
Dimitri, your link is broken.
@CyberNils Can you try again?
Still not working. The ) is included in the link address, so I think you must remove that.
Thank you for this documentation it is amazing!I have a question about the multi site NSX Manager 2+1 architecture. When Site A crashes and we use the "deactivate cluster" command on Site B, what happens to the cluster and the nodes when Site A comes back. How will the cluster behave? What are the procedures in this case? After using "deactivate cluster" command can we include this NSX Manager back to the cluster or we have to create a new cluster and delete NSX Managers from Site A?
Does NSX-T 3.2 bring any significant changes to the multi-site design guide? I assume we'll get an updated design guide at some point, but I wanted to ask in the interim. (I see some notes in the release notes around support for VM tag replication and some management/operational improvements, but it doesn't seem like those make any significant changes to design.)
After the "deactivate cluster, you have to redeploy new NSX-T Mgr VMs to rebuild a cluster of 3 VMs Managers.
The NSX-T 3.2 brings some enhancement in Multi-Location:
I expect the NSX-T Multi-Location Design Guide for NSX-T 3.2 to be available end of this week 😉
Thanks for the update. Federation w/ network introspection is something I'm certainly interested in. The release notes didn't indicate there was anything new there.
Is there any guidance on how to deploy load balancing (either NLB or ALB) in conjunction with federation? I know I can't configure LB from the GMs themselves, but I believe it's possible to do from each LM. However, I'm not sure what is the best way to do that and then migrate it to another site in the event of a failover. (My use case is an primary/secondary DR scenario, so I don't need to worry about having the LB active at both sites simultaneously.)
Situation - Management cluster deployed in 2+1 mode accross 2 sites in different subnets. It is possible that ESXi TNs are served by Management cluster nodes in a remote DC.
Failure - failure on the interconnect between site (creating a split brain).
Will it work in a way that the Transport nodes will connect to reachable Management cluster node locally, the single node won't be accessible from UI / API and configuration automatically sync between the nodes when the connectivity between sites recovers?