article NSX Multisite 101 ToI in VMware NSX Documents

NSX Multisite 101 ToI

ddesmidt — Mon, 21 Aug 2023 20:56:45 GMT

This document highlights NSX-T MultiSite capabilities from NSX-T 2.5 including:

. All use cases currently supported

. How to deploy it

. Manual/Scripted and (new) Automatic Recovery steps

. Recorded Demos

Note: NSX-T 3.0 offers the same NSX-T Multisite capabilities detailed in NSX-T 2.5.

Also FYI, VMworld 2019 had a public session presenting NSX-T Multisite "NSX-T Design for Multi-Site [CNET1334BU]" Recordin g + Deck.

Note:

NSX-T 3.0 introduced a second Multisite technical solution offer: Federation.

Federation solution is based on a new component: “NSX-T Global Manager Cluster” (GM).

GM offers a central global configuration of multiple (local) NSX-T Manager Cluster, each offering Network & Security services for a Location.

Federation solution targets "Large Scale Deployment", replies to "Specific Site Management/ GDPR/ Policy Requirements", and offers "Simplified DR".

NSX-T Multisite solution remains fully available to customers in NSX-T 3.0 and the deck above applies to NSX-T 3.0 release too.

NSX-T Multisite solution is perfect for customers who don't need "Large Scale", want a "Smaller NSX-T Management Footprint" (with only 3x NSX-T Mgr VMs for all their locations), and accept a "DR Recovery Procedure with few more requirements/steps".

Re: NSX-T Multisite

ChrisOk — Mon, 25 Mar 2019 10:52:43 GMT

Thank you very much for this presentation.

For "Current NSX-T Multisite Lite Requirements and Limitations" it is mentioned: "No Local-egress capabilities (100% North/South traffic goes via 1 site)"

Is there any plan to support this in future releases?

Re: NSX-T Multisite

ddesmidt — Mon, 25 Mar 2019 15:03:36 GMT

There is no committed day/release for that feature yet.

Can you contact ddesmidt@vmware.com for your "Local Egress" Use case and understand how you are looking at using it.

Thanks,

Dimitri

Re: NSX-T Multisite

RaymundoEC — Fri, 01 Nov 2019 19:46:08 GMT

thanks guys!

Re: NSX-T Multisite

tmtechnologent — Mon, 16 Dec 2019 17:07:30 GMT

Is this going to become a part of the product from a deployment option or will it remain a design/manual deployment?

Re: NSX-T Multisite

ddesmidt — Wed, 05 Feb 2020 17:58:34 GMT

It's a design you choose.

You can make it manually (click-click-click) or orchestrate that via your orchestration tool (API).

Re: NSX-T Multisite

RaymundoEC — Wed, 26 Feb 2020 16:08:51 GMT

I hear your voice saying "click click click"

Re: NSX-T Multisite

Ahmed_Bouja — Sat, 28 Mar 2020 15:39:31 GMT

Hi Dimitri,

