Ipd - Windows Server Virtualization

Infrastructure Planning and Design Windows Server Virtualization

Version 1.0

Published: November 2007 Updated: February 2008 For the latest information, please see microsoft.com/technet/SolutionAccelerators

FPO

Copyright © 2008 Microsoft Corporation. This documentation is licensed to you under the Creative Commons Attribution License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/us/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA. When using this documentation, provide the following attribution: Infrastructure Planning and Design is provided with permission from Microsoft Corporation. This documentation is provided to you for informational purposes only, and is provided to you entirely "AS IS". Your use of the documentation cannot be understood as substituting for customized service and information that might be developed by Microsoft Corporation for a particular user based upon that user’s particular environment. To the extent permitted by law, MICROSOFT MAKES NO WARRANTY OF ANY KIND, DISCLAIMS ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, AND ASSUMES NO LIABILITY TO YOU FOR ANY DAMAGES OF ANY TYPE IN CONNECTION WITH THESE MATERIALS OR ANY INTELLECTUAL PROPERTY IN THEM. Microsoft may have patents, patent applications, trademarks, or other intellectual property rights covering subject matter within this documentation. Except as provided in a separate agreement from Microsoft, your use of this document does not give you any license to these patents, trademarks or other intellectual property. Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious. Microsoft, Hyper-V, Outlook, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. You have no obligation to give Microsoft any suggestions, comments or other feedback ("Feedback") relating to the documentation. However, if you do provide any Feedback to Microsoft then you provide to Microsoft, without charge, the right to use, share and commercialize your Feedback in any way and for any purpose. You also give to third parties, without charge, any patent rights needed for their products, technologies and services to use or interface with any specific parts of a Microsoft software or service that includes the Feedback. You will not give Feedback that is subject to a license that requires Microsoft to license its software or documentation to third parties because we include your Feedback in them.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Contents The Planning and Design Series Approach..........1 Introduction ................................................. .....4 Windows Server Virtualization in Microsoft Infrastructure Optimization...............................5 Virtualization Design Process.............................7 Step 1: Determine the Virtualization Scope........9 Step 2: Create the List of Applications..............12 Step 3: Determine Resource Requirements.......15 Step 4: Select the Backup Approach for Each Application.............................................. .........21 Step 5: Applying Fault Tolerance .....................23 Step 6: Summarize and Analyze the Application Requirements................................................ ...26 Step 7: Select a Form Factor for the Hosts........28 Step 8: Determine Server Placement................30 Step 9: Map Guests to Hosts................ .............33 Step 10: Determine the Host Backup Approach. 35 Step 11: Design Fault Tolerance.......................37 Step 12: Design the Storage Infrastructure .....39 Step 13: Design the Network Infrastructure.....41 Step 14: Validate the Overall Approach............44 Conclusion........................... ............................45 Appendix..................................................... .....46 Acknowledgments............................... .............48

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

The Planning and Design Series Approach This guide is one in a series of planning and design guides that clarify and streamline the planning and design process for Microsoft® infrastructure technologies. Each guide in the series addresses a unique infrastructure technology or scenario. These guides include the following topics: • Defining the technical decision flow (flow chart) through the planning process. • Describing the decisions to be made and the commonly available options to consider in making the decisions. • Relating the decisions and options for the business in terms of cost, complexity, and other characteristics. • Framing the decision in terms of additional questions for the business to ensure a comprehensive understanding of the appropriate business landscape. The guides in this series are intended to complement and augment Microsoft product documentation.

Document Approach This guide is designed to provide a consistent structure for addressing the decisions and activities most critical to the successful implementation of the infrastructure for Windows Server® 2008 Hyper-V™ technology and Microsoft Virtual Server 2005 R2 SP1. Each decision or activity is subdivided into four elements: • Background on the decision or activity, including general considerations. • Typical options or tasks to perform for the activity. • A reference section that evaluates items such as cost and complexity for the options or tasks identified. • Questions for the business that might significantly affect the decisions to be made. Table 1 lists the full range of characteristics discussed in the option-evaluation sections later in this guide. Only the characteristics relevant to a particular option or task are included in each section.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

2

Table 1. Characteristics Characteristic

Description

Complexity

This characteristic relates the effect a choice will have on overall infrastructure complexity.

Cost

This value shows the relative cost associated with a particular option. This takes into account initial and repetitive costs associated with the decision.

Fault tolerance

The fault tolerance characteristic indicates the effect the option will have on the ability of the infrastructure to sustain operation during system failures.

Performance

Performance is rated based on the effect the option will have on the performance for the technology featured in the guide. This does not necessarily reflect the impact on other technologies within the infrastructure.

Scalability

This characteristic depicts the effect the option will have on the ability of the solution to be augmented to achieve higher sustained performance within the infrastructure.

Security

This value reflects whether the option will have a positive or negative impact on overall infrastructure security.

Each of the design options is compared against the above characteristics and is subjectively rated in order to provide a relative weighting of the option against the characteristic. The options are not explicitly rated against each other as there are too many unknowns about the business drivers to accurately compare them. The ratings take two forms: • Cost and Complexity are rated on a scale of High, Medium, or Low. • The rest of the characteristics are rated on the scale listed in the following table. Table 2. Additional Characteristics Symbol

Definition

↑

Positive effect on the characteristic.

→

No effect on the characteristic or there is no comparison basis.

↓

Negative effect on the characteristic.

The characteristics are presented either as two-column or three-column tables. The twocolumn table is used when the characteristic is applicable to all options or when there are no options available—for example, when performing a task. The three-column table is used to present an option, the description, and the effect—in that order—for the characteristic. There are times that decisions being made within the business may affect the infrastructure design. The “Validating with the Business” section is used to provide additional questions that should be asked of the business leaders. In addition, this provides a means to have check points within the design process to give the business leaders a way to provide additional input into the design process.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 3

Who Should Use This Document This guide is written for information technology (IT) infrastructure specialists who are responsible for planning and designing a Windows Server 2008 Hyper-V or Virtual Server 2005 infrastructure for server virtualization. These specialists include consultants, internal IT architects, and others who are concerned with design decisions related to virtualization. The content in this guide assumes that the reader is familiar with Microsoft virtualization technology and its potential applications.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

4

Introduction This guide leads the reader, step by step, through the process of planning the server virtualization environments. The first six steps in the guide focus on determining requirements for the guest operating systems, applications, and services; they enumerate the capacity and performance requirements that will be used in planning host systems. By addressing information such as resource requirements, backup approaches, and availability first, the user can determine the size of the load that the virtual applications will require from the host infrastructure. Steps 7 through 13 in the guide focus on the planning and design issues that affect the physical host infrastructure design. Specific guest workload requirements determine the server form factor, server placement, and the storage and network architecture. Specific steps and an overview of the entire decision process appear later in this document.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 5

Windows Server Virtualization in Microsoft Infrastructure Optimization The Infrastructure Optimization (IO) Model at Microsoft groups IT processes and technologies across a continuum of organizational maturity (for more information, see Microsoft.com/io). The model was developed by industry analysts, the Massachusetts Institute of Technology (MIT) Center for Information Systems Research (CISR), and Microsoft's own experiences with its enterprise customers. A key goal for Microsoft in creating the Infrastructure Optimization Model was to develop a simple way to use a maturity framework that is flexible and can easily be used as the benchmark for technical capability and business value. IO is structured around three information technology models: Core Infrastructure Optimization, Application Platform Optimization, and Business Productivity Infrastructure Optimization. According to the Core Infrastructure Optimization Model, organizations that are actively pursuing server consolidation for production workloads with virtualization are meeting one of the requirements in order to move to the Rationalized level. This guide will assist in planning and designing the infrastructure for virtualizing server workloads using Windows Server 2008 Hyper-V and Virtual Server 2005 R2.

Figure 1. Mapping of technology into Core Infrastructure Model

Infrastructure and Business Architecture Microsoft produces architectural decision-making guidance for IT infrastructure and business architecture. The architectural principles and decisions presented in the Infrastructure Planning and Design series are relevant to IT infrastructure architecture. The business architecture templates from Microsoft are focused on detailed business capabilities, such as price calculation, payment collection process, and order fulfillment. Although the IT infrastructure will affect business capabilities, and business architectural requirements should contribute to infrastructure decisions, the Infrastructure Planning and Design series does not define or correlate specific individual business architecture templates. Instead, the Infrastructure Planning and Design guides will present critical decision points where service management or business process input is required. For additional information about business architecture tools and models, please contact your nearest Microsoft representative or watch the video about this topic at http://channel9.msdn.com/ShowPost.aspx?PostID=179071. Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

6

Feedback Please direct questions and comments about this guide to [email protected].

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 7

Virtualization Design Process This guide addresses the most common scenarios, decisions, activities, options, tasks, and outcomes that organizations encounter when implementing a virtual server environment. It does not, however, attempt to address every possible scenario. If an environment is unique, design consultants or specialists should be employed to address specific needs.

Decisions The following steps represent the most critical design elements in a successful, wellplanned implementation of Windows Server 2008 Hyper-V or Virtual Server 2005 for server virtualization: • Step 1: Determine the virtualization scope. • Step 2: Create the list of applications. • Step 3: Determine the resource requirements. • Step 4: Select the backup approach for each application. • Step 5: Select the high-availability approach. • Step 6: Summarize and analyze the application requirements. • Step 7: Select a form factor for the hosts. • Step 8: Determine server placement. • Step 9: Map guests to hosts. • Step 10: Determine the host backup approach. • Step 11: Design high availability. • Step 12: Design the storage infrastructure. • Step 13: Design the network infrastructure. • Step 14: Validate the overall approach. Where an item represents decisions the organization must make, this guide presents a corresponding list of common response options. Other items in this list represent tasks the organization must complete; they appear in this guide because they are needed to complete the infrastructure design.

Decision Flow Figure 2 shows the flow diagram for the steps, both decisions and tasks, which are included in this guide.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

8

Figure 2. Decision flow diagram

Information Collection Organizations must have the following information when designing a server virtualization infrastructure: • General business requirements. Before performing step 1, an organization must have a thorough understanding of its primary business goals for implementing a server virtualization environment to ensure that the technical decisions can be matched to business requirements. • List of server assets. Prior to beginning step 7, an organization should create a list of the server and network hardware assets present in its environment. This information is used if an organization is considering the reuse of existing hardware.

Applicable Scenarios Planning for the server virtualization infrastructure may apply to the following types of goals and scenarios: • Server consolidation • Support for legacy operating systems and applications • Reducing deployment and provisioning times • Reducing data center and hardware costs by increasing hardware utilization • Implementing training labs

Out of Scope Although the infrastructure planning information in this guide applies to many applications of virtualization technology, certain details are outside the scope of this document. Such details include: • Disaster recovery and business continuity planning. • Creating development and test environments. • Increasing workload security through virtualization. • Operating the virtualized environment. • Considerations for virtualization hosting providers.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 9

Step 1: Determine the Virtualization Scope Before beginning to plan for and design a virtualization infrastructure, an organization needs to determine which parts of its environment to include in the design. The goal of this initial step is to define the scope of the virtualization infrastructure. Virtualization can be deployed across the entire enterprise, or to specific hub locations (a regionalized approach), or to individual satellite offices (a decentralized approach). This section examines each of these options. This step drives decisions related to how organizations implement virtualization. This information helps determine how the computing environment is intended to run, allows for mapping requirements to a virtual infrastructure, and defines the mode of operations following the virtualization implementation. Because details relating to workloads and other technical decisions vary for each scenario, this guide was designed as a review of each scenario’s required tasks, decisions, and questions. If an organization is considering multiple options, it should complete the steps in this guide for each option.

Option 1: Enterprise Deployment This option involves deployment of virtualization technology to the entire organization, including corporate data centers.

Benefits • •

Delivers standardization across the enterprise and the associated economies of scale. Maximizes the return on investment that can be realized by the virtualization project.

Challenges • •

Upfront costs of the virtualization project are all incurred before the benefit is fully realized. High risk, because of the large number of systems that will be affected.

Option 2: Hub Deployment This option involves deployment of virtualization technology to one or more hub locations. Hubs are physical locations where there are concentrations of users, computers, and/or network connectivity. Resources within the hub may be provided to additional satellite locations.

Benefits • • •

Provides a pilot environment in which to prove the process and benefits of virtualization before deployment on a wider scale. Can deliver standardization across a region and the associated economies of scale. Increases the return on investment that can be achieved by the virtualization project when compared to a decentralized approach.

Challenges • • •

Upfront costs of the virtualization project are relatively high. Medium risk, because a significant number of systems will be virtualized at one time. Disruptive, since numerous changes will be made at the same time.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

10

Option 3: Satellite Deployment This option involves deployment of virtualization technology to one or more satellite locations. Satellite locations are smaller than enterprise or hub environments and often have limited network connectivity to the rest of the environment because of bandwidth constraints.

Benefits • • •

Upfront costs of the virtualization project are relatively low. Lower risk, because a smaller number of systems will be virtualized at one time. Provides a pilot environment in which to prove the process and benefits of virtualization before deployment on a wider scale.

Challenges • •

Potentially creates a non-standard configuration in smaller, remote locations. More complex to implement since satellite offices often lack dedicated technical staff with expertise to optimize systems, which makes support and troubleshooting more costly. • Limited return on investment that can be achieved by the virtualization project when compared to a larger implementation. When implementing virtualization in hub and/or satellite locations, organizations may have two primary infrastructure options: They can build a virtual infrastructure within the hub or satellite office itself, or they can move server-related resources to a centralized hub or data center location.

Evaluating the Characteristics The following tables compare the characteristics of the options. Complexity

Justification

Enterprise

Many systems to virtualize.

H

Hub

Fewer systems but limited virtualization skills available onsite.

M

Satellite

Few systems but often no dedicated staff with virtualization expertise.

L

Cost

Justification

Enterprise

Large numbers of systems requires the greatest effort.

H

Hub

Medium number of systems means less effort.

M

Satellite

Smallest number of systems minimizes the work involved.

L

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 11

Validating with the Business When deciding which portion of the infrastructure to virtualize, business stakeholders should ask questions similar to the following to ensure that they have a complete view of how the planned infrastructure affects the business: • What is the primary reason for implementing virtualization? Business goals should determine which portions of the infrastructure to virtualize—for example, reducing data center costs by reducing the number of physical servers as well as consolidating applications and workloads. Another business goal may be to reduce deployment time for new applications and operating systems. Virtual machine (VM) deployment requires significantly less time than physical machine deployment. • What is the expected timeline for moving to virtualization? In many cases, organizations start with a limited deployment in order to gain expertise with the technology and to test various configurations.

Decision Summary Decisions about which part of the infrastructure to virtualize should be based on the specific needs of the organization. The scope of the virtualization project drives decisions in future steps related to capacity requirements. Although there is no single “best” approach to follow, ensure that the entire organization is aligned with and supports the selected approach before continuing the planning process.

Additional Reading •

•

• •

Virtual Server 2005 Case Studies at http://www.microsoft.com/windowsserversystem/virtualserver/evaluation/casestudies/ default.mspx provide information on how various organizations have implemented virtualization technologies. For information on how Microsoft IT has deployed server virtualization technology, see the Technical Solution Brief, “Server and Data Center Consolidation: Microsoft IT Enhances Cost Savings, Availability, and Performance,” at http://www.microsoft.com/technet/itshowcase/content/svrdatactrconsoltsb.mspx. Windows Server 2008 Hyper-V library at http://technet2.microsoft.com/windowsserver2008/en/library/5341cb70-0508-4201a6da-dcac1a65fd351033.mspx. Windows Server 2008 Hyper-V Resources at http://www.microsoft.com/virtualization/resources.mspx#documents.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

12

Step 2: Create the List of Applications Before designing and implementing the infrastructure, determine which applications the infrastructure needs to support. This information will be used in later steps to determine resource requirements and, ultimately, to design the physical host infrastructure.

Task 1: Determine Application Compatibility Although the goal of virtualization technology is to provide virtual environments that can support a wide variety of operating systems and applications, certain limitations can prevent some types of workloads from running virtualized. The first step in deciding which applications to virtualize is to consider the specific technical requirements for the application or operating system and map that against any constraints in the virtualization technology. Factors include: • Processor architecture requirements. • The number of required processors. • Memory requirements. • Graphics adapter requirements. • Special hardware requirements. Windows Server 2008 Hyper-V has the following constraints and limitations: • Is available with Windows Server 2008. • Requires specialized hardware chipset (Intel VT or AMD-V). • No access to USB devices or hardware such as Host Bus Adapters (HBAs). Virtual Server 2005 has the following constraints and limitations: • Support for up to 3.6 gigabytes (GB) of virtual memory in each guest. • Support for 32-bit applications. • Support for a single virtual CPU. • No access to USB devices or hardware such as Host Bus Adapters (HBAs). Other technical considerations related to storage and networking are covered during steps 12 and 13 later in this guide. To ensure compatibility, IT staff members, users, and application support staff should verify applications by running them within a VM. In addition to verifying technical compatibility, verify that the application vendor will support the application when used in a virtual workload. Also, consider the suitability of an application for virtualization. Security and/or other business requirements may lead an organization to run an application on physical hardware rather than virtually.

