Overview

Currently, enterprises adopt horizontal standardization, deploying common technologies at the storage and network layers. Storage offers block, file, and object access over a standard physical driver layer. Networks offer standard Ethernet- and IP-based physical drivers to the physical platforms.

The cloud changes this model by introducing a new virtual to physical layer into the IO layer; this adds complexity and obscures the underlying shared services, but delivers application mobility. In much the same way that (to date) enterprises have adopted a multi-vendor approach to operating system and hardware selection in order to provide support for their mix of legacy and best of breed application portfolio, today’s cloud-enabled enterprise is just as likely to need to support multiple hypervisors. This has significant implications for the selection and configuration of shared service layers.

The Changing Landscape

Legacy Windows platforms have been consolidated onto VMware farms for many years now as enterprises try to regain control over the server sprawl they built up over the last decade. VMware has been successfully deployed as an after-market fix that has enabled enterprises to execute on a physical to virtual consolidation without making code or environmental changes to their applications.

The next wave of virtualization is now starting, with new applications developed from the outset to support virtualization. This new world offers significant additional benefits to the consolidated/virtualized farms of today. IT will be able to migrate certain applications, live, between servers and within a data center without user impact. This offers the prospect of compute on demand with dynamic provisioning, improved availability (migrate on failure), and greater operational flexibility.

Key Technologies

The key virtualization technology here is the hypervisor and there are a number of competing platforms.

• VMware ESX
• Citrix Xen
• Red Hat KVM
• Microsoft Hyper-v
• Virtual Desktop Infrastructure (VDI) – [Xen, Hyper-v, or VMware]

Technology Diversity

From an end-user perspective, there are four conflicting drivers for the choice of hypervisor technology.

• Oracle VM (which uses Xen) is the recommended and fully supported virtualization platform for the 4,000 Oracle applications on the market and is likely to receive significant support from CIOs.
• Hyper-v is the recommended and fully supported virtualization platform for Windows platforms and services from Microsoft.
• VDI often leverages Citrix Xen, but can also use Hyper-v or VMware at the discretion of the integrator.
• VMware has a large install base of consolidated platforms.

Adoption of a single hypervisor is becoming an increasingly unlikely prospect for the enterprise, so developing a strategy and technology set that will fully support disparate hypervisors across the shared services layers of network and storage is essential.

What Are We Trying to Achieve?

Given that we must support multiple physical platforms and hypervisors simultaneously, we need to determine at the outset what is desirable and what is essential in our cloudscape.

Desirable. It might be desirable to transparently migrate applications between hypervisors (inter-hypervisor), but this is unlikely to be an immediate and essential requirement even if it were possible to achieve at present.

Essential. It is certainly essential to be able to migrate applications within a hypervisor environment (intra-hypervisor) as this enables load sharing and operational flexibility as well as an opportunity to improve availability and business continuity. Today, this is possible (with varying degrees of sophistication depending on the hypervisor), but it is dependent on fully functional virtual IO capability at the storage and network layers.

What Do We Need at the Network Layer?

Modern network ports are configured with more than MAC and IP addresses. It is common to configure QoS (quality of service), VLAN, and ACL parameters; these switch configuration parameters must be maintained as applications are migrated from one physical server to another server connected to a different switch port.

Uniquely, Blade Network Technologies provides support for all of the important hypervisor technologies, including VMware VMotion, Xen XenMotion, and Microsoft Hyper-v Live Migration. Its VMready is switch-resident software that provides the ability to transparently migrate a virtualized machine from one physical server to another whilst maintaining all of the essential quality, connectivity, and security settings.

In fact, VMready delivers against the desirable and essential network layer requirements for live virtual machine migration, both intra-hypervisor and inter-hypervisor. All that’s needed is to have the hypervisor capability in place to make live inter-hypervisor migrations a reality.

What Do We Need at the Storage Layer?

At the storage layer, SAN addresses (also known as WWN – World Wide Number) are virtualized across all major hypervisor platforms using N_Port ID Virtualization (NPIV). NPIV enables a single physical host bus adapter (HBA) to log in to a switch multiple times. The hypervisor then manages the connections between virtual HBAs in the guest operating system and these virtual NPIVs.

The benefit of this standards-based approach is that zoning, LUN masking, and QoS  are all based on the WWN so as long as the guest operating system maintains the same WWN migration between physical servers. The key is that all HBAs and all SAN switches must support NPIV; SAN controllers however, treat NPIV-created WWNs transparently. The hypervisor must also be NPIV-aware so that it can manage the virtual fabric ports. In the case of VMware, it is important to recognize that RDMs should be used in preference to the VMFS file system so that LUN masking, zoning, and QoS functionality can be related to specific VMs rather than to all VMs in a cluster. In addition to mitigating the security complications and risk that can arise from a configuration error if all VMs in the cluster share the same storage, VM-related storage frees storage/VM pairs from being restricted to a pool of clustered storage, all having to share the same values.

Analysis

It is likely that enterprises will choose to support multiple hypervisors within their private clouds and perhaps others in the public cloud, posing support and integration problems. How are we to deliver compatibility between multiple hypervisors and an existing legacy physical estate whilst maintaining our horizontal standardization in the storage and network layers?

Network layer virtual machine migrations are not just about moving IP and MAC addresses; they are much more significant and complex. The network switch needs to be included in the migration—unless you are interested in running in lowest common denominator mode with no QoS, VLAN, or ACL parameters.

Choosing the right open technologies and the best fit configuration options will enable enterprises to leverage shared services layers across multiple hypervisors.

The Bigger Truth

The second wave of virtualization is starting. It is essential that organizations select technology directions at the shared services layer that are open enough to support live VM migration. Blade Network Technologies, through VMready, has recognized that the point of network connectivity is now the application and not a MAC or IP address. By taking this approach, Blade Network Technologies has been able to deliver a flexible and universally applicable solution for highly virtualized multi-vendor platforms.