Introduction to Virtualization

(1)

Introduction to Virtualization

q

_{OPTIMIZING SERVER}

VIRTUALIZATION

q

_{MAKING VIRTUAL}

INFRASTRUC-TURES HIGHLY AVAILABLE

q

_{STORAGE IN THE}

VIRTUALIZED WORLD

q

_{HYPERVISORS: AT}

(2)

OPTIMIZING SERVER VIRTUALIZATION MAKING VIRTUAL INFRASTRUCTURES HIGHLY AVAILABLE STORAGE IN THE VIRTUALIZED WORLD HYPERVISORS: AT VIRTUALIZATION’S CORE

Optimizing Server Virtualization

Factoring server management and performance into consolidation

projects can help optimize virtual server deployments.

consolidation is easy. Making it work correctly can be a challenge. Optimizing virtual server consolidation should start with a careful look at virtualization benefits as well as tradeoffs. One immediate benefit is the use of fewer physical servers, which reduces capital hardware costs and space requirements in the data center. It can also lower collateral energy costs for power and cooling.

There is often a compelling return on investment argument with these fac-tors alone, but because there are fewer hardware devices that could fail, that saves maintenance costs as well. Fewer physical servers also mean fewer costly annual service contracts to pay.

Older servers displaced in a technology refresh can be reallocated to other less critical tasks, extending the hardware’s useful life. Fewer physical servers make it easier to standardize on management tools. These benefits, together with the tools used for virtual machine (VM) management, can make data cen-ters easier to manage with fewer personnel. Consolidation can also mitigate the need to add staff as a data center grows.

Perhaps the most overlooked and often understated benefit of server virtual-ization is enhanced flexibility. A VM is basically a file that can be moved and copied between servers and storage systems. An administrator can create and configure a new VM from a basic “image” in minutes. Similarly, a working VM can be migrated to a faster, more powerful server or copied to backup storage at a disaster recovery (DR) site without disrupting the machine or its users.

One of the most obvious risks with server virtualization is hardware failure. In a traditional environment, a server fault would affect only the application and users running on that physical server. In a virtual environment, however, a server failure can disable all VMs that reside on it.

OPTIMIZING SERVER VIRTUALIZATION

(3)

Although techniques like server clustering help maintain high availability (HA), the practices are usually reserved for mission-critical VMs and often leave secondary VMs on a single server. Consequently, administrators must track VM distribution across the enterprise to ensure that important VMs are running on adequate HA hardware. It’s equally important to arrange backup cycles that meet the recovery point objective and recovery time objective for each VM.

A proliferation of VMs also affects server virtualization. Just as conventional data centers faced the problem of server sprawl, the ease and speed of creating new VMs can precipitate worse conditions as administrators quickly deploy a new virtual machine for each new application or task.

VM sprawl can easily lead to software licensing violations and can further complicate maintenance because there is no direct link between an application’s VM and the underlying physical server. Although this abstraction is a desirable feature of virtualization, it can have undesirable consequences for careless ad-ministrators.

A final issue that often goes unnoticed is VM assignment. Although a virtual machine should function on any suitable piece of hardware, it might not be pru-dent to combine certain VMs—depending on their resource demands. “Server consolidation isn’t a good solution for all applications,” said Rand Morimoto, president of Convergent Computing, a solution provider headquartered in Oak-land, Calif. Demanding database applications can be problematic when virtual-ized and may cause performance problems when consolidated with other VMs on the same server, Morimoto said.

ELEMENTS OF PRACTICAL SERVER CONSOLIDATION

The basic premise of server consolidation is to leverage unused computing power. For example, instead of operating 10 servers at 5% utilization, operate one server hosting those 10 VMs at 50% utilization.

The secret to successful server consolidation is to ensure that there are

