If you would like to read the other parts in this article series please go to:
- What You Need to Know About Software Defined Networking in Hyper-V (Part 1)
- What You Need to Know About Software Defined Networking in Hyper-V (Part 3)
- What You Need to Know About Software Defined Networking in Hyper-V (Part 4)
In the first article in this series, I started out by discussing how VLANs have traditionally been used as a mechanism for creating isolated virtual networks. I also showed you why VLANs don’t scale very well and I explained that software defined networking was going to be the preferred mechanism for providing network isolation going forward.
My original plan for this article was to jump right in and start talking about the nuts and bolts of software defined networking. As I sat down to start writing this however, I realized that my previous article made it sound as if the most compelling reason to begin using software defined networking is that traditional VLANs don’t do a very good job of accommodating enterprise scale or cloud scale networks.
Although there is no question that software defined networks scale better than VLANs, scalability is far from being the only reason for using software defined networks. If it were, then software defined networks would be one of those things that smaller shops would never have to worry about. In reality however, smaller shops can derive significant benefits from software defined networking too.
The single biggest advantage to using software defined networks is that doing so gives you an unprecedented degree of flexibility. In fact, once software defined networking in place you can do some things that would otherwise be very difficult, expensive, or perhaps even impossible.
Let me give you an example of how software defined networking can help to simplify some otherwise very complex network tasks. Imagine for a moment that an organization landed a short term contract and needed to ramp up capacity in order to fulfil the contract. For the sake of discussion, let’s pretend that the organization needs to spin up a couple hundred virtual machines, but currently lacks the hardware necessary to do so.
In the not too distant past, the organization probably would have had to purchase hardware to accommodate the VMs. Once the project was over they would have to figure out what to do with the leftover hardware. Today however, there are other options.
If you examine the problem from a business standpoint, it probably doesn’t make much sense to spend big bucks on hardware that is only going to be needed on a temporary basis. A better option might be to lease capacity from a cloud service provider. However, doing so presents other challenges. Simply put, the cloud service provider’s hosts exist on a completely different subnet. That means that if you want VMs that you create in the cloud to be able to seamlessly communicate with your on premise VMs then you are going to have to put in place some sort of routing mechanism.
This is where software defined networking comes into play. Remember, software defined networking is designed to add a layer of abstraction so that the physical network design no longer gets in the way. In this particular situation for example, a software defined network would make the local network, the WAN link, the service provider’s network, and the various virtual networks that are in use invisible to the VMs. The VMs only see the software defined network. This means that the VMs can easily be made to believe that they all exist on a common, local subnet. As such, all of the virtual machines can share a common IP address range, which would allow them to seamlessly communicate with one another.
Obviously being able to lease capacity from a service provider and make that additional capacity appear as if it were a local resource can be very helpful, but this is really only the beginning of what is possible using software defined networking.
If you really stop and think about my previous example, a single software defined network spanned multiple datacenters. This means that a virtual machine’s IP address space no longer has to be tied to the physical location of the host server on which the VM is running. As such, software defined networking makes it much easier to live migrate virtual machines between datacenters on an as needed basis without having to worry about changing the VM’s IP address or updating DNS records.
It is the abstraction layer that sits on top of the physical and virtual networks that allows IP addresses to be used without regard to the virtual machine’s physical location. As such, a software defined network can be thought of as a logical structure that mimics a traditional network.
With that said, it is also important to understand that just as a single physical network can accommodate numerous VLANs, it is also possible for multiple software defined networks to reside on a common physical network.
Just as VLANs are isolated from one another, so too are software defined networks. As such, it is perfectly acceptable to use duplicate private IP addresses, so long as each IP address is used only once per software defined network. Of course this raises the question of why you would ever want to create multiple software defined networks or use duplicate IP addresses.
There are a number of different situations that might warrant the use of multiple software defined networks, but the main reason has to do with a fundamental shift in the way that networks are being managed. Once upon a time, the network administrator had dictator like control over all things IT. However, that began to change once cloud services started to become popular. Power users began to realize that they no longer needed to call IT every time they needed to have something done. Instead, they could simply use the corporate credit card to set up an account with Windows Azure, Amazon Web Services, or one of the other cloud service providers, and bypass IT completely. This practice became known as shadow IT.
The problem with shadow IT was that it not only bypassed the corporate IT department, but it also lead to sensitive data being stored in the cloud. Administrators who wanted to see that data kept in house and who did not want to have their jobs outsourced began looking at private clouds as an alternative.
Private clouds deliver functionality that is similar to the public cloud, except that resources are kept on premise. In a private cloud environment, authorized users are provisioned with blocks of compute and storage resources and are given access to pre-configured virtual machine templates. Those templates can then be used to generate brand new virtual machines that are configured according to the various corporate policies. In other words, authorized users do not have to ask the IT department to create virtual machines. They can do it themselves through a self-service interface.
This is where multi tenancy comes into play. When you blindly give users the ability to create virtual machines, you have no idea how the users will configure those virtual machines or what they will do with them. For everyone’s safety and security it is necessary to keep user created environments separate from one another and separate from IT’s resources. This is where software defined networking comes into play. When implemented in a private cloud environment, software defined networking is used to provision each tenant (or authorized user) with their own unique address space (their own software defined network) so that their self-configured environment can remain isolated from the rest of the network.
Now that I have spent some more time talking about what software defined networking is used for, I want to begin talking about the nuts and bolts of software defined networking in Part 3.
If you would like to read the other parts in this article series please go to: