VMware Networking Community
NSX_Ninja_52
Contributor
Contributor
Jump to solution

NSX Upgrade for Muti-Site Environment

If you have a NSX upgrade for an multi-site environment, you should upgrade the primary NSX Manager and it's components first right? I scanned the NSX Upgrade doc and I did not see this. I could of missed it but can any help? Also give me some tips and tricks or gotchas while doing these upgrades?

Thanks

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
chuckbell
VMware Employee
VMware Employee
Jump to solution

Upgrade Cross-vCenter NSX

NSX components must be upgraded in the following order:

1 Primary NSX Manager appliance

2 All secondary NSX Manager appliances

3 NSX Controller cluster

4 Host clusters

5 NSX Edge

6 Guest Introspection

Upgrade to NSX 6.3.x with Cross-vCenter NSX

Upgrading any of the NSX components should be done in a maintenance window as some data plane outages are expected. Commentary on specific components can be found below:

NSX Manager: Upgrading NSX Manager should not cause any type of data plane outage, but will render the NSX environment unmanageable for a period of time while the upgrade progresses. The NSX Web Client plugin, as well as the Web UI will not be functional during this time, nor will GET or POST API calls function. Expected management outage is approximately 15-20 minutes.

NSX Controllers: Upgrading the control cluster should not cause a disruption to any existing data flows. None the less, we recommend upgrading controllers only in designated outage/change windows.

ESXi Host NSX VIBs: So long as DRS can distribute virtual machines via vMotion, there should be no data plane impact as a result of NSX VIB upgrades in stateful or auto-deploy clusters. Hosts are automatically evacuated, upgraded and rebooted. If upgrading from 6.3.0 to 6.3.1, no reboot is required but hosts will still need to evacuate and be placed into maintenance mode. There is no expected data plane outage, however resource utilization during the upgrade may be unbalanced for a period of time.

ESGs: Edge Service Gateway upgrades are done by deploying a new VM in parallel to the existing one and then cutting over services. GARP is used to notify the physical switch of the MAC change. During this switchover, it is expected to have a brief data plane disruption while the cutover happens and routing convergence occurs. ECMP edges should not be done simultaneously to minimize this effect. When upgrading ECMP edges, we expect a data plane disruption for a percentage of the data flows (for example, 25% when upgrading one of four ECMP ESGs) while convergence happens. Expected data plane outage is approximately 10 seconds per ESG. For ECMP ESGs only a percentage of the flows for approximately 10 seconds.

DLR: The DLR upgrade has a similar impact to the ESGs as described above. Some of designs implement floating static routes to reduce the downtime during DLR upgrades and control VM outages. With floating static routes, the outage should be very brief (about 10 seconds or so). In environments without floating static routes, the outage during DLR upgrade could be as long as 60 seconds.

View solution in original post

0 Kudos
1 Reply
chuckbell
VMware Employee
VMware Employee
Jump to solution

Upgrade Cross-vCenter NSX

NSX components must be upgraded in the following order:

1 Primary NSX Manager appliance

2 All secondary NSX Manager appliances

3 NSX Controller cluster

4 Host clusters

5 NSX Edge

6 Guest Introspection

Upgrade to NSX 6.3.x with Cross-vCenter NSX

Upgrading any of the NSX components should be done in a maintenance window as some data plane outages are expected. Commentary on specific components can be found below:

NSX Manager: Upgrading NSX Manager should not cause any type of data plane outage, but will render the NSX environment unmanageable for a period of time while the upgrade progresses. The NSX Web Client plugin, as well as the Web UI will not be functional during this time, nor will GET or POST API calls function. Expected management outage is approximately 15-20 minutes.

NSX Controllers: Upgrading the control cluster should not cause a disruption to any existing data flows. None the less, we recommend upgrading controllers only in designated outage/change windows.

ESXi Host NSX VIBs: So long as DRS can distribute virtual machines via vMotion, there should be no data plane impact as a result of NSX VIB upgrades in stateful or auto-deploy clusters. Hosts are automatically evacuated, upgraded and rebooted. If upgrading from 6.3.0 to 6.3.1, no reboot is required but hosts will still need to evacuate and be placed into maintenance mode. There is no expected data plane outage, however resource utilization during the upgrade may be unbalanced for a period of time.

ESGs: Edge Service Gateway upgrades are done by deploying a new VM in parallel to the existing one and then cutting over services. GARP is used to notify the physical switch of the MAC change. During this switchover, it is expected to have a brief data plane disruption while the cutover happens and routing convergence occurs. ECMP edges should not be done simultaneously to minimize this effect. When upgrading ECMP edges, we expect a data plane disruption for a percentage of the data flows (for example, 25% when upgrading one of four ECMP ESGs) while convergence happens. Expected data plane outage is approximately 10 seconds per ESG. For ECMP ESGs only a percentage of the flows for approximately 10 seconds.

DLR: The DLR upgrade has a similar impact to the ESGs as described above. Some of designs implement floating static routes to reduce the downtime during DLR upgrades and control VM outages. With floating static routes, the outage should be very brief (about 10 seconds or so). In environments without floating static routes, the outage during DLR upgrade could be as long as 60 seconds.

0 Kudos