OPTIMIZING SERVER VIRTUALIZATION MAKING VIRTUAL INFRASTRUCTURES HIGHLY AVAILABLE STORAGE IN THE VIRTUALIZED WORLD HYPERVISORS: AT VIRTUALIZATION’S CORE OPTIMIZING SERVER VIRTUALIZATION

(4)

adequate resources to support all VMs that will reside on the server. If the same 10 physical servers are running at an average of 15% utilization, those virtual-ized workloads must be spread across two or more physical servers.

If they’re not, then the performance of those VMs—and the corresponding user experience—will suffer. Prior to consolidation, each workload must be evaluated to ensure that it meets CPU, memory, I/O, storage and network con-nectivity—or bandwidth—requirements. Those factors are then combined to yield the total approximate needs for the virtualized server.

There is no single recipe for sizing a physical server, and there are countless possible exceptions. When calculating memory requirements, for example, you don’t need to add up all requirements for every operating system because the virtualized server will use only one OS. Similarly, you can get by with half of a CPU for every workload.

As a rule, no more than two VMs per CPU should be used. A single network interface card may supply enough bandwidth for several workloads. Generally, it depends on the criticality of the applications you plan to consolidate.

Server consolidation must make sense. There’s no point in trying to over-reduce the number of physical servers just to do it. There is nothing wrong with virtualizing a single application on a single server and forgoing consolidation, instead focusing on migration and other benefits that virtualization offers.

Storage is one resource area that is frequently overlooked. Using a single huge disk drive on a virtualized machine isn’t an option. Storage I/O demands from multiple VMs can seriously compromise performance. Instead, use a striped RAID array or a basic storage area network (SAN) with a separate LUN for each VM.

DETERMINING AND TRACKING YOUR VM NEEDS

The actual number of VMs that can be hosted on a single physical server is largely subjective. In most cases, practical resource limitations of the physical server—available CPU, RAM and other computing resources—will halt VM

(5)

growth long before any hard limits of the virtualization platform are reached. But this is also governed by the complexity and requirements of the VMs.

Backup needs can greatly limit the number of virtual machines on a single server. VMs must still be protected, and traditional backups are notoriously I/O-intensive. Backing up multiple VMs simultaneously can cripple a virtual server and frequently drives other business decisions.

“You need to start thinking about changing the way you do things,” said Pierre Dorion, data center practice director at Long View Systems, an IT solu-tions and services company headquartered in Denver. For example, traditional backups may be phased out in favor of VM migration tools, such as VMware Inc.’s VMotion.

One way to determine and track resource needs is to gather data using per-formance and capacity planning tools, such as IBM’s Tivoli Monitoring Express and HP's Diagnostics Software, and virtualization tools such as VMware’s Ca-pacity Planner. Microsoft’s Assessment and Planning Toolkit can help adminis-trators assess their infrastructures and recommend a variety of projects. It’s important to collect data over time and during peak use times.

Finally, address the issue of VM assignments—putting the right VMs on the right physical servers. Just because a server can be virtualized doesn’t mean that it should be. Some applications, such as databases, can tax server resources and might run better if unconsolidated and kept as the only VM on a mission-critical server. Conversely, some applications that would not ordinarily coexist on the same physical server, such as SharePoint and Outlook Web Access, could easily reside on the same physical system in separate VMs.

Complementary applications that would typically communicate with one an-other across the network may actually perform better when virtualized along-side each other on the same server. This can eliminate the slower network link and allow applications to communicate internally across the server’s backplane.

It’s not enough to simply create new VMs and combine them based solely on available server resources. Admins must understand how VMs interoperate and use physical resources before allocating VMs throughout the enterprise. ■

(6)

Making Virtual Infrastructures

Highly Available

Protect production workloads by ensuring that virtual

machines and the applications they run are highly available.

using a high-availabilitystrategy provides a valid approach for VM fault tolerance. But it’s not always apparent which method is best for each situation.

Each host runs several production VMs. If that host fails and no HA solution exists, then each VM on that failed host will also fail. This is different when you run single workloads in individual physical machines. In a case like that, there is no reason why you can’t run a host-level cluster while running a guest-level HA solution such as failover clustering or network load balancing (NLB).

Use these concepts in concert with your organization’s existing service-level requirements to determine which level of HA you need to configure for each VM. You also must consider the support policy of the application you intend to run in the VM.

WORKING WITH SINGLE-SITE AND MULTI-SITE CLUSTERS

Single-site and multi-site clusters are available for host servers. Single-site clus-ters are based on shared storage in various forms. For example, VMware uses two key technologies for host clustering: HA and the Virtual Machine File Sys-tem (VMFS), which is a sharable file sysSys-tem that lets multiple host servers con-nect to the same storage container.

VMFS usually requires some form of SAN, network-attached storage (NAS) or an iSCSI storage target. VMware can also perform this via the Network File System (NFS), which enables small organizations to access HA configurations for host servers. The HA VMware component then manages potential host server failures. VMware host clusters can include up to 32 nodes.

Citrix XenServer can also rely on shared storage—usually in the form of NFS,

OPTIMIZING SERVER VIRTUALIZATION MAKING VIRTUAL INFRASTRUCTURES HIGHLY AVAILABLE STORAGE IN THE VIRTUALIZED WORLD HYPERVISORS: AT VIRTUALIZATION’S CORE MAKING VIRTUAL INFRASTRUCTURES HIGHLY AVAILABLE

(7)

NAS, SAN or even an iSCSI target to provide HA for host servers. In a Citrix host server environment, admins can create highly available configurations by building host server resource pools.

Although other hypervisors rely on management databases to control multi-host configurations, each Citrix XenServer multi-host stores its own copy of the re-source pool configuration data. This removes a potential single point of failure from resource pool configurations. Citrix resource pools can also include up to 32 host nodes.

Microsoft Hyper-V relies on Windows Server 2008 Failover Clustering to create host clusters. Single-site Hyper-V host clusters require shared storage in the form of SANs or iSCSI targets. No other storage format is supported.

Hyper-V single-site clusters can include up to 16 host nodes. It can also sup-port multi-site clusters, which span more than one site. Because of this, the Hyper-V multi-site cluster does not require shared storage and can rely on the much faster direct-attached storage (DAS) to operate. However, to provide VM high availability, these DAS repositories must be synchronized at all times with a third-party replication tool.

No matter which hypervisor you use, it’s best to create host clusters when possible to provide two different levels of service continuity:

1. Host clusters support continuous VM operation. If a host fails or indicates that it is failing, all VMs running on that host will be transferred automatically to another node on the cluster.

2. Host clusters support VM operation during maintenance. If you need to work on one cluster node to install software updates, you can move VMs off of the node during operation. Move VMs back to the node once the operation is complete. Repeat this process if other cluster nodes also require maintenance.

In either case, service will be interrupted while the VMs are being moved.

(8)

When the cluster detects that a node is failing, the cluster service causes VMs to fail over to another node. In this case, it will use a migration process to move the VM from one node to another. Depending on which hypervisor you use, this may cause a service interruption.

WORKING WITH GUEST FAILOVER CLUSTERING

Any VM can be made highly available when added as an application within a host cluster. But a VM is not like a traditional application. Even though the VM will always run—or run as much as possible—when operating on a host cluster, this model won’t apply to every workload in your production network. This is because host server clustering does not affect applications contained within the VM. These applications are not aware of the host’s HA feature—unlike applica-tions that are installed directly into a cluster through guest failover clustering.

Host server clustering does ensure that the VM will run if a host fails. This HA model works for most applications, even though they aren’t aware of it when transfers occur from one node to another. Some state-sensitive applica-tions, such as Microsoft Exchange, do not behave properly under this model and may lose data when a transfer occurs.

