1. Gain better understanding of NSX (came from vCNS/vShield and Nicira) and dive more into details of VMware networking
4. What is DevOps all about?
An Introduction to Network Virtualization” (NET5516)
For NSX, I attended an excellent session titled “An Introduction to Network Virtualization” (NET5516) with Eric Lopez and Thomas Kraus (@tkrausjr)
from VMware, both formerly of Nicira. Following are some notes I took down from their slides.
Cloud Consumers want the following, and these are driving network virtualization:
- Ability to deploy apps at scale and with little preplanning (provisioning speed and efficiency)
- Mobility to move workloads between different geographies and providers (investment protection and choice)
- Flexibility to create more diverse architectures in a self service manner (rich L3-L7 network services)
NSX System Architecture consists of 3 planes familiar to most network engineers: Management, Control, and Data Planes
- Management Plane = NSX Manager – programmatic web services api to define logical networks
- Control Plane = Control Cluster
- Clustered App runs on x86 servers, controls and manages 1000s of edge switching devices, does NOT sit in data plane
- Data Plane = OVS/NVS
- Open vSwitch (OVS) vmWare-led open source project
- NSX vSwitch (NVS) is a software vSwitch in ESXi kernel
- Switch software designed for remote control and tunneling installed in hypervisors, NSX gateways or hardware VTEP devices
- Can work with vSphere, KVM, XenServer
- vSwitch in each hypervisor controlled through API by Controller Cluster
- NSX manager uses this API, so does cloudstack, openstack, CMS/CMP, VMware
- To get between physical and virtual networks, Open vSwitch NSX Gateway or HW Partner VTEP Device is used
- NSX Controller Cluster establishes an overlay network
- Multiple tunneling protocols including STT, GRE, VXLAN
- Packets encapsulate with Logical Switch info
- The tunneling protocol is NOT network virtualization, rather, it is a component of it
NSX use cases include:
- Automated network provisioning
- Inter rack or inter DC connectivity
- P2V and V2V migration
- Burst or migrate enterprise to cloud
The Whiteboard snapshot above was drawn to demonstrate the basic components of NSX and how VMs communicate using the virtual overlay netowrk
The example uses ESXi on left and KVM hypervisor on right (HV1 and HV2)
- Each connected to IP fabric
- 3 controllers drawn in the middle
- Intelligent Edge NVS installed on ESXi and OVS installed on KVM
- Controllers talk with ESXi on vmkernel management interface, something similar with KVM
- Addresses assigned that used for encapsulation and direct communication between hypervisors: 172.16.20.11/24 on left, 172.16.30.11/24 on right
- Customer A is green, they have a VM on each hypervisor (192.168.1.11 on left, 192.168.1.12 on right)
- Customer B is red, they have VM on each hypervisor with SAME IP ADDRESSES – logically separated similar to VRFs (I didn’t get a picture of this–sorry)
- Controller cluster controls virtual ports, so they can programmatically control QoS, Security, Distributed Routing
NSX Hands-On-Lab HOL-SDC-1303, continued
I was able to continue, but not yet finish, the NSX lab I started yesterday in the VMworld Hands-on-Labs (HOL-SDC-1303). This portion of the lab went into more technical detail surrounding the following diagram:
The network drawing depicts a 3-tier web application which includes web, application, and database servers. Each server tier is on a different subnet, and thus connected to a different port group. The NSX Edge shown acts as the external layer 3 (L3) gateway for each subnet shown in blue, green, and orange. At the beginning of this lab section we verify the web app is working properly by connecting to the website and verifying data is served from the back 2 tiers (application and database servers). Then we disconnect the NSX Edge from the App and DB subnets/port groups and validate that the website is broken (can get to web servers but get an HTTP error saying service not working). Next, we connect to the vCenter web client and verify that each cluster is configured and loaded with the virtual router and virtual firewall components of the NSX suite, and we configure the router and firewall to connect to the App and DB tiers and allow the appropriate traffic. Finally we verify that service is restored on the website. Part of the configuration includes OSPF connectivity between the virtual distributed router on the ESXi hosts and OSFP running in the NSX Edge routing engine. Looking at the snapshot below of the NSX Edge you can see the similarities with Cisco IOS. For instance, “show ip ospf neighbor” and “show ip route” commands are identical.
I hope to complete this lab tomorrow.
What is DevOps?
While spending some time in the Solutions Exchange I discussed what DevOps means with someone involved in that space at the Cisco booth. As I understand it, companies usually first get virtualized, then they implement a service catalog, then they implement a “cloud” such that it’s self-service enabled. DevOps refers to IT working closely with developers such that they create the development environment as well as production environment that the developers will deploy to. If you know more about DevOps and I’ve misunderstood, please keep me honest.
VMware IT Business Management Suite
Finally, in the VMware booth I learned about the VMware IT Business Management Suite. It enables companies to understand costs and, as I understand it, implement chargeback to IT’s internal customers. The demo looked pretty impressive, and I think there is a lot of value in such a tool. It can pull General Ledger data directly from standard systems such as Oracle and SAP and presents data in a well-thought-out manner. It’s something to share with the CIO and/or accounting folks back home.