virtualization.info

Following on from my first article, Designing the Virtual Data Center - Part 1 which covered the importance of exploring converged networks as the fabric for the virtual infrastructure (VI), Part 2 will focus on the actual building blocks of the virtual infrastructure with an emphasis on the datacenter of 2010.

With the release of Cisco Unified Computing System (UCS) and now Virtual Computing Environment (VCE) coalition vBlocks, many people are starting to question the physical foundation for their virtual infrastructure (VI). It is accepted that the cornerstone of a VI is a highly available server farm connected to a resilient storage environment. The server and storage vendors are often different as decisions are made based on performance, purse strings and relationships.  The capstone of a VI, when present, is the logic and advanced orchestration that unleashes a solution’s true potential; most solutions today lack this level of maturation.

The conventional method of building a VI involves deciding between blade (e.g. HP C-Class) and typical rackmount (e.g. Dell R-Series) servers. From that decision, the processor vendor may come into play, but often this piece is not deeply analyzed.  Historically, processor decisions have been based on a pre-existing preference, price or general availability.  Since the release of the Intel 55xx series CPU (codename Nehalem), my experience is that customers are specifically requesting this chipset.  Other server components, such as the number of network interface cards (NICs) and host bus adapters (HBAs) are also analyzed based on existing network and storage design.

The complex nature of building out a VI has often had people with strong administration skills trying fill the role of a high-level architect, which can yield less than ideal results. Now that virtualization has become an accepted technology in many datacenters, people supporting the VI can be extremely talented administrators (capable of scripting en masse commands, advanced troubleshooting, etc.) but may ultimately lack the full breadth of experience to make them capable of piecing together the many physical components of a fine-tuned VI.

Single points of failure can run rampant in such organizations, where a VI admin may not understand the many failure points that exist in the overall infrastructure. Furthermore, security can become an issue as administrators use an allow-first/deny-later policy, so they can get their VI running. Compliance is often another piece that is overlooked by an admin-cum-architect.

However, assembling a bespoke physical infrastructure does have the potential for greatest flexibility for a custom-tailored solution that aligns fully with the business needs. It’s a case of form following function, as the functionality needs are defined and then the necessary hardware pieces are determined. With a pre-canned hardware stack the customer must adopt their needs to the functionality of that particular stack.

With complete control over the physical components, strategic solutions such as tiered storage become easier to implement. Some large customers must retain two vendors to provide datacenter components (e.g. servers), so that should one vendor have a supply chain issue, hardware can still be procured.

Pros:

• Hardware is determined based on business needs
• Greatest flexibility of vendors and overall technologies
• More nimble and able to use new technology quicker

Cons:

• Many organizations lack the skills necessary to build a proper VI
• The end solution may not be complete, lacking security and scalability
• (potential) Single points of failure
• Integration of business processes and intelligent automation is often an afterthought, if thought of at all
• Often lacking a unified fabric which allows I/O flexibility

So is a custom-tailored solution the way to go?

For organizations building out mega-scale datacenters (or private clouds), it may be easier to buy and assemble compute blocks that have been fully vetted by a small army of engineers; enter VMware-Cisco-EMC (aka the VCE coalition). VCE vBlocks will be sold by the newly formed company, Acadia.
As speculated on virtualization.info, HP is also likely looking to enter the virtual building block space with a (potentially) polished HP Matrix solution. And Dell partnered with Xsigo back in February of this year to provide Dell PowerEdge servers with a converged network adapter.
It’s important to note that converged networks are one of the important components of the building block approach. However, security, management and orchestration are also key ingredients.

Shining the light on vBlock, which seems to have the greatest exposure at the moment, we find that an enterprise-grade vBlock consists of:

• Cisco UCS B-series blades
• Cisco 5100 series blade chassis
• Cisco UCS 2100-series Fabric Extender
• Cisco UCS 6100-series Fabric Interconnect
• Cisco Nexus 1000V
• EMC CLARiiON CX-4 or EMC Symmetrix V-Max
• Security by RSA (one of the other EMC subsidiaries)
• EMC Ionix Unified Infrastructure Manager (UIM)
• VMware vSphere 4.0 (Enterprise Plus license)

The primary difference between Cisco UCS and a VCE vBlock is that in a vBlock, the storage (EMC) has already been determined. With Cisco UCS, a customer can connect to their storage vendor of choice.

In the building block, or, plug&play approach, the component-level thinking has been removed from the equation. This allows the organization to focus on integrating their business processes and mission into the rules driving the automation and management engine. Many organizations are trying to incorporate business processes into a virtual infrastructure after the fact; the same can be said for enterprise management of the VI as well.

Pros:

• Fully vetted solution with no single points of failure
• Design offers great scalability
• Allows an organization to spend resources on integrating the business processes and mission into the orchestration engine
• Places the emphasis on the applications hosted in the VI, which are often the revenue-generating pieces of an organization
• Can quickly align needs with resources due to the solution’s stateless nature

Cons:

• Vendor lock-in (especially with vBlocks)
• New skill sets required (e.g. EMC Ionix Unified Infrastructure Manager)
• Still a new and emerging concept

So is off-the-rack the way to go, then?

I believe the answer comes down to two variables: size and experience.

For organizations that have existing large-scale infrastructures, they are likely built upon pre-Nehalem processors, with a mix of Ethernet and Fibre Channel connectivity, thus contributing to network infrastructure sprawl. The advancements released this year move the ball forward and will likely start to be incorporated during refresh cycles and as new initiatives take place. In these environments, the massive scale is often used to support revenue-generating or mission-supporting applications (such as a financial transaction system or an advanced surveillance system), so the differentiator is not the supporting infrastructure, but what it supports. For true large-scale private clouds, the building block approach makes the most sense, as automation and the customer-facing experience are often paramount; thus allowing the organization to spend more time and resources on their differentiators and less time trying to build a recipe from scratch.

Experience is another deciding factor. Organizations who adopted virtualization years ago have likely sorted out pieces like compliance, management and monitoring, or have at least started the discussion. However, organizations new to virtualization, organizations that lack highly-skilled human capital, or organizations that have not matured their VI have a true benefit to the building block approach.

A side note about VDI

In the enterprise, VMware is clearly the incumbent hypervisor powering large-scale virtual infrastructures. This may benefit VMware in a minor way as VDI continues to gain traction. If an organization bases their datacenter on vBlocks, for example, they are committing to VMware for the hypervisor layer. This would make VMware View the default VDI solution for customers adopting building block technology. Certainly XenDesktop could live on top of a vBlock-based datacenter, but organizations looking to leverage an existing VI for their hosted desktops often use the solution provided by their hypervisor, simply from a cost perspective (e.g. VMware View on VMware vSphere 4 is typically cheaper than Citrix XenDesktop 4 on VMware vSphere4). While Cisco UCS and/or vBlocks will likely not run rampant in 2010, Cisco will certainly take a percentage of the market share in servers hosting VI. This could mean good news for VMware as VDI technologies and protocols continue to mature.