Transactional applications, especially those that support very high-speed transactions, do not work well with this model because they are designed to behave in a particular way when failover occurs. These applications cannot behave as planned when a VM has been failed over.

Because of this, admins should consider building highly available VMs— creating clusters within the VM layer—to produce application-aware clusters. These clusters ensure continuous availability and stability of the applications moved into the virtual layer of a resource pool. Failover clusters work only for stateful workloads or workloads that record data from user sessions.

Stateless workloads, or workloads that provide read-only services, can rely on NLB. Like failover clustering, NLB is an HA solution that’s fully supported in the virtual layer. To ensure the HA of stateful applications within virtual

(9)

workloads, most organizations opt to run single-site clusters. These clusters are often easiest to create in the virtual infrastructure and don’t require a replica-tion engine, which often must be procured from third-party sources.

WORKING WITH GUEST NLB CLUSTERS

Although NLB is an HA solution, it is different than failover clustering. In a failover cluster, only one node in the cluster runs a given service. When that node fails, the service is passed onto another node, which then becomes the owner of the service. This is because of the structure of the failover cluster model.

Because of this model, only one node can access a given storage volume at a time. Therefore, the clustered application can run only on a single node at one time.

In NLB or server load-balancing clusters, each member of the cluster offers the same service. Users are directed to a single IP address when connecting to a particular service. The NLB service then redirects users to the first available node in the cluster. Because each member in the cluster can provide the same services, they are usually in read-only mode and considered stateless.

NLB clusters are fully supported in VMs because the hypervisor network layer provides a full set of networking services, one of which is NLB redirec-tion. This means that admins can create a multi-node cluster—up to 32 NLB nodes—to provide HA for the stateless services available in production VMs. However, each computer participating in an NLB cluster should include at least two network adapters—one for management traffic and another for public traffic. This can be done in VMs by adding another virtual network adapter.

When you run production services in VMs, make sure that the configuration is supported. Otherwise, you may need to convert the VM into a physical ma-chine if issues arise. After that, obtain support from the vendor. Resource pool administrators should consider these configurations when preparing VMs.

Supported configurations run from standalone implementations on host failover clusters to HA configurations at the guest level. When configuring VMs, always keep a product’s licensing requirements in mind. ■

(10)

Storage in the Virtualized World

Storage virtualization can improve utilization rates,

keep resource costs low and boost network performance

for real-world and future applications.

the benefits ofvirtualization don’t end with consolidation. Although the ability to run multiple virtual workloads on the same physical hardware is essential for server virtualization, enterprise storage can also benefit from virtualization technologies. Storage virtualization offers the advantage of aggregation—allowing disparate or isolated storage resources to be pooled, provisioned and allocated regardless of their physical location within the enterprise.

Storage can be virtualized in a variety of ways to achieve a balance of per-formance, management efficiency and flexibility. Virtualization directly affects storage efficiency. As traditional (nonvirtualized) storage needs increase and storage systems proliferate across an enterprise, unused storage resources can be “orphaned” through overprovisioning or simple neglect. This waste often leads organizations to invest in additional storage sooner than necessary, re-sulting in higher costs.

Combining disparate sources reduces waste, improves utilization rates and stalls the costs of additional disk investments. For example, nonvirtualized storage use often peaks around 50%, while virtual storage utilization can fre-quently exceed 80%.

Overprovisioning is the act of assigning more storage space to an application than is necessary. The practice is meant to prevent the provisioned volume from running out of space—forcing administrators to provision new space and migrate the exhausted volume to a larger space. If the overprovisioned space goes unused, this practice can be extremely wasteful.

Virtualization can also improve storage management. Without virtualization,

OPTIMIZING SERVER VIRTUALIZATION MAKING VIRTUAL INFRASTRUCTURES HIGHLY AVAILABLE STORAGE IN THE VIRTUALIZED WORLD HYPERVISORS: AT VIRTUALIZATION’S CORE STORAGE IN THE VIRTUALIZED WORLD

