Multi-tenant Networking Primer: needs more research
So searchnetworking.com posted a primer on Multi-tenant networking covering the obvious approaches used today which are:
- physical segmentation
- VLANs
- separate vSwitches like Nexus 1000V or Open vSwitch per application or tenant
Overall, I thought the article, written by Michael Brandenburg, Technical Editor, made a lot of good points and got me thinking enough to want to comment on it directly. But I do think it needs more work. I actually wanted to leave my comments on the site, but they don’t seem to let you (I did not try to register and log in). That said, let’s dig into the article a little bit.
Specific to common approached to multi-tenant networking, I agree with 1. and 2., but not with 3. as explained in the article. Approach 3 is never implemented on its own as the choice to deploy separate vSwitches actually leads to either 1.physical segmentation (different network devices upstream) or 2.VLANs because vSwitches can’t share physical NICs last I checked. So option 3. only really serves to make option 1. or 2. better and isn’t really an option on it’s own (with today’s technology). The Nexus 1000V only supports 1 VEM per server (a VEM is a Cisco vSwitch) anyway, but with that product, there are better approaches to securing the edge. You can read about that here in my article 2 vSwitches are Better Than One, Right?
Also, this statement is just wrong:
The vSwitch operates and runs in the same virtual environment as the virtual application servers, so instead of the servers pushing packets to a dedicated piece of networking hardware, packets go through to another virtual machine instance, requiring additional processing and overhead on the host server.
A vSwitch is NOT a virtual machine, typically there is a kernel module and a component running in user space. In a VMW environment, CPU and memory usage of the vSwitch when a virtual machine transmits comes from that VM’s allocated mem/cpu resources. On packet receive, regardless of the packet destination, mem/cpu cycles come from the hypervisor (not a specific VM allocation).
Another part of the article that I have a problem with is this:
The application would ultimately dictate the latency and bandwidth requirements, for example, and an application-aware network could then dynamically adjust itself to meet those demands.
Latency and BW are physical characteristics dictated by the underlying switches and routers. How does a network dynamically add more Arista, Juniper or Cisco switches to increase capacity? How does a network respin ASICs dynamically to lower latency? It doesn’t. Like a nervous system, an application aware network has to be able to provide feedback to the application system manager such that workloads can be intelligently reshuffled around the physical infrastructure to meet BW & latency requirements per tenant or per app. And again, like a nervous system, there needs to be 1 brain providing this feedback for the network domain, not 1 brain per switch.
But this one I LOVE!
In an application-aware network, the private cloud and all of the applications would become the tenants on the network, receiving the appropriate isolation and security based on each application’s specific requirements.
Amen. This applies to all clouds, not just private.
Finally, I am wondering why the author didn’t touch on technologies like VPLS or OpenFlow, both of which are viable solutions to the multi-tenant problem.
Michael, are you going to VMWorld? If so, let’s grab a coffee and discuss some more.