Task 2: Document the List of Applications Most organizations run multiple operating systems, applications, and services that IT may consider moving to a virtual environment. To ensure that no important considerations are overlooked, a spreadsheet or table should be created that lists the applications, whether they are compatible with virtualization, and whether it is appropriate to virtualize them. Such a job aid could also include additional notes, requirements, and concerns. Filling out such a table can provide a very helpful structure to the process of planning for virtualization. Table 3 provides an example of information to include; the full table is shown in the appendix at the end of this document.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 13

Table 3. Applications That Could Be Virtualized Application name

Description /purpose

Application owner

Application version

Is the application supported as virtual?

Approved by business

Microsoft Outlook® Web Access

Server Admin

2007

Yes

Yes

Microsoft System Center Essentials

IT Service Desk

2007

Yes

Yes

Application 3 Application 4 … This initial list serves as the basis for designing the virtualization infrastructure.

Validating with the Business To ensure that the list of applications for virtualization is accurate, ask business stakeholders the following questions: • Is the list of applications complete? The success of the virtual infrastructure design depends on determining requirements for applications that can be supported in a virtual environment. • Are there applications on the list that should not be virtualized? It is often difficult to determine all the potential issues with virtualization based on technical details alone. The fact that a workload can be virtualized does not necessarily mean that it should be. Business leaders should understand the basic idea behind virtualization and should verify that it appears to be a suitable solution for each workload. • Can the business accept the risks of moving to virtualization? Making changes to any application or server involves risk. The business should ensure that the level of risk is acceptable. • Do specific legal requirements prevent an application from running within a VM? Requirements related to physical isolation of applications or that prevent certain applications from running on the same servers can prevent the use of virtualization. Another legal consideration is whether the application is licensed for use in a virtualized environment. • Do support-related requirements prevent an application from being virtualized? Organizations should consider support contracts and associated technical requirements before committing to run an application within a VM. • How should applications be prioritized? Businesses should prioritize applications based on importance. • Do scheduling issues exist? Some applications may have availability requirements that prevent downtime during certain times of the year. If the time frame of the project is fixed, this may affect which applications are considered virtualization candidates.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

14

•

•

What about applications that are used only rarely? Applications that are rarely used might translate to a lower priority or might be removed entirely from the list of virtualized applications. Alternatively, they may prove excellent candidates since virtualization may offer a way to eliminate server hardware that runs all year, but is hardly ever used. Can business users assist in testing application compatibility? Although IT departments are responsible for deploying and supporting applications, business users are often experts in application functionality. Compatibility tests should involve input from representative users who can verify that their programs are running properly in the virtual environment.

Decision Summary The list of applications considered for virtualization should begin with an analysis of the technical requirements of each operating system, application, and service. Good virtualization candidates are not only technically compatible with Windows Server 2008 Hyper-V or Virtual Server 2005, but also deliver business value and conform to business restrictions. The final list should include input from all affected users.

Additional Reading •

Solution Accelerator for Consolidating and Migrating LOB Applications at http://www.microsoft.com/technet/solutionaccelerators/ucs/lob/lobsa/default.mspx provides information and details on moving workloads to a virtual environment.

•

Virtual Server 2005 Frequently Asked Questions at http://www.microsoft.com/windowsserversystem/virtualserver/evaluation/virtualization faq.mspx provides information on the features, capabilities, and limitations of Virtual Server 2005.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 15

Step 3: Determine Resource Requirements After determining the list of applications that the virtual environment will support, the resources required to support those applications needs to be determined. In step 3, the technical requirements for each application that will be virtualized will be collected; this information will be used in subsequent steps to design the host infrastructure. In the case of existing production applications, determining the resource requirements can be an objective process. However, when a new application is being considered, more subjective approaches may be all that are available. Subjective information sources can come from experience with similar technologies or literature. Objective information sources can include: • Real-world performance data (based on monitoring existing applications and workloads). • Specifications and requirements from application and operating system vendors. • Results from application benchmark testing. • Details that application developers and systems integrators provide. • Load-testing based on expected use patterns and metrics. IT should plan to support the peak load of each application VM to ensure that the host system can handle the full load of all of the applications it hosts. For existing applications, systems administrators should collect performance information from production environments. This step assumes that an application represents the entire physical server that hosts the application. When collecting performance information then, the counters being collected are for the entire server. It is further assumed that the entire physical server is to be virtualized, not just the application itself. This approach maps applications to guests on a 1:1 basis. The opportunity exists to go further and combine one or more applications from different servers into a single guest. However, this topic is beyond the scope of this guide. The tasks in this step involve examining the various hardware resource requirements for each application and operating system that the virtual environment will support. These details are used to determine the size of the virtualization infrastructure environment. The table developed in step 2 will help track the information generated, as shown in Table 4.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

16

Table 4. Tracking Resource Requirements Application

Application 1

Application 2

CPU %

60

30

Memory

2048

1024

Disk Capacity

500 GB

20 GB

Disk (IOPS)

750

100

Network Bandwidth

800 mbps

100 mbps

Number of NICs

1

1

Backup

Guest Level

None

Fault Tolerance

Yes

Yes

Availability Approach

MSCS

Load Balance

Physical Isolation requirement

Yes

No

Application N

Total

Note To provide safeguards against underestimating resource requirements, add a “buffer” amount when determining specific host requirements. You can do this by adding additional capacity for each application or by using a percentage or constant adjustment for all applications.

Task 1: CPU Over-committing CPU resources can adversely affect all the workloads on the same host server, causing significant performance issues for a larger number of users. Because CPU resource use patterns can vary significantly, no single metric or unit can quantify total resource requirements. One approach, however, is to collect CPU requirement specifications for particular applications and workloads. Table 5 provides the Windows® Performance Monitor statistic to collect over time. Table 5. Performance Monitor Statistics Object

Counter

Instance

Processor

% Processor Time

_Total

Note

Similar performance counters are available for other operating systems.

CPU calls are transmitted directly from VMs to the underlying host computer’s physical CPU. Therefore, a good guideline is to specify the same CPU architecture and speed that would be used for the same applications running on a physical computer. Document the CPU that the application is running on, and express the CPU demand as a percentage.

Task 2: Memory Applications that are allotted too little memory will experience frequent disk page faults, resulting in decreased performance and additional disk resource use. In contrast, allocating too much physical memory leaves physical hardware resources unused, leading to lower overall host server utilization. Collect memory use information when the system is running at peak load to ensure that the appropriate amount of memory is allotted. Table 6 provides the Windows Performance Monitor statistics that should be collected. Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 17

Table 6. Performance Monitor Statistics for Required Memory Object

Counter

Instance

Memory

Committed Bytes

N/A

For each machine being virtualized add approximately 24 megabytes of memory to account for overhead needed by the virtualization host.

Task 3: Disk This task involves measuring disk storage and performance requirements.

Disk Capacity Every VM requires disk space to support multiple file and data types. Common types of storage requirements include: • Operating system storage, including binaries, the paging file, and other required disk resources. • Application-related storage space. • User data storage. • Databases and other required files. Predicting disk space use is similar for physical and virtual workloads. For existing systems, take the total disk space in use and add a factor for future growth Record in the spreadsheet the total amount of disk storage capacity required for each application.

Disk Performance To determine the actual disk performance, measure and record the physical I/O that occurs over a period of time, then calculate the Input Outputs per second (IOps)—that is, the total number of I/O operations that occur per second, and plot this over the time period to determine requirements at peak usage. The IOps calculations for a RAID 0+1 configuration is (Reads Required + (Writes Required *2)) / Max Drive IOps. The IOps calculations for RAID 5 configuration is (Reads Required + (Writes Required *4)) / Max Drive IOps. Given a specific configuration such as a RAID 5 array of five drives (with each drive capable of approximately 135 IOps), the IOps capacity of an existing configuration can also be calculated. By using Windows Performance Monitor, what the current system is actually using in terms of IOps can be measured. However, that number does not indicate whether the system has a bottleneck in the disk subsystem. To see whether the system is disk-bound, look at the queue length of the physical disk. The queue length should be zero on a wellperforming system.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

18

Disk Performance Counters Table 7 provides the Windows Performance Monitor statistics that should be collected. Table 7. Performance Monitor Statistics for Disk Performance Object

Counter

Instance

Physical Disk

Disk Reads/sec

_Total

Physical Disk

Disk Writes /sec

_Total

Note

Similar performance counters are available for other operating systems.

Total the Physical Disk counters from the table above to calculate the IO usage for each system. Record the values in the table.

Task 4: Network Most workloads require access to production networks to ensure communication with other applications and services and to communicate with users. Network requirements include elements such as throughput—that is, the total amount of traffic that passes a given point on a network connection per unit of time. Other network requirements include the presence of multiple network connections. Workloads might require access to several different networks that must remain secure. Examples include connections for: • Public network access. • Networks for performing backups and other maintenance tasks. • Dedicated remote-management connections. • Network adapter teaming for performance and failover. • Connections to the physical host server. • Connections to network-based storage arrays. Add the number of required network connections to the spreadsheet that was created earlier.

Network Performance Counters Table 8 provides the Windows Performance Monitor statistics that should be collected over time and graphed to record peak usage. Table 8. Performance Monitor Statistics for Network Performance Object

Counter

Instance

Network Interface

Bytes Total / sec

(Specific network adapters)

Note

Similar performance counters are available for other operating systems.

Add the values for each application, and then add the information to the spreadsheet that was created earlier.

Task 5: Backup Considering backup requirements for applications helps inform storage, network, and other requirements in subsequent steps in this guide. Some types of workloads might not require backups. For example, a Web server that presents static data might simply be rebuilt in case of a failure. Most workloads, however, contain important configuration settings, operating system settings, and user data that must be protected in the case of a VM failure. If this application requires backup, record it in the table. Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 19

Task 6: Availability The requirement for high availability in applications has significant implications for host storage, network, and availability infrastructure. However, the most important question is: Does the application require high availability through fault tolerance? For each application that requires high availability, determine the necessary method. Options include: • Network load balancing. Primarily for stateless applications such as Web servers that serve static content or that store session state in a shared location. • Cluster-aware applications. For applications that are Microsoft Cluster Service (MSCS) aware, such as Microsoft Exchange Server and Microsoft SQL Server®. • Host clustering. When network load balancing is not appropriate and the application is not cluster aware, some risk mitigation can be achieved by running the VM on a host system that is part of an MSCS cluster. Because the application is not cluster aware, there is no assurance that the application will recover gracefully from a failure. However, this practice offers a best-odds approach to minimizing downtime when no other fault tolerant options exist.

Task 7: Coexistence and Physical Isolation From a technical standpoint, it is possible to support a wide variety of different workloads on the same physical computer. However, business or technical characteristics may prevent more than one system from running on the same server. One example is the need for VMs to exist in different physical locations. When supporting hubs and satellite offices, specific sites may require certain VMs. Security and regulatory compliance requirements can also drive the need to keep certain workloads separate. If specific applications, databases, and services must remain segregated, note them (along with the reasons, such as security, regulatory compliance, or business policies) in the table above. This data will be used to determine the acceptable placement of guest VMs in the infrastructure.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

20

Validating with the Business The primary considerations in step 3 are the technical resource requirements for each application. Although IT departments are often able to measure factors such as CPU, memory, disk, and network use, other details will require business input. Specifically, work with business decision makers to ensure agreement on the specific details of the following considerations: • Would any regulatory requirements or political issues prevent combining specific applications on the same servers? In addition to technical requirements for physical isolation and coexistence, business or political issues can prevent the same server hosting specific applications. • Are there any legal concerns about the geographical location of an application? Legal requirements and international regulations can prevent certain applications from residing in specific geographic locations. • Confirm the availability and backup requirements for each of the applications. • What are the expected growth patterns for each of the applications, over the next two to three years? This will enable a sizing of the virtualization environment to accommodate that growth.

Decision Summary After completing this step, the total resource requirements for all the applications that the organization’s virtual infrastructure will host have been identified. To obtain rough estimates of the total requirements, add each row of each resource requirement. Doing so provides an estimate of the total amount of memory and other resources required in future steps.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 21

Step 4: Select the Backup Approach for Each Application The backup approach selected for the virtualized applications affects the storage and network infrastructure of the host system. Several approaches are available for meeting applications’ backup and restore requirements. There are three basic options for performing backups for the applications identified in step 4. In this step, each application is reviewed to determine which backup approach to use. The decision should be recorded in the job aid chart.

Option 1: Per Application Products such as SQL Server and Exchange Server have specific backup application requirements to ensure that a complete backup is obtained. That is, ensure that not only the data files are backed up but also that transactions in memory and transaction log files are committed to the database. Performing application-level backups has several useful benefits. First, the backuprelated functionality is typically designed specifically for protecting an application. It helps ensure that files that are typically in use are backed up in a consistent state. Additionally, the restore process is often simplified because administrators can use application-level features to bring data back online. The backup files themselves can be significantly smaller than those generated from a guest- or host-level backup. Application-specific backups can have a significant impact on the host system from a CPU, disk, and network usage perspective.

Option 2: By Guest In guest-level backups, VMs essentially function the same as physical machines. Each computer may include a backup agent responsible for transferring backups to a designated storage location, or they can use the native Windows Backup application. Guest-based backups can have a significant impact on the host system from a CPU, disk, and network usage perspective.

Option 3: By Host When performing backups at the host level, two options are available with Virtual Server 2005 R2 SP1: • Offline backups. This approach requires turning off the VM or placing it in a saved state before copying files. After the copy process is complete, the VM can be started again. This approach involves downtime for each VM, but it provides a simple method for implementing complete backups. • Online backups. Using snapshot technology such as Volume Shadow Copy Service (VSS), administrators can make copies of VM configuration files while the VM is running. Doing so avoids downtime but may affect performance momentarily. This option is only available on hosts using Storage Area Networks (SANs) that have a VSS writer available. The reason for understanding the type of backup approach for each application is to: • Allow for the possibility of grouping VMs with similar backup requirements onto the same hosts (for example, all VMs using host backup are placed on the same host). • Determine the impact that backups will have on the host system from a CPU, network, and disk usage perspective. Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

22

Evaluating the Characteristics Additional characteristics to consider include are discussed in the following tables. Complexity

Justification

Per application

Different backup methods must be used for different applications.

H

By guest

Backup options can be centrally managed using enterprise backup software.

M

By host

Requires no knowledge of the VM’s contents; therefore, backups can be performed consistently across the entire environment.

M

Performance

Justification

Per application

Backups include only important data.

↓

By guest

Backups are treated the same as physical machines and can include the operating system, program files, and user data.

↓

By host

Backups include the entire contents of a VM, usually requiring more time and storage space. However, backups can be performed while the VM is turned on.

→

Validating with the Business Technical requirements often drive decisions about specific backup approaches. However, be sure to ask the following questions to ensure that business needs are met: • Is it necessary to back up all the content for a specific workload or application? In some cases, application experts might determine that it is necessary to store only certain information in backup files because users can easily re-create other data in the event of a failure. • Will the determined approach meet data loss requirements? Perform backups frequently enough to ensure that data loss is minimized for critical applications. • Does the recommended approach meet recovery requirements? Business users will likely have expectations related to the amount of time required to recover from various failure scenarios. Based on answers to these questions, backup-related decisions for specific applications may need to be reviewed and revised.

Decision Summary At the end of this step, sufficient information about the expected backup approach for each application that will move to a virtual infrastructure should be available. In some cases, it may be desirable to note which backup strategies are possible and which are preferred based on the needs of the VM.

Additional Reading The Windows Server TechCenter article, “Backing up and restoring Virtual Server,” at http://www.microsoft.com/technet/prodtechnol/virtualserver/2005/proddocs/vs_operate_u sing_backUp.mspx?mfr=true addresses considerations for implementing Virtual Server 2005 backups. Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 23

Step 5: Applying Fault Tolerance Application fault tolerance requirements place specific technical requirements on the virtualization host server, storage, and network infrastructure. In this step, the most appropriate fault tolerance approach for each application that will be virtualized will be selected. The technical approach can vary based on the details of the underlying operating system and applications that are running in the virtual environment. Some workloads (such as Web servers, database servers, and messaging servers) have their own methods of implementing fault tolerance. For example, a Web server can store session state information in a shared memory space or in a database, so the services can automatically fail-over to another node without causing a disruption in service. Cluster-aware applications can rely on operating system functionality such as Microsoft Cluster Services to provide automatic fail-over. For applications that do not provide their own fault tolerance methods, it is possible to use virtualization fault tolerance options. In this step, map the requirements identified in step 3 to specific options for implementing high-availability virtual systems.

Option 1: Network Load Balancing Stateless applications such as Web servers can have fault tolerance support by establishing network load balancing across multiple identical instances of the application. Network load balancing technology distributes the inbound traffic headed for the application across multiple machines running the same application, which allows for one server to fail and the remaining servers to pick up the load. Windows Server has a software implementation of network load balancing built in. A hardware network load balancing solution can distribute requests based on a variety of load-distribution algorithms. It can also monitor various nodes in the server farm and ensure that they are operating properly before sending requests to them. This option requires that at least one additional VM be added for each application using network load balancing.

Option 2: Application-Specific Clustering Many enterprise applications that customers consider mission critical have fail over capabilities built into them through cluster awareness. These applications were designed and built to run on an MSCS cluster. Examples include SQL Server and Exchange Server. An MSCS cluster can be configured by using multiple VMs that have a common shared disk. This option requires that at least one additional VM be added for each VM that is being clustered.

Option 3: Host Clustering A significant number of applications cannot effectively use network load balancing and were never designed to be cluster aware. However, one additional option can help mitigate the exposure of a failure of systems running these applications. The Virtual Server 2005 host system itself can be configured in an MSCS cluster. In this configuration, if the host server running the VMs fails, the Virtual Server 2005 application and all its VMs fail over to another node in the MSCS cluster. The cluster would then attempt to restart each VM on the new node of the cluster. Note that because none of the applications inside each VM are cluster aware, there is no guarantee that the application will restart in the correct manner.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

24

Evaluating the Characteristics The following tables compare the characteristics of the options. Complexity

Justification

Network load balancing

Can be implemented independent of the application technology (assuming that workloads support this approach).

M

Applicationspecific clustering

Requires expertise in several high-availability approaches and procedures.

H

Host clustering

Uses a standard approach for protecting against host failures but requires cluster configuration.

H

Cost

Justification

Network load balancing

Can be implemented in software or commodity hardware.

M

Applicationspecific clustering

Shared storage and configuration requirements increase cost.

H

Host clustering

Protects against VM and host failures.

H

Fault Tolerance

Justification

Network load balancing

If appropriate for the application, provides a highly scalable and resilient method of ensuring reliability.

↑

Applicationspecific clustering

If available for the application, provides a highly resilient method of ensuring reliability.

↑

Host clustering

Protects against VM and host failures.

→

Performance

Justification

Network load balancing

Delivers a high performance solution through load balancing.

↑

Applicationspecific clustering

Clustering does not significantly affect performance.

→

Host clustering

Clustering does not significantly affect performance.

→

Scalability

Justification

Network load balancing

Can be scaled out to the largest implementations.

↑

Applicationspecific clustering

Can be scaled up, but at additional cost.

→

Host clustering

Can be scaled up, but at additional cost.

→

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 25

Validating with the Business Because numerous technical considerations are involved in each fault tolerance approach, ensure that technical decisions meet business requirements. Specific questions to ask include: • Are all critical areas of the application infrastructure protected? It is easy to focus on protecting applications by themselves. However, fault tolerance requires a focus on areas such as the power infrastructure, the network, and storage devices. Applications might have dependencies on a wide array of services, all of which must remain available to support mission-critical activities.

Decision Summary The process of determining the best fault tolerance approach for specific applications involves many considerations. For applications that support these approaches, application-level and network-level clustering offer simplified implementation and management.

Additional Reading •

•

The following white papers and articles discuss clustering options for VMs and Virtual Server 2005: • “An Overview of Windows Clustering Technologies: Server Clusters and Network Load Balancing” at http://technet2.microsoft.com/windowsserver/en/library/c35dd48b-4fbc-4eee8e5c-2a9a35cf63b21033.mspx?mfr=true • “Server Clusters: Cluster Configuration Best Practices for Windows Server 2003” at http://technet2.microsoft.com/windowsserver/en/library/5172c43a-2e6d-4d94bd44-163a8735ef921033.mspx?mfr=true • “Clustering virtual machines” at http://technet2.microsoft.com/windowsserver/en/library/73b03235-bad1-4ca8939f-c507d00e273f1033.mspx?mfr=true The Microsoft TechNet article, “NLB Design Process,” at http://technet2.microsoft.com/windowsserver/en/library/251c6d81-b2c7-43eb-892c2488a57ec9a81033.mspx?mfr=true provides information about implementing Network Load Balancing Service (NLBS) on Windows Server 2003.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

26

Step 6: Summarize and Analyze the Application Requirements In preceding steps, information about specific technical and business requirements for the applications that will move to a virtual infrastructure was collected. In step 6, this information is combined in order to summarize the overall host requirements for the solution. By the end of this step, sufficient information will be available to start designing the host infrastructure.

Task 1: Summarize Guest Hardware Resource Requirements To determine the total host hardware resource requirements, consider the requirements of each workload that will run in the virtual infrastructure. The sum of this information will be used to determine the total hardware requirements for the host infrastructure. This information will also be used in later steps to design the virtual environment. Considerations include: • CPU. Total the CPU requirements. The final number represents the total CPU capacity requirements for the host hardware pool. There is no convenient method for converting the CPU utilization usage on one processor type to another newer type so some assumptions may be required. • Memory. The total physical RAM requirements obtained by using application estimates or production performance data. The result should be a value for the total amount of memory in gigabytes that the virtual machines require. • Disk (storage capacity). The specific storage requirements should include the required amount of disk space for all the virtual hard disks created for VMs. • Disk (performance). Total the IOps requirements to obtain a view of the total disk performance requirements. • Network. To determine host network requirements, total the peak values of network bandwidth use. Express the result in megabits per second (Mbps) and the number of network cards. Record the sum of the gathered statistics in the spreadsheet that was created earlier. This information helps in estimating the total hardware capacity required for the virtual infrastructure. Note To provide a safeguard against underestimating resource requirements, add “buffer” amounts when determining specific host requirements. Obtain this by adding additional capacity for each application or by using a percentage or constant adjustment for all applications.

Task 2: Group Applications Use business and technical requirements to determine which workloads to combine on which virtual servers. This information is collected in steps 1–5. Considerations include: • Backup requirements and approach. • Coexistence and compatibility of workloads. • Physical isolation requirements. • High-availability requirements. Group VMs that have similar requirements to indicate that they might be able to run concurrently on the same host servers.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 27

Decision Summary By the end of this step, a spreadsheet or database that summarizes all the requirements for the applications and operating systems that will move to the virtual infrastructure should be completed.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

28

Step 7: Select a Form Factor for the Hosts In this step, begin to design the host infrastructure based on workload requirements collected in the preceding steps. The goal of step 7 is to determine the most appropriate type of host hardware on which to deploy the VMs. In making the selection, take account of the prerequisites for the virtualization platform, whether Windows Server 2008 Hyper-V or Virtual Server 2005 R2 SP1. The characteristics of each option also depend on the organization’s current and planned hardware investments. Note Form factor here refers to CPU and RAM. Later sections in this guide discuss disk space and network requirements.

Option 1: Use Existing Hardware In many cases, organizations already have host hardware resources that can be reconfigured and redeployed to support the virtual workload. For example, in a serverconsolidation scenario, the goal is to increase overall hardware use by combining workloads onto fewer physical host computers. These machines can differ significantly based on the age of the hardware, the system specifications, and other capabilities. Often, using existing hardware can decrease overall costs of implementing a virtual infrastructure (cost avoidance) but may result in sacrificing standardization. The primary drawback for using existing machines is that the hardware configuration might not match the “ideal” configurations for the host system.

Option 2: Purchase New Hardware When purchasing new hardware, the organization has the opportunity to set a hardware configuration standard that can be used throughout the company. In some cases, organizations can acquire already-approved server form factors. In other cases, considering newer server specifications that provide increased scalability is more appropriate. Organizations should be prepared to complete significant evaluation and performance testing of host hardware platforms before making significant investments. Considerations include the following: • Scaling up versus scaling out. Fewer servers with large memory and CPU support can be easier to manage and can be more cost-efficient for some infrastructures. Using smaller, commodity servers with lower capacity can involve a smaller capital outlay but often requires additional management effort. • Fault tolerance features. The hardware configuration for new servers should support fault tolerance and fault tolerance features based on application requirements. • Hardware management features. Organizations should consider purchasing servers that support the online addition of components such as network adapters and memory to reduce downtime and simplify administration. It may be necessary to review this step and the defined strategy when applications are actually allocated to each system. It is not uncommon to iterate several times through form factor decisions to find the optimal configuration.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 29

Evaluating the Characteristics The following tables compare the characteristics of the options. Complexity

Justification

Use existing hardware

Organizations that have not standardized on specific hardware configurations must maintain many different types of systems. Legacy host hardware can also be difficult to manage.

M

Purchase new hardware

New servers often come with built-in distributed management features. Using standardized platforms can simplify systems administration.

L

Cost

Justification

Use existing hardware

Provides the lowest initial cost but might add to recurring cost based on management of older hardware platforms.

L

Purchase new hardware

Requires significant capital expenditures to create and deploy new hardware for the virtual infrastructure.

H

Validating with the Business Ask the following questions to verify that the host hardware approach meets the organization’s business requirements and directions: • What is the total budget for implementing the virtual infrastructure? Details help define options for purchasing and deploying new hardware. Budget constraints might necessitate changes to the list of applications that can be supported in the virtual infrastructure. • Are the hardware estimates aligned with purchasing goals? Factoring in current and future purchasing decisions is a necessary step in designing the virtual infrastructure. • Will the business realize the cost reductions and savings it anticipates? Often, Total Cost of Ownership (TCO) and Return on Investment (ROI) numbers must be calculated to ensure that the organization will achieve the expected benefits.

Decision Summary Determining the optimal hardware configuration for the virtual infrastructure should involve an inventory of existing host hardware systems. Compare resource specifications to the requirements summarized in step 6 to determine whether new purchases will be required or would be optimal. Business constraints play a crucial role in determining the most appropriate approach for the organization.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

30

Step 8: Determine Server Placement Details about the scope of virtualization were generated in step 1, and this information will be used to determine the placement of host servers. Organizations should consider the overall goals of centralization, regionalization, and decentralization when deciding where to deploy servers. IT can deploy virtualization host servers to many areas of the organization, depending on the needs of virtual workloads. The purpose of step 8 is to choose the most appropriate approach for determining where servers should go. Specific decisions are based on user needs in addition to business and technical requirements. If IT will support several different scenarios within the virtual infrastructure, it is likely that all options will be used.

Option 1: Enterprise Deployment The default location for the majority of corporate resources is typically within one or more corporate data centers. These environments are designed to support a large number of physical computers. They tend to have on-site systems administrators who have expertise in deploying, monitoring, and troubleshooting hardware-related issues. As described in step 7, organizations can choose to keep existing hardware within the data center and use it to form the basis of a virtual infrastructure, or they can purchase and deploy new hardware. The primary advantages of locating servers in a data center include the ability to achieve centralized management and reduced costs because of a shared power, cooling, and network infrastructure. Other components such as SANs can help increase scalability. However, constraints related to data center capacity might necessitate moving servers to other locations.

Option 2: Hub Deployment Business and technical needs can often require that virtual workloads be geographically distributed. Considerations are based on user requirements for virtual workloads. In most organizations, remote offices and satellite locations are connected by relatively lowbandwidth network links. This raises the need to deploy systems that are located physically closer to application users. Other reasons for distributed host deployment include meeting the needs of independent business units.

Option 3: Satellite Deployment Satellite deployments use a decentralized approach for host server placement. For example, an organization that has a franchise model might have specific business requirements for placing host servers within each location.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 31

Evaluating the Characteristics The following tables compare the characteristics of the options. Complexity

Justification

Place host servers in a data center

Centralizing the infrastructure in a single location will result in a less complex deployment that will likely be easier to manage.

L

Place host servers in hub offices

Distributing infrastructure components across additional sites will require more co-ordination of resources between the sites.

M

Place host servers in a satellite office

Coordinating resources across satellite locations will increase the complexity of the implementation.

H

Cost

Justification

Place host servers in a data center

Generally, deploying systems in a data center can be far less costly than deploying them to remote locations. By using existing data center features and expertise, costs are lower overall.

L

Place host servers in hub offices

Supporting host servers in remote sites can be expensive, especially for sites that do not already have the necessary server infrastructure.

M

Place host servers in a satellite office

Supporting host servers in satellite offices will be expensive because the necessary server infrastructure is unlikely to be in place and there will not be skilled staff on-site.

H

Security

Justification

Place host servers in a data center

IT organizations can ensure that centralized data centers are in compliance with security and regulatory requirements. Systems administrators can be dedicated to ensuring that systems remain properly configured.

↑

Place host servers in hub offices

Remote sites typically lack the expertise and resources to ensure that systems have adequate physical security.

→

Place host servers in a satellite office

In remote satellite offices, it is more difficult to guarantee the physical security of infrastructure components.

↓

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

32

Validating with the Business Server-placement decisions affect all areas of the organization and can significantly affect costs and the overall user experience. Questions to ask include: • Does the current design support future business expansion? Organizations that are planning additional sites and locations should take into account future plans when considering server placement. • Are the server placement decisions in accordance with regulatory and security compliance requirements? Organizations might have a business need to store certain types of data and applications within the corporate data center. • Does the organization have the expertise to support servers in the defined locations? Larger branch offices tend to have dedicated IT staff, whereas smaller environments do not. • Are there any geopolitical considerations? Are there any international boundaries that need to be considered?

Decision Summary Physically centralizing host servers within one or more corporate data center offers numerous advantages in security and availability. These benefits can help reduce costs for the virtual infrastructure. Specific needs in geographically distributed organizations can, however, necessitate the deployment of applications into other locations. In general, place servers within a data center whenever it is possible, and move servers to remote locations only when it is absolutely required.

Additional Reading Solution Accelerator for Consolidating and Migrating LOB Applications at http://www.microsoft.com/technet/solutionaccelerators/ucs/lob/lobsa/lobsaplg.mspx includes information on deployment planning for various applications and workloads using Virtual Server 2005.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 33

Step 9: Map Guests to Hosts The purpose of step 9 is to determine which specific applications will be placed on which specific physical hosts. The mapping process involves using information collected in previous steps. For example, if several applications are unable to coexist on a server based on physical security or coexistence issues, they must be mapped onto different host servers.

Task 1: Determine Host Resource Limits The overall process of determining the ideal mapping of guest computers to specific hosts can require significant effort. The process of taking into account the many different considerations for resources and other requirements can lead to many viable options worth considering. Additionally, workload characteristics can change over time. Therefore, consider details such as target host resource use.

Determine the Threshold/Buffer Plan From the standpoint of host servers, the organization must decide on the optimum host resource use levels. One approach is to maximize resource use on each host while leaving sufficient “head room” for handling unexpected peaks in use patterns. For example, it might be determined that the optimum CPU utilization for virtualization host servers is 80 percent.

Task 2: Map Guests to the Form Factor This task involves allocating the guest-related workload requirements (summarized in step 6) to the physical host machines. Use information about specific VM resource requirements to determine how best to place VMs. For example, categorize workloads based on their CPU requirements. In addition to resource requirements, consider combining or separating those applications based on backup, availability, and isolation requirements. For example, if entire VM backup is required, deploy the application onto servers designated for this method. Ideally, this process would be likened to an automatic coin counter where all of the coins are put in a funnel in the top of the machine and the coins are automatically separated into their respective denominations and stacked in sizes that fit the coin wrappers. When a stack is full, the machine stops until the full wrapper is removed and a new one is positioned. Unfortunately, most of this process is manual today so it is more analogous to a child’s shape sorting toy where each object must be manually placed into the right location. The goal of this part of the design is to map all the applications onto as few physical servers as possible in each geography while still respecting the needs for server buffer, isolation, availability, backup type, and so on. At the end of this exercise, all applications and requirements should be accounted for and the number of physical servers should be identified. Additional servers may be required to meet fault tolerance requirements. These are addressed later in this guide. It may be appropriate to iterate through this process using different form factor designs to find the optimal configuration.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

34

Validating with the Business IT can complete resource-related requirements for mapping guests to the host infrastructure. However, other details, such as fault tolerance and backup requirements, should be verified with the business. Considerations include: • Are these decisions consistent with the organization’s goals for virtualization? Determine the method of workload allocation based on the expected business benefits of adding a virtual infrastructure. • Does the current design meet the organization’s availability and backup requirements? Details such as host server placement, facility limitations, and systems administrator expertise can affect overall operations. • Which requirements and constraints can be considered flexible? In some cases, businesses might find that relatively small investments in additional hardware can lead to better overall workload distribution decisions. The organization should reconsider details such as budgets and employee resources based on results from this step.

Decision Summary Determining how best to distribute guest workloads onto a virtual infrastructure can take significant time and effort. The specific considerations vary widely based on the number and type of applications to be supported in addition to preliminary decisions based on the host hardware infrastructure. Plan to regularly review these decisions after making changes to either the guest or host requirements.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 35