(11)

each heterogeneous storage system must be managed through a console that’s unique to that particular storage system or manufacturer. Additionally, man-agement differences may exist between products from the same vendor. Each new storage platform introduces more management overhead that administra-tors must deal with.

STORAGE VIRTUALIZATION WOES

Storage virtualization has a number of potential drawbacks. One issue is that the abstraction layer alone introduces complexity. Just as the hypervisor in server virtualization obscures the relationship between physical servers and the VMs that run on them, storage virtualization also obfuscates the relation-ship between pooled storage and underlying disks or storage subsystems.

Virtual LUNs do not necessarily correlate to physical storage. This can com-plicate troubleshooting and problem resolution, especially as LUNs are mi-grated and copied between storage

systems.

This type of abstraction can also be a problem when storage virtualization is used temporarily. Most organizations approach storage virtualization as a per-manent technology, but it’s also possible for it to help with storage migration be-tween physical systems.

Using a number of diverse storage systems carries some amount of natural redundancy—a failure in one storage system may not affect the availability of other applications, data or VMs. But by aggregating storage through virtualiza-tion, a problem with one storage system can affect several other virtual LUNs.

In addition, organizations must be sensitive to vendor lock-in. Interoperabil-ity between storage virtualization products is often acceptable but not necessar-ily universal. An organization that is evaluating or selecting its storage

Each new storage

platform introduces

more management

overhead that

adminis-trators must deal with.

(12)

virtualization platform should consider interoperability across all of its storage systems as well as its compatibility with all its existing virtualization products.

PRACTICAL STORAGE VIRTUALIZATION METHODS

Ways to implement storage virtualization include software, appliances, switch-level and array-switch-level. Which method an organization chooses will depend on the barriers to entry such as cost and technical complexity, performance, flexi-bility, ease of use and interoperability with storage types and subsystems. Im-plementing storage virtualization via software, which deploys a third-party system, is often simpler and less expensive for smaller businesses.

But one or more additional storage vir-tualization servers must be deployed to support virtualization. Software interop-erability is also a common concern, partic-ularly when deployed in conjunction with high-end operating systems and hypervi-sors. Additionally, updates or changes to virtualization software must be thor-oughly tested before rolling them out to the entire enterprise.

An appliance-based approach, such as IBM’s SAN Volume Controller, features

dedicated servers that already contain the hardware and software needed to implement storage virtualization. Appliances usually cost a bit more, but they offer better performance compared to software.

There are also fewer risks during internal software revisions, and the appli-ance can typically handle heterogeneous storage. Virtualization can also be im-plemented at the SAN switch, possibly yielding the lowest latency and highest performance of any approach. The centralized nature of a storage switch lends itself well to centralized management.

Virtualization can

also be implemented

at the SAN switch,

possibly yielding the

lowest latency and

highest performance

of any approach.

(13)

Still, switch-level virtualization can be more expensive than other proaches, and the feature set may not be as rich. Storage virtualization can ap-pear as an integrated feature of the actual storage array too. Older systems on the market virtualized only internal storage, which provided excellent perform-ance but resisted heterogeneity and centralized management. Newer systems can include virtualization support for external storage, improving heterogene-ity and making the array appear more like an appliance.

WHICH METHOD IS BEST?

Choosing the most appropriate storage virtualization technique can present still another challenge. Both NAS and SAN storage can be virtualized. Choos-ing which one to use should depend on performance and ease of use. NAS is file-based storage that’s less expensive and easier for organizations to work with.

SAN is block-based storage that’s more expensive, but it provides better per-formance than NAS. Although both can be virtualized, many organizations opt to virtualize only the SAN storage, leaving NAS for secondary tasks like

archival storage or backup.

And although it is theoretically possible to combine NAS and SAN storage in the same pool, it’s certainly not recommended because of the disparity in stor-age device performance. You must be cognizant to the storstor-age access needs of each application. Furthermore, storage network architecture has little direct ef-fect on storage virtualization choices—it’s merely the plumbing that ties storage to applications.

