Real Fabrics for a Virtual World

Vendor marketing suggests that fabrics are almost the preferred guest infrastructure for cloud and virtualization deployments. Is this true, or can you look at a traditional rack and blade alternative? This session explores these issues and others, including best practices in consolidation, agility and sourcing for virtualization and cloud infrastructure.

The concept of "fabrics" has emerged over the past two years as a means to converge separate storage, networking and server technology in the data center. User interest and demand is partly fueled by vendor enthusiasm and partly by the growing number of workload scenarios, such as cloud computing and virtualization, that support this new way of buying and implementing technology. This association of the workload to a business function will change traditional IT from compute-centric toward a user, department, consumer and service orientation. Enterprises are increasingly seeing their performance and success in relation to user empowerment, innovation and productivity, with IT as the integral element of such success. Fabric lines up well with this shift, because it creates more opportunities for agility and adaptability, such that the user assumes a more active role in the tools and intelligence at its disposal. But many factors influence what "ideal" approach organizations should take when planning to implement a fabric-based infrastructure (FBI) policy. This presentation charts the likely evolution of the market for fabric-based infrastructures, to help IT leaders determine the most appropriate vendor approach.

Deploying traditional server, network and storage systems has been a labor of frustration. The life cycles and deployments were often one-off configurations that were glued to their specific application and departmental roles. Applications stayed rooted to the configuration that formed silos. Optimization was a guessing game of capacity planning, while the mobility of applications was a manually intensive process, when it was done at all. The new world of virtualization has forced greater attention to speeding the processes of deployment and using resources more efficiently. In effect, IT is demanding the end of hard and fixed intersections and boundaries. This "unified fabric" concept will take time to evolve through increased levels of automation, OS intelligence and management tools, but the evolution is well under way. As vendors jockey for market position, we expect many of the concepts will be haphazardly thrown into the propaganda mill, so users are advised to lay out prescribed tactical guidelines that match vendor claims to actual deliverables. Future systems will increasingly be based on a fabric-enabled mesh of components that can deliver vertical scaling attributes through aggregation to create logical systems, but are equally qualified to address the scale-out workloads that will become increasingly prevalent as application development evolves. All systems, including mainframes and Unix platforms, are evolving to incorporate parallelism, and the ability to support multiple operating environments and/or processor architectures.

An essential component in the definition of fabric will be the concept of the fabric resource pool manager (FRPM). The FRPM responds to requests for resources, and attempts to optimize resources along multiple dimensions, such as CPU, memory, input/output (I/O), energy, performance, etc. It assumes an OS role where the system is an aggregated pool of resources applied to a specific service deliverable. FRPMs may also be viewed as the framework to monitor and delegate resources in satisfying business consumption requirements delivered through a cloud infrastructure.

The building blocks of fabric-based computing will typically be packaged in high-density configurations (such as blades), but can also leverage more-conventional rack or tower designs. Much as blade computing is doing today, fabric-based computing architectures disaggregate traditional server designs into more granular components. Under a fabric architecture, processor, memory, network input/output (I/O) and storage I/O components can exist at different locations on the fabric, and these compute elements are assembled into logical servers. The fabric interconnects all internal communication, including processor-to-memory, processor-to-processor and memory-to-network communications. Speed and latency of the fabric are critical to the performance of the virtual servers. As a result, the boundaries between server, storage and networking technology become blurred, and ultimately irrelevant.

This is a subset of the results of live polls conducted at Gartner's Las Vegas Data Center Conference in December 2010. We asked what the principal drivers are behind fabric adoption. While vendor "push" is a factor in many instances, the past six months has seen other influences, like virtualization, cloud computing investment and infrastructure convergence, rise to prominence. When attendees were shown the degrees of verticalism (in a previous slide), most rejected the concept of too much verticalization – preferring instead to better leverage existing investments and to adopt a more vendor-neutral approach. However, highly integrated solutions will appeal to some end-user constituencies – such as new build situations and cloud service providers that want an infrastructure that will be dedicated to the task, and easier to meter or manage. We expect the dynamics in the decision process will be fluid and will vary by: (1) type of organization (Types A, B or C); (2) leadership, maturity and skills; (3) application sets and their "hospitability" to fabric; and (4) proven and compelling ROI.

Fabric adoption – especially at the early market stages – increases the probability of vendor lock-in and forces organizations to choose their fabric implementation paths wisely. This chart offers a means to determining how to map the vendor landscape, which is continuing to expand with more vendor participation. Most of the vendors can be differentiated from one another on an arc-spanning vertical integration to horizontal integration. Vertical integration is designed to deliver most of the components integrated and packaged – out of the box, so to speak. The other end of the arc is a best-of-breed approach – to buy and integrate components that are most compatible and synergistic to the IT organization's current infrastructure and evolution. Since fabric concepts are relatively new, all users should get familiar with the vendor approaches and solutions before embarking on a do-it-yourself approach. It's good for a reference comparison to calibrate how far from proven vendor solutions the IT organization is. There may also be some hybrid approach that mixes the current IT framework and technologies within a vendor-driven vertical approach. Some vendors may even allow for heterogeneous mixing and matching tools, and software management and resource components, while still retaining account management to glue the parts together. This approach might enable a stepwise, incremental evolution that would be precluded by a vendor-block approach of prefabricated SKUs, such as parts of VCE/Cisco and HP deliverables, or even the highly verticalized approach of an integrated stack appliance, such as Oracle's Exadata.

While x86 server virtualization may seem to have been done by all, it has not. It is still being done – and there is a lot more to do. We believe that, today, 30% to 40% of workloads are in a VM, and that this will double in five years to 60% to 80%. Clients must plan for and manage this growth. Clients must undertake a workload approach to the portfolio. Not all workloads have the same cost of virtualization. The more you virtualize, the more the cost of each workload to virtualize increases. This cost per VM is dependent on "what not to virtualize." Start with a simple standard distribution curve. This can be split into straight thirds – easy, medium and hard to virtualize workloads – and be overlaid onto the exponential cost per VM. If we say that 33% of workloads are virtualized today, then we can observe that these workloads are the low-hanging fruit and are easy to virtualize. Costs are also fairly predictable with this level of virtualization penetration. At 50% virtualized workload adoption, we see a tipping point. From that point, every additional workload that is virtualized should see an increase in cost, but at this point, the costs are contained. So, today, we can safely say that we can virtualize 50% to 66% of workloads with an acceptable degree of cost and investment. These workloads and projects should be consolidated and rationalized accordingly over one to two years. Focus should be given to projects that are close to the boundaries, and either reset the SLA/price (i.e., move the projects to the easier third of workloads), or simply wait until skills and technology mature. While vendors claim 100% virtualization, they need to "get real," because the last third of workloads and projects (66% or more) requires a complementary strategy.

Fabrics and blades offer and enable many of the benefits of virtualization and cloud. This relationship is so tight that it is often difficult to assess the benefits of a virtualized private cloud fabric individually, and assess whether the benefits derive from virtualization, fabrics and blades, or from private cloud initiatives – especially if all three are introduced at once for either new projects or a refresh. Much of the benefit is delivered simply because clients get a better handle on the management of systems and unravel their server DNA. This is the first part of any consolidation process, whether systems are to be virtualized or not for consolidation. Grouping workloads, by size, complexity or style, becomes the next part for logical consolidation. This in itself helps standardize deployments and indeed helps in understanding what needs to be rationalized. Logical consolidation can take place with grouped workloads to common racks, blades fabrics or VMs. The main efficiency gain of these approaches are workload management and SLAs that are delivered through improved operational expense (opex), which often outweighs the initial capital expense (capex) required.

Virtualization focuses these consolidation efforts around infrastructure and operations. However, virtualization also has the ability to increase the individual SLA through better migration, agility and portability of the VM. Consolidation alone is an "all eggs in one basket" model and creates a single point of failure. This leads to many vendors selling HA and DR systems to improve the SLA of the basket. Virtualization and associated practices (live migration, site recovery) help reduce planned and unplanned downtime, which, in turn, allows the VM software to offer the agility required for SLA requirement, not the hardware or OS. However, part of this virtualization drive leads to a conundrum. Today, can you virtualize 100% of the portfolio of applications, like the virtualization vendors may suggest? Or should you aim to virtualize 50% to 80% as a ceiling for now? Depending on physical issues and requirements, transactional and I/O concerns and commercial issues, this may not get to 100% over a three- to five-year period (see "Virtualization Reality," G00205779). Therefore, how you manage virtual workloads and their hosts, as well as physical servers, becomes key.

