Objective 4.3: Upgrade Existing vCNS/NSX Implementation
Based on a given upgrade scenario, identify requisite steps and components for upgrading to NSX 6.x
Before you install or upgrade NSX, consider your network configuration and resources. You can install one NSX Manager per vCenter Server, one instance of Guest Introspection and Data Security per ESXi host, and multiple NSX Edge instances per datacenter.
Caution: Downgrades are not supported
- Verify that vCloud Networking and Security is version 5.5. If not, see the vShield Installation and Upgrade Guide version 5.5 for upgrade instructions
- Verify that all required ports are open
- Verify that you can retrieve uplink port name information for vSphere Distributed Switches
- If any vShield Endpoint partner services are deployed, verify compatibility before upgrading
- If you have Data Security in your environment, uninstall it before upgrading vShield Manager.
- If you are using Cisco Nexus 1000V as an external switch provider, you must migrate those networks to vSphere Distributed Switch before upgrading to NSX
- Verify that you have a current backup of the vShield Manager, vCenter and other vCloud Networking and Security components
- Create a Tech Support Bundle.
- Ensure that forward and reverse domain name resolution is working, using the nslookup command
- If VUM is in use in the environment, ensure that the bypassVumEnabled flag is set to true in vCenter
- Download and stage the upgrade bundle, validate with md5sum
- As a best practice, quiesce all operations in the environment until all sections of the upgrade are complete
- Do not power down or delete any vCloud Networking and Security components or appliances before instructed to do so
- Evaluate License Needs Before Upgrading vCloud Networking and Security to NSX:
- Starting in NSX 6.2.3, the default license upon install will be NSX for vShield Endpoint. This license enables use of NSX for deploying and managing vShield Endpoint for anti-virus offload capability only, and has hard enforcement to restrict usage of VXLAN, firewall, and Edge services, by blocking host preparation and creation of NSX Edges
- If you need other NSX features, including logical switches, logical routers, Distributed Firewall, or NSX Edge, you must either purchase an NSX license to use these features, or request an evaluation license for short-term evaluation of the features
To upgrade vCloud Networking and Security to NSX 6.2.x, you must upgrade the NSX components in the following order:
- vShield Manager
- Host clusters and virtual wires
- vShield App
- vShield Edge
- vShield Endpoint
If you are using vCenter embedded SSO and you are upgrading vCenter 5.5 to vCenter 6.0, vCenter might lose connectivity with vShield Manager
Upgrade vCNS 5.5 to NSX 6.x
To upgrade to NSX 6.2.x, you must upgrade the vCloud Networking and Security components in this order:
- Upgrade vShield Manager to NSX Manager
- Deploy NSX Controller cluster – optional, required for logical (distributed) routers and changing control plane mode to hybrid or unicast
- Update host clusters
- Update Transport Zone – optional, if NSX Controller cluster is deployed, can change control plane mode to hybrid or unicast
- Upgrade vShield App to NSX Distributed Firewall
- Upgrade vShield Edge to NSX Edge
- Upgrade vShield Endpoint to NSX Guest Introspection
Upgrade vCNS Virtual Wires to NSX Logical Switches
Upgrade to NSX Components
- Upgrade to NSX Edge
- Upgrade vShield Endpoint from 5.5 to 6.x
- Upgrade to NSX Data Security
Upgrade NSX Manager from 6.0 to 6.x
NSX components must be upgraded in the following order:
- NSX Manager appliance
- NSX Controller cluster
- Host clusters
- NSX Edge
- Guest Introspection
Update vSphere Clusters after NSX upgrade
After upgrading NSX Manager and NSX Controllers to version 6.2.x, you can update the appropriate clusters in your environment. During this process, each host in the cluster receives a software update and is then rebooted.
Upgrading the host clusters upgrades the NSX VIBs, esx-vsip and esx-vxlan
- Make sure the fully qualified domain names (FQDNs) of all of your hosts can be resolved.
- Log into one of the hosts in the cluster and run the esxcli software vib list command. Note the current version of the following VIBs:
- Upgrade NSX Manager and the NSX Controller cluster.
- Make sure that you understand the operational impact of a host cluster upgrade while the upgrade is in progress
- If DRS is disabled, power off or vMotion the VMs manually before beginning the upgrade.
- If DRS is enabled, the running VMs are moved automatically during the host cluster upgrade. Before beginning the upgrade, make sure that DRS can work in your environment.
- Make sure that DRS is enabled on the host clusters.
- Make sure that vMotion functions correctly.
- Check the host connection state with vCenter.
- Check that you have a minimum three ESXi hosts in each host cluster.
- In a small cluster with only two or three hosts, if you have created anti-affinity rules stating that certain VMs must reside on separate hosts, these rules might prevent DRS from moving the VMs during the upgrade.
- In the vSphere Web Client, navigate to Home > Networking & Security > Installation, select the Host Preparation tab
- For each cluster that you want to upgrade, click Upgrade available
- The cluster Installation Status displays Not Ready. Click Not Ready to display more information. Click Resolve all to attempt to complete the VIB installation
- If the Resolve action fails when DRS is enabled, the hosts might require manual intervention to enter maintenance mode (for example, due to HA requirements or DRS rules), the upgrade process stops and the cluster Installation Status displays Not Ready again
To confirm the host update, log into one of the hosts in the cluster and run the esxcli software vib list | grep esx command. Make sure that the following VIBs have been updated to the expected version:
Understand the impact of availability to the aspects of NSX during an upgrade
Objective 4.4: Expand Transport Zone to Include New Cluster(s)
Explain the function of a Transport Zone
A transport zone controls to which hosts a logical switch can reach. It can span one or more vSphere clusters. Transport zones dictate which clusters and, therefore, which VMs can participate in the use of a particular network
NSX does not allow connection of VMs that are in different transport zones. The span of a logical switch is limited to a transport zone, so virtual machines in different transport zones cannot be on the same Layer 2 network. A distributed logical router cannot connect to logical switches that are in different transport zones. After you connect the first logical switch, the selection of further logical switches is limited to those that are in the same transport zone. Similarly, an edge services gateway (ESG) has access to logical switches from only one transport zone.
The following guidelines are meant to help you design your transport zones:
- If a cluster requires Layer 3 connectivity, the cluster must be in a transport zone that also contains an edge cluster, meaning a cluster that has Layer 3 edge devices (distributed logical routers and edge services gateways).
- Suppose you have two clusters, one for web services and another for application services. To have VXLAN connectivity between the VMs in these two clusters, both of the clusters must be included in the transport zone.
- Keep in mind that all logical switches included in the transport zone will be available and visible to all VMs within the clusters that are included in the transport zone. If a cluster includes secured environments, you might not want to make it available to VMs in other clusters. Instead, you can place your secure cluster in a more isolated transport zone.
- The span of the vSphere distributed switch (VDS or DVS) should match the transport zone span. When creating transport zones in multi-cluster VDS configurations, make sure all clusters in the selected VDS are included in the transport zone. This is to ensure that the DLR is available on all clusters where VDS dvPortgroups are available.
If you do not follow this best practice, keep in mind that if a VDS spans more than one host cluster and the transport zone includes only one (or a subset) of these clusters, any logical switch included within this transport zone can access VMs within all clusters spanned by the VDS. In other words, the transport zone will not be able to constrain the logical switch span to a subset of the clusters. If this logical switch is later connected to a DLR, you must ensure that the router instances are created only in the cluster included in the transport zone to avoid any Layer 3 issues
Understand proper addition of a Transport Zone
- In vCenter, navigate to Home > Networking & Security > Installation and select the Logical Network Preparation tab.
- Click Transport Zones and click the New Transport Zone
- To add a universal transport zone, select Mark this object for universal synchronization
- Select the replication mode:
- Unicast –> requires PIM/IGMP in the physical network
- Multicast –> is handled by NSX controller
- Hybrid –> requires IGMP snooping in the first hope and querier in each VTEP subnet
- Select the clusters to add to the transport zone
Understand necessity to expand or contract a Transport Zone
You can add clusters to a transport zone. All existing transport zones become available on the newly added clusters.
- In Transport Zones, click a transport zone
- Click the Add Cluster
- Select the clusters you want to add to the transport zone and click OK
You can remove clusters from a transport zone. The size of existing transport zones is reduced to accommodate the contracted scope
- In Transport Zones, double-click a transport zone
- In Transport Zones Details, click the Remove Clusters
- Select the clusters that you want to remove and click OK
Edit a Transport Zone
You can view the logical networks in a selected transport zone, the clusters in, and the control plane mode for that transport zone.
- In Transport Zones, double-click a transport zone.
- Click the Edit Settings icon in the Transport Zone Details section to edit the name, description, or control plane mode of the transport zone.
- If you change the transport zone control plane mode, select Migrate existing Logical Switches to the new control plane mode to change the control plane more for existing logical switches linked to this transport zone. If you do not select this check box, only the logical switches linked to this transport zone after the edit is done will have the new control plane mode.
- Click OK
Understand appropriate use of Control Plane mode modification of a Transport zone