NSX in Real Life
NSX has been released for years, it is commonly known as a Network Virtualization Solution. Of course, more people thinks it as an “Enhanced” vCloud Networking and Security (VCNS) Solution previously VMware provided through vShield Stacks. But actually it aims higher, as I have been using and deploying VCNS and NSX, from my view point they differ in a way that,
- vCloud Networking and Security (VCNS) solution is more an VNF (Virtual Network Function) Solution
- NSX instead targets to establish a NFVI (Network Function Virtualization Infrastructure)
So here comes some terms including VNF, NFV, NFVI and you may also hear about SDN (Software Defined Network) and NV (Network Virtualization). While it’s honestly very easy to mix up in between the terms. I wanna take chance to explain among the terms. So all these terms are actually not defined by Vendors or Sticked to any product actually. These instead are defined by Standard Frameworks. And they should be understand with the following correlation
- Difference between SDN (L2-L3 network) and NFV (L3-L7 Network Functions) in a NV design
- NFVI is a platform setup for running VNF utilities to provide NFV functions
And following diagrams give you a graphical visualisation of the above two statements.
SDN and NFV Relationship
NFV, VNF and NFVI Relationship
Remember again that the above definition is NOT vendor specific, as if any solution is sticking and adhering to the framework and Definition mentioned above, those can contribute to this SDN + NFV + VNF + NFVI + NV ecosystem. And VMware vSphere + VSAN + NSX is one of the solution targets the build the NFVI Platform which allows other 3rd party solution provider to run their VNF solutions on top of it. Yes, you may discover that the so called VNF solutions should be x86 VMs if you are running your NFVI in a x86 Platform (which is the most making sense CPU architecture platform currently). The idea of running VNF solutions on x86 definitely because one wanna offload the high cost of ASICs network equipments.
The Red Highlighted NFVI platform is what VMware Solutions can provide.
After talking a bit on the whole Network Virtualization Framework, I would like to come back to the NSX topic particularly. As Mentioned in the previous vSAN Blog, I am really pleased to see some actual deployment of NSX in my region and honestly I think it’s a very successful usage of NSX. Just like how VSAN targets, NSX is definitely NOT design to complex your environment. And how I define the “successful usage”, I would be more biased in the solution fit into the requirements from my customer who actually want to:
- Gain the ease in Network Function Provisioning to fulfil Application User
- Creating Identical network environments for each Application Development Stages
- Networks should be running across two Physical Datacenter
For their new project which has a really tight time line and resources. So, to be coherent to the topic of this blog “NSX in Real Life”, let me illustrate the NSX Journey of this customer and how NSX is turn out benefiting them in a Real Life Daily Use.
Design And Deployment
So the first and foremost thing we have to do, definitely would be having a proper design of the NSX. We already mentioned that “Multiple Overlapping IP Networks Environments Across Two Datacenter” have to be built for application deployment stages. Of course, there are actually many ways e.g. OTV, VPLS…etc. for doing NOT just NSX, but why NSX? This is because it gives a very low barrier in Physical Network Requirements and more important the Ease in Expanding and Reconfiguration of the Networks.
The Diagram Above is a high level Design I worked out for my customer. You could spot some more Requirements And Constraints that I didn’t detail before, including:
- Requirement of VDI deployment
- Constraint of using Metro Storage Across two Datacenter
- Two types of Hosts, one for running SQL Servers and another for others
In Order to implement a solution to fulfil all of the above, three clusters are used. Where there are one (1) management cluster and two (2) resource clusters, this is allows a great separation of workloads to allow management machines securely isolated from the Desktop Workloads and User Workloads running in the resource clusters. You should be aware that this is actually a best practice VMware recommends for VDI and Cloud Deployment.
Due to the deployment size, we don’t have the luxuriance to have a separate VDI environment and thus we collocate the VDI workloads into the “Normal” workloads in the Resource Cluster 2 but secure the resource with a dedicated Resource Pool. As all the vSphere Clusters are deployed on top of the Metro Storage, so all the workloads are protected cross site.
After handling all the Compute Consideration in the Design, then we should think about how the networks to be designed in the environment. As mentioned, the User Workloads Running in the Resource Clusters have to be run in overlapping Networks. And definitely we should not segregate the networks between the SQL Server running Resource Cluster 1 and Normal Server running Resource Cluster 2. This is why we set up a VDS (vds01) for NSX networks across the Resource Clusters while the DMZ Networks are just running in a separate VDS (vds02) in Resource Cluster 2.
You can see how traditional networks and NSX networks are being used together here, it is as always not an “Either Or” selection between using SDN or Traditional Network. But it actually can be used together, while here, the traditional network help extending the Management, vMotion and DMZ Networks, the SDN help building overlapping IP network environments as the following diagram
We still need non-overlapping network for the VDI Jumpbox Hosts which let user accessing different environments and such Application Stages. But this makes deployment of Application Comparatively Easy, since we don’t have to change anything (IP or Hostname) when we migrate codes from one environment to another.
After building the overlapping IP Network Environments, then my customer deployed honestly really a lot of VNF (NSX Edge) over the NSX Platform. It is very nice to see that they can handle Application User Requirements very quickly now, for example, a user may requires:
- A Network Load Balancer for their Servers
- VPN Connection from Datacenter to Other environment
- L2 Connection from Datacenter to a Remote Office/ Branch Office
Following is a summary of the NSX Usage in my Customer Environment. Again I want to state that their environment is not very big one (only 12 ESXi hosts), but they comprehensively leveraged the NSX function in their environment to fulfil most of the network requirements from their application users.
Finally, many people would worry if Operation and Monitoring would be difficult after using NSX. Well to be fare, if you are using a traditional monitoring way to monitor a SDN network, may be this could generate a lot of effort. But if you are using a suitable way to monitor a SDN solution, you could see the magic and ease in monitoring. This is another life example when my customer picked up the vRealize Operation Manager and vRealize LogInsight to Monitor the environment, they can trouble shoot stuffs promptly now and save a lot of time in log diagnosis.
Actually, VMware does have another new product named vRealize Network Insight which provides even better and more comprehensive visibility of both physical and virtual network environment. But what I want to state again, there are no best tool for everything but instead do use the most suitable tool upon your requirements.