ptg6432687 70 2 Best Practices at Planning, Prototyping, Migrating, and Deploying Windows Server 2008 Hyper-V . Create a scope of work detailing the servers that you want to virtualize. . Define high-level organizational goals. . Define departmental goals. . Determine which components and capabilities of the network are most important and how they contribute to or hinder the goals expressed by the different units. . Clearly define the technical goals of the project on different levels (50,000-foot, 10,000-foot, 1,000-foot, and so on). The Discovery Phase . Review and evaluate the existing environment to make sure the network foundation in place will support the new virtualized environment. . Make sure the existing environment is configured the way you think it is, and iden- tify existing areas of exposure or weakness in the network. . Define the current network stability and performance measurements and operation. . Use external partners to produce more thorough results and predict the problems that may emerge midway through a project and become “showstoppers.” . Start the discovery process with onsite interviews. . Review and evaluate every affected device and application to help determine its role in the new environment. . Maintain and protect business-critical information. . Determine where data resides, what file stores and databases are out there, how the data is maintained, and whether it is safe. The Design Phase . Create a design document including the salient points of the discussion, the reasons the project is being invested in, the scope of the project, and the details of what the results will look like. . Create a migration document providing the road map showing how the end state will be reached. . Use a consultant with hands-on experience designing and implementing Windows 2008 Hyper-V virtualization to provide leadership through this process. . Determine what hardware and software will be needed for the migration. . Determine how many server software licenses will be required. . Detail the level of redundancy and security required and that the solution will ulti- mately provide. . Present the design and migration documents to the project stakeholders for review. Download at www.wowebook.com ptg6432687 71 Best Practices The Migration Planning Phase . Create a migration document containing the details of the steps required to reach the end state with minimal risk or negative impact to the network environment. . Create a project plan that provides a list of the tasks, resources, and durations required to implement the solution. The Prototype Phase . Create a lab environment in which the key elements of the design as defined in the design document can be configured and tested. . Isolate the lab environment from the production network so that any problems created or encountered in the process don’t affect the user community. . Thoroughly test all applications in a virtual environment. The Pilot Phase . Identify the first group of servers that will be moved to the new Windows 2008 Hyper-V virtual environment. Servers that are already redundant and have limited failure points should be chosen first. . Clarify a rollback strategy, just in case unexpected problems occur. . Test the disaster-recovery and redundancy capabilities thoroughly. . Fine-tune the migration processes and nail down time estimates. The Migration/Implementation Phase . Verify that applications have been thoroughly tested, administrators and support personnel have been trained, and common problem resolution is clearly docu- mented. . Conduct a check of end-user satisfaction. . Allocate time to verify ongoing support and maintenance of the new environment, before migrating the last servers into the new virtualized networking environment. . Plan a project-completion party. 2 Download at www.wowebook.com ptg6432687 This page intentionally left blank Download at www.wowebook.com ptg6432687 3 Planning, Sizing, and Architecting a Hyper-V Environment IN THIS CHAPTER . Logically Distributing Virtual Servers on Specific Host Systems . Choosing Servers to Virtualize . Capturing the Workload Demands of Existing Servers . Analyzing the Workload Demands of Existing Servers . Choosing the Hyper-V Host System Environment . Sizing a Hyper-V Host System Without Existing Guest Data Whereas Chapter 2, “Best Practices at Planning, Prototyping, Migrating, and Deploying Windows 2008 Hyper-V,” focused on the project management process for a migration of physical servers to virtual servers, this chapter focuses on the technical assessment of existing physical servers and the host server sizing that is needed to prepare a virtual host environment. Instead of just randomly virtual- izing physical servers onto host systems sequentially, orga- nizations can better utilize host server hardware systems by technically assessing the server loads of existing physical servers and logically placing them on host servers to balance virtual guest sessions. Logically Distributing Virtual Servers on Specific Host Systems Moving physical servers to virtualized host servers is not a process that should be done randomly. A fine balance exists between the distribution of server workloads, the distribu- tion of servers for redundancy and fault tolerance, and the distribution of servers for application performance and user connectivity. Distributing Virtual Servers Based on Workload Some server sessions are processor intensive (for example, index servers, transaction-analysis servers), whereas some server sessions are I/O intensive (for instance, file servers, messaging servers). Putting several processor-intensive server sessions on a single host can overload the processing Download at www.wowebook.com ptg6432687 74 3 Planning, Sizing, and Architecting a Hyper-V Environment capabilities of the server, whereas balancing host servers with some processor-intensive server workloads with some I/O-intensive server workloads can better extend the capabili- ties of a host system. The variables and constraints of workload on a server can be technically categorized as follows: . Processor workload—This refers to the demands a guest session places on the processor, typically from applications that do calculations or analysis of information. All applications use the processor of a server; some can get away with sharing a processor with other server sessions, whereas other server sessions require the dedica- tion of one, two, or four processors to properly allocate processor capabilities to the guest session. Key in evaluating processor workload is to look at sustained processor workload versus burst workload. Some applications use a lot of processing speed, but only to do periodic reports or transactions, which might be an end-of-day posting of information or a month-end or quarter-end task. Differentiate between sustained workload and periodic workload so that you don’t allocate two or four processors to a session when the processor transaction occurs only once a month. . Disk I/O workload—This refers to the demands a guest session places on the disk for reading and writing of information. In the normal processing of information, a guest session may read and write information periodically to disk. For some applica- tions, however, the guest session is constantly reading information, fetching data to place in cache, or writing transaction logs, data, or both simultaneously in the management of disk information. For guest sessions with high disk I/O workloads, you can assign dedicated disks to the virtual guest session rather than share a common disk storage system. If you dedicate the disk location, reading and writing of information should not cause an application to bottleneck (and thus you avoid degradation of performance of all other virtual guest sessions on the host server). . Network I/O workload—This refers to the demands a guest session places on a network adapter from sending and receiving data to other servers or systems on the network. Applications that are gateways or frontend servers to backend data stores may have significant network I/O because all traffic passes through a specific system. Guest sessions with significant network I/O can cause all the guest sessions to slow down if all the guest sessions share a single network adapter in the host system. By identifying the guest session that has high network I/O workloads, an administrator can add an additional network adapter to the server and dedicate the network adapter for a given guest session. Doing so allows the isolation of traffic from the guest session out to a network switch, and offloads the workload data from the shared host server resource. Other strategies in managing network I/O workload is to create a dedicated virtual switch within a Hyper-V host server where communica- tions between guest sessions is virtually dedicated in a core communication path that can be isolated from the network communications path of other guest sessions. By creating a virtual network switch between servers dependent on communicating to each other within a host server, you can greatly enhance communications between the servers, perhaps even increasing the speeds above those of traditional Download at www.wowebook.com ptg6432687 75 Logically Distributing Virtual Servers on Specific Host Systems Gigabyte Ethernet because the Hyper-V virtual network switch can communicate at native system bus speeds. . Guest session RAM requirements—Some virtual guest sessions have a high demand for memory allocated to the guest session, whether that’s 8GB or 16GB or 32GB for the session. Many applications use whatever available memory is given to the ses- sion to load data into RAM and cache the data to provide higher transaction fetch rates of the information when an application requires access to the information. For these applications, there appears to be no limit on how much memory the applica- tion requires; it uses whatever is available. It is important to test these applications to determine whether an optimal amount of memory can be allocated that provides a flatline return on performance. For example, an application may perform twice as fast with 4GB of memory than with 2GB of memory, but the same application gains no incremental improvement at 8GB or 16GB. These applications can then be capped at 4GB for the guest session, allowing any additional memory to be used for other guest sessions. Distributing Virtual Servers Based on Redundancy When choosing to distribute virtual guest sessions across virtual host servers, taking in account redundancy and high availability helps in deciding which guest server sessions to place on which host servers. As an example, placing both the primary cluster server and a passive backup cluster server on the same host system nullifies the benefits of clustering if the host server fails and both cluster nodes are brought offline. So, the placement of cluster pairs across two host servers as shown in Figure 3.1 will ensure that a guest session failure will remain operational on the second cluster pair session, and will ensure that a host server failure will also maintain operations of the second cluster pair on a separate host server system. 3 Virtual Session A Host A Virtual Session B Virtual Session C Virtual Session A Host B Clustered Pair Virtual Session B Virtual Session C FIGURE 3.1 Distributing servers to split systems across separate hosts for reliability purposes. Download at www.wowebook.com ptg6432687 76 Frontend A Host A Backend B Frontend A Host B Frontend Load Balanced Backend B Backend Clustered FIGURE 3.2 Frontend/backend server interrelationships. 3 Planning, Sizing, and Architecting a Hyper-V Environment Distributing Virtual Servers Based on Server Interrelationships When analyzing servers to determine where to logically place guest server sessions, look beyond just server performance demands. Also look at how servers interact with each other. In many applications, a frontend server and a backend server make up the client connection portion and the database portion of the application (for instance, Exchange, Office Communication Server, SharePoint), as shown in Figure 3.2. The frontend and backend pair are directly associated to each other, so from a redundancy standpoint, if either is offline, the application doesn’t operate. Therefore, splitting the applications across two hosts provides no benefit because the application doesn’t work unless both servers in the pair are operational. By placing the two servers on the same virtual host system and then establishing a virtual switch that allows the two applications to communication directly with each other inside the virtual host system, you can greatly improve the communications between the fron- tend and the backend server. Likewise, an Exchange server communicates regularly with a global catalog server to query distribution lists, email address lists, and the like. By placing a global catalog guest session on the same host server as an Exchange server, you can greatly improve the communications between the application server and directory server. Distributing Virtual Servers Based on User Connectivity Other factors to consider when deciding where to place virtual guest sessions include user connectivity and where users who need access to the host servers reside. If a physical server is in a remote site close to users and is then virtualized and centralized in a data Download at www.wowebook.com ptg6432687 77 Logically Distributing Virtual Servers on Specific Host Systems 3 Site A Users Physical Server A Site B Users Physical Server B FIGURE 3.3 Maintaining links between users and user data. center on the other side of a WAN connection, the performance between the users and the virtualized server needs to be taken in account. Although virtualization might be a good business decision to remove servers from remote locations to simplify administration and management, performance or reliability of information access across an unreliable or slow WAN link coul d si gnif icantly and neg ativ ely impact users accessing the ser vers . During the assessment process, identify where users are and how they interact with the servers, as illustrated in Figure 3.3. As you can see in this figure, a link is maintained between users and the data they access. Virtualize the server and centralize the system, but make sure to consider user access to the resource in the process. Distributing Virtual Servers Across a WAN Connection With regard to the virtualization process, many believe that migrating physical servers to virtual guest sessions in a consolidation process means that the host servers must be centralized in a single data center. However, if users are in remote locations, servers might need to be distributed closer to the remote users. Therefore, a virtual host system can be brought up in a remote location with physical servers in that remote location virtualized in the remote host system. A remote host system can also be used as a backup to a host server in a main data center location so that stretch clusters can be established between guest sessions in host servers in separate locations. Figure 3.4 shows this distribution of host servers across WAN connections; such a distribution can provide redundancy, fault tolerance, and disaster recovery of servers and applications for the enterprise. Download at www.wowebook.com ptg6432687 78 3 Planning, Sizing, and Architecting a Hyper-V Environment Site A Site B Failover for Appication A Appication A FIGURE 3.4 Distributing servers across a WAN for redundancy purposes. Choosing Servers to Virtualize When choosing to virtualize guest sessions, deciding which applications are the best candi- dates for virtualization is a key factor. Not all server applications can or should be virtual- ized. That’s not to say, however, that an organization can’t choose to virtualize 100% of their servers if desired. The key to choosing servers for virtualization is to first pick the servers that make perfect sense to virtualize, and then make the more difficult decisions about virtualizing other server systems. Prioritizing Servers to Virtualize As mentioned previously, some servers are prime candidates for virtualization—for example, servers that have low system resource utilization or where multiple servers exist for shear redundancy and recoverability. Other server systems that have high processor demands and excessive disk and network I/O requirements may not be the best servers to virtualize; during the physical to virtual server migration process, these servers may be the ones chosen for second-round migration. The process of converting physical servers to virtual servers takes several days, if not weeks, depending on the number of servers an organization has. Therefore, the organiza- tion should create a priority list and stage the migration in a logical manner. In many instances, the priority may be to virtualize a physical server that is failing. Make sure, however, that the rush to evacuate a server off faulty hardware into a virtual environ- ment doesn’t create more problems for the organization. Such a quick migration might not factor in whether the application works well in a virtualized environment, or whether the system resource demands of the application really suggest that the application should have instead been migrated off one physical server onto a new physical server. Candidates for Immediate Virtualization to Guest Sessions When organizations are prioritizing servers for virtualization, as noted, many server systems make perfect sense to virtualize. Server roles that are typically simple decisions to virtualize include the following: Download at www.wowebook.com ptg6432687 79 Choosing Servers to Virtualize 3 . DHCP servers—The Dynamic Host Configuration Protocol (DHCP) server assigns IPv4/IPv6 network addresses to devices on the network. Most organizations have at least one DHCP server, if not several, for both redundancy and to associate different IP addresses to different groups of users. However, DHCP servers rarely have more than 5% utilization and are prime candidates for server virtualization. . DNS servers—The domain name system (DNS) maintains a list of network servers and systems and their associated IP addresses. A DNS server is queried and responds with information. In general, however, DNS servers, like DHCP servers, rarely have more than 5% utilization. And because DNS servers are so critical in resolving server names and addresses, organizations generally have several DNS servers for redun- dancy. These systems are perfect candidates for virtualization. . Network policy servers—Network policy servers keep track of the policies required to allow users access to certain network resources, or they may maintain a list of users authorized to access specific network resources remotely. Remote Authentication Dial-in User Service (RADIUS) servers are a form of policy server, and with Windows Server 2008, Microsoft has introduced a server called the Network Policy Server (NPS). The NPS performs centralized connection authentication, autho- rization, and accounting for many types of network access, including wireless and virtual private network (VPN) connections. Because these policy servers are queried only when a policy requires validation, the demands on policy servers are pretty limited; they are therefore good candidates for virtualization. . Web servers—As more and more technologies become web aware and have web frontend interfaces for user access, enterprise web servers have proliferated. And because many Microsoft web-based frontend servers don’t work well when combined together, each frontend web server needs to be on its own server session. This multi- tude of web frontend servers can be virtualized and hosted on a limited number of virtual host systems. In this way, you combine the web servers without forcing the web applications to share the same guest session; instead, those guest sessions share the same host server system as dedicated virtual guests. . Certificate and Rights Management servers—As with network policy servers, cer- tificate servers and rights management servers are queried when certificates are required or when certificate or rights management policies are requested. Other than at those limited times, the certificate server or rights management server remains idle. Hence, certificate servers and rights management servers are prime candidates for virtualization. Secondary Candidates for Virtualization to Guest Sessions A number of application services can be virtualized. These services will be different for every organization, and so the decision to virtualize these servers must be organization specific. In general, however, the secondary candidates for virtualization to guest sessions include the following: . File servers—Most organizations have a lot of data stored on file servers, but the reality is that use access to the file servers is an occasional read and write of files Download at www.wowebook.com . ptg6432687 70 2 Best Practices at Planning, Prototyping, Migrating, and Deploying Windows Server 2008 Hyper-V . Create a scope of work detailing the servers that you want. Hyper-V Host System Environment . Sizing a Hyper-V Host System Without Existing Guest Data Whereas Chapter 2, “Best Practices at Planning, Prototyping, Migrating, and Deploying Windows 2008 Hyper-V,”. applications, there appears to be no limit on how much memory the applica- tion requires; it uses whatever is available. It is important to test these applications to determine whether an optimal