Today's 40% virtualized results in some interesting metrics. At a 10:1 reduction of VMs per server, 40 workloads out of 100 are pooled and virtualized onto four hosts, which may then have some level of live migration or portability. This requires, in total, four VMs and two live migration hosts, and leaves 60 physical workloads on servers. So, while 60% of workloads are physical, 90% of servers are physical. Gartner recommends the doubling of the average virtualization from 40% to 80%. But this can take one to five years, depending on portfolio size and virtualization efforts. Even at 80 virtualized workloads, 20% of workloads remain physical, but 65% of servers are physical hosts. This gets to 50:50 at 90% virtualized. One way of helping reduce these burdens and ratios is to rationalize between 5% to 10% of workloads, retiring them as necessary and fencing off the rest. So the more you virtualize, the more you intensify the headache of the physical server pool and what is not virtualized. These workloads are good candidates for private or hybrid cloud, and should be treated in a similar fashion to selective outsourcing. Virtualization is a key program to enable the private cloud, but also look at sourcing options for what is left.

Plan for the day – and that day is imminent – when you need to support operating environments from multiple vendors. Hardware vendors, operating system vendors, virtualization vendors, and many other tool and application vendors are vying for the account influence that is achieved through the "single pane of glass." There are always good reasons to justify vendor intent – for example, cost, operating richness, vendor support – but be aware that this will add to overall operational and management complexity. Be sure to think about your management structure – what tools you will use, and at what "level." For example, you may have a provisioning process that is instantiated within a tool that is provided by the virtualization platform provider. Or, you may wish to leverage your enterprise management tool, but this approach has further options. A multivendor approach will likely require more integration work – for example, defining the integration mechanisms themselves. The key is to plan ahead (which will help you assess the best management approach), should you need to consider a multivendor management strategy.

This slide shows the x86 server shipments in 2010 by vendor. Overlaid on this is the adoption of the vendors' management tools, which varies from 25% to 75% for racks, and is around 90% to 95% for blades. The red "nontooled" portion is for potential competitive displacements for consolidation and virtualization initiatives. Here, the benefits of management can be realized not just for the platform, but also for the virtualization and OS tools associated with the project. The blue "tooled" portion is a different story. First, these have been logically consolidated with common platform management tools. Therefore, these benefits cannot be realized again to the same level by introducing new tools for virtualization or workload management. Indeed, there may be complementary toolsets and gains, but this will not be as dramatic when compounded with platform tools. These workloads do, however, benefit from better virtualization agility and private cloud capabilities. Racks that are well-managed and that provision virtualization and private cloud workloads are very difficult to separate from the benefits of blades and fabrics. Indeed, vendor marketing may be the only difference when positioning blades, fabrics and modular servers with racks. If all are managed, they can provide virtualization agility and private cloud infrastructure.

Taking the same 2010 server split, we now drill down to just blade servers, which, to date, encompasses any fabric sales, because fabrics are not yet a separate market. Blades have a tooled attach rate of up to 90% by vendor. Therefore, the stickiness of the vendor and platform or lock-in is higher than that of regular racks. Although this stickiness of Racks with tools also increases! With this high adoption the consolidation benefits of blades has already been realized. Although they do benefit from increased agility with live migration and other virtualization tools for recovery. Blades (and fabrics) are also great candidates for private cloud infrastructure, offering abstraction and separation, agility, flexibility and management. Also with increased core count and memory density, with sufficient virtual I/O blade sand fabrics can offer higher increases in SLAs for private cloud infrastructure, as well as management efficiencies.

Consequently, we believe that the use of fabrics within the data center will steadily expand over the coming years, but fabrics will not be an overnight success story, and many data centers will need significant political and cultural upheaval to benefit fully from the trend. As it becomes ever more difficult to judge the boundaries of fabric computing, this prediction could even be too conservative. For instance, all blade server platforms deploy a form of simple fabric to enable the common backplane/midplane and enable capabilities, such as virtual I/O. With blade adoption now pushing 20% of total server spending, the 30% target may be achieved purely through blade market expansion. And most fabric solutions are likely to be based on blade infrastructure anyway, as modularity and common components are key attributes of a converged infrastructure approach. What is highly likely is that growth of fabric adoption will closely follow the more mature market trend of virtualization. Many organizations are already gravitating toward fabrics as they start to hit barriers in which increased virtualization deployment becomes impractical due to hardware constraints. And as cloud infrastructure – both public and private – becomes more prevalent, this too will naturally favor a fabric-based approach.