Once again, cost and performance requirements should dictate choices. For example, Fibre Channel is the unquestioned leader in block-storage network-ing, but it’s also the most expensive and sophisticated technology. On the other hand, iSCSI has embraced 1 Gigabit Ethernet (GbE) and gained tremendous popularity in recent years.

Ethernet-based products are much less expensive than Fibre Channel. Plus,

(14)

they’re readily available, so management and maintenance are already under-stood. For many small and medium-sized companies that are considering stor-age virtualization, iSCSI is preferable.

Although Fibre Channel over Ethernet (FCoE) is still emerging, it promises another alternative that can handle high-performance Fibre Channel storage demands across standard Ethernet

net-works. Ultimately, all three network types should be equally suited to storage virtual-ization.

Although storage virtualization can pool storage and create LUNs from a potentially sizable pool, the OS that will access the LUN ultimately limits its size. However, huge virtual LUNs are not always the right choice. Experts are quick to point out that

large LUNs can cause traffic bottlenecks. Performance problems can occur when multiple VMs are located on the same LUN.

One way to maintain adequate performance is to configure and present smaller LUNs or otherwise limit the number of VMs placed on a single LUN. Large LUNs can also pose problems when restoring data to VMs.

During a rollback, all of the VMs on that LUN would need to be rolled back, potentially causing unexpected data loss. It also takes longer to restore the LUN on another machine in order to recover necessary pieces of lost or missing data. Smaller LUNs avoid this type of potential contention.

Administrators must be concerned with overall reliability and vulnerabilities found in single points of failure in any virtual storage infrastructure. Some high-availability storage may guard against trouble by implementing redun-dant storage arrays, but the added layer of protection may inflate costs and re-duce application storage performance. Look for quality-of-service features that allow storage performance to be optimized for certain applications or data types. ■ OPTIMIZING SERVER VIRTUALIZATION MAKING VIRTUAL INFRASTRUCTURES HIGHLY AVAILABLE STORAGE IN THE VIRTUALIZED WORLD HYPERVISORS: AT VIRTUALIZATION’S CORE STORAGE IN THE VIRTUALIZED WORLD

For many small

and medium-sized

companies that are

considering storage

virtualization,

(15)

Hypervisors: At Virtualization’s Core

No data center administrator should implement a virtual

environment without knowledge of hypervisor selection,

deployment and management.

virtualization technology thatrelies on a hypervisor—software that re-sides between the hardware and the operating system—opens the door to new levels of hardware consolidation and workload flexibility. But to take advantage of the benefits of virtualization, IT professionals must possess basic hypervisor knowledge and understand its implications.

Simply stated, a hypervisor creates a layer of abstraction that isolates an OS and its associated applications from the underlying computing hardware. This effectively mitigates software from its traditional reliance on hardware devices and their drivers. The implications of this behavior are profound.

A hypervisor allows operating systems and their application workloads to run on a broader array of hardware. Similarly, multiple OSes and workloads— each a unique virtual machine or VM instance—can reside on the same system to simultaneously share computing resources.

Each VM can be migrated between computing platforms on demand with lit-tle—if any—processing disruption. The result is better use of computing plat-forms with seamless workload migration and backup capabilities.

BARE METAL VS. HOSTED HYPERVISORS

Hypervisors generally fall into two categories: bare metal and hosted. A bare-metal (Type I) hypervisor, which is the most common type, installs directly onto the computing hardware. The OS installs and runs above the hypervisor. Major virtualization products can be called bare-metal hypervisors, including Oracle VM, VMware ESX Server, Microsoft Hyper-V and Citrix XenServer.

Some bare-metal hypervisors can also be embedded into the firmware suite

