Last week in my TechRepublic IT Leadership column, I wrote about a brewing IT alignment issue rising in the form of the Cisco/VMware/EMC-provided Vblock product. I, along with a number of storage and virtualization experts, attended a session at a Cisco office describing Vblocks, which are marketed as units of IT infrastructure consisting of servers, storage network gear, management software, and storage equipment. In this column, I will focus on the underlying product.
VMware, EMC, and Cisco have joined forces and created what they call the Virtual Computing Environment (VCE) coalition. This coalition brings together an array of products from each company that are packaged together and sold and supported as a single product called a Vblock. The coalition considers a Vblock to be an IT-as-a-service offering that is billed as a unit of overall infrastructure.
Vblock support is about as simple as things can get. Although Vblocks are comprised of products from three companies, organizations needing support for any part of a purchased Vblock have a single point of contact for all support issues, making the overall architectural seamless from a technical and from a support perspective.
The coalition is pretty strict when it comes to defining what is and is not a Vblock. In short, a Vblock is an engineered, tested, and validated unit of IT infrastructure that is guaranteed to perform at a defined level. The VCE coalition created Vblocks to meet the needs of large organizations that want guaranteed levels of infrastructure performance without having to hire an army of people to tune and optimize the environment.The coalition provides two Vblock products. Aptly named Vblock 1 and Vblock 2, each Vblock is engineered to provide vastly different performance levels, but only an environment that stays within the Vblock predefined parameters can call itself a Vblock and enjoy Vblock unified support. Note: While Vblock's are strictly engineered, each Vblock provides a range of horsepower from which to choose through the proscription of minimum and maximum resource levels for each Vblock component.
In many cases, organizations will not need the massive level of capability offered by a Vblock; in these cases, an organization is free to build out an environment using individual components. But if that environment does not fall within a Vblock's minimum and maximum requirements, the purchasing organization will not enjoy the same benefits as organizations that stay within the Vblock guidelines. In short, that company will have to call individual vendors when particular parts fail. If storage becomes an issue, a phone call to EMC is necessary. If a server fails, contacting Cisco is necessary, and so on.
Vblocks are made up of a number of architectural components, which include:
- Management software. Vblocks come standard with an array of software intended to manage the infrastructure; at the core sits VMware's vCenter.
- Compute components. Think servers and their associated hardware here. Vblocks are based on Cisco's Unified Computing System B-200 servers, which reside in Cisco UCS 5108 blade chassis. Vblocks range from two to eight fully populated UCS 5018 chassis. In this tier also resides VMware vSphere Enterprise Plus software, a required vBlock component. (Only Enterprise Plus is supported; if you opt to use another edition of vSphere, the solution cannot be considered a Vblock.)
- Networking components. The Vblock solution's only real networking component comes in the form of the Cisco Nexus 1000V virtual switch, which is available as an addon for VMware vSphere Enterprise Plus.
- Storage-focused networking components. At this layer sit the Cisco MDS-based storage networking components.
- Storage devices. Depending on the Vblock selected, storage consists of either an EMC Clariion CX4-480 or an EMC Symmetrix V-Max storage solution.
High-level overview of Vblock. (Click the image to enlarge.)
As you can see from Table A, Vblocks have minimum and maximum configuration scenarios. Outside the minimum and maximum bounds, the solution is not a Vblock. There is, however, some wiggle room within each Vblock type. In a Vblock 1, for example, the base solution does not include any local storage on individual servers; all servers boot from the SAN. If you find that you need some local storage for vSphere local paging, you can add a SATA disk, and the solution will still be considered a Vblock. If, however, you decide you need only 8 servers rather than the 16 server minimum for a Vblock 1, you can't call your implementation a Vblock even if everything else is identical, nor can you call a single phone number for support. Moreover, if you decide to use the locally installed disk for something else, such as operating system storage rather than vSphere local paging, this, too, is considered a custom implementation and is not a Vblock.
You'll also notice that Vblock are rather large units of IT infrastructure. Vblock 1 is currently the smallest available Vblock, and it starts at a minimum of 16 servers with 128 processing cores and 38TB of storage per Vblock unit; this puts the use of a Vblock out of reach for all but the largest of customers. This is not an unintentional path for the coalition.
Vblocks are intended to leverage economies that come with implementation of larger-scale infrastructures and to do so in a way that is supportable and repeatable. As such, the coalition has focused their initial efforts on cloud providers and other very large organizations. I imagine that this is also a way for the coalition to control uptake on the solution, while they make sure that their technical resources are in place to handle the unified support promise inherent in the Vblock support arrangement.
The coalition has not completely abandoned smaller organizations. Engineers at VMware, Cisco, and EMC are working hard on what they're currently calling Vblock 0, which will be the next step down in the Vblock capacity chain and the next step forward in the coalition's expansion strategy. There are not a ton of details yet regarding Vblock 0, but as they are made available, I will share them.
The simple answer
For organizations that have a need to simply roll out new infrastructure to meet an immediate demand, Vblocks certainly raise some compelling possibilities. Under a traditional infrastructure acquisition model, an organization would need to spend precious time on a number of steps, including:
- Sizing each infrastructure component.
- Ordering each component.
- Installing each component.
- Initially configuring each component.
- Optimizing each component to meet performance needs.
- Following up with individual vendors for each incident.
Vblock's primary value proposition lies in the elimination of a lot of the complexity that goes into procuring traditional infrastructure. Sure, organizations will still need to size a Vblock to meet performance and other requirements, but the environment will arrive as a "single unit" and be ready to go on day one. Long-term support needs are met with a single phone call regardless of which component fails. There is a beauty in this simplicity, as it enables organizations that have immediate large-scale needs to get underway much more quickly, which could provide a significant competitive advantage by reducing go-to-market timeframes.
I heard someone compare a Vblock to a home-theatre-in-a-box setup that you'd find at Best Buy. While the average consumer could spend countless hours buying just the right receiver, speakers, and BluRay player, the "all in one" option takes the complexity away and allows the consumer to go home and start enjoying the new hardware right away. Better yet, that consumer doesn't have to go home and try to figure out how to make it all work together.
I find the Vblock concept fascinating, and I will find it even more useful as the coalition scales the solution down for smaller organizations. Rather than constantly tweaking the infrastructure, I can simply buy a pre-defined infrastructure unit that has well-known and well-tested performance characteristics and focus my efforts on providing solutions that directly benefit the business.
For more details, you can download a complete guide to Vblock architecture.
Want to keep up with Scott Lowe's posts on TechRepublic?
Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive with CampusWorks, Inc. Scott is available for consulting, writing, and speaking engagements and can be reached at firstname.lastname@example.org.