NSX Uprade

[rajeevsrikant]

During NSX upgrade below is the sequence that will be followed.

1. NSX Manager - No downtime during upgrade

2. NSX Controller Cluster - No downtime during upgrade

3. NSX Host clusters - No downtime during upgrade

4. DLR - Downtime for the VM communications

5. Edge Routers - Downtime for the VM communications

Would like to know how much will be the down time required when DLR is getting upgraded & also for the Edge Routers.

How much down time should i consider for these components upgrade.

[Kamuthiking]

Hi

The DLR and Edge wont take more then 15 to 20 min  .

and for nsx manager and controllers 30 to 45 min will be fine .

[Techstarts]

I suggest you clarify to your management what downtime actually means?

Below I'm assuming the downtime is for end user/vm traffic/workload

1. NSX Manager - No downtime during upgrade

NSX manager no downtime from user/workload perspective but not available for any new provisioning/change/addition to NSX Objects.

2. NSX Controller Cluster - No downtime during upgrade

Again you right but DRS should be disabled in the outage window as Upgrade guide states VMs shouldn't be move. NB: If you disable DRS, Resource Pools will be deleted.

3. NSX Host clusters - No downtime during upgrade

It is correct. Now here you need to enable DRS again.

4. DLR - Downtime for the VM communications

5. Edge Routers - Downtime for the VM communications

DLR no downtime unless you have L2VPN configured (I might be wrong).

NSX Edge: North/South is impacted. This is the only part where users will face downtime.

Would like to know how much will be the down time required when DLR is getting upgraded & also for the Edge Routers.

Recommend approach is to use single outage window. How much that outage window should be? It is has different parameters which will influence the downtime.

But If I were you, I will have 1 hour downtime per host which will cover all 5 elements of upgrade. Also, you need do is a pre and post-upgrade check and some additional hours in case things go wrong. As discussed in this forum, upgrade is straight forward.

[Sreec]

Few points from my experience

1. NSX Manager - No downtime during upgrade

This is not fully true. If you have IDFW or any third party integration directly with NSX manager - it will not work,so there is a downtime

2. NSX Controller Cluster - No downtime during upgrade

Try to perform VM movement prior to Controller upgrade and don't do any routing changes ,both in physical/virtual side if there is a communication path for those routes to Virtual Networks. Control Plane is impacted since Upgrade process in one at a time(Cluster majority gone)

3. NSX Host clusters - No downtime during upgrade

If your Management hosts are  part of NSX cluster- you need to plan Controller Movement during this phase in addition to the above plan . So after this phase is the best time to enable DRS rules rather than doing after step-2

4. DLR - Downtime for the VM communications

5. Edge Routers - Downtime for the VM communications

Time factor for upgrade depends upon on environment,features and how you have deployed the instance for workloads .  For eg : If you are having 5-10 edges in HA mode ,edge VM upgrade will take more time comparing with ECMP mode standalone edges. Also if you have multiple exit path via unique edge for Egress traffic,downtime will be less if you are doing edge upgrade one at a time comparing with Edge in HA mode.

Note: Take necessary backup/snapshot for NSX manager/firewall rules/Controllers

[benjamin000]

Sreec​ is 100% correct in his advice as I have personally upgraded from NSX 6.2.3 to 6.3.1 and the upgrade process invoked some downtime however this way mainly due to the 3rd party IDS from what I saw however  in my experience the downtime was minimal and as on this cluster there were only 400 VMs running and not one customer noticed. If you follow the advice of Sreec your upgrade should succeed without much headache.

[rajeevsrikant]

Thanks Sreec​

1. NSX Manager - No downtime during upgrade

This is not fully true. If you have IDFW or any third party integration directly with NSX manager - it will not work,so there is a downtime

[Rajeev] - I dont have IDFW (Identity firewall) or any 3rd party integration. So assuming no downtime.

2. NSX Controller Cluster - No downtime during upgrade

Try to perform VM movement prior to Controller upgrade and don't do any routing changes ,both in physical/virtual side if there is a communication path for those routes to Virtual Networks. Control Plane is impacted since Upgrade process in one at a time(Cluster majority gone)

[Rajeev] - There will be no routing changes during that time. VM movement will not be feasible during NSX controller cluster upgrade. Will it impact during the upgrade. My understanding is that even when all the controllers are down, the data plane communication will not have any impact. In case of any changes like vmotion or any other changes will only have the impact.

Correct me if i am wrong.

3. NSX Host clusters - No downtime during upgrade

If your Management hosts are  part of NSX cluster- you need to plan Controller Movement during this phase in addition to the above plan . So after this phase is the best time to enable DRS rules rather than doing after step-2

