Demystifying NSX-V Redeploy


Often, when helping customers isolate and resolve problems with NSX-V or with HCX (hybrid cloud extensions), a redeploy is the best option to fix the problem. When I propose a redeploy, I can sense fear gripping the recipient of the suggestion. I understand the initial fear, because coming from a hardware networking background, I recognize it takes time for NSX-V users to grasp the advantages of software networking over physical networking. Redeploying a hardware router, switch, or firewall is not a small ordeal. You'll need to procure the new device, copy the configuration from old to new, then swing the cabling over from old to new device during a planned maintenance window. With NSX-V, this process happens in a matter of minutes, in an automated fashion, at the literal click of a button. Human error is minimized due to automating the process.

For the speed readers, here is the TL;DR of the NSX-V redeploy process:

1. Click Redeploy.
2. vCenter builds out a new VM that lives in parallel with the VM you are redeploying.
3. Once the VM is built, the services of the previously existing VM are moved to the new VM. This introduces a hiccup in service.
4. The old VM is destroyed (i.e. the compute resources are returned to the hypervisor).
5. You have a fresh VM, possibly resolving some unexplained problem in the previous VM.

For a more in-depth look at what redeploy does, keep reading.

To understand the difference between virtual networking and physical networking, lets define virtualization.
" Virtualization is the faithful reproduction in software of an IT resource delivering to its consumers benefits that were unavailable in its physical form."
 -VMware NetworkVirtualization Fundamentals Guide (page 3)

In our case with NSX-V, we redeploy Edges. Edges perform services such as routing, load balancing,  firewalling for north/south traffic, and network address translation (NAT). Edges have two roles in NSX that have never existed in physical networking. First, they are the on-ramp for ip traffic between physical and virtual networking devices. Second, in the context of a distributed logical router (DLR), they serve as the control plane of a distributed router (Sometimes called logical control VM). Hopefully that provides some clarification about what edges do. In VMware documentation, they often look like this. Notice the "P" "V", Physical to Virtual I assume:


Edges reproduce the router or firewall hardware components as a virtual machine. The guest operating system of the VM is NSX's proprietary network operating system. When clicking redeploy, NSX will generate a new virtual machine using the edge form factor, run both new and old edges in parallel, move services over from the old to the new virtual machine, and finish by releasing the resources of the old virtual machine back to the hypervisor. The whole process takes about 3 minutes. You will see some packet loss if you perform a redeploy on a production edge. See the screenshots below:


Inventory of Edges in NSX User Interface.

This is the same edge, but seen from the vCenter (VC) inventory.


Here is where to find the redeploy option, though it can be found in other places in the interface.


Redeploy warning message.


Redeploy process begins!


We can see in the VC inventory that the new VM is being deployed.



See the new edges in the VC inventory.


This is the VC recent tasks list of a redeployed edge. 
You can see the redeploy process through VC's eyes.





Comments

Post a Comment

Popular posts from this blog

VXLAN versus GENEVE (NSX-V vs. NSX-T)

Image
  August 14th, 2021 With the ramp-up of NSX-T overlay networks and transition away from NSX-V overlay networks, it's a good time to look at one of the fundamental differences between them. NSX-V uses VXLAN as its encapsulation protocol while NSX-T uses the more recent GENEVE encapsulation protocol. Each require the physical networking devices have their MTU adjusted to 1600 bytes or greater. We'll take a detailed look at why that is. First, the basics: VXLAN is: short for Virtual eXtensible Local Area Network Is defined in rfc 7348 - https://datatracker.ietf.org/doc/html/rfc7348 Uses UDP port 4789 8 byte header GENEVE is: short for Generic Network Virtualization Encapsulation Is defined in rfc 8926 -  https://datatracker.ietf.org/doc/html/rfc8926 Uses UDP port 6081 16 byte header From the prospective of the physical network, an overlay network is essentially an application. NSX-T is an application using well known UDP port 6081. Switching perspectives to the overlay's...
Read more

"Twice NAT" with NSX-T T0 Gateway

Image
  Network address translation, or more commonly NAT, is most often used to do source NAT or destination NAT. In rare instances, SNAT or DNAT isn't enough to get ip packets to their destination. Enter twice nat. While twice NAT isn't a function I've needed often, it was a function drilled into me while studying for various Cisco exams. I used to watch Christian Matei explain it over at INE and it really helped me to understand what twice NAT is and how to configure it on Cisco devices. Previous to my time working with NSX-T, I'd only utilized twice NAT once. A few years back, a customer wanted to build and IPsec tunnel from the organization HQ to a branch office. The private ip space used by HQ and the branch used overlapping ip space. We used twice NAT to NAT the source and destination ip address in a single NAT rule ( similar to this guy ) before shoving it all into an IPsec tunnel. Previous to working with NSX, circumstances requiring twice NAT were uncommon.  While w...
Read more

Packet Capture Network Traffic Inside ESXi Hypervisor

Image
The three components of computer infrastructure are considered compute, storage, and networking. When applications don't work properly, its often the case that networking is the first component to receive blame for failed application performance. In the case of virtualized workloads (i.e. applications running on virtual machines), we are fortunate to have a powerful troubleshooting tool which allows us to packet capture network traffic in an ESXi hypervisor. For this blog, I'm going to use an Hands On Lab (HOL) from the VMware website to demonstrate the process of doing a quick live packet capture. The output of the packet capture will be sent to the shell of the hypervisor. There are ways to sent the network traffic to a file so it can be extracted and analyzed by a packet analyzer tool, but that will be for another post. First, lets start with heading over to the HOL website:  https://labs.hol.vmware.com/ For this lab, I'm going to type NSX in the search bar to find...
Read more