Good afternoon my name is John Whitman, I'm a Staff System Engineer at the Network and Security Business Unit here at VMware. Today I'm going to be talking about NSX architecture and the components that are involved. So, first we're going to talk about the product features and what is an NSX today. Network planes, data planes, control planes, what are they? How do they interact with each other and what's their purposes? The management plane, how you as the consumer interact with it, NSX as a platform holistically, and then failures and recovery with inside of these individual components. Now, NSX is more than just an intelligence switching platform. It's not just logical switching and logical routing. It's a complete suite of products. It's got load-balancing, connectivity to physical infrastructure using L2 gateways, Firewalling DFW, VPN, data security, activity monitoring, and its policy and group driven. Remember, it's also API and automation driven as well. So, it's a platform it's a suite of products it's not just getting into SDN. Now, there's three main components to NSX. You have the control plane, the management plane, and the data plane. Let's talk about how each one interact with each other, and how you interact with them individually. Now, let's start off with the data plane. The data plane is where all of your connectivity between your virtual machines and your infrastructure takes place. This is your VXLAM, this is your distributed logical routers, this is your distributed firewalling, your distributed services, and your NSX edges. Remember, think of an NSX edge as the very tip of your software-defined networking environment. It is your on-ramp and you're off-ramp into the rest of your data center. The control plane is how we control this logical environment. It's forwarding decisions, it's the control cluster that goes out and manages all of your logical networking components, and it's the separation between the control and the data plane. You then have your management plane. This is your single plane of glass. This is how you interact with your NSX environment, it's UI driven and REST API driven and it gives you a single entry point in order to interact with the environment. Then there's the consumption platform. That's how you want to consume it. It can be a self-service portal, this can be vRealize automation, OpenStack, some sort of custom integration that you've written with inside of your company, third-party applications, or you just go in and clicking in through the UI environment itself. Now, the NSX edge is what bridges that control plane, that run-time state, and your data plane. Because NSX edge is your gateway into the environment, it's split between control plane and data plane integration. Now, the data plane components consist of your vSphere Distributed Switch. Now remember, NSX is dependent on a VDS it is not built and designed to work with your standard switches that are deployed in the environment. You have a VMkernel module, you have your VXLAN logical switching, you have your distributed logical router, and your distributed firewalling which we reference as DFW. Those are your data plan components? Now, your Edge Services Gateway, you're ESG. This is a VM that you actually deploy into the environment. All the previous modules your distributed logical router, your DFW, VXLAN that runs inside the kernel module of the ESX host itself. The ESG is an actual VM form factor that's deployed in the environment, it's highly available, it's does your dynamic routing, it synchronizes OSPF and BGP with your upstream routers, and it gives you the L3-L7 services like NAT, DHCP, Load Balancing, VPN, and Edge Firewalling. The control plane components are once again a VM form factors that are deployed, but they're small. 4CPU generally four gigs and we deploy three controllers whether it's a local stand-alone NSX implementation or it's a universal construct where you're deploying multiple NSX instances. If it's a global control cluster or a standalone control cluster it's three individual VMs that get deployed. This is what controls your data plane and it isolate your data plane from your control plane. The benefits of this is it's a cluster. It's highly available, it scales out, its VXLAN with no multicast, and it gives you ARP Suppression. Now, remember because this is an actual VM form factor, it takes advantage of these vHA and DRS with anti-affinity rules to make sure that your cluster is maintained and healthy. Now, the NSX management component is what allows you to interact with the NSX environment. You have deeply integrated vSphere APIs and REST APIs that allow you to talk between your vCenter Server Manager and whatever type of consumption that you have at the top level whether it be OVRA OpenStack, or an in-house custom application. Now, this NSX manager is a virtual machine that you deploy in the environment. It's what provisions your control cluster and it's the single pane of glass that allows you to deploy all of your logical networking components out in the environment. It's where you do your VXLAN preparation. It's where you consume your logical networking, and it's where your networking services configurations are maintained and managed. It's also where you can have a single plane of glass to manage your third party management console in our partner ecosystem like Trend Micro, Symantec McAfee, and Palo Alto. The NSX manager does have a one-to-one mapping between itself and the vCenter Server. So, whether you're running a single site or multi-site deployment, each vCenter Server that's in the environment that will be under management, will have an NSX manager deployed. You can either configure and deploy through the UI or through the NSF's API. It gives you a deeply integrated vSphere Web Client plugin. It's where you deploy and configure all of your VXLAN and distributed logical routing components, and it's where you configure your control cluster. Now, let's talk about building the next platform. There's three key pillars to building out NSX into an environment. You have your prerequisites. Inside of your data center, you need to be able to run 1,600 bytes MTU or larger. Now, in most data centers this isn't a problem today. Traditionally a jumbo frames is enabled inherently. You need a vCenter Server. You need deployed and configured ESXi hosts, and then as previously mentioned, you need a vSphere distributed switch that get configured and enabled in the environment. Now, your onetime deployment is the NSX manager itself, the control cluster, the host preparation which is deploying VBs and drivers out to the physical ESXi hosts. Then a logical networking preparation which is a segment ID and a transport zone. Then finally, we're able to now deploy reoccurring and logical components like your logical networking security services, your logical switches, your bridge networks, and your centralized distributed logical router. Now, let's walk through a quick deployment of NSX. You deploy your intersex Manager which is a simple OTF deployment into your vSphere environment. You then register it with your vCenter Server and your platform services controller. The NSX manager then deploys your control cluster. The NSX manager then tells the control cluster to now configure itself and synchronize with your vSphere clusters and it does a host prep. It's deploying drivers and VBs out to that environment so those hosts are now ready for VXLAN. It then deploys it to VX cluster 2, 3, 4, and so on and now preps the entire environment. Once your environment is now configured and ready you can deploy your end services gateways which gives you that on-ramp and off-ramp into the rest of your data center environment. Now, what is a transport zone? A transport zone is what controls the logical span between physical hosts. It's what dictates the clusters that can participate in your VXLAN logical networking. Now, NSX logical routing with DLR and ESG. So, there's two very specific components here. A DLR, which is your distributed logical router, is what is optimized for East-West traffic that's what gives you the connectivity inside of your data center. Whereas your NSX edge is an actual appliance that's deployed in the environment that gives you a centralized routing for your north-south integration and access points. Your NSX control cluster is what gives you the control plane to distribute VXLAN and networking information to all your ESX hosts. The control cluster is designed to be scalable and highly available out into the environment. That way if one happens to fail or you do have an HFI event you don't lose data playing connectivity and control plane connectivity. Now, remember because this is a control cluster, there is a master election that happens. So, each when you do deploy the three controllers, there is an election that happens and when one of them fails and other one will pick up that master election. This guarantees consistency and correctness and always gives you a single point of truth out in your environment. Recovering from a control cluster failure is very easy. The controllers are stateless. So, when you do have a failure in the environment, you simply go and you delete the existing controllers, even if they're still healthy. You create a new control cluster by simply going into your NSX manager, going in your actions, deploy in your control cluster and then telling it to update controller state. It's very simple right out of the box. Now, the NSX controller and manage your communication path uses a UWA which is a User World Agent. This is an SSL driven communication that is secured between all components of your NSX environment. Now, between the NSX manager and the rest of your control cluster it uses RabbitMQ to communicate securely out in the environment. Now, the ESXi user and Kernel Space is a little bit different. So, you as you push changes and configurations through the NSX manager, it's then internally pushed through the control cluster that control cluster talks over SSL as a TCP connection to NetCPA which is your controller connectivity on the ESXi host, and that's how you can then push down routing VXLAN and core configurations into your environment. The insects vSwitch and NSX edges are two separate components. The logical switch is in Kernel module that runs inside of your physical ESXi host that gives you VXLAN, distributed routing, distributed firewall and switch security and connectivity. Whereas your ESG or Edge Services Gateway is actually what is connecting you out to the physical environment that gives you full control function, dynamic routing, and controller updates into the environment. You're Edge Services Gateway also gives you the L3 and L7 connectivity services like NAT, DHCP, Load Balancing, VPN and Firewalling. It's a VM form factor that has actually deployed and it can be deployed in a high availability mode where you have an active and standby or active nodes there in your environment. Now, how is control plane connectivity secured? So, all connectivity and all communication is protected through an SSL over the management network. The NSX manager creates a self-signed certificate that is then deployed to each host and each NSX controller, thus allowing secure communication throughout the environment. What does this look like? When you deploy your analytics manager it creates a certificate. You then deploy an OVF for the control cluster. That certificate is then passed down, your NSX manager then communicates with your ESXi hosts through the control bus, and NSX Manager talks to its own control cluster through the rest API. Once this is established you now have a secure certificate-based communication between all three components the physical ESX hosts, your control cluster, and your NSX manager. So, NSX does have control plane resiliency you built into it. Here in this case, we have separate virtual machines that are deployed across three physical hosts. In this environment this is VNI 5000 that includes host 1, 2, and 3. Now, when vMotion, a VM from host 1 or 2 to host 3 there's no changes in this environment. But when you power on or vMotion a VM from host 3 to 4 that traditionally or originally didn't have a virtual machine residing on, it results in a new table add and update to that physical host. Now, let's take a look at an example of your enterprise routing topology. In this environment, we have a distributed logical router, we have our logical switches, we have multiple components that are running inside of our logical environment. Each logical segment is then up-linked to an Edge Services Gateway, and in this scenario we have ECMP running, which means that all three or four of my Edge Services Gateways are intimately connected. They're sharing load balancing traffic up to the physical routers through the physical VLAN connectivity and back to the core of the environment. This is best practice and this allows you to get a north-south optimisation and allows for high traffic flow and high volume throughput in this logical NSX environment. Thank you. That concludes our NSX architecture components.
