Posted by Back in February VMware announced version 2.4 of NSX-T calling it a “landmark release in the history of NSX”. The new and enhanced features introduced in version 2.4 are indeed impressive:
- Converged NSX Manager appliance – bringing together management, policy, and central control services in one appliance with 3-node clustering support. Thus we now have high availability and a scale-out architecture for the management plane.
- Simplified user interface – making configuration and administration of the NSX platform much intuitive.
- A declarative policy model – specify your network and security requirements in a JSON file and send it to the API which will then deploy and configure all the necessary components to achieve the required outcome.
- Advanced security features – L7 application context-based firewalling, identity-based firewalling, FQDN/URL whitelisting, guest introspection, and E-W service insertion.
- Higher levels of scale, better performance – Bigger, better, faster.
With a “what’s new” list like this I have no other option than to upgrade my only weeks old 2.3 installation. Let’s see how that works out.
The lab environment
Just a quick recap of my lab environment in the form of some diagrams.
On a high level the environment looks like this.
Zooming in on an ESXi transport node that is hosting an Edge VM:
And finally the routing topology as I’ve configured it:
Most of the components are running in a nested environment.
The upgrade
VMware released an excellent upgrade guide which is a must-read if you’re about to upgrade to version 2.4. The upgrade checklist especially is a great resource for getting through the process and I highly recommend to follow it at all times.
Upgrade bundle
I start by downloading the 2.4 upgrade bundle which a 7,3 GB MUB package you fetch from VMware.com.
Once downloaded I log in to my NSX Manager and navigate to System > Utilities > Upgrade.
On the landing page I see the different components and their current version. I click on the “Proceed to Upgrade” button:
Under “1. Bundle And Status” I upload the MUB package:
The uploading and subsequently unpacking of the bundle will take some time.
System upgrade
Once done I click on “Begin Upgrade”. I accept the license agreement (what else?) and start the system upgrade:
The upgrade coordinator gives me a clear overview and the option to run pre-checks to see if the different components are ready for an upgrade to version 2.4:
Running pre-checks is not mandatory, but highly recommended so I’ll do that:
In my lab environment I received one non-critical issue on NSX Manager:
Well, this is a lab environment so I’m good here and will continue with the system upgrade.
The upgrade coordinator starts with the (ESXi) hosts. Here we have some options:
We can upgrade in serial or in parallel and decide for which conditions we want to pause the process. Under “Host Groups” I see that the coordinator has created a group containing the hosts in scope.
Under Actions > Change Upgrade Mode I can decide which mode I want to use:
This is a lab environment so I’ll do an in-place upgrade. Notice the warning though and understand that “Maintenance” mode is a better fit for a production environment.
I’m pretty happy with the defaults and click “Start” to fire off the upgrade of my hosts.
Once the hosts have been upgraded we should see a confirmation that everything went successful:
Clicking on “Next” brings me to “3. Edges” where I see more or less the same options as for the hosts.
The upgrade coordinator has placed my two Edge VMs in a group. The defaults look fine to me so I’m clicking “Start” to get the Edge VM upgrade process underway.
Clicking on the group you can see the installation progress per node:
Once this is completed I click “Next” to proceed to “4. Controller Nodes”:
This is probably the quickest part in the upgrade process.
One of the architectural changes in NSX-T 2.4 is the convergence of manager, policy, and central controller services into one appliance. In other words we won’t be working with dedicated controller nodes anymore after the management plane upgrade. The existing controller nodes can simply be deleted after the upgrade.
Clicking “Next” brings me to the “5. Management Nodes”:
The “Plan” here is to allow transport node connections after a single node cluster is formed. This is a lab and I’m happy with just one cluster node at this point. I can always add more nodes later on if I want to.
Not much else to look at here so I’m starting the upgrade of the management plane by clicking the “Start” button.
I’m not planning on doing any CRUD (create, update, delete) operations on managed objects during the upgrade so I click on “Start” (again):
And the upgrade of the management plane is underway:
The node restarts as part of the upgrade so you will loose connection to the web interface at some point. Once the upgrade is completed you can log in again and will land on the new “NSX-T Overview” page:
Verification
Let’s just verify that the upgrade completed successfully by going to System > Upgrade:
Things are looking good. It seems the upgrade was indeed successful.
Another pretty important thing is verifying that the components are up and running. For this I’ll check the new dashboard under Home > Dashboards > System:
Green circles usually mean things are good (I should set up automatic backup though).
New user interface
The user interface got a pretty big overhaul in version 2.4 and it takes some time before you find your way around.
Different parts of the UI are handled by different underlying managers:
As you can see the UI is basically divided in two parts where one part is handled by Policy Manager and the other part by NSX Manager.
This has some immediate practical consequences. In version 2.3 my logical switches and logical routers were created by NSX Manager. For that reason they are found under “Advanced Networking & Security”:
Moving forward the Policy Manager/Simplified UI should be used (as much as possible) to create and manage NSX-T objects.
Simplified UI
So let’s have a very brief look at the Simplified UI.
Under “Networking” I see some new NSX-T terminology:
Logical switches are called “Segments” and logical routers are now called “Gateways”. Nothing too shocking, but good to know.
A look under “Security” shows that things are categorized in “East West Security” and “North South Security” which makes sense:
Have a closer look at the distributed firewall shows some new stuff as well.
First of all we can now choose a default connectivity strategy:
It’s set to “none” as I upgraded from version 2.3. For new deployments the default is “Blacklist” (AnyAllow as the catchall rule).
Next we see that there are now predefined categories that we can use when building a security policy model for the East-West firewall:
Conclusion
Upgrading my lab environment from version 2.3 to version 2.4 was a painless process. Good documentation and the upgrade coordinator made it a fairly straight forward process.
The NSX-T 2.4 upgrade is bigger than the minor version adjustment implies. We have some architectural changes, an almost completely new UI and some new terminology. There are many other things as well that I haven’t touched upon in this post, but will explore in more detail in upcoming posts.
All in all I would definitely say that version 2.4 is a landmark release in the history of NSX-T. With this release NSX-T also reaches feature parity with NSX-v and that should make it the SDN platform of choice moving forward.
rutgerblom.com 