Step 10: Determine the Host Backup Approach The purpose of this step is to determine the backup approach that host servers will use to meet the application requirements defined in steps 1–6. This information will be used to determine storage and network requirements in subsequent steps. In this step, two main approaches to backing up virtual workloads are presented. The guest-related backup requirements are important for informing host backup decisions. Since backup requirements are based primarily on recovery requirements, familiarity with the downtime and data-loss limitations for each workload is important. The results of this step help determine requirements for the storage and network infrastructure. Because the entire contents of a VM are encapsulated in virtual hard drive (VHD) and configuration files, a simple method of performing backups is to copy these files from the host computer’s file system. One of the advantages of this approach is that administrators can create the backups for any guest operating system. Also, the restore process is simplified because administrators can restore the VM using a simple file copy process. In addition to backing up the host system itself, the host-level backup process can be performed in a variety of ways that affect the guest systems, but the primary challenge is that VHD files are locked as “in use” while VMs are running. One solution involves temporarily pausing or shutting down a VM before starting backups. However, doing so requires downtime and an interruption to application availability. Other options include performing snapshot-based backups directly from the storage system. Virtual Server 2005 R2 with Service Pack 1 (SP1) supports VSS to make consistent backups of VMs while they are in use. Windows Server 2008 Hyper-V does not support VSS at the time of writing. Host-level backups will have an impact on the performance of the server. They can also affect the capacity and performance of the disk and network subsystems. It is necessary to account for these impacts in the form factor buffer as well as the network and disk capacity and performance planning considerations.

Evaluating the Characteristics The following tables compare the characteristics of the options. Cost

Justification

VM shut down for host backup

Generally requires less disk space and can use existing enterprise backup solutions (if available).

L

VSS snapshot

Requires enough disk space to store copies of all VM content.

H

Performance

Justification

VM shut down for host backup

The VM is down while backup occurs.

↓

VSS snapshot

Minimal effect on performance.

→

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

36

Validating with the Business The specified backup approach can have a significant effect on the business. To validate its decisions, ask the following questions: • Are there special disaster recovery requirements for the backup solution? In some cases, it might be much easier to maintain a disaster recovery site using full VM backups. In other cases, file system replication or other technologies might be more appropriate. • How are data-protection requirements expected to change in the future? Although this question can be difficult to answer, factoring in anticipated enterprise application deployments can help the organization decide how best to invest in storage capacity to support the selected backup approach.

Decision Summary Many organizations choose to use both guest- and host-level backups for specific applications and workloads. The key concept in considering host backup choices is to recognize and plan for the impact the backup strategy will have on guest and host availability, performance, and capacity planning.

Additional Reading • •

See the Windows Server TechCenter article, “Backing up and restoring Virtual Server,” at http://technet2.microsoft.com/windowsserver/en/library/d7c25b9e-dab6425c-95d2-b085825e95891033.mspx?mfr=true. See the Microsoft Knowledge Base article, “How to back up virtual machines in Virtual Server 2005,” at http://support.microsoft.com/kb/867590. Note that Virtual Server 2005 R2 with SP1 supports VSS.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 37

Step 11: Design Fault Tolerance In step 5, information was collected on the → requirements for all the workloads that IT will support in the virtual infrastructure. In this step, this information is used to design the fault tolerance solutions for server virtualization host hardware.

Task 1: Apply Load Balancing For each application identified in step 5 that required network load balancing, determine how many additional VM instances of the application are needed, and then map them onto physical host systems in the same way as for the original VMs in step 9. Ideally, load balanced VMs should be distributed across multiple hosts to protect against the failure of a single host taking down all instances of the load-balanced application. Each loadbalanced VM adds at least one more VM and often several to the list of VMs that need to be placed in the infrastructure.

Task 2: Plan for Host Clustering In step 9, all the applications were mapped onto physical host servers. Count the number of physical servers that have applications requiring an MSCS cluster or host cluster as defined in step 5. This number represents the number of active cluster nodes required. Then, build an MSCS cluster plan that supports this defined number of active nodes. Each MSCS fail over cluster will require at least one additional physical host server to act as the passive node in the cluster.

Validating with the Business As in preceding steps related to fault tolerance, it is important to validate decisions based on input from the business. Questions should include: • Are there nontechnical availability needs for specific applications? Some users might require a way to access applications while disconnected from the network or while working at occasionally connected remote sites. These considerations can affect the host fault tolerance design. • What are the future capacity needs for the virtual infrastructure? Conferring with the business will help the business plan for future expansion. • Will future application versions provide more availability options? Newer versions of applications might provide enhanced fault tolerance capabilities that can allow less expensive options to be used.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

38

Decision Summary Host clustering can provide a simple method of ensuring that many types of VMs remain available even after the failure of a host system. The costs of implementing host clustering, however, can be significant because of hardware and storage requirements. Additionally, unused capacity on standby nodes and servers lowers overall hardware resource use.

Additional Reading •

•

Virtual Server Host Clustering Step-by-Step Guide for Virtual Server 2005 R2 at http://www.microsoft.com/downloads/details.aspx?FamilyID=09cc042b-154f-4ebaa548-89282d6eb1b3&displaylang=en provides information about implementing hostlevel clustering in Virtual Server 2005. The Microsoft Knowledge Base article, “Requirements for configuring clustering in Virtual Server 2005,” at http://support.microsoft.com/kb/840192 provides implementation details for enabling clustering.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 39

Step 12: Design the Storage Infrastructure In a virtualization environment, the infrastructure must be able to provide large amounts of storage space to support many different VMs. Fortunately, many options exist for scaling storage based on overall workload requirements. Step 12 presents considerations for designing the storage infrastructure for server virtualization. Infrastructure storage planning consists of two primary considerations: planning for performance and planning for capacity.

Task 1: Plan for Performance The goal of designing storage to meet disk performance requirements is to support the required number of IOps. This information was collected in step 2 and totaled in step 6 to arrive at the total disk performance requirement. In this task, calculate the IOps requirements for each physical server by totaling the IOps requirements for each application on each server. This will give the IOps requirement per server because each host server may be connected to a different storage system. The choice of disk redundancy levels such as RAID 1 or RAID 0+1 affects the IOps calculation. By mapping this IOps requirement to the selected type of disk subsystem and the drive characteristics of that subsystem, it is possible to determine the number of actual drives required to achieve the performance objectives. Remember to consider host-based activities in your planning such as the impact of backup operations on disk performance as well as adding an appropriate buffer to protect the system in the event of any system performance anomalies.

Task 2: Plan for Capacity In this task, calculate the disk capacity requirements for each physical server by totaling the capacity requirements for each application on each server plus the space that backups need (if any). Doing so gives the disk capacity requirement per server because each host server may be connected to a different storage system. Redundant Arrays of Independent Disks (RAID) can be used to provide fault tolerance and to improve performance of disk arrays. Common RAID options for production virtualization host servers include RAID 1 (Disk Mirroring), RAID 5 (Disk Striping with Parity), and RAID 0+1 (Mirror Stripe Sets). Each option offers a different portfolio of capacity, performance, and cost. By mapping this disk capacity requirement plus the RAID configuration to the size of disks in the selected subsystem, it is possible to determine the number of actual drives required for performance. Note The actual number of disks required is the greater of the number determined in Task 1 (performance) and the number determined in Task 2 (capacity). Usually that will be the number determined by performance.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

40

Task 3: Select an I/O Form Factor A primary challenge of implementing a storage infrastructure is maintaining manageability. When working with local storage, a typical data center can include hundreds of individual hard disks and storage volumes. The result is increased management effort and wasted disk space (because of unused storage resources on each computer). Using network-based storage solutions, organizations can centralize their storage management by storing data on the network. The choice of the form factor for the storage system should reflect the ability to provide the performance and capacity requirements as well as clustering support, if applicable, and VSS snapshot backup capabilities, if required.

Additional Reading •

•

•

•

The TechNet Webcast Working with the VHD File Format in Virtual Server 2005 (Level 3000) at http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=enUS&EventID=1032284293&CountryCode=US provides details on the different VHD types available in Virtual Server 2005. The Windows Server TechCenter article, “Creating virtual hard disks in Virtual Server,” at http://technet2.microsoft.com/windowsserver/en/library/c1726ff8-ea2b41b1-8cc8-7ec5848d813e1033.mspx?mfr=true provides details on the architecture of different VHD types in Microsoft Virtual Server. The white paper, “Using iSCSI with Virtual Server 2005 R2,” at http://www.microsoft.com/downloads/details.aspx?FamilyID=d112aa63-a51e-4722a41b-98b3ab3700a3&displaylang=en provides information on using iSCSI initiators in a Virtual Server 2005 environment. The Microsoft TechNet article, “Using a storage area network with virtual machines,” at http://www.microsoft.com/technet/prodtechnol/virtualserver/2005/proddocs/vs_deploy _SAN.mspx?mfr=true provides information on SAN design for a virtual infrastructure.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 41

Step 13: Design the Network Infrastructure Most production applications require access to the network in order to communicate with users and other VMs. Additionally; the server virtualization hosts require connections for management, backup, and storage purposes. Consider these requirements when determining the network configuration for the server virtualization infrastructure. Using the application requirements collected in step 2 and the physical server designs in steps 9– 12, for each host server, determine the number of physical network adapters and the total throughput requirements. Also, consider redundancy for implementing fault tolerance. The business and technical requirements for each application to be deployed to the virtual network infrastructure should drive these decisions.