[Rajeev] - In the management cluster, I have 3 hosts where the 3 controllers reside. If DRS is enabled & if the Anti Affinity rule is disabled, controllers will be vMotion by itself because of DRS & there should not be any impact.

Correct me if i am wrong.

4. DLR - Downtime for the VM communications

5. Edge Routers - Downtime for the VM communications

Time factor for upgrade depends upon on environment,features and how you have deployed the instance for workloads .  For eg : If you are having 5-10 edges in HA mode ,edge VM upgrade will take more time comparing with ECMP mode standalone edges. Also if you have multiple exit path via unique edge for Egress traffic,downtime will be less if you are doing edge upgrade one at a time comparing with Edge in HA mode.

[Rajeev] - I have one DLR control VM in active standby & 1 NSX Edge in active standby with ECMP enabled.

In this case how much is the downtime i should expect.

[Sreec]

2. NSX Controller Cluster - No downtime during upgrade

Try to perform VM movement prior to Controller upgrade and don't do any routing changes ,both in physical/virtual side if there is a communication path for those routes to Virtual Networks. Control Plane is impacted since Upgrade process in one at a time(Cluster majority gone)

[Rajeev] - There will be no routing changes during that time. VM movement will not be feasible during NSX controller cluster upgrade. Will it impact during the upgrade. My understanding is that even when all the controllers are down, the data plane communication will not have any impact. In case of any changes like vmotion or any other changes will only have the impact.

Correct me if i am wrong.

True - Limit the VM movement and routing change

3. NSX Host clusters - No downtime during upgrade

If your Management hosts are  part of NSX cluster- you need to plan Controller Movement during this phase in addition to the above plan . So after this phase is the best time to enable DRS rules rather than doing after step-2

[Rajeev] - In the management cluster, I have 3 hosts where the 3 controllers reside. If DRS is enabled & if the Anti Affinity rule is disabled, controllers will be vMotion by itself because of DRS & there should not be any impact.

Correct me if i am wrong.

True-As long they are residing on a shared storage and you have enough compute resource on next available host

4. DLR - Downtime for the VM communications

5. Edge Routers - Downtime for the VM communications

Time factor for upgrade depends upon on environment,features and how you have deployed the instance for workloads .  For eg : If you are having 5-10 edges in HA mode ,edge VM upgrade will take more time comparing with ECMP mode standalone edges. Also if you have multiple exit path via unique edge for Egress traffic,downtime will be less if you are doing edge upgrade one at a time comparing with Edge in HA mode.

[Rajeev] - I have one DLR control VM in active standby & 1 NSX Edge in active standby with ECMP enabled.

In this case how much is the downtime i should expect.

In this case i would do Control VM and 1 NSX edge at a time upgrade ,followed by other ECMP edges . You can consider minimum 5-10 minutes for these individual instances to get upgraded . Since you have HA it will take more time. So better disable HA and after upgrade you can enable HA.

[rajeevsrikant]

Sreec​

Thanks.

Time factor for upgrade depends upon on environment,features and how you have deployed the instance for workloads .  For eg : If you are having 5-10 edges in HA mode ,edge VM upgrade will take more time comparing with ECMP mode standalone edges. Also if you have multiple exit path via unique edge for Egress traffic,downtime will be less if you are doing edge upgrade one at a time comparing with Edge in HA mode.

[Rajeev] - I have one DLR control VM in active standby & 1 NSX Edge in active standby with ECMP enabled.

In this case how much is the downtime i should expect.

In this case i would do Control VM and 1 NSX edge at a time upgrade ,followed by other ECMP edges . You can consider minimum 5-10 minutes for these individual instances to get upgraded . Since you have HA it will take more time. So better disable HA and after upgrade you can enable HA.

[Rajeev] - Got it. I will upgrade the Control VM first & then the NSX Edge.

I have only 1 NSX Edge Gateway in HA with ECMP enabled. Will try if I can disable the HA before the upgrade & enable it after the upgrade.

[Techstarts]

1. NSX Manager - No downtime during upgrade

This is not fully true. If you have IDFW or any third party integration directly with NSX manager - it will not work,so there is a downtime

Sreec,

would please help me understand what will not work? Referring to your earlier post here there is low impact on unavailability NSX manager.  Below you are referring there is a downtime? Is this downtime for VM/ESXi/AV/SVM?

[Sreec]

As you know for IDFW - NSX manager will be connected with AD for user/group sync - This functionality will be impacted during upgrade process(For eg : if VDI provisions are happening and IDFW rules are suppose to work based on new user logins ,it will not work since the nsx manager is going through upgrade process) however there is no impact for data traffic.