There is no more fashionable – and frankly sometimes confusing – slogan embroidered on the banners of today’s data center design and implementation teams than “SDDC,” or Software Defined Data Center. What does it mean?
As a first step, we define our servers as virtual machines in software, and then – and this may seem daunting at first – we say thank you, but we don't ask for traditional data storage solutions, as this will become an SDS, i.e. software-defined data storage. From here on, we become increasingly uninterested in the miraculous capabilities of rack-mounted network devices, since we have SDN, i.e. software-defined networking. Let's take a look at the latter for a moment, and take a broad look at what VMware's SDN solution, NSX, offers!
Both in practice and during courses, I often find that it is helpful to clarify the basic concepts related to network virtualization.
Virtual networks can be found even among the “basic” vSphere services, as there is the “plain” virtual switch, and for the more advanced, the distributed virtual switch version offers a much more advanced feature set. Both solutions are perfect in their place and role for connecting hypervisors and virtual machines to the network, but here comes a small snag: although the network created with them is virtual, they are not able to connect to real or virtual (VLAN) networks implemented in the physical switches of the data center, and to satisfy the network needs of the aforementioned virtual machines and the VMkernel, so that the network is not configured by us, but by “the network guys”. However, with our settings, we actually follow the possibilities offered by the physical network.
What does this mean in practice?
If we need VLANs, we tell the Network Admin, and he, in his great mercy, creates some for us. Of course, not immediately! The Network Office's response time, as stipulated by law, is 8-15 days. Sounds familiar, right?
If we need routing, we beg gently, we threaten to implement NAT as soon as possible, we don't shy away from bribery for a VPN server, and for a load balancer setup, we reflexively call the secret number of our Ukrainian friend to convince (gently of course!) the head of the network team that evening in the parking lot of the office building that this really needs to be configured, and quickly.
Based on this, this article could go in two directions at this point:
- How to be aggressive, fearsome, and therefore successful data center operators?
- How can we take control?
Although I would personally lean towards the solution detailed in the first point, here and now let me suggest discussing point 2.
What do we want to achieve?
In fact, we want the problems outlined above to disappear (and if possible, quickly and in one fell swoop). Okay, but how?
Logical Switching:
Using NSX, we will not have any problems with VLANs that serve the need for separate networks in virtualization, a high-speed Transport Network is enough, this can be a VLAN, or even a completely transparent physical switch. In this, with VXLAN (or GENEVE in the case of the newer NSX-T) technology, we can create practically any number of networks (Logical Switches) with kernel modules integrated into the hypervisor. We also call these horizontal networks among ourselves, in vain, every subculture has its own slang, right?
And this way we don't have to call the Network Admin for a new VLAN, he's happy about that, and it's easier for us too.
Distributed Logical Routing (DLR):
The network communication needs of virtual machines and machine groups require routing and routing settings. Thank you very much, but not in the physical network, but in virtualization, and moreover, we solve the connections between horizontal networks with kernel-mode routers placed in hypervisors. Should static or dynamic entries (OSPF, BGP) be placed in the tables? Choose according to your needs! We are pleased that the routing implemented in this way does not “run” useful communication vertically, i.e. through the real routers of the data center. The real advantage of this is speed and performance.
The Network Admin looks at us with a frown, then nods: ah, the vemveres will realize that this is not the One True Way and they will laugh at us among themselves.
Distributed firewall and micro-segmentation:
The world is full of bad guys, and in fact, everyone except us - everyone, without exception - is a cybercriminal. This has established the need for a firewall, which we could implement in several places: in the operating systems of virtual machines as well as on real, large firewall devices on the physical network. The only problem is that the monitoring capabilities of virtualization do not extend to these. But what if the firewall also worked in the hypervisor kernel, directly on the network connections of virtual machines? Good idea, let it be so! Wouldn't it be better if we managed all this based on policies, in which we could choose from countless options as conditions from the information that is already available in virtualization? What if the conditions could be independent of the location of the virtual machines, or could they monitor just that? Could they even depend on the logged-in user? Could we set conditions ranging from L2 to L7? But, yes, this is the Distributed Firewall kernel module, the monitoring of which is in our hands.
The Network Admin now says sorry, but he doesn't smoke when you ask him for a cigarette. Even though you know he has one.
Direct connection of Logical Networks to the Physical Network (L2 Bridge):
Let's say that life brings you a relatively long time to convert physical machines to virtual machines, or to integrate virtual machines with traditional VLAN-based connections into logical networks while maintaining their direct reachability. So, what should we do? No big deal, let's configure L2 Bridge in NSX! The function is also handled by a kernel-mode software component, on a hypervisor designated for this task.
The Network Admin no longer greets you in the elevator in the morning.
Edge Services (EDGE Services):
So far, we have reviewed the most important kernel-mode services, now we must also talk about well-known and frequently used solutions of the network environment, which operate here, in NSX, in special purpose machines, so-called Edge Services Gateway Appliances: Edge Firewall, DHCP Server, VPN Service, Load Balancing, NAT. The Edge Services Gateway can provide all these functions with redundancy, scaled to the task and its resource requirements. We produce and configure it according to our needs. It performs its task appropriately when connecting the data center and the outside world, as well as the data center's delimited environment (Tenant) and the data center's common network.
A standalone rule-based firewall that can be extended with policies, two-way NAT, L4-7 Load Balancing, Site-to-site VPN, SSL Client VPN? Yes. OSPF and BGP routing protocols with redistribution capability? Of course! How many do you want? Will it be consumed here? Here you go!
It's sad, but the Network Admin doesn't work here anymore. Yesterday we saw him walking out to the parking lot to his old, worn-out brown Toyota with a paper box in his arms - his coffee mug, a half-withered flower and a faded photo of a long-forgotten soccer tournament -, putting the box in and driving away. Just like in American movies. The security guard opened the barrier for him because he no longer had a magnetic card...
Author's note
I apologize with great respect to the Network Admin mentioned several times above, especially if anyone recognizes themselves in him. Most of all, because I could not overcome the inner compulsion, the little devil, and used his precious person in the writing, for which I am ashamed. Very much. At the same time, I follow him, because a great injustice was done to him in a brazen way. We pretended as if we did not need his knowledge and many years of experience, but the reality is that we really need him and his knowledge when implementing SDN solutions. Just because we have a management console in our hands in which we can actually define network configuration on a software basis, let's not think that we can avoid learning and practicing network concepts, terminologies and rules with this...
And so it ends, because the story wouldn't be complete without a happy ending:
Today we called the Network Admin back. The management ordered a path strewn with rose petals from the main entrance to his new, sunny office from a reputable catering company. We configured him with permissions to the NSX management console, which he understood in minutes. We gratefully drink in his every word as we discuss implementation and operational issues. He often asks if we want a cigarette. We learn from him. He from us. We are a team.
If you are interested in the (technical) details, let's meet at the NSX courses!
András Székács
senior VMware instructor, Training360
VMware Certified Instructor (VCI), VMware Certified Advanced Professional (VCAP)