I have seen the published presentation about the NSX-T 2.5 Multisite and DR recovery procedure (https://communities.vmware.com/docs/DOC-39405). It is a great job and it helps us a lot. Thanks a lot for sharing this document.

We have a question and we need your support and assistance please if possible.

Through the Data plane recovery steps when the production site is down, we have remarked only these two actions to be performed:

Attach the Tier 1 to the DR tier 0
Modify the Tier 1 EDGE cluster to the DR site EDGE cluster.

Because the transit subnet between Tier 1 and Tier 0 is assigned automatically (from Subnet 100.64.0.0/10), normally when moving Tier 1 Gateway from production site to DR site, this transit subnet will be changed to a new one and we have to change the static routing on both Tier 1 and Tier 0 gateway. Is that correct?

Thanks a lot

Ahmed

Re: NSX-T Multisite

stephenhowellvc — Fri, 24 Apr 2020 11:14:20 GMT

Hi Dimitri,

We are seeking to deploy NSX-T with multi-site failover where stretch-L2 is not an option for the NSX-T manager cluster.

What does the failover process look like without stretch L2? We understand that DNS entries are required and must be changed to new IPs as the nodes move to the new site. We are wondering if this is simply a case of re-starting the NSX-T manager node at the other site and changing IP and DNS entry or if it is more complex? Documentation is hard to find on this one.

thanks

Re: NSX-T Multisite

ddesmidt — Mon, 18 May 2020 23:02:45 GMT

You're correct. Those "internal T0/T1 subnets" will be different after the move of T1 to a T0-DR.

However, T0/T1 routing is something "internal".

There is nothing to do on the NSX-T Managers nor the physical fabric.

You can watch the embedded demo videos of the recovery to validate that by yourself.

Dimitri

Re: NSX-T Multisite

ddesmidt — Mon, 18 May 2020 23:04:53 GMT

The exact steps of NSX-T Manager recovery are well detailed in the deck.

And you even have embedded videos for each step (ppt section "Demo Script/Manual").

I let you look at those in detail.

Thanks,

Dimitri

Re: NSX-T Multisite

r0ck — Mon, 01 Jun 2020 09:59:43 GMT

Very useful guide! Is it really correct that the hole traffic has to go over 1 site?

I mean: blue data plane goes 1 site and if you want with AS Prepend green data plane goes the other..

Then the statement 100% north/south traffic goes via 1 site is wrong in my opinion, its more like,

all blue traffic has to use the same north/south site and all green traffic has to use same north/south site (if you want the other one with as prepend).

Hint: In this scenario of course you have to use /24 BGP external ip adress blocks for blue and green site.

I dont see the limitation here. Its limited to the green and blue data plane but not to the hole traffic, right?

Re: NSX-T Multisite

r0ck — Mon, 01 Jun 2020 10:02:41 GMT

How you do the configuration of the additional overlay uplink for blue and green site?

Its a geneve segement where you route the sites between each other, right?

Re: NSX-T Multisite

emerson132 — Tue, 30 Jun 2020 16:56:05 GMT

Thanks for this document its very helpful.

I do have a question, if I want active/active multi-site cross vCenter topology. Site A and Site B are going to host there own site specific workloads, and then SRM will protect some workloads in Site A to Site B, and Site B will protect some workloads in Site B to Site A.

I dont want to have to Re-IP the workloads during failover.

Is this possible?

Re: NSX-T Multisite

ddesmidt — Wed, 08 Jul 2020 16:30:20 GMT

Correct. The "interlink" between the T0-Blue and T0-Green is an Overlay Segment connected on those T0 as uplink (so BGP can be configured).

Dimitri

Re: NSX-T Multisite

ddesmidt — Wed, 08 Jul 2020 16:31:48 GMT

Yes that's possible. That's what the deck talks about in the "Active/Active Use Case"

Dimitri

Re: NSX-T Multisite

DonalB — Thu, 10 Dec 2020 10:48:15 GMT

Hi Dimitri,

Excellent deck, 2 quick questions

1. Is protecting the NSX Managers with vSphere Replication and SRM a valid approach in the case where stretched management vSphere cluster is not an option (we do have an NSX-V universal LS to place the managers on) - any drawbacks to using vSphere replication?

2. For the T0 is there local site recoverability from Blue to Green?

Thanks

Re: NSX-T Multisite

shank89 — Thu, 10 Dec 2020 22:34:12 GMT

Hey DB,

What sort of RTT do you have between sites?
By site recovery, do you mean workload and segments fail from blue to green? If so the answer is no, the edge clusters attached to their respective t0s maintain their own segments and work loads, when the active edge fails, the dataplane comes up in the standby site. As Dimitri mentioned earlier, there is a segment between the two for bgp and route exchange.

Cheers

Re: NSX-T Multisite

IanDJackson — Wed, 22 Dec 2021 08:43:15 GMT

Slide 26 is a little misleading, it makes it look like you have 4x edge nodes when in fact you can only use 2x edge nodes for automated active-standby T0 failover I believe?

Re: NSX-T Multisite

Techstarts — Mon, 17 Jan 2022 11:53:34 GMT

This topic which I'm describing below is do with the local egress.

What I'm depicting is a pretty common Datacenter scenario. Maybe I might have not fully understood

In VCF design document it state "local egress in VCF is not recommended"

I want to understand how others are handling below scenarios.

DC1 --is running Domain Controller DomContr01 and DC2 is running another Domain Controller e.g. DomContr02.

Server01 is deployed on overlay segment. Server01 wants to communicate with DomContr02. In this case, traffic will move out of NSX Domain and go to Preferred Site and come back to DomContr02?

Since local egress is not allowed, all traffic will hairpin to preferred site.

I'm concern about the local services (not deployed in Overlay or VLAN Backed segments) deployed in the DC2. Will this communication always hairpin to Preferred Site.