faz1.com blog

So searchnetworking.com posted a primer on Multi-tenant networking covering the obvious approaches used today which are:

1. physical segmentation
2. VLANs
3. 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.

Mastered the art of infuriating your wife or girlfriend?  Can’t get your daughter to talk to you because you work all the time?  I can help you buy your way out o’ trouble.

(Thanks to Neal at http://nealmueller.com for the image recommendation!)

My wife Joy is a womens’ jewelry & accessories designer (which balances the geek in me out quite nicely) and she has just launched her new site.  Her jewelry & hair designs have been paired with some of the most respected & sought-after names in the fashion industry, such as Oscar de la Renta, Zac Posen and Reem Acra.  You can check it out at http://joypardifazzone.com or through FB.  Throw her a “like” on FB to help us spread the word.  Who says technology and fashion don’t mix?

Citrix is looking for beta testers for their upcoming release of XenServer featuring a Distributed Virtual Switch (DVS).

The Citrix DVS capability allows XenServer customers to centrally apply networking policy and gain visibility into VM network interfaces in a centralized manner.  It also enables the persistence of VM network policy and state through mobility events.

The Citrix DVS leverages Open vSwitch (http://openvswitch.org/) running in the individual XenServer hypervisors.

There has been a lot of discussion about the Enterprise Stack and if any one vendor will ever own the whole thing. While that is a grand vision for any of the companies named below (and sure to bring applause from their shareholders on “analyst” day), I simply don’t see customers ever allowing it to become reality.  Customers don’t want to be locked in.  In my opinion, the virtual enterprise stack is what will win, but there will be lots of different vendor choices up and down that stack….and by the way, it probably won’t actually be hosted in the Enterprise DC (but that is another discussion).

Via: What is the Enterprise Stack?

For the first part of this year, customers are voting with their wallets and they are choosing…..drum role…..everyone (see How Much Integration Is Too Much in the Cloud?).  Unlike the Internet bubble burst back in 2000/2001 where companies like Cisco stole market and revenue share from the rest of the networking industry during the recovering, this recovery looks like it might be shaping up to be a little different.  Back in 2001, the technology didn’t really evolve very much between the time of the burst to the point where the recovery really kicked in.  Sure, it got faster and cheaper, but architectures fundamentally stayed the same (they just got some new bells and whistles).  Blade servers started to emerge and networks saw a lot of movement from 100M to 1G at the access layer but virtualization hadn’t really kicked in yet.  Since November of 2008, customers have had a lot of time to reevaluate their entire IT stack AND a lot of new architectural solutions have emerged.  Amazon’s EC2 and Rackspace’s Cloud Hosting have given customers direct access to more cost effective data center resources that they can access on demand.  Google Apps have given companies big and small complete business solutions (email, docs, spreasheets, sites, etc) that can be spun up and online the same hour the company opens it’s doors.  VMware’s vNetwork Distributed Swith/Cisco’s Nexus 1000V, OpenFlow & Open vSwitch, HP’s Virtual Connect, Palo Alto Networks NG Enterprise Firewalls, Cisco’s Nexus 5000/2000 combination (foundational to Cisco UCS)  and Arista’s 7×00 w/ vEOS are all examples of fundamentally new capabilities introduced since the downturn which customers can now leverage to harness their increasingly complex and highly virtualized data centers.

The point is that customers today are faced with much greater IT challenges than they were in 2008 and the technologies are dramatically different…not necessarily all of them better, but definitely different.  And, there are a lot of new IT solutions warming up their engines to go out on track for the first time and see what types of lap times they can turn in.  Should be fun!

There has been a lot of hub-bub made earlier this year about the fact that Red Hat was dropping Xen from RHEL 6.0 in favor of KVM and that this would ultimately lead to Xen’s demise.  You can read through the timeline of events here and details about when the drop was first spotted here.

Citrix Senior Marketing Director John Humpheys has done a short write up on 3 aspects of server virtualization where XenServer is actually seeing a lot of traction (data center, cloud, desktop).  Last I checked, these are THE major 3 areas.