NSX-T Data Center 2.5 Upgrade – Planning
NSX-T Data Center 2.5 Upgrade – Practical
Upgrades to software-based products are generally thought of just ‘next, next, next’ and done. When you’re using a software platform for running your most critical business workloads, you’re usually a bit more careful.
The Healthcare organization has taken a look at the most recent release of NSX-T Data Center, version 2.5, since putting NSX-T Data Center 2.4.1 in recently. There are several new use cases that have come up that the organization feels that 2.5 can provide them so they’re looking into what is necessary to perform an upgrade of their current NSX-T deployment.
Requirements:
- Upgrade the NSX-T deployment from 2.4.1 to 2.5.0
- Note any outages that may occur
Steps:
- Check VMware Product Interoperability Matrix
- Check VMware Product Interoperation Matrix – Upgrade Path
- Take Backup of NSX-T Manager
- Check NSX-T 2.5 Upgrade Guide Official Documentation
- Perform upgrade – Steps 4a – 4l
- Post-upgrade tasks
- Troubleshoot upgrade errors
Step 1 – Check VMware Product Interoperability Matrix
One of the first things to do is to check the VMware Product Interoperability Matrix to ensure that the version of ESXi and vCenter Server are compatible with NSX-T Data Center 2.5. The organization’s infrastructure is running ESXi 6.7 U2 and vCenter Server version 6.7 U3.
From this chart, it appears that NSX-T Data Center 2.5.0 supports the version of ESXi and vCenter Server necessary.
Step 2 – Check VMware Product Interoperability Matrix – Upgrade Path
While on the same web page, by clicking on the Upgrade Path tab, the admin can see what versions of NSX-T Data Center are supported upgrade paths.
Step 3 – Take Backup of NSX-T Manager
The admin runs a current backup of the NSX-T Manager in case a restore is necessary.
Step 4 – Check NSX-T 2.5 Upgrade Guide Official Documentation
Digging into the NSX-T 2.5 Upgrade Guide, VMware has provided a checklist of items to review for upgrading NSX-T Data Center.
Each of these tasks has sections to follow for performing the upgrade of NSX-T. The admin will add these steps to the existing steps as part of the overall plan.
Step 3a – Review the known upgrade problems and workaround documented in the NSX-T Data Center release notes.
Doing a quick search in the Release Notes for NSX-T Data Center 2.5 for the word ‘upgrade’, the admin starts looking through the matches to see any changes that might impact the upgrade process.
There are a few items that stand out:
- Messaging Port Change – There is a port change in the messaging channel from the NSX-T Manager to the Transport and Edge Nodes. This TCP port has changed from TCP 5671 to TCP 1234.
- Upgrade Order Change– When upgrading to NSX-T 2.5, the new upgrade order is Edge-component upgrade before Host component upgrade. This enhancement provides significant benefits when upgrading the cloud infrastructure by allowing optimizations to reduce the overall maintenance window.
The admin notes these impacts and has checked the other smaller upgrade issue changes and noted them in case they run into any of them.
Step 3b – Follow the system configuration requirements and prepare your infrastructure
Reviewing the NSX-T Data Center 2.5 Installation Guide, the admin takes a look at the following components:
- NSX-T Manager – no changes in the requirements from 2.4.1 to 2.5 in terms of size, disk, vCPU, or memory requirements
- ESXi Hypervisors – no changes in the requirements from 2.4.1 to 2.5 and the admin verified that the ESXi version was listed on the VMware Product Interoperability Matrix.
Step 3c – Evaluate the operational impact of the upgrade.
- Manager Upgrade – TCP port 1234 will replace TCP port 5671 from NSX-T Manager to Edge Nodes and Transport Nodes. There should be no impact as there is currently no firewall between the NSX-T Manager and the Transport or Edge Nodes.
- Edge Cluster Upgrade – One of the notable impacts looking over the official documentation for the upgrade, is the possible impact to the North-South datapath during the upgrade of the Edge Nodes and disruption between East-West datapath traffic. This possible disruption of traffic will require the admin to notify their change management and perform the upgrade during a maintenance period where a disruption has minimal impact to the business.
- Hosts Upgrade – All ESXi hosts are in a DRS-enabled cluster and hosts will be placed into maintenance mode and flushed before upgraded. No impact to the running VMs is anticipated.
Step 3d – Upgrade your supported hypervisor.
The admin confirms that they are running the appropriate version of VMware vSphere that is supported by NSX-T Data Center 2.5.
Provided from – https://kb.vmware.com/s/article/2143832
Step 3e – Verify that the NSX-T Data Center environment is in a healthy state.
To perform this step, the admin logs into the NSX-T Manager and checks the following locations for errors:
- Overview dashboard
- Fabric Nodes
- Host Transport Nodes
- Edge Transport Nodes
- Edge Clusters
Checking the Edge cluster status and the high availability for the cluster requires checking the CLI from one of the Edge nodes in the cluster. Logging in as ‘admin’ via SSH to one of the Edge Nodes, run the following command – ‘get edge-cluster status’.
Then the admin will double check from a VM:
- North-South connectivity
- East-West connectivity
A quick RDP session into one of the production servers and both connectivity needs can be tested.
Step 3f – Download the latest NSX-T Data Center upgrade bundle.
The admin visits http://my.vmware.com, logs in, and downloads the appropriate upgrade bundle for NSX-T Data Center 2.5. The file comes in a .mub file extension.
Step 3g – If you are using NSX Cloud for your public cloud workload VMs, upgrade NSX Cloud components.
The organization is not currently using any cloud-based workloads, so this step is not applicable at this time.
The steps that proceed after the last step are part of the actual upgrade process. Those steps will be continued in the next post.
This blog goes through a typical check during an upgrade process. There may be other processes that other organizations take prior to upgrading and this blog is not meant to be encompassing of every step another organization may take.