OPTIMIZING SERVER VIRTUALIZATION MAKING VIRTUAL INFRASTRUCTURES HIGHLY AVAILABLE STORAGE IN THE VIRTUALIZED WORLD HYPERVISORS: AT VIRTUALIZATION’S CORE HYPERVISORS: AT VIRTUALIZATION’S CORE

(16)

of the computing platform—the same level as the motherboard BIOS. Examples of this approach include Hitachi Virtage, VMware ESXi and Linux KVM, a ker-nel-based VM.

Alternately, a hosted (Type II) hy-pervisor is an application that runs within the OS, allowing additional OS and application instances to run on top. VMware Server and Microsoft Virtual Server—as well as numerous endpoint-based virtualization plat-forms like VMware Workstation, Mi-crosoft Virtual PC and Parallels Workstation—are hosted hypervi-sors.

Hypervisors don’t simply manage virtual instances. Current hypervi-sors actively manage the computing

platform for better control and resource allocation to the instances that depend on their unique processing needs. “There’s intelligence in the underlying hyper-visor for performance balancing so that I can run applications inside virtual machines,” said Chris Wolf, senior analyst at the Burton Group, an IT research and advisory firm headquartered in Midvale, Utah.

SCRUTINIZING HYPERVISOR FEATURES

The ability to support and nondisruptively move multiple workloads is funda-mental to hypervisors, but there are other features that should be evaluated for an enterprise virtualization platform:

DWorkload support. Ensure that a hypervisor is fully tested and compatible with the OSes that you intend to virtualize. For example, Citrix XenServer can

Hypervisors don’t

simply manage virtual

instances. Current

hypervisors actively

manage the computing

platform for better

control and resource

allocation to the instances

that depend on their

(17)

support VMs on Windows Server 2000 through 2008, Windows Vista, Win-dows XP SP3 and a variety of Linux distributions. Other systems may not oper-ate properly as virtual machines.

Also, think about the applications that make up a workload. Many current enterprise applications can support virtualization, but some may not perform well in a VM. Although it isn’t as much an issue with processor-intensive pro-grams, it can happen with some I/O-intensive applications.

To evaluate the hypervisor’s scalability and its ability to handle additional workloads as well as oversubscribed physical CPU cores, run multiple work-loads on the same processor. Some workwork-loads behave best with a traditional 1:1 ratio of physical cores to VMs. Other workloads, such as test and development or virtual desktops, may demand access to additional cores.

DProcessor acceleration requirements.Intel VT and AMD-V processors in-clude hardware assistance for virtualization. Although both approaches differ, each affects the way that memory is handled in an x86 architecture. Hypervi-sors like Microsoft Hyper-V may require Intel VT or AMD-V procesHypervi-sors, so it’s important to know that your servers meet system requirements for the in-tended hypervisor.

DPower management and resource optimization support. This is an increas-ingly important issue for energy-efficient data centers. Hypervisors generally don’t support traditional sleep states like standby or hibernate. These features won’t work when the hypervisor is enabled.

The hypervisor should provide some support for power management and af-ford a level of control over processor power consumption as server utilization changes. If the hypervisor doesn’t handle power management directly, it should interface with power management capabilities in the OS or other performance management software.

The hypervisor should also be able to move system resources around—allo-cating more or less computing power depending on the unique resource needs

(18)

of each workload. One example of this capability is VMware’s Distributed Re-source Scheduling utility.

DSystem device support. Some virtual devices are not available to a VM— usually because of missing or inadequate driver support. The hypervisor may not support older network adapters or SCSI controllers under certain OSes. Similarly, USB device support is often absent under VMs in a production envi-ronment. Verify hypervisor support if your server uses legacy adapters or con-trollers as well as USB devices.

DSecurity. The challenge with hypervisors is that a security breach in one workload, or in the hypervisor level itself, can potentially jeopardize all other workloads on a server. This makes security a high priority for administrators who should protect applications such as directory services integration, admin-istrative action logs and role-based access controls.

