NSX with Separate Clusters vs Cross-VC NSX

[nov1ce]

Hi,

We have one cluster (ClusterA) containing 4 VSAN nodes in the DataCenterA, and another cluster (ClusterB) with 4 VSAN nodes in the DataCenterB. There are 2 x 10GB lines (L2) between both data centers with <10ms latency.

Both clusters are managed by one VC, and there is NSX deployed in ClusterA. There is no common/shared storage between both clusters/data centers.

We're considering to extend NSX functionality to the ClusterB, and after reading Multi-site Options and Cross-VC NSX Design Guide I'm trying to understand what are the key advantages of Cross-VC NSX vs NSX with Separate Clusters?

Both designs are active-active with the VM mobility, and consistent networking and security across sites. OK, having a secondary NSX Manager is clearly a plus, but what are other major benefits in going towards the Cross-VC direction?

Thank you in advance.

[bayupw]

Hi

In my opinion, it would be depend on your requirements both infra/management requirements and application requirements.

At the moment you only have one VC in DataCenterA so you might want to think first whether you need a separate vCenter in DataCenter B or not.

The good thing with separate VC for DataCenterB is that you can access and manage DataCenterB if DataCenter A is unavailable.

But the drawback is you can't share same NSX objects (security groups, security policy/firewall rules, logical switch) unless you use Cross-VC NSX.

Especially with the DFW, for example if you have some VMs in DataCenterA communicating to VMs in DataCenterB you cannot use NSX dynamic security objects on your rules.

VMs in DataCenterB need to be specified using IP Sets in NSX Manager/vCenter in DataCenter A.

Whereas with Cross-VC, you can use Universal DFW objects.

Active/Active would also depend is it active only for one network or some network (logical switch) will active in two sites.

If you need local egress, at the moment single VC with local egress can only work with static routing.

So if you have dynamic routing with local egress, you would need multi-VC and cross-VC NSX

I normally don't recommend stretching layer 2 network whether it is through physical stretch layer 2 network solutions or through VXLAN.

Stretching layer 2 network is tricky when you need to handle the ingress routes and stateful services such as load balancing services or north-south firewall services.

Imagine you have a load balancer in DataCenterA, if you need to move the workload VM behind load balancer to DataCenter B, you can probably move the VM to DataCenter B and stretch the network.

But your load balancer stays in DataCenterA you would need to create a new load balancer in DataCenterB with same config and shutdown load balancer in DataCenterA.

If it is a partial application failover, then there could be some communication between app in DataCenterA & DataCenter B and the app components are miliseconds apart instead of microseconds apart.

Things could get really messy

[vXav]

Hi Bayu,

Do you know if there is a safe way to get VM mobility across sites for the management components (vCenter, NSX, etc...) in a single vCenter deployment?

Just a cheeky attempt to dodge the gold plated Enterprise license

[bayupw]

As my reply in your other thread.

First option is vSphere Metro Storage Cluster

Second option is storage replication or via backup software to a standby management cluster in Site 2 with a manual recovery process .

But the IP addresses of the management VMs need to stay as I believe changing the IP address of the VMs would break the underlying app (vCenter, NSX Manager, etc).