Task 1: Determine Host Connectivity Requirements Windows Server 2008 Hyper-V and Virtual Server 2005 provide the ability to configure network settings based on application requirements. Several options exist for defining network access settings for VMs: • No network connectivity. In this configuration, the VM does not have network access to other VMs or physical servers. • VM-only (logical) networks. For security purposes, VMs can be configured to communicate only with other VMs that are on the same host computer. • Physical network access. This method allows VMs to exist on production host networks similar to physical computers. Design the number and types of network connections that will be required based on applications’ needs. The general rule should be to provide each VM with minimal network access based on specific application requirements. Doing so helps ensure security and reduces network traffic.

Task 2: Determine Host Throughput Requirements In step 3, the amount of required network bandwidth for each VM to be deployed to the server virtualization infrastructure was established. Translate this information into specific host network requirements based on which VMs will reside on which servers. In the simplest configuration, a single physical host server network interface might be sufficient to handle the needs of all the VMs on a server. More often, performance and security requirements will require additional physical ports. The following types of connections are common for server virtualization deployments: • Private network access. Applications that must have dedicated communication with other VMs. Physical servers such as a cluster heartbeat should be placed on private network segments through the host’s physical network adapter. • Public network access. These networks allow external traffic for publicly accessible VMs such as Web servers. For security purposes, use separate physical network connections in this case. • VM networks. Create physical network connections that isolated groups of VMs located on different host servers can use. These networks are typical in test and development environments.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

42

•

Management networks. For security and reliability purposes, organizations can choose to use a separate network for managing server virtualization administrative functions. These networks are restricted to internal traffic. • Backup networks. Use these networks for performing host- and guest-level backups based on the specific needs of the environment. • Storage networks. Storage-related traffic can require large amounts of free bandwidth and low latency. Use storage network connections to provide access to remote VHDs or to virtual operating systems to access network-based storage data. Each network connection requires corresponding physical switch port capacity and available bandwidth within the physical network environment.

Task 3: Plan for Network Reliability and Availability In addition to providing multiple network connections based on functional needs, ensure that physical host network connections meet reliability and availability needs. Most network vendors offer network adapter “port teaming” functionality to provide fault tolerance. This approach works by allowing multiple physical network adapter ports to act as a single port, ensuring reliability and availability. Features like automatic failover and bandwidth aggregation require switch and network-layer support, and specific configurations depend on the standards in use. For each physical host, calculate the number of physical network adapters required. The determinations made for this step may inform changes in the host form factor if the selected host chassis cannot support the number of physical network cards required.

Validating with the Business Base the specific design of network connections on application and business requirements. To validate design decisions, ask the following questions: • Does the design accommodate all the supported user access scenarios? When designing virtual network access, it is often easy to overlook some segments of the user population. Consider factors such as remote access, access from the Internet, and support for branch offices. • Does the network infrastructure meet security and regulatory compliance requirements? Organizations must ensure that communications and data remain secure in order to meet these standards. Network design should take into account methods for managing authentication, authorization, and encryption.

Additional Reading “Manage virtual networks” in the Virtual Server 2005 Administrator’s Guide (http://www.microsoft.com/technet/prodtechnol/virtualserver/2005/proddocs/vs_operate_h t_configVMN.mspx?mfr=true) provides information on the design and implementation of various virtual network options.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 43

Technical Note: Managing Network Addressing Like physical machines, VMs require unique network media access control (MAC) and IP addresses to communicate with each other. By default, Virtual Server 2005 uses an automatic method to create MAC addresses for virtual network adapters. When working in a distributed environment that requires connectivity among many different virtual systems, some MAC addresses may be reused. Consider using static MAC address assignments to avoid this behavior. Use the following approaches for IP address management: • Using static IP address assignments within each VM • Using the Virtual Server 2005 internal Dynamic Host Configuration Protocol (DHCP) server • Using a network-based DHCP server Most organizations use a combination of these approaches, depending on the specific connectivity needs of each VM.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

44

Step 14: Validate the Overall Approach Once a completed draft design has been established, the plan and supporting decisions made in previous steps are compiled and presented to the business. In most organizations, this step will be required to obtain cost approval and to approve the virtualization project. The process of identifying application requirements and mapping them to a server virtualization infrastructure design requires input from people throughout the organization. Technical requirements such as CPU, memory, disk, and network details are often the domain of IT architects and implementers. However, to ensure that the overall design remains aligned with the initial goals and business requirements, plan to review all decisions and the final design with stakeholders. Much of the host infrastructure’s design is based on having accurate information about which applications will be virtualized. The review process should begin with a validation of this list of applications and with an assessment of their resource requirements. Decisions about which technology approaches to use to support the virtual infrastructure can substantially affect an organization’s ability to meet its business goals. Details and conclusions that must be validated include: • Server placement. • Server form factor. • Guest-to-host mappings. • Host backup approaches. • Host high-availability approaches. • Storage infrastructure design. • Network infrastructure design. Take the time to ensure that the business understands the specific implications prior to moving forward with implementation.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 45

Conclusion Virtualization technology can provide dramatic benefits to nearly all aspects of an organization’s IT environment. The ideal implementation depends on determining the business and technical requirements for the applications to be deployed to the virtual infrastructure. The process begins by collecting detailed information on the applications to be deployed. Details include specific hardware resource requirements in addition to availability, security, backup, and other considerations. After all this information is collected and analyzed, it can be used to design the host infrastructure. Specific decision points include determining server placement, selecting a server form factor, mapping guests to hosts, and choosing backup and availability approaches. Numerous considerations also exist for designing the storage and network infrastructure to support the virtual environment. Overall, by following an organized process for designing a server virtualization infrastructure, organizations can help ensure that they meet business and technical requirements.

Additional Reading In addition to Virtual Server 2005 R2 with SP1 product documentation, the following sites offer supplemental information on the product concepts, features, and capabilities addressed in this guide: • Microsoft Virtual Server 2005 R2 at http://www.microsoft.com/windowsserversystem/virtualserver/default.aspx provides a central location for information about the Virtual Server platform. • Virtual Machine Technology FAQ at http://www.microsoft.com/licensing/highlights/virtualization/faq.mspx provides answers to commonly asked questions about Virtual Server functionality, licensing, and deployment options. • Microsoft TechNet Server Virtualization forum at http://forums.microsoft.com/TechNet/ShowForum.aspx?ForumID=583&SiteID=17 provides a location in which architects, implementers, and users can discuss issues related to designing and deploying Virtual Server. • The white paper, “Improving IT Efficiency at Microsoft Using Virtual Server 2005,” at http://www.microsoft.com/technet/itshowcase/content/virtualserver2005twp.mspx provides details on how Microsoft has implemented a Virtual Server 2005 infrastructure. An associated Webcast at http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=103227699 8&EventCategory=3&culture=en-US&CountryCode=US is also available. • See Microsoft TechNet Radio, “How Microsoft Does IT: The Future of Server Virtualization,” at http://www.microsoft.com/technet/community/tnradio/archive/june262007.mspx. • Windows Server 2008 Hyper-V Library at http://technet2.microsoft.com/windowsserver2008/en/library/5341cb70-0508-4201a6da-dcac1a65fd351033.mspx. • Windows Server 2008 Hyper-V Resources at http://www.microsoft.com/virtualization/resources.mspx#documents.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

46

Appendix The table used to determine and total the requirements for the virtualization infrastructure is shown in Table 9.

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Windows Server Virtualization 47

Table 9. Documenting the Requirements

Solution Accelerators

microsoft.com/technet/SolutionAccelerators

Infrastructure Planning and Design

48

Acknowledgments The Solution Accelerators - Management and Infrastructure (SA-MI) team acknowledges and thanks the people who produced the Infrastructure Planning and Design Guide for Windows Server Virtualization. The following people were either directly responsible for or made a substantial contribution to the writing, development, and testing of this guide. Project Team: • Jeremy Chapman – Microsoft • Charles Denny – Microsoft • Anil Desai – Studio B • Dave Field – Studio B • Michael Kaczmarek – Microsoft • Lex Liao – Microsoft • Robin Maher – Microsoft • Lisa Pere – Studio B • Fergus Stewart – Microsoft Contributors: • Ben Armstrong – Microsoft • René Scholten – Capgemini • Allen Stewart – Microsoft Editors: • Michele Anderson – Studio B • Laurie Dunham – Microsoft • Kris Maxwell – Studio B • Pat Rytkonen – Volt

Solution Accelerators

microsoft.com/technet/SolutionAccelerators