Build For IT Nirvana

In many data centers large and small there is a history of making short-term decisions that affect long-term design. These may be based on putting out immediate fires, such as rolling out a new application, expanding an old one, or replacing failed hardware. They may also be made by short-sighted or near-sighted policies, or more commonly old policies that aren't question in the light of new technology. These types of decisions can range from costly to crippling for data center operations…

To see the full post visit NetworkComputing: http://www.networkcomputing.com/private-cloud/231700329

Related posts:

  1. Network Management Needs New Ideas
  2. World Wide Technology’s Upcoming Geek Day
  3. The Data Center Network OS – Cisco Open NXOS
  4. Storage Protocols
  5. What Network Virtualization Isn’t

Thoughts From a Global Technology Leadership Forum

I recently had the privilege to attend and participate in a global technology leadership forum.  The forum consisted of technology investors, vendors and thought leaders and was an excellent event.  The tracks I focused on were VDI, Big Data, Data Center Infrastructure, Data Center Networks, Cloud and Collaboration.  The following are my notes from the event:

VDI:

There was a lot of discussion around VDI and a track dedicated to it.  The overall feeling was that VDI has not lived up to its hype over the last few years, and while it continues to grow market share it never reaches the predicted numbers, or hits the bubble that is predicted for it.  For the most part the technical experts agreed on the following:

There was some disagreement on whether VDI is the right next step for the enterprise.  The split I saw was nearly 50/50 with half thinking it is the way forward and will be deployed in greater and greater scale, and the other half thinking it is one of many viable current solutions and may not be the right 3-5 year goal.  I’ve expressed my thoughts previously: http://www.definethecloud.net/vdi-the-next-generation-or-the-final-frontier. Lastly we agreed that the key leaders in this space are still VMware and Citrix.  While each have pros and cons it was believed that both solutions are close enough as to be viable and that VMware’s market share and muscle make it very possible to pull into a dominant lead.  Other players in this space were complete afterthoughts.

Big Data:

Let me start by saying I know nothing about big data.  I sat in these expert sessions to understand more about it, and they were quite interesting.  Big data sets are being built, stored, and analyzed.  Customer data, click traffic, etc. are being housed to gather all types of information and insight.  Hadoop clusters are being used for processing data, cloud storage such as Amazon S3 is being utilized as well as on-premises solutions.  The main questions were in regard to where the data should be stored and where it should be processed, as well as the compliance issues that may arise with both.  Another interesting question was the ability to leave the public cloud if your startup turns big enough to beat the costs of public cloud with a private one.  For example if you have a lot of data you can mail Amazon disks to get it into S3 faster than WAN speed, but to our knowledge they can’t/won’t mail your disk back if you want to leave.

Data Center Infrastructure:

Overall there was an agreement that very few data center infrastructure (defined here as compute, network, storage) conversations occur without chat about cloud.  Cloud is a consideration for IT leaders from the SMB to large global enterprise.  That being said while cloud may frame the discussion the majority of current purchases are still focused on consolidation and virtualization, with some automation sprinkled in.  Private-cloud stacks from the major vendors also come into play helping to accelerate the journey, but many are still not true private clouds (see: http://www.definethecloud.net/the-difference-between-private-cloud-and-converged-infrastructure.)

Data Center Networks:

I moderated a session on flattening the data center networks, this is currently referred to as building ‘fabrics.’  The majority of the large network players have announced or are shipping ‘fabric’ solutions.  These solutions build multiple active paths at Layer 2 alleviating the blocked links traditional Spanning-Tree requires.  This is necessary as we converge our data and ask more of our networks.  The panel agreed that these tools are necessary but that standards are required to push this forward and avoid vendor lock-in.  As an industry we don’t want to downgrade our vendor independence to move to a Fabric concept.  That being said most agree that pre-standard proprietary deployments are acceptable as long as the vendor is committed to the standard and the hardware is intended to be standards compliant.

Cloud:

One of the main discussions conversations I had was in regards to PaaS.  While many agree that PaaS and SaaS are the end goals of public and private clouds, the PaaS market is not yet fully mature (see: http://www.networkcomputing.com/private-cloud/231300278.)  Compatibility, interoperability and lock-in were major concerns overall for PaaS.  Additionally while there are many PaaS leaders, the market is so immature leadership could change at any time, making it hard to pick which horse to back. 

Another big topic was open and open source.  Open Stack, Open Flow and open source players like RedHat.  With RedHat’s impressive YoY growth they are tough to ignore and there is a lot of push for open source solutions as we move to larger and larger cloud systems.  The feeling is that larger and more technically adept IT shops will be looking to these solutions first when building private clouds.

Collaboration:

Yet another subject I’m not an expert on but wanted to learn more about.  The first part of the discussion entailed deciding what we were discussing i.e. ‘What is collaboration.’  With the term collaboration encompassing: voice, video, IM, conferencing, messaging, social media, etc. depending on who you talk to this was needed.  We settled into a focus on enterprise productivity tools, messaging, information repositories, etc.  The overall feeling was that there are more questions than answers in this space.  Great tools exist but there is no clear leaders.  Additionally integration between enterprise tools and public tools was a topic and involved the idea of ensuring compliance.  One of the major discussions was building internal adoption and maintaining momentum.  The concern with a collaboration tool rollout is the initial boom of interest followed by a lull and eventual death of the tool as users get bored with the novelty before finding any ‘stickiness.’

Related posts:

  1. Additional Private Cloud Blogs
  2. The Cloud Rules
  3. Intent all of the things: The Power of end-to-end Intent
  4. Thoughts From a Tech Leadership Summit
  5. Your Technology Sunk Cost is KILLING you

VDI, the Next Generation or the Final Frontier?

After sitting through a virtualization sales pitch focused around Virtual Desktop Infrastructures (VDI) this afternoon I had several thoughts on the topic I thought may be blog worthy.

VDI has been a constant buzzword for a few years now, riding the coattails of server virtualization.  For the majority of those years you can search back and find predictions from the likes of Gartner touting ‘This is the year for VDI’ or making other similar statements, typically with projected growth rates that don’t ever happen.  What you won’t see is those same analyst organizations reaching back the year after and answering to why they over hyped it, or were blatantly incorrect. (Great idea for a yearly blog here, analyzing previous years failed predictions.)

The reasons they’ve been incorrect vary over the years starting with technical inadequacy of the infrastructures and lack of real understanding as an industry.  When VDI first hit the forefront many of us (myself included) made the assumption desktops could be virtualized the same as servers (Windows is Windows right?)  What we neglected to account for is the plethora of varying user applications, the difficulty of video and voice, and other factors such as boot storms which are unique and or more amplified within VDI environments than their server counterparts.  From there for a short while the VDI rollout horror stories and memories of failed Proof of Concepts slowed adoption and interest for a short period.

Now we’re at a point where the technology can overcome the challenges and the experts are battle hardened with knowledge of success and failures in various environments; yet still adoption is slow.  Users are bringing new devices into the workplace and expecting them to interface with enterprise services; yet still adoption is slow.  We supposedly have a more demanding influx of younger generation employees who demand remote access from their chosen devices; yet still adoption is slow.  This doesn’t mean that VDI isn’t being adopted, nor that the market share numbers aren’t increasing across the board; it’s just slow.

The reason for this is that our thinking and capabilities for service delivery have surpassed the need for VDI in many environments. VDI wasn’t an end-goal but instead an improvement over individually managed, monitored, and secured local end-user OS environments.  The end-goal isn’t removing the OS tie to the hardware on the end-point (which is what VDI does) but instead removing the applications tie to the OS; or more simply put: removing any local requirements for access to the services.  Starting to sound like cloud?

Cloud is the reason enterprise IT hasn’t been diving into VDI head first, the movement to cloud services has shown that for many we may have passed the point where VDI could show true Return On Investment (ROI) before being obsoleted.  Cloud is about delivering the service to any web connected end-point on-demand regardless of platform (OS.)  If you can push the service to my iOS, Android, Windows, Linux, etc. device without the requirement for a particular OS, then what’s the need for VDI?

To use a real world example I am a Microsoft zealot, I use Windows 7, Bing for search and only IE for browsing on my work and personal computers (call me retro.)  I also own an iPad, mainly due to the novelty and the fact that I got addicted to ‘Flight Control’ on a friends iPad at release of the original.  I occasionally use the iPad for what I’d call ‘productivity work’ related to my primary role or side projects.  Using my iPad I do things like: Access corporate email for the company I work for and my own, review files, access Salesforce, and Salesforce Chatter, and even perform some remote equipment demos, my files are seamlessly synched between my various other computers.  I do all of this without a Windows 7 virtual desktop running on my iPad, it’s all done through apps connected to these services directly.  In fact the only reason I have VDI client applications on my iPad is to demo VDI, not to actually work.

Now an iPad is not a perfect example, I’d never use it for developing content (slides, reports, spreadsheets, etc.) but I do use it for consuming content, email, etc.  To develop I turn to a laptop with full keyboard, screen and some monitor outputs.  This laptop may be a case for VDI but in reality why?  If the services I use are cloud based, public or private, and the data I utilize is as well, then the OS is irrelevant again.  With office applications moving to the cloud (Microsoft Office 365, Google Docs, etc.) along with many others, and many services and applications already there, what is the need for a VDI infrastructure?

VDI like server virtualization is really a band-aid for an outdated application deployment process which uses local applications tied to a local OS and hardware.  Virtualizing the hardware doesn’t change that model but can provide benefits such as:

Once the wound of our current application deployment model has fully healed, the band-aid comes off and we have service delivery from cloud computing environments free of any OS or hardware ties.

So friends don’t let friends virtualize desktops right?

Not necessarily.  As shown above VDI can have significant advantages over standard desktop deployment.  Those advantages can drive business flexibility and reduce costs.  The difficult questions will become

Many organizations will still see benefits from deploying VDI today because the ROI of VDI will occur more quickly than the ability to deliver all business apps as a service.  Additionally VDI is an excellent way to begin getting your feet wet with the concepts of supporting any device with organizational controls and delivering services remotely.  Coupling VDI with things like thin apps will put you one step closer while providing additional flexibility to your IT environment.

When assessing a VDI project you’ll want to take a close look at the time it will take your organization to hit ROI with the deployment and assess that against the time it would take to move to a pure service delivery model (if your organization would be capable of such.)  VDI is a fantastic tool in the data center tool bag, but like all others it’s not the right tool for every job.  VDI is definitely the Next Generation but it is not The Final Frontier.

Additional fun:

Here are some sales statements that are commonly used when pitching VDI, all of these I consider to be total hogwash.  Try out or modify a few of my one line answers next time your vendors there telling you about the wonderful world of VDI and why you need it now.

Vendor: ‘<Insert analyst here (Gartner, etc.)> says that 2011 is the year for VDI.’  Alternatively ‘<Insert analyst here (Gartner, etc.)> predicts VDI to grow X amount this year.’

My answer: ‘That’s quite interesting, let’s adjourn for now and reconvene when you’ve got data on <Insert analyst here (Gartner, etc.)>’s VDI predictions for the previous 5 years.’

Vendor: ‘The next generation of workers coming from college demand to use the devices and services they are used to, to do their job.’

My answer: ‘Excellent, they’ll enjoy working somewhere that allows that, we have corporate policies and rules to protect our data and network.’  This won’t work in every case as Mike Stanley (@mikestanley) pointed out to me, universities for example have student IT consumers who are the paying customers, this would be much more difficult in such cases.

Vendor: ‘People want a Bring Your Own (BYO) device model.’

My Answer: ‘If I bring my own device and the fact that I want to matters, what makes you think I’ll want your desktop?  Just give me application or service.’

Related posts:

  1. HP Flex-10, Cisco VIC, and Nexus 1000v
  2. The Cloud Rules
  3. Thoughts From a Tech Leadership Summit
  4. Passwords Are Doomed: You NEED Two-Factor Authentication
  5. Intent all of the things: The Power of end-to-end Intent

Server/Desktop Virtualization–A Best of Breed Band-Aid

Virtualization is a buzzword that has moved beyond into mainstream use and enterprise deployment.  A few years back vendors were ‘virtualization-washing’ their products and services the way many ‘cloud-wash’ the same today.  Now a good majority of enterprises are well into their server virtualization efforts and moving into Virtual Desktop Infrastructures (VDI) and cloud deployments.  This is not by accident, hardware virtualization comes with a myriad of advantages such as: resource optimization, power and cooling savings, flexibility, rapid deployment, etc.  That being said we dove into server/desktop virtualization with the same blinders on we’ve worn as an industry since we broke away from big iron.  We effectively fix point-problems while ignoring big picture, and create new problems in the process:

The underlying issue is the way in which we design our applications.  When we moved to commodity servers we built an application model with a foundation of one application, one operating system (OS), one server.  We’ve maintained that model ever since.  Server/desktop virtualization provides benefits but does not change this model it just virtualizes the underlying server and places more silos on a single piece of hardware to increase utilization.  Our applications and the services they deliver are locked into this model and suffer from it when we look at scale, flexibility and business continuance.

This is not a sustainable model, or at best not the most efficient model for service delivery.  Don’t take my word for it, jump on Bing and do a search for recent VMware acquisitions/partnerships.  The dominant giant in virtualization is acquiring companies or partnering with companies poised to make it the dominant giant in PaaS and SaaS.   Cloud computing as a whole offers the opportunity to rethink service delivery, or possibly more importantly brings the issue of service delivery and IT costing to the front of our minds. 

Moving applications and services to robust, highly available, flexible architectures is the first step in transforming IT to a department that enables the business.  The second step is removing the application OS silo and building services that can scale up and down independent of the underlying OS stack.  When you talk about zero downtime business continuance, massively scalable applications, global accessibility and other issues the current model is an anchor. 

That being said transforming these services is no small task.  Redesigning applications to new architectures can be monumental.  Redesigning organizations/processes and retraining people can be even more difficult.  The technical considerations for designing global highly available services touches on every aspect of application and architecture design: storage, network, web access, processing, etc.  That being said the tools are either available or rapidly emerging.

Any organization looking to make significant IT purchases or changes should be considering all of the options and looking at the big picture as much as possible.  The technology is available to transform the way we do business.  It may not be right for every organization or application but it’s not an all or nothing proposition.  There’s no fault in virtualizing servers and desktops today, but the end goal on the road map should be efficient service delivery optimized to the way you do business.

For more of my thoughts on this see my post on www.networkcomputing.com: http://www.networkcomputing.com/private-cloud/230600012.

Related posts:

  1. What Network Virtualization Isn’t
  2. The Cloud Rules
  3. Thoughts From a Tech Leadership Summit
  4. The Brocade FCoE Proposition
  5. Additional Private Cloud Blogs

My Recent Guest Spot on The Cloudcast (.NET) Podcast

image

Brian Gracely, Aaron Delp, and I discuss converged infrastructure stack, tech news and industry direction: http://www.thecloudcast.net/2011/06/cloudcast.html.  It was a lot of fun to chat with them and we covered some great topics.

Related posts:

  1. Choosing The Right Private Cloud Storage
  2. Inter-Fabric Traffic in UCS
  3. Building the Right Network for your VMware NSX Deployment
  4. An End User’s Cloud Security Question
  5. Digging Into the Software Defined Data Center

The Difference Between Private Cloud and Converged Infrastructure

With all of the  hype around private clouds and manufacturer private cloud infrastructure stacks I thought I’d take some time  to differentiate between ‘private-cloud’ and ‘converged-infrastructure.’  For some background on Private Cloud see two of my previous posts: http://www.definethecloud.net/building-a-private-cloud and http://www.definethecloud.net/is-private-cloud-a-unicorn.

Private clouds typically consist of four architectural stages (I describe these here: http://www.definethecloud.net/smt-matrix-and-vblock-architectures-for-private-cloud):

To build a true private cloud hardware/platform consolidation is layered with virtualization, automation and orchestration (without which the ‘On-Demand Self Service requirement of NIST’s definition is not met.)  The end result is a IT model and infrastructure that moves at the pace of business.

Converged infrastructure on the other hand is a subset of this, typically consolidation and virtualization but could possibly include some automation.  With all major vendors selling some form of ‘Integrated stack’ marketed at Private Cloud I thought I’d take a look at where four of the most popular actually fall along the path.

 

image

Starting from the bottom (as in bottom of the pyramid rather than bottom in quality, value, etc.)

FlexPod: FlexPod is an architecture designed using NetApp storage and Cisco compute and networking components.  The FlexPod architectures address various business and application needs but do not include automation/orchestration software.  The idea being that customers will have the flexibility to choose the level and type of automation/orchestration suite they require.

Vblock: Vblocks consist of EMC storage couple with VMware virtualization and Cisco Network/Compute.  Additionally VBlock incorporates EMC’s Unified Infrastructure Manager (UIM) which enables automation and single point of management for most of the infrastructure components. An orchestration suite would still be required for true private cloud.

Exalogic: Oracle’s stack offering is Exalogic which combines Oracle hardware with their middleware and software to provide a private cloud platform tailored toward Java environments.  The provisioning tools included offer the promise of private cloud ‘on-demand self-service.’

BladeSystem Matrix: Is built upon HP BladeSystem, storage, network and software components and is managed by HP’s Cloud Service Automation.  The automation and orchestration tools included in that software suite put HP’s offering in the private cloud arena.

Bottom Line:

Depending on the drivers, requirements, and individual environment all of these stacks can offer customers a platform from which to rapidly build cloud services.  The key is in deciding what you want and what is the best tool to get you there.  The best tool to get you there will be based on both ROI and business agility as cost is not the only reason for a migration to cloud.

For a deeper look at private cloud stacks check out my post at Networking Computing (http://www.networkcomputing.com/private-cloud/229900081.)

Related posts:

  1. Why You’re Ready to Create a Private Cloud
  2. Choosing The Right Private Cloud Storage
  3. The Cloud Rules
  4. Post defining VN-Link
  5. Your Technology Sunk Cost is KILLING you

World Wide Technology’s Upcoming Geek Day

Coming up very quickly is World Wide Technology’s (www.wwt.com) annual Geek Day, March 10th 2011 (http://www.wwt.com/geekday/.)  I’m very much looking forward to the event for two reasons:

  1. It’s free to customers
  2. It’s totally focused on geeks interacting with geeks.

The event is focused around live interactive demo’s from sponsor technology companies with breakout sessions chosen by the attendees via online voting.  My favorite parts are that the sponsors aren’t allowed to do lead collecting (badge scanning you know from conferences), gimmicky swag giveaways, or stock their booths with gobs of marketing fluff.  It’s true focus is the demo, and engineer to engineer discussion.  See the link above for more information, and the video below for some customer feedback on the events.  I hope to see you here in St. Louis in March!

Related posts:

  1. Choosing The Right Private Cloud Storage
  2. Support St. Jude and the Fight Against Childhood Cancer
  3. Digging Into the Software Defined Data Center
  4. An End User’s Cloud Security Question
  5. Data Center 101: Server Systems

Where Are You?

Joe wrote an excellent guest blog on my website called To Blade Or Not To Blade and offered me the same opportunity. Being a huge fan of Joe’s I'm honored. One of my favorites blog posts is his Data Center 101: Server Virtualization. Joe explained the benefits of server virtualization in the data center. I felt this post is appropriate because Joe showed us that virtualization is “supposed” to make life easier for Customers.  However, a lot of vendors have yet to come up with management tools that facilitate that concept. 

It’s a known fact that I’m a huge Underdog fan. However, what people don’t know is that Scooby-Doo is my second favorite cartoon dog. As a kid I always stayed current with the latest Underdog and Scooby-Doo after school episodes. This probably explains why my mother was always upset with me for not doing my homework first. I always got a kick out of the fact that no matter how many times Mystery Inc. would split up to find the ghost, it was always Scooby-Doo and Shaggy that managed (accidentally) to come face-to-face with the ghost while looking for food. Customers face the same issues that Scooby and Shaggy faced in ghost hunting. If a Customer was in VMware vCenter doing administrative tasks there was no way to effectively manage HBA settings (the ghost) without hunting around or opening a different management interface. Emulex has solved that issue with the new OneCommand Manager Plug-in for vCenter (OCM-VCp).

Being a former Systems Administrator in a previous life. I understand frustrations in opening multiple management interfaces to do a task(s). Emulex has already simplified infrastructure management with OneCommand. In OneCommand Customers already have the capability to manage HBAs across all protocols, generations, see/change CEE settings,  and do batch firmware/driver parameter updates (amongst a myriad of other capabilities).

 

 Not convinced? No problem. Let me introduce you to OCM-VCp interface. Take a look, you know have the opportunity to centrally discover, monitor and manage HBAs across the infrastructure from within vCenter, including vPort to to VM associations. How cool is that? Very.

 

 You get all the functions of the OneCommand HBA management application. No more looking for the elusive ghost that is called HBA settings. No more going back and forth between management interfaces. Which increases the probability of messing up the settings. However, out of all the cool capabilities here are the top 4 functions that I feel stand out for vCenter:

 

In my opinion this couldn't have come any sooner. As more organizations look to do more with less (virtualization principle) OCM-VCp will be the cornerstone of easing infrastructure management within VMware vCenter.  There is no learning curve because the plug-in has the same look and feel as the standalone management interface. In other words is very intuitive. So if you or your Customer(s) are expanding their adoption of virtualization take serious look at this plug-in, because it's going to make your life so much easier.

http://www.niketown588.com/

Related posts:

  1. What Network Virtualization Isn’t
  2. The Organizational Challenge
  3. Learning from FaceBook's failures
  4. CloudStack Graduates to Top-Level Apache Project
  5. Data Center Bridging

Access Layer Network Virtualization: VN-Tag and VEPA

One of the highlights of my trip to lovely San Francisco for VMworld was getting to join Scott Lowe and Brad Hedlund for an off the cuff whiteboard session.  I use the term join loosely because I contributed nothing other than a set of ears.  We discussed a few things, all revolving around virtualization (imagine that at VMworld.)  One of the things we discussed was virtual switching and Scott mentioned a total lack of good documentation on VEPA, VN-tag and the differences between the two.  I’ve also found this to be true, the documentation that is readily available is:

This blog is my attempt to demystify VEPA and VN-tag and place them both alongside their applicable standards, and by that I mean contribute to the extensive garbage info revolving around them both.  Before we get into them both we’ll need to understand some history and the problems they are trying to solve.

First let’s get physical.  Looking at a traditional physical access layer we have two traditional options for LAN connectivity: Top-of-Rack (ToR) and End-of-Row (EoR) switching topologies.  Both have advantages and disadvantages.

EoR:

EoR topologies rely on larger switches placed on the end of each row for server connectivity.

Pros:

Cons:

ToR:

ToR utilizes a switch at the top of each rack (or close to it.)

Pros:

Cons:

Now let’s virtualize.  In a virtual server environment the most common way to provide Virtual Machine (VM) switching connectivity is a Virtual Ethernet Bridge (VEB) in VMware we call this a vSwitch.  A VEB is basically software that acts similar to a Layer 2 hardware switch providing inbound/outbound and inter-VM communication.  A VEB works well to aggregate multiple VMs traffic across a set of links as well as provide frame delivery between VMs based on MAC address.  Where a VEB is lacking is network management, monitoring and security.  Typically a VEB is invisible and not configurable from the network teams perspective.  Additionally any traffic handled by the VEB internally cannot be monitored or secured by the network team.

Pros:

Cons:

These are the two issues that VEPA and VN-tag look to address in some way.  Now let’s look at the two individually and what they try and solve.

Virtual Ethernet Port Aggregator (VEPA):

VEPA is standard being lead by HP for providing consistent network control and monitoring for Virtual Machines (of any type.)  VEPA has been used by the IEEE as the basis for 802.1Qbg ‘Edge Virtual Bridging.’  VEPA comes in two major forms: a standard mode which requires minor software updates to the VEB functionality as well as upstream switch firmware updates, and a multi-channel mode which will require additional intelligence on the upstream switch.

Standard Mode:

The beauty of VEPA in it’s standard mode is in it’s simplicity, if you’ve worked with me you know I hate complex designs and systems, they just lead to problems.  In the standard mode the software upgrade to the VEB in the hypervisor simply forces each VM frame out to the external switch regardless of destination.  This causes no change for destination MAC addresses external to the host, but for destinations within the host (another VM in the same VLAN) it forces that traffic to the upstream switch which forwards it back instead of handling it internally, called a hairpin turn.)  It’s this hairpin turn that causes the requirement for the upstream switch to have updated firmware, typical STP behavior prevents a switch from forwarding a frame back down the port it was received on (like the saying goes, don’t egress where you ingress.)  The firmware update allows the negotiation between the physical host and the upstream switch of a VEPA port which then allows this hairpin turn.  Let’s step through some diagrams to visualize this.

image  image

Again the beauty of this VEPA mode is in its simplicity.  VEPA simply forces VM traffic to be handled by an external switch.  This allows each VM frame flow to be monitored managed and secured with all of the tools available to the physical switch.  This does not provide any type of individual tunnel for the VM, or a configurable switchport but does allow for things like flow statistic gathering, ACL enforcement, etc.  Basically we’re just pushing the MAC forwarding decision to the physical switch and allowing that switch to perform whatever functions it has available on each transaction.  The drawback here is that we are now performing one ingress and egress for each frame that was previously handled internally.  This means that there are bandwidth and latency considerations to be made.  Functions like Single Root I/O Virtualization (SR/IOV) and Direct Path I/O can alleviate some of the latency issues when implementing this.  Like any technology there are typically trade offs that must be weighed.  In this case the added control and functionality should outweigh the bandwidth and latency additions.

Multi-Channel VEPA:

Multi-Channel VEPA is an optional enhancement to VEPA that also comes with additional requirements.  Multi-Channel VEPA allows a single Ethernet connection (switchport/NIC port) to be divided into multiple independent channels or tunnels.  Each channel or tunnel acts as an unique connection to the network.  Within the virtual host these channels or tunnels can be assigned to a VM, a VEB, or to a VEB operating with standard VEPA.  In order to achieve this goal Multi-Channel VEPA utilizes a tagging mechanism commonly known as Q-in-Q (defined in 802.1ad) which uses a service tag ‘S-Tag’ in addition to the standard 802.1q VLAN tag.  This provides the tunneling within a single pipe without effecting the 802.1q VLAN.  This method requires Q-in-Q capability within both the NICs and upstream switches which may require hardware changes.

image VN-Tag:

The VN-Tag standard was proposed by Cisco and others as a potential solution to both of the problems discussed above: network awareness and control of VMs, and access layer extension without extending management and STP domains.  VN-Tag is the basis of 802.1qbh ‘Bridge Port Extension.’  Using VN-Tag an additional header is added into the Ethernet frame which allows individual identification for virtual interfaces (VIF.)

image

The tag contents perform the following functions:

 

Ethertype

 Identifies the VN tag

D

 Direction, 1 indicates that the frame is traveling from the bridge to the interface virtualizer (IV.)

P

 Pointer, 1 indicates that a vif_list_id is included in the tag.

vif_list_id

 A list of downlink ports to which this frame is to be forwarded (replicated). (multicast/broadcast operation)

Dvif_id

 Destination vif_id of the port to which this frame is to be forwarded.

L

 Looped, 1 indicates that this is a multicast frame that was forwarded out the bridge port on which it was received. In this case, the IV must check the Svif_id and filter the frame from the corresponding port.

R

 Reserved

VER

 Version of the tag

SVIF_ID

 The vif_id of the source of the frame

The most important components of the tag are the source and destination VIF IDs which allow a VN-Tag aware device to identify multiple individual virtual interfaces on a single physical port.

VN-Tag can be used to uniquely identify and provide frame forwarding for any type of virtual interface (VIF.)  A VIF is any individual interface that should be treated independently on the network but shares a physical port with other interfaces.  Using a VN-Tag capable NIC or software driver these interfaces could potentially be individual virtual servers.  These interfaces can also be virtualized interfaces on an I/O card (i.e. 10 virtual 10G ports on a single 10G NIC), or a switch/bridge extension device that aggregates multiple physical interfaces onto a set of uplinks and relies on an upstream VN-tag aware device for management and switching.

image

Because of VN-tags versatility it’s possible to utilize it for both bridge extension and virtual networking awareness.  It also has the advantage of allowing for individual configuration of each virtual interface as if it were a physical port.  The disadvantage of VN-Tag is that because it utilizes additions to the Ethernet frame the hardware itself must typically be modified to work with it.  VN-tag aware switch devices are still fully compatible with traditional Ethernet switching devices because the VN-tag is only used within the local system.  For instance in the diagram above VN-tags would be used between the VN-tag aware switch at the top of the diagram to the VIF but the VN-tag aware switch could be attached to any standard Ethernet switch.  VN-tags would be written on ingress to the VN-tag aware switch for frames destined for a VIF, and VN-tags would be stripped on egress for frames destined for the traditional network. 

Where does that leave us?

We are still very early in the standards process for both 802.1qbh and 802.1Qbg, and things are subject to change.  From what it looks like right now the standards body will be utilizing VEPA as the basis for providing physical type network controls to virtual machines, and VN-tag to provide bridge extension.  Because of the way in which each is handled they will be compatible with one another, meaning a VN-tag based bridge extender would be able to support VEPA aware hypervisor switches.

Equally as important is what this means for today and today’s hardware.  There is plenty of Fear Uncertainty and Doubt (FUD) material out there intended to prevent product purchase because the standards process isn’t completed.  The question becomes what’s true and what isn’t, let’s take care of the answers FAQ style:

Will I need new hardware to utilize VEPA for VM networking?

No, for standard VEPA mode only a software change will be required on the switch and within the Hypervisor.  For Multi-Channel VEPA you may require new hardware as it utilizes Q-in-Q tagging which is not typically an access layer switch feature.

Will I need new hardware to utilize VN-Tag for bridge extension?

Yes, VN-tag bridge extension will typically be implemented in hardware so you will require a VN-tag aware switch as well as VN-tag based port extenders. 

Will hardware I buy today support the standards?

That question really depends on how much change occurs with the standards before finalization and which tool your looking to use:

Are there products available today that use VEPA or VN-Tag?

Yes Cisco has several products that utilize VN-Tag: Virtual interface Card (VIC), Nexus 2000, and the UCS I/O Module (IOM.)  Additionally HP’s FlexConnect technology is the basis for multi-channel VEPA.

Summary:

VEPA and VN-tag both look to address common access layer network concerns and both are well on their way to standardization.  VEPA looks to be the chosen method for VM aware networking and VN-Tag for bridge extension.  Devices purchased today that rely on pre-standards versions of either protocol should maintain compatibility with the standards as they progress but it’s not guaranteed.    That being said standards are not required for operation and effectiveness, and most start as unique features which are then submitted to a standards body.

Related posts:

  1. How Emulex Broke Out of the ‘Card Pusher’ Box
  2. Choosing The Right Private Cloud Storage
  3. The Organizational Challenge
  4. Building a Private Cloud
  5. VXLAN Deep Dive

Data Center 101: Server Virtualization

Virtualization is a key piece of modern data center design.  Virtualization occurs on many devices within the data center, conceptually virtualization is the ability to create multiple logical devices from one physical device.  We’ve been virtualizing hardware for years:  VLANs and VRFs on the network, Volumes and LUNs on storage, and even our servers were virtualized as far back as the 1970s with LPARs. Server virtualization hit mainstream in the data center when VMware began effectively partitioning clock cycles on x86 hardware allowing virtualization to move from big iron to commodity servers. 

This post is the next segment of my Data Center 101 series and will focus on server virtualization, specifically virtualizing x86/x64 server architectures.  If you’re not familiar with the basics of server hardware take a look at ‘Data Center 101: Server Architecture’ (http://www.definethecloud.net/?p=376) before diving in here.

What is server virtualization:

Server virtualization is the ability to take a single physical server system and carve it up like a pie (mmmm pie) into multiple virtual hardware subsets. 

imageEach Virtual Machine (VM) once created, or carved out, will operate in a similar fashion to an independent physical server.  Typically each VM is provided with a set of virtual hardware which an operating system and set of applications can be installed on as if it were a physical server.

Why virtualize servers:

Virtualization has several benefits when done correctly:

How does virtualization work?

Typically within an enterprise data center servers are virtualized using a bare metal installed hypervisor.  This is a virtualization operating system that installs directly on the server without the need for a supporting operating system.  In this model the hypervisor is the operating system and the virtual machine is the application. 

image

Each virtual machine is presented a set of virtual hardware upon which an operating system can be installed.  The fact that the hardware is virtual is transparent to the operating system.  The key components of a physical server that are virtualized are:

image

At a very basic level memory and disk capacity, I/O bandwidth, and CPU cycles are shared amongst each virtual machine.  This allows multiple virtual servers to utilize a single physical servers capacity while maintaining a traditional OS to application relationship.  The reason this does such a good job of increasing utilization is that your spreading several applications across one set of hardware.  Applications typically peak at different times allowing for a more constant state of utilization.

For example imagine an email server, typically an email server is going to peak at 9am, possibly again after lunch, and once more before quitting time.  The rest of the day it’s greatly underutilized (that’s why marketing email is typically sent late at night.)  Now picture a traditional backup server, these historically run at night when other servers are idle to prevent performance degradation.  In a physical model each of these servers would have been architected for peak capacity to support the max load, but most of the day they would be underutilized.  In a virtual model they can both be run on the same physical server and compliment one another due to varying peak times.

Another example of the uses of virtualization is hardware refresh.  DHCP servers are a great example, they provide an automatic IP addressing system by leasing IP addresses to requesting hosts, these leases are typically held for 30 days.  DHCP is not an intensive workload.  In a physical server environment it wouldn’t be uncommon to have two or more physical DHCP servers for redundancy.  Because of the light workload these servers would be using minimal hardware, for instance:

If this physical server were 3-5 years old replacement parts and service contracts would be hard to come by, additionally because of hardware advancements the server may be more expensive to keep then to replace.  When looking for a refresh for this server, the same hardware would not be available today, a typical minimal server today would be:

The application requirements haven’t changed but hardware has moved on.  Therefore refreshing the same DHCP server with new hardware results in even greater underutilization than before.  Virtualization solves this by placing the same DHCP server on a virtualized host and tuning the hardware to the application requirements while sharing the resources with other applications.

Summary:

Server virtualization has a great deal of benefits in the data center and as such companies are adopting more and more virtualization every day.  The overall reduction in overhead costs such as power, cooling, and space coupled with the increased hardware utilization make virtualization a no-brainer for most workloads.  Depending on the virtualization platform that’s chosen there are additional benefits of increased uptime, distributed resource utilization, increased manageability.

Related posts:

  1. Have We Taken Data Redundancy too Far?
  2. Data Center Bridging
  3. The Organizational Challenge
  4. What Network Virtualization Isn’t
  5. The Data Center Network OS – Cisco Open NXOS