NSX-V Lab: Secondary NSX Manager Configuration

Intro

Welcome to Part 10 of the NSX-V Lab Series. In the previous post, we covered configuring the Segment ID’s for both global for site A and Universal Segments.
In this post we will cover configuring our secondary NSX Manager, prepared our Site B hosts and configured them for VXLAN so it’ll be a pretty large post but don’t worry we’ve already done all this before on the primary manager so it’ll be simple 😉

The Build

I’m going to skip over most of the steps since we have already covered how to deploy an NSX manager etc however I will the differences needed for the Site B NSX Manager deployment and configuration.
First off I deploy a new NSX manager for Site B.
I’ll be deploying it onto the Lab cluster just as I did for the Primary NSX Manager so it will run directly on the physical hosts along with the vCenter2. The main difference between the primary and secondary NSX managers here is that the Primary manager sits in VLAN 10 and the secondary sits in VLAN 15.
There’s no need for these to be different but I’ve done it that way because well why not.
So during the OVA deployment I select SiteB-MGMT for the management network.

Of course the IP’s and name will be unique.

Once the manager is deployed I again need to reduce the CPU and RAM for the lab down to 1 CPU and 5 GB RAM and remove the reservations.

Once the manager is powered on we can login and start the initial configuration the main difference here is that we are going to connect it to vcenter2. Remember NSX-V managers have a one-to-one mapping to vCenters

As shown the Secondary NSX manager is now paired with the vCenter2

Once the manager is rebooted we need to login again to our vCenter.
If you have a shared SSO domain you can login to either vCenter and you’ll see both vCenters and both NSX managers.
If the SSO domain is separate then you have to do everything from different windows. For my lab the vCenters are in the same SSO domain so I can do everything from a single pane.

From here we now need to set our NSX manager to secondary.
It’s a bit counter intuitive but we need to select the Primary NSX Manager not the Standalone.

Once selected Click ‘ACTIONS’ then ‘Add Secondary Manager’

Select the new NSX Manager from the drop down list. Enter the username and Password and click ‘ADD’

Accept the Thumbprint.

Our NSX Manager is now set as a Secondary.

If we change to the NSX Controller Nodes screen and select the Secondary NSX Manager you will notice it has the same NSX controllers as the Primary.
Remember we don’t deploy controllers to the secondary NSX Manager unless we are failing over the site, it does however utilize the controllers on the primary site.

Before I forget lets set the CDO mode.
Controller Disconnected Operation (CDO) mode ensures that the data plane connectivity is unaffected when hosts lose connectivity with the controller.
From the NSX Managers tab click each NSX Manager go to ‘Actions’ and click ‘Enable CDO mode’

Click ‘Yes’

CDO is now enabled.

We can also now configure the Unique IS Selection Criteria.
The unique ID selection criteria is used when assigning Universal Security tags for use with the distributed firewall to Virtual Machines on active standby deployments.
Unique ID is used by the NSX Manager when a Virtual Machine goes from standby to active deployment. The unique ID can be based on VM instance UUID, VM BIOS UUID, or VM name or a combination of these options.
If the criteria changes (such as a VM name change) after universal security tags have been created and attached to VMs, the security tag must be detached and reattached to the VMs.

Select the Primary NSX Manager click ‘Actions’ and then ‘Unique ID Selection Criteria’

Pick one or more criteria and click ‘SAVE’

Right we now need to prepare our Site B hosts.
The process is the same as before just ensure that the Secondary NSX Manager is selected on the drop down menu otherwise you won’t see the site B hosts 😉

Once the hosts have NSX installed we need to setup our IP pools.
We will setup two pools but use only one at this stage. They are the Site B controller pool and the Site B VTEP pool.
The VTEP pool will be used to configure our host VTEPS.
The controller pool will only be used when we do a site failover as the controllers need to be re-deployed and will need an IP pool ready for this.

So go over to ‘Groups and Tag’ then ‘IP Pools’ ensure the secondary NSX Manager is selected and click ‘+ ADD’
Enter the details for the Site B controller pool. and Add.

Now we add the Site B VTEP IP Pool the process is the same but with the details for the VTEP’s

Now we have the Pools configure we can setup VXLAN on our hosts.
So back to ‘Installation and Upgrade’ select our compute cluster and either go to the actions menu and configure VXLAN or click on the ‘CONFIGURE’ in the middle of the right pane.

Enter the Site B details and ‘SAVE’ Then repeat for the Edge cluster.

At this stage also make sure you set the IP Detection type for each cluster.

The final step is to set our Segment IDs. So go to ‘Logical Network Settings’
Notice that the Universal Segment ID is already set, remember it’s only set on the Primary NSX Manager and is then replicated to all secondaries.
Go ahead and click ‘EDIT’ and we will add our Global Segment ID which is local this this NSX Manager

You can only edit the local Segment ID here so add in the desired range remembering not to overlap with the Primary site.
My Primary site was set to 5000-5999.

We now have our Segment ID set.

That’s it we are now ready to carry on with the Lab build
NSX-V Lab Part:11 NSX-V Transport Zones

Leave a Reply

Your email address will not be published. Required fields are marked *