DResiliency. Virtualization can improve the reliability of a server and its net-work by adding HA, fault tolerance, business continuance and DR features. In some cases, resiliency may be a matter of migration—moving a workload from a failing server to a working server or spinning up a failed instance from storage onto an auxiliary server. In other cases, multiple instances of the same work-loads can run redundantly across multiple physical servers, reducing recovery time when a fault occurs.

DRobustness. There are few features or capabilities that are noticeably ab-sent from modern hypervisors—most of them are already quite capable. But virtualization experts point out several hypervisor capabilities that can cer-tainly be added or improved.

Having the ability to overcommit memory—to allocate more memory than what’s available—would be noteworthy for memory-intensive virtualization tasks, especially desktop virtualization, where many instances can quickly sap

(19)

memory space. Security features are another facet of hypervisors that could benefit from some improvement, but the primary need would be better integra-tion with VM management tools.

SUCCESSFUL HYPERVISOR DEPLOYMENT

When planning a hypervisor deployment, don't just think about the current en-vironment. From a practical perspective, the move to virtualization involves some amount of vendor lock-in.

“When you commit to a hypervisor, you’re probably committing for at least three to five years,” Wolf said. “Make sure the technology aligns with the long-term strategic vision of your company.”

Hypervisor deployment is relatively simple. It’s installed as software in a way that’s similar to that of an OS or critical application. Embedded hypervisors don’t require any installation per se because the firmware is already provided in the system hardware itself.

Success with any newly installed hypervisor will depend on several factors. First, all hypervisor deployments will impose a performance penalty on the workload. It’s a small penalty, and hypervisor efficiency is constantly improv-ing, but administrators must test applications, especially I/O-intensive work-loads.

Workload planning and balancing can offset small penalties. New hardware platforms can be deployed to support the most demanding tasks.

Workload balance is also reflected in consolidation, and experts underscore the importance of balancing consolidation levels with recovery needs. “If a 4U server fails with 60 VMs on it, then I have 60 applications that are offline that IT has to deal with,” Wolf said. “Even if I have high availability implemented, that’s still 60 applications offline for a couple of minutes until those VMs can be restarted.” ■ OPTIMIZING SERVER VIRTUALIZATION MAKING VIRTUAL INFRASTRUCTURES HIGHLY AVAILABLE STORAGE IN THE VIRTUALIZED WORLD HYPERVISORS: AT VIRTUALIZATION’S CORE HYPERVISORS: AT VIRTUALIZATION’S CORE

(20)

Stephen J. Bigelow, a senior

tech-nology writer in the Data Center and Virtualization Media Group at Tech-Target Inc., has more than 15 years of technical writing experience in the PC/technology industry. He holds a bachelor of science in electrical engineer-ing, along with CompTIA A+, Network+, Security+ and Server+ certifications, and has written hundreds of articles and more than 15 feature books on computer troubleshooting, including Bigelow’s PC Hardware Desk Reference and Bigelow’s PC Hardware Annoyances. Contact him at [email protected].

Danielle Ruest and Nelson Ruest are IT experts focused on

virtu-alization, continuous service availabil-ity and infrastructure optimization. They are authors of multiple books, in-cluding Virtualization: A Beginner’s Guide for McGraw-Hill Osborne, as well as the MCTS Self-Paced Train-ing Kit (Exam 70-652): ConfigurTrain-ing Windows Server Virtualization from Microsoft Press. Download a free copy of “Chapter 8: Securing Hosts and Virtual Machines” for more informa-tion on Hyper-V security.

OPTIMIZING SERVER VIRTUALIZATION MAKING VIRTUAL INFRASTRUCTURES HIGHLY AVAILABLE STORAGE IN THE VIRTUALIZED WORLD HYPERVISORS: AT VIRTUALIZATION’S CORE ABOUT THE AUTHORS Cathleen Gagne Editorial Director [email protected] Jo Maitland