NSX SETUP IN A SMALL ENVIRONMENT

[mmarstrell]

Hello, I'm working on setting up NSX Advanced in a small environment and was hoping I could get some advice. We are currently running VSphere 6.5 Standard on 3 hosts; we have standard virtual switches set up now and I know I'm going to have to move to a distributed switch with NSX. So a few questions.

First, is adding NSX non-disruptive? I have the NSX Manager VM in our environment; can I attach it to VCenter without any network disruption to our existing VMs? I assume distributed firewall is turned off at first. I'll still need to set up my distributed switch and add my hosts after the fact as I won't have the licensing until NSX is active.

Second, we currently have our hosts (5 active NICs each) set up with 2 NICs teamed and dedicated to vMotion and Management networks, 2 NICs dedicated to our Production network (All our VMS are in this network) and 1 NIC dedicated to a Heartbeat network. Is this overkill and we should just have all 5 teamed and communicating with all networks? Or are dedicated NICs best practice? We have a SDDC that just has two NICs per host and they are teamed and connect to all networks without any issue. I figured this was a good time to re-evaluate our set up as we transition to a distibuted switch configuration.

Third, once I have the DSwitch set up can I attach the hosts one at a time and still have them communicate the others, ie is there a non disruptive way to transition the hosts?

Thanks for any help you can give. 😃

[smitmartijn · Accepted solution]

Hi,

I'd be interested in knowing what NSX functionality you would be using. It's probably security, as automation isn't usually needed in a smaller environment?

As for your questions; yes, installing NSX is non-disruptive. The firewall is installed with a default rule of "allow any any". Host preparation (on a clean host, not having used NSX or vCNS before) will also be non-disruptive. If you're going to be doing virtual networking (VXLANs, distributed routing, NSX Edges), there will be some disruption as you build the new NSX network next to your existing network and move the VMs over to the NSX networks. You can mitigate that somewhat with a L2 bridge and moving subnet per subnet.

The current VMware Validated Designs (VVD) give the best practice for 2x 10Gbit uplinks per host. Network I/O Control is used to keep certain traffic (vMotion) from bothering other traffic flows. Here's more info: VMware Validated Design 4.1 Documentation Library

Migrating between an old standard vswitch and a new distributed switch can be quite non-disruptive and simple, the only "but" is that you have multiple uplinks of the same configuration. What you do is remove an uplink from the old vSwitch and plug that into the new VDS, make sure the portgroups are the same (and the VLANs used), then use the network migration tool to swap VMs on a certain standard vswitch portgroup to a new DVS portgroup. I've done these migrations during office hours, it's just like a vMotion.

Hope that helps,

[mmarstrell]

Yes, mostly the micro segmentation functionality with the possiblity for distributed routing and load balancing in the future. Your answer helped a lot, thanks!

[mmarstrell]

One more question about the distributed switch migration; So I moved over two interfaces over to the VDS from each host along with any VMKernal Adpaters, and then moved the VMs over as well. Everything was fine; I'm now in a state where there's some old port groups on the simple switches but no VMs, etc. Well when I went to move the last adapters over on the host that's running VCenter over I lost connectivity to vCenter. I was able to get connected to vCenter from a VM on a host still connected to the simple switches and get the original adapters moved back, so we're up for now. Do I need to specifically allow management traffic on the VDS port groups or is there something else I'm missing? We have a simple set up that doesn't employ VLANs so there was none on the old and None set on the new. Any ideas?

Thanks in advance.