Multisite lite question

[SpencerLaV]

Hello all.

I am looking to deploy nsx-t in multiple sites. I have looked thru docs for multisite lite and am consider that option (we don't have federation license level iirc).

But i noticed one thing. It seems multisite lite requires nsx-t overlay deployment, t-0 and t-1 routers, etc but we want only microsegmentation.

Does multisite lite work with microsegmentation only deployments?

[shank89 · Accepted solution]

I take that to mean that you will only be using VLAN backed segments?

If so, you can still perform micro seg on VLAN backed segments.  The hosts will need to be prepped for NSX-T (vibs installed and hosts configured) so you can configure VLAN backed segments on all of the host transport nodes.  How these VLANs route is dependant on your network configuration.

The multi-site configuration that you are talking about is for overlay segments, where you either do active-active or active-standby T0 gateways and route through them.

An easy way to think of it for your scenario is that you are just creating VLAN portgroups in NSX-T instead of vCenter.  Their traffic is leaving the hosts on those VLANs locally to the ToR's or whatever is above the hosts.

Keep in mind, this is all if you are in fact talking about just running VLAN backed segments and not terminating or moving the VLAN gateways into NSX-T.  If you do want to do that, you will need to create some gateways in NSX-T and utilize router ports.

You may find this blog article useful; https://vmdave.com/2020/04/13/prepare-clusters-for-vlan-micro-segmentation-with-nsx-t-3-0/

[SpencerLaV]

Greetings Shashank.

Thx for your reply. Yes we only want vlan backed segments, so no t-0 routing or overlay. We use dr use case for multiple sites using srm.

So for dr use case is it correct that multisite lite guideline still is still used for my case, but just ignore overlay parts?

So ensure requirements met like fqdn registration and dr site nsx-t manager backup/restore functions. Then per guide when failover to dr we update local dns and restore nsx-t manager?

So as long as dr site has physical infrastructur set up correctly (default gws and routing) the restored nsx-t manager will still do microsegmentation on recovered srm workloads?

Thx again for your reply.

[shank89]

For me it would come down to the rest of the design. If you are using vlans, does that mean you are stretching your networks across as well?

Also, if you lose your management plane, your dataplane still works.  Its just in your best interest to recover faster.

Any stretched clusters? I guess not if you are recovering with srm.

But depending on how you're structuring it and the boxes are checked, then yea those recovery methods should still work.

[SpencerLaV]

Greetings.

Thx again. We are stretched vlans to dr site , network team use  otv to do this. but do not intend to stretch clusters unless can make strong argument for them. As you say we use srm for dr and do not have stretched storage either.

With this in mind does it still make sense to use multisite lite steps for nsx-t manager restore or would u use other option? Or us srm for nsx-t manager recovery?

[shank89]

It'll all still work, it sounds like nothing will be re-ip'd, so you could probably get away without using fqdn.  Doesn't hurt though. 

[SpencerLaV]

Greetings.

Can I ask u a followup question? What is reason to use multisite lite, with or without overlay added, over just srm dr?

I am having read over multisite lite guidebook and many blog posts, but i do not see advantage. Am i missing something simple?

[shank89]

As mentioned earlier, you are not really running true multisite and just vlan backed portgroups.  

The only difference from the traditional vDS portgroups is that you are using VLAN backed segments in NSX-T and doing so to enable micro-seg capabilities.

Multisite refers to either an A/A or A/S edge cluster design.  A few different architecture models and their use can be found here; https://www.lab2prod.com.au/2020/09/nsx-t-active-active-multisite-part1.html and in the multisite deck.

As I had mentioned earlier, how your network is configured determines how your packets traverse with VLAN backed segments that are not terminated in NSX-T.

[SpencerLaV]

Greetings.

Thx for ur reply. I know ur site lab2prod. Good work!

If business consider active/standby nsx-t multisite deploy like #1 option in your article (greater than 10ms latency, no shared storage or clustered mgmt) and use nsx-t overlay/t-0 routing, what does multisite lite w/ srm advantage over just srm dr recover? That is my confusion i think.

By the way HybridNetArchit on this form find error in nsx-t multilocation guide where states on the bottom of pg 38 that nsx-t manger vms does not currently support srm. but as you kindly say earlier that is an error and should work fine. Thx.

[shank89]

You would use SRM in conjunction with multisite.  

That is, SRM would be used to failover workload, the standby edge (that already exists in the DR DC) would become active in the event of active edge failure.  However, just because your standby edge becomes active, doesn't mean the workload and management appliances are active in that data center..  Eg.  How do you access your workload if the entire DC where they sit is offline?

If you don't have a method of failing over the workload, you would just have an active edge node in the DR data center with nothing behind it.  Hence my questions about stretched clusters and design.

You may find some useful information here; https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-E1412B0E-A661-4400-AF81-....  Although I guess you have already seen it.

[alejandromemu]

Hello, I am having a very similar scenario.

i undesrtand this:
using multi-site NSX-T only with segments based on VLANs, without overlay (without T0, BGP ..).

In case the main site fails, the NSX-T manager must be recovered by modifying the DNS records and the Managers must be backed up on the secondary site.
vlans-based segments will now be accessible on the secondary site correct?? and in this way the workloads can be reconnected to these segments but at the secondary site.

I understand that by not having a T0 with BGP or overlay, it will be necessary for the physical network to make the adjustments to allow communication now in the secondary site.

Thanks