You got SDN, now what
It has three years since VMware announced and showcased NSX to the world. Since then everyone and then some has announced their version of SDN. You have players such a Cisco, Cumulus Networks and of course VMware in this space. All doing SDN in their own unique way. Cisco being the biggest network player of course wants to move hardware to your datacenter. Therefore, their way to SDN is to buy new boxes. Another player is Cumulus Networks, again theirs another focus. Here the OS is king. Build on open source components Cumulus Networks deliver the OS for SDN, which run on any white box. If you do not want to build your own white box networks based on Cumulus Networks many vendors have, join Cumulus Networks. Vendors such as HPE, Dell and Supermicro amongst others are selling switches, which comes with Cumulus Networks OS baked in. Even Microsoft is entering the stage of SDN with Server 2016, though one could argue a bit late, but then better late than never.
I am not going to start a fight over what SDN means. Just note, that MY definition does not involve the requirement to buy a given vendors physical hardware boxes, be it switch or server based. From here on NSX is the SDN of choice. This author is running NSX and it is what I assume to be running in the datacenter for this article.
You got SDN, now what. You are now the happy owner of a SDN. You go about your everyday life just as you did before you got SDN. Well, your network scales better than before, so the complexity of you network has increased which is the result of not being bound to the physical constructs of regular networking and of course the costs that comes with scaling physical networks. This is not to say that the physical network does not matter anymore! I do, if not more than ever then at least the same as before. After all the physical network is what makes SDN possible. It is what moves packages across your enterprise. It is not the time to throughout your network gear, but it might be time to design the network differently. Two of the things that have been synonymously with SDN is east-west traffic and 10Gb+ at the access layer, whereas north-south bandwidth is becoming less important as less traffic is traveling north-south in the datacenter. This is mostly due to how applications are architected, with more services being split out on multiple VMs/containers, which is somewhat opposite to the pre-virtualization world where it was normal to have many services running on the same physical server to shave hardware costs.
Let me go back a bit again. I did state that the complexity of your network has increased did I not. Wasn’t that one of the things that SDN was set out to fix? It is and it does. SDN does deliver, but just as with VMs where it started out as a way to grow beyond the physical limitations of your datacenter and shave costs. It became so easy to deploy a VM that it was given a name. VM Sprawl. The same holds true for SDN. Creating VXLANs are just as easy if not easier than creating a VM. This leads to more networks, which might need to be routed and firewalled. Therefore, you will see that SDN bring a lot of scale and ease of management, but if not well designed, will in the end lead to a boom in networks and rules to govern them and this is here the increased complexity some in. This is not the fault of SDN. It is the fault of the design of the network and just like with VMs where automation/cloud projects are an increasing event in the enterprise. Retirement plans and exit strategies are now something that is being taken seriously at the CxO and board level. It is some of the same thoughts that need to go into planning and designing a SDN.
- How do you make sure you can have multiple vendors in the datacenter, both software and hardware wise? After all, we all know the first fix is free and you do not want vendor lock-in.
- If you choose a SDN vendor, how easy is it to switch another vendor?
- Are there any ties to the physical network equipment? Or can the equipment simply be replaced with something else?
- Are your current monitoring tools good enough?
- Do you have the right staff for things to come?
As you already have SDN, you of course has all of the above and then some under control. Then again this article is not called SDN 101, but “You got SDN, now what”. Indeed now what! So you might not have everything under control. Is it your network team, which does both physical network and SDN? Can you monitor both the physical network and your SDN? Do you understand the impact one has on the other? What about micro-segmentation, do you just guess which ports need to be open and where to and from? You could also hope that the documentation is right, but then you have to ask; can I afford it to be wrong?
Queue VMware’s vRealize Network Insight.
This is one of the more hyped products that VMware has announced as of recently. It is to complement NSX, but it is not an NSX exclusive product. It does cover the physical network as well. Before vRealize Network Insight, your option was to use vRealize Operations Manager (vRops) together with the management pack for network devices. That one would cover both physical and SDN, but not as brilliant as vRealize Network Insight does. In that sense, it was merely a band-aid. vRealize Network Insight is the real deal when you want to monitor your physical and Software Defined Network. It does day 0 operations like planning for implementation of micro-segmentation and day 2 operations like, optimization, health validation and compliance check. It does so for your entire network.
When I say the entire network, what I really mean is of course all those who are supported. I think the list at this point is too short, but much longer than I would have expected. It covers Cisco Catalyst (3, 4.5, 6.5K) and Nexus (1, 5, 7, 9K) series and Arista, Brocade, Juniper and lastly Dell. Besides routers and switches Cisco and HP converged infrastructures are supported and Palo Alto Networks on the firewall side. That only leaves VMware. Here obviously NSX is supported as well as vCenter. The latter is to gain more insight into the virtual environments metric such as CPU and memory load.
Let me try to give you an idea of what vRealize Network Insight does. It is very much a tool for designing your network. The way it works is that it uses information from your virtual network via IPFIX, your NSX manager and your physical network devices. It will give you insight into how traffic flows in your network and between VMs. Now you will be able to see if there is a network bottleneck against your backup solution or on a given port in your network. You will be able to move very chatty VMs closer to each other, so that traffic can be, contain within the host and therefore never hitting the physical network, even if they are on different L3 networks thanks to NSX’s routing capabilities. For the day-to-day operations vRealize Network Insight will alert you if there is faults or misconfigurations in your network be it physical or virtual.
As this tool is all about network I will leave you with the below L2 Network Metrics graph, which shows you some of the metrics which are available in vRealize Network Insight. This of course is not what vRealize Network Insight is all about. Analytics and planning are the key words here. It is a powerhouse for network operations both for day 0 operations where planning is key and day 2 operations where you as a network administrator, need to make sure the entire network runs as a well-greased engine and making sure it scales to the needs of your business requirements. It is all about making your business shine and run better than the competition. You got SDN, now get enlightened; take vRealize Network Insight for a test drive.
- vRops 6.3 – Walkthrough new features
- Comparing vSphere Distributed Switch and Cisco Nexus 1000v switch