Microsoft Exchange, Lync, and SharePoint Server 2010 on Dell Active System 800v

Transcription

1 Microsoft Exchange, Lync, and SharePoint Server 2010 on Dell Active System 800v A Design and Implementation Guide with a sample implementation for 5,000 users Global Solutions Engineering

2 This document is for informational purposes only and may contain typographical errors and technical inaccuracies. The content is provided as is, without express or implied warranties of any kind Dell Inc. All rights reserved. Dell and its affiliates cannot be responsible for errors or omissions in typography or photography. Dell, the Dell logo, Force10, EqualLogic, OpenManage, and PowerEdge are trademarks of Dell Inc. Intel and Xeon are registered trademarks of Intel Corporation in the U.S. and other countries. Microsoft, Windows, Lync, SharePoint, SQL Server, and Windows Server are either trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. VMware, vsphere, ESXi, vmotion, vcloud, and vcenter are registered trademarks or trademarks of VMware, Inc. in the United States and/or other jurisdictions. Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Dell disclaims proprietary interest in the marks and names of others. April 2013 Rev 1.0 ii

3 Contents 1 Executive Summary Audience and Scope Introduction Dell Active System 800v Microsoft Exchange, Lync, and SharePoint Benefits of Application Co-existence Designing Microsoft Exchange, Lync and SharePoint 2010 on Dell Active System Design Principles Common Implications of Design Principles Design Implications for Exchange Server Design Implications for Lync Server Design Implications for SharePoint Server Reference Implementation of Microsoft Exchange, Lync and SharePoint for 5,000 users Virtual Machine Configurations Storage Networking Co-Existence of Exchange, Lync, and SharePoint Virtualization Rules Solution Recommendation Verification Methodology Performance Verification Recovery and Load Balancing Verification Conclusion Appendix A: Exchange Sizing with Combined Server Roles Appendix B: Configuring the Failover Cluster for Exchange DAG Nodes Tables Table 1. Active System Configurations... 4 Table 2. Solution Requirements Table 3. VM Configuration...12 Table 4. Exchange VMs Configuration...13 Table 5. Lync VMs Configuration...13 iii

4 Table 6. SharePoint VMs Configuration Table 7. SQL Server VM Configuration Table 8. Storage Configuration Table 9. Database Availability Group Storage Volumes Table 10. SQL Database Volumes Table 11. Application VM Resource Summary Table 12. Selecting Automation Level Table 13. Active System Solution Table 14. Exchange Thresholds and Performance...31 Table 15. Lync Audio/Video Thresholds and Performance Table 16. Lync Front End Thresholds and Performance Table 17. Lync SQL Database Thresholds and Performance Table 18. Quality of Service Statistics Table 19. SharePoint SQL Mirror Thresholds and Performance Table 20. SharePoint Application Pool Thresholds and Performance Table 21. SharePoint Web Front End Pool Thresholds and Performance Table 22. Manual DRS Rule Violation Recovery Time Table 23. Exchange Performance Test Plan Table 24. Exchange Performance in Steady State with Normal Load Table 25. Exchange Performance in Steady State with Peak Load Table 26. Exchange Performance in Degraded State with Normal and Peak Loads Figures Figure 1. High Level Architecture of Active System 800v... 3 Figure 2. Exchange Storage Mapping Figure 3. Example SCSI Mapping for Exchange Server Figure 4. SQL Storage Mapping Figure 5. Lync Storage Mapping...21 Figure 6. SQL SCSI Mapping Figure 7. SharePoint Storage Mapping Figure 8. Network Partitioning Figure 9. External Datacenter Connectivity Figure 10. Logical View Figure 11. Virtualization Rules Figure 12. Application VM CPU Figure 13. Storage Array Throughput iv

5 Figure 14. Exchange VM Memory and Processor during vmotion Figure 15. SharePoint Web Front End VM Memory and Processor during vmotion Figure 16. SharePoint SQL VM Memory and Processor during vmotion v

6 1 Executive Summary Traditional Information Technology (IT) infrastructures have been transformed with the use of virtualization technologies in the datacenters. Some of the benefits of virtualization, including consolidation and availability, have enabled creation of large clusters that are rich in hardware resources and are managed with virtualization and related software. These architectures improve the administrative management of underlying hardware resources and enable coexistence of different tiers of server applications on the same hardware. Microsoft Exchange, Lync, and SharePoint Servers are critical enterprise applications that businesses use to provide their employees with productivity tools, such as , instant messaging, document sharing, to accomplish their daily tasks. While these applications are critical to day-to-day business operations, it is important to correctly configure, deploy, and maintain them. Although these applications can exist in their own standalone silos, there is much to be gained by deploying these enterprise applications on a common virtualized infrastructure. By deploying these applications on the same virtualized infrastructure, deployment, configuration, maintenance, and administration become easier, which reduces hardware costs and administration time. Deploying all three server applications on the same infrastructure allows a single performance and utilization view of the storage, network, and server resources, and also prepares for the future since the next version of these enterprise applications share many server components across the entire suite. However, while these are substantial benefits, it is important to ensure that certain design principles guide the implementation decisions to ensure ease of maintenance, maximization of uptime, and flexibility in a dynamic datacenter. By following these high level design principles namely application high-availability, application best practices and performance, abstraction from underlying hardware, and resource consolidation Dell Active System 800v with Microsoft Exchange Server 2010, Lync Server 2010, and SharePoint Server 2010 can provide a consolidated solution that provides business users the tools they need to accomplish their work in a modern datacenter that is prepared for future technologies. Dell Active System 800v is a converged infrastructure solution that provides highly-available infrastructure resources. It is a pre-engineered, virtualized bundle that has already been extensively validated. Beginning with this bundle reduces deployment complexity and also ensures no infrastructure level problems. When deploying these applications together, hardware resources can be better used through consolidation of application roles and services, such as combining network load balancing, databases, and storage volumes, while improving administrative simplicity. Furthermore, by configuring the applications to allow for hardware abstraction, these applications can easily be moved around the virtual cluster provided by Active System. This ease in movement allows for transparent hardware maintenance. However, Exchange, Lync, and SharePoint also have application layer availability concerns, which can be addressed through proper implementation as shown in this and previous guides. This strategy presented in this design and implementation guide can be leveraged for deploying future versions of the applications, including Exchange, Lync, and SharePoint Server The previous guides that describe deploying these applications on Dell active System individually while maintaining the architecture design principles are Microsoft Exchange Server 2010: Design and Implementation on Dell Active System 800v, Microsoft Lync Server 2010: Design and Implementation on Dell Active System 800v, and Microsoft SharePoint Server 2010 Implementation on Active System 800v. 1

7 2 Audience and Scope This guide is intended for IT professionals and administrators interested in designing and deploying a custom-sized Microsoft Exchange, Lync, and SharePoint solution. The example implementation provides specifics for a custom-sized Exchange, Lync, and SharePoint solution consisting of up to 5,000 users on Dell Active System 800 with VMware vsphere. While the guide provides an overview of Active System 800v and the Microsoft server applications, the reader is expected to have an understanding of Exchange Server 2010, Lync Server 2010, and SharePoint Server 2010, as well as Dell Active System 800v, and familiarity with VMware vsphere 5.1. The audience for this paper is also expected to be familiar with converged infrastructure concepts such as Data Center Bridging (DCB). 3 Introduction This guide explores applying Microsoft Exchange Server, Lync Server, and SharePoint Server 2010 on Dell Active System 800v, which consists of best-in-class Dell Force10 switches, Dell PowerEdge servers, and Dell EqualLogic storage, utilizing the latest networking protocols to achieve converged networking. This paper concentrates on design principles which include high availability, application best practices, hardware abstraction, and resource consolidation. The implications of these design principles to the application servers are discussed, and then a sample implementation of these principles is architected for up to 5,000 users. This sample solution is then verified using a test methodology to evaluating key metrics of application performance. Consolidating these workloads onto one virtualized infrastructure reduces management complexity, simplifies hardware maintenance, and provides the end users with business critical applications with minimal down time. To evaluate the performance and validity of this consolidation, similar test methodologies and deployment practices to the previous individual guides were followed except for changes presented in the following sections. Those guides are presented below: Microsoft Exchange Server 2010: Design and Implementation on Dell Active System 800v Microsoft Lync Server 2010: Design and Implementation on Dell Active System 800v Microsoft SharePoint Server 2010 Implementation on Active System 800v 3.1 Dell Active System 800v Dell Active Infrastructure is a family of converged infrastructure solutions that combine servers, storage, networking, and infrastructure management into an integrated and optimized system that provides general purpose virtualized resource pools. Active Infrastructure leverages Dell s converged networking and modular server architecture to help IT rapidly respond to dynamic business demands, maximize datacenter efficiency, and strengthen IT service quality. 2

8 Figure 1. High Level Architecture of Active System 800v PowerEdge M1000e PowerEdge M620 PowerEdge M I/O Aggregators PowerEdge M I/O Aggregators PowerEdge R620 Force10 S4810 Force10 S4810 EqualLogic PS6110 LAN & iscsi SAN (Converged Network) As a member of the Dell Active Infrastructure family, the Active System 800 solution has been designed and validated by Dell Engineering. It is available to be racked, cabled, and delivered to a customer s site to speed deployment. Dell Services deploys and configures the solution so that it is ready to be integrated into the datacenter. This guide considers Active System 800 configured with VMware vsphere (Active System 800v). Dell Active System 800v intelligently combines Dell PowerEdge servers, Force10 switches, EqualLogic SAN, and VMware vsphere. It utilizes a networking technology called Data Center Bridging (DCB) that extends Ethernet to support the convergence of LAN and SAN traffics on a single physical pipe while guaranteeing lossless transport of iscsi traffic. A summary of the components can be found in Table 1 3

9 below. For complete details of Active System 800v, please refer to the Reference Architecture for Active System 800 with VMware vsphere. Table 1. Active System Configurations Component Hypervisor Server Converged Fabric Switch Storage Management Infrastructure Management Components Hosted in the Management Infrastructure Details Up to 2 x Dell PowerEdge M1000e chassis with up to 32 x Dell PowerEdge M620 Blade Servers and embedded VMware vsphere x Dell Force10 S x Dell PowerEdge M I/O Aggregator in each Dell PowerEdge M1000e chassis Up to 8 x Dell EqualLogic PS6110 series arrays 2 x Dell PowerEdge R620 servers with embedded VMware vsphere 5.1 hosting management VMs 1 x Dell Force10 S55 used as a 1Gb out-of-band management switch Dell Active System Manager VMware vcenter Server Dell Management Plug-in for VMware vcenter Dell OpenManage Essentials Dell EqualLogic Virtual Storage Manager (VSM) for VMware Dell EqualLogic SAN HeadQuarters (HQ) VMware vcloud Connector Dell Repository Manager 3.2 Microsoft Exchange, Lync, and SharePoint Combining Microsoft Exchange, Lync, and SharePoint 2010 locates all essential business communication and collaboration within Dell Active System, simplifying management while leveraging the benefits of virtualization and pre-configured converged infrastructure. These three products provide a better end-user experience by: Using a common address book within all three applications Sending s or scheduling meetings in Exchange using Lync contacts Calling Lync contacts using Outlook Seeing Lync presence status for users in SharePoint Microsoft Exchange 2010 is a popular solution for enterprise . Microsoft Lync 2010 is the application from Microsoft for real time communication such as instant messaging and presence, audio/video conferencing, and web conferencing (formerly known as live meeting). Microsoft SharePoint 2010 provides a web-based engine and a platform for deploying a wide range of business services, including collaborative sites, content management systems, publishing intranets, business intelligence systems, and Web portals. For interested readers, further details on all three of these workloads can be found in the following sections. Note: This design and implementation guide does not consider mobile clients, unified messaging with Lync and Exchange, enterprise voice, or uses of SharePoint outside the scope of team collaboration. 4

10 3.2.1 Exchange Server 2010 Exchange Server 2010 is the leading enterprise messaging system and is comprised of multiple Exchange server roles. An Exchange Server role is an application layer entity, and multiple roles can be collocated on a single server. The server roles most relevant to an Exchange deployment are described below: Mailbox Server Role: A back-end server capable of hosting mailboxes and public folders. Multiple Mailbox Server roles can be clustered using a Database Availability Group (DAG). Client Access Sever Role: A server role that supports all messaging clients, such as Outlook, mobile cellular devices, and Exchange Web Services. Hub Transport Server Role: A routing server that routes a message within the Exchange organization. Unified Messaging Server Role: Responsible for connecting a Private Branch Exchange (PBX) system to Exchange topology and helps combine voice and messages to a single infrastructure. Exchange Server architecture allows collocation of multiple server roles as application level entities on a single physical or virtual server. A configuration consisting of multiple server roles, for example Mailbox, Hub Transport, and Client Access server roles, that are collocated on a single server is referred to as Exchange Multi-role server configuration and is used in the example implementation in this guide. Note: This guide concentrates primarily on the collocation of Mailbox, Client Access, and Hub Transport server roles in the contexts of the design and implementation. Unified Messaging Server role and Exchange clients corresponding to mobile cellular devices are not considered in this study Lync Server 2010 Lync Server 2010 enables instant messaging and presence, audio and video conferencing, web conferencing, and voice-interoperability. To support these features, there are four server types required in this deployment: Front End Server Role: A Lync server role for client registration, also known as login, presence status and contact card feeds, address book retrievals, instant messaging, and web conferencing. AV Conferencing Server Role: This Lync server role supports audio and video meetings. Archiving and Monitoring Server Role: This Lync server role monitors user statistics and Quality of Experience (QoE) within Lync, as well as archives conference content and instant messages for future audits. SQL Database: A Microsoft SQL Server provides databases for the Lync Front End, Archiving, and Monitoring roles. This server is used to retrieve contact lists and store transient presence data, as well as keep records for the archiving and monitoring functions. Note: This guide does not consider Mediation Server and Enterprise Voice. This additional functionality can be added by the use of Session Initiation Protocol (SIP) Trunks, PBXs, or voice gateways to communicate with users on the telephony network (PSTN). Dell Global Infrastructure Consulting Services can assist with this functionality. 5

11 3.2.3 SharePoint Server 2010 For best practices, SharePoint Server 2010 is designed with three-tier architecture as follows: Front End Servers: SharePoint Server is installed on these servers to provide end user access through a hardware network load balancer, enabling end user access. Application Servers: SharePoint Server is installed on these servers and additional SharePoint application services, such as search indexing, are configured. Databases: a highly available Microsoft SQL Server is installed on these servers to provide storage for the SharePoint application. This design utilizes mirroring to provide highavailability; therefore, an additional SQL witness server is needed. Unlike Exchange and Lync Server, there are no SharePoint server roles. Instead, for Front End Servers and Application Servers, the SharePoint Server application itself is installed. Front End Servers are then configured for client access and Application Servers are configured differently to provide SharePoint application services such as Search. The SharePoint database is a Microsoft SQL Server deployment that is connected to the Front End and Application Servers. The Front End access should have a network load-balanced path to the SharePoint users through either a hardware or software load balancer. This implementation uses a virtual hardware load balancer appliance. The Application server has search services configured and runs the search crawl. Note: This guide focuses on the recommendations and reference implementation for the SharePoint collaboration workload only. 3.3 Benefits of Application Co-existence Active System provides several benefits when running Exchange, Lync, and SharePoint Server on the same converged infrastructure, including increased hardware flexibility, ease of infrastructure maintenance, and easier administrative tasks. Due to Active System s infrastructure, the applications can easily move from host to host while maintaining best practices. By abstracting specific hardware details, such as the physical host, and the storage location, the application virtual machines (VMs) movement greatly benefits maintenance and administration. The infrastructure s lifecycle management, such as firmware updates or memory increases, can be done seamlessly by moving application VMs to other hosts in Active System. By moving VMs, the administrators can perform maintenance tasks while the application uptime is maintained. By specifying and configuring applications correctly, these benefits from Active System can be achieved while maintaining all best practices and a good end user experience. Furthermore, these enterprise applications, when deployed on a single converged infrastructure, benefit from the synergy across the products, easy ways to evaluate performance, and are better prepared for the future. Typically, these applications are run in silos, preventing an overall view of how the collaboration and communication tools are performing. By deploying on a single infrastructure, administrators can quickly debug, view performance, and manage the hardware for these applications. This benefit is exemplified by EqualLogic SAN HQ, where viewing EqualLogic performance and utilization can quickly provide an overview of the space, throughput, and RAID used for the storage volumes of all these applications. In a traditional deployment, these storage volumes would be spread across multiple servers or storage arrays, making it difficult to adequately gauge storage performance and space. 6

12 Additionally, Lync and SharePoint databases can be collocated, and utilizing the same virtual load balancer appliance provides synergy between all three applications. Consolidating the same underlying hardware makes sense since these applications integrate server components. This coexistence prepares the deployment for the future, since the 2013 version of these applications integrates even more features, leveraging each the shared infrastructure. 4 Designing Microsoft Exchange, Lync and SharePoint 2010 on Dell Active System To design a robust solution, it is helpful to create principles that guide implementation decisions. These design principles are high-level concepts that must be considered for each individual application and at every layer of the infrastructure. The details of these design principles are presented below and are followed by their impact to Microsoft Exchange, Lync, and SharePoint servers. 4.1 Design Principles While Active System follows a number of design principles, such as Infrastructure high availability, virtualization, and networking best practices, there are additional principles that must be considered for the deployment and configuration of Exchange, Lync, and SharePoint Servers on Active Infrastructure. These additional design principles are goals that drove every aspect of this combined application design when running on Dell Active System: High Availability Application Best Practices and Performance Hardware Abstraction Resource Consolidation Deploying high availability of the solution is critical as a principle to ensure minimal business downtime. High availability must be considered at each layer of the solution, including the infrastructure, VM, and application. Installing the application correctly and ensuring that the application s performance remains above appropriate thresholds, even during degraded scenarios, is necessary for the business to function properly. One of the goals of this virtualized converged infrastructure is to abstract hardware requirements from the applications that run on that hardware. This hardware abstraction reduces administrative complexity, but it must be done while ensuring that the high availability and application performance principles are not compromised. Lastly, consolidation of VMs, storage arrays, network load balancing, and databases, while maintaining application s best practices, reduces resource cost and administrative time High Availability High availability is a feature that must be considered at every layer, and Dell Active System makes architecting such a solution easy. This document is concerned with three layers of High Availability that are presented below. Infrastructure availability is provided by Active System to ensure when a hardware resource fails, there is another storage drive, storage array, network path, server, etc. that provides the same resource. 7

13 Hypervisor availability brings application VMs back up on other hosts after hardware failure. Application level availability entails utilizing pools of application servers to provide a highly available service. If infrastructure fails, infrastructure availability provided by Active System ensures there is an additional hardware resource, and the application level availability will keep the application service up to end users, but since there are fewer VMs running the application, these services are now in a degraded state. Hypervisor availability automatically moves VMs to other available physical hosts to reduce the time that an application is in a degraded state. While these two levels of availability relate to the end user access to the application service, the application data also needs to sustain a storage failure. This solution deploys multiple copies or leverages mirroring to ensure application data availability in the event of a storage array failure. This ensures that user data will persist even through a hard drive or storage array failure Application Best Practices and Performance While maintaining high availability is critical, applications must still perform well to ensure a good end user experience. Following application best practices helps prevent performance bottlenecks, and by validating and verifying performance under load generation, the application s performance will be known. Several high level concepts are dictated by following best practices and performance. These high level concepts are listed below: Memory ballooning for memory intensive applications should not be used, as specified by that application role s best practices. vcpu to physical core ratio must be maintained at one-to-one. No co-existence of critical application services on the same host. Dedicated hard drive spindles for certain application s critical data as specified by best practices. Raw Device Mapping and Hardware iscsi is needed to avoid performance bottlenecks while accessing data from EqualLogic SAN Hardware Abstraction Abstracting specific hardware from the application services reduces complexity and ensures that the application is load balanced across the entire cluster. Applications can be decoupled from their underlying hardware, as long as best practices from the infrastructure and application layer are maintained. Using a virtual cluster with VM failover and performance load balancing provides this abstraction. VM failover allows the application VMs to be moved around from server to server within the cluster for maintenance or in the event of server failures. However, certain application VMs cannot co-exist amongst themselves or with other application VMs for performance reasons. By creating rules, certain VMs can be forced not to co-exist on the same physical server with other VMs. Note: Certain application VMs are not supported to migrate while end users connect to their services. Configuring the automation level appropriately can enable or disable the VM migrations while these VMs are running Resource Consolidation While running a solution that combines Exchange, Lync, and SharePoint servers on the same infrastructure, resources can be consolidated to reduce the overall hardware needed. 8

14 A virtual hardware load balancer appliance is easily shared across all three applications, reducing the number of VMs and their technical requirements. Shared SQL servers can be used by applications to reduce resources and licenses. A single virtualized cluster allows VMs to reside on the same shared storage array, reducing hardware resource cost. Sharing storage arrays for application data also reduces costs as long as application best practices and performance is met. 4.2 Common Implications of Design Principles Dell Active System was designed around similar principles for high availability, efficiency, and extensibility. The solution presented below incorporates the above design principles in addition to the principles used by Active System. Additionally, this design utilizes a shared VM datastore, storage Raw Device Mappings, and NIC Partitioning Shared VM Datastore The VMs can be stored on the same shared VM datastore, allowing high availability and satisfying Active System requirements. The VM root partition or C:\ drive is stored on this shared storage space. By storing these system files in a shared volume, the VMs can be moved from host to host. This shared VM volume should be placed on a high performing EqualLogic storage array, as specified by Active System Raw Device Mapping for Application Data Each application requires additional storage for data volumes, requiring the use of Raw Device Mapping (RDM). DCB allows for storage and web traffic to be converged on a single fabric while guaranteeing a fixed network bandwidth for storage traffic. To ensure that storage traffic is not impacted by LAN traffic, DCB must be implemented for the entire path, and for Active System, DCB stops at the Broadcom network card. Therefore, RDMs in vcenter allow for EqualLogic storage volumes to be added to VMs directly without utilizing the non-dcb hypervisor storage path VLANs for Logical Separation of Network Traffic Lastly, each application requires additional Virtual Local Area Networks (VLANs) for logical separation of network traffic and to benefit from network load balancing. A virtual hardware load balancer appliance is shared across all three application servers. This load balancer appliance is deployed as an active-passive pair to provide highly-available end user access to the services. Each application requires network separation by adding port groups to the specific NIC partitioning scheme implemented by Active System. 4.3 Design Implications for Exchange Server The design principles influence the way the Exchange solution is configured and deployed. To ensure these principles are met, Exchange requires using a Database Availability Group (DAG), dedicated storage hardware, and consolidation of exchange server roles. These facets of the Exchange architecture are discussed below. High availability at the application level recommends the use of DAGs in the Exchange architecture. To complement the application high availability, Exchange should be designed to use a DAG in conjunction with hypervisor availability to resume from a degraded state caused by mailbox server 9

15 failures. The use of DAG also ensures multiple copies of the mailbox database, and thus the application is able to recover automatically from any server, storage controller, or disk hardware failure with little to no impact to the end user experience. Application best practices and performance recommend having dedicated compute and memory resources for Exchange VMs, along with a dedicated set of spindles and storage controllers, for each copy of the Exchange mailbox databases. In addition, a DAG also requires each copy of the database to be located on a separate set of drives and have separate storage controllers. Application best practices also prohibit two or more DAG nodes to co-exist on same physical host. For performance reasons, Exchange VMs running the mailbox server role must interface with the database storage according to the application best practices. Due to resource consolidation, Exchange benefits from a virtual network hardware load balancer appliance, allowing Exchange multi-role server configuration. Using a multi-role server configuration requires fewer Exchange VMs and fewer resources. Note: For additional information refer to best practices for virtualizing Exchange Server 2010 and Exchange Server 2010: Design and Implementation on Dell Active System 800v. 4.4 Design Implications for Lync Server Lync Server is impacted by all four of the design principles high availability, best practices, hardware abstraction, and consolidation and benefits from these goals by providing good end-user access and functionality as well as ease of maintenance and manageability. Lync provides high availability by creating server pools for critical Lync end-user functionality, such as client registration and status updates, instant messaging, and audio/video conferencing. Hypervisor availability is leveraged for its SQL Server and collocated Archiving and Monitoring Server. A short service interruption can occur with presence updates and contact lists should there be a SQL Server VM failover. During this time, users will continue to use conferences and have access to address books. Hardware abstraction is leveraged for the Lync Servers and SQL Server. Each of these VMs is placed on a shared VM datastore, thereby decoupling the OS and application from the hosts. This feature is particularly useful for Lync Backend SQL VM, allowing it to fail over to another host with minimal loss of functionality. Since Microsoft does not support live migrations of VMs running the Lync server application, their high availability must be configured correctly. Refer to the Quick Migration and Live Migration Support section in the Server Virtualization in Microsoft Lync Server 2010 white paper for additional information on Lync live migration support. To maintain application best practices and performance, VMs running the same Lync Server Role should reside on different hosts. The application deployment is per best practices as specified in Server Virtualization in Microsoft Lync Server 2010 with sufficient vcpu and memory allocation. As was the case in the Lync Design and Implementation Guide, the best practices require separate VMs for each of the Front End and AV Conferencing roles on separate hosts. For consolidation, Lync shares its Back End and Archiving and Monitoring SQL Server installation with the SharePoint SQL witness. This consolidation reduces hardware resources, but also has further implications in the VM configuration. For better manageability and security, two separate instances are used for these distinct functions, while leveraging the benefit of a single SQL Server. This stacking of 10

16 instances is useable in this scenario since the second SQL instance for SharePoint SQL witness does not cause any noticeable CPU, memory, or IO contention. Additionally, if the application still performs with no IO bottlenecks, both SharePoint and Lync can utilize the same storage arrays, since this does not violate best practices. 4.5 Design Implications for SharePoint Server To design SharePoint to co-exist with an Exchange and Lync Servers, the aforementioned design principles should be applied. These principles impact how the SharePoint farm is configured and its dependency on the Lync deployment. The SharePoint servers provide high availability through a web front end pool and application search service pool. These pools continue to provide application availability while the hypervisor availability is relocating failed VMs. SharePoint stores all its data in a SQL server, so it is critical this database is available and redundant for application best practices and performance. To accomplish this, a mirror is used between a primary SQL server and a secondary SQL server, and each SQL server stores its data on separate spindles and storage controllers. A SQL witness server provides automated failover between these mirrored servers, and for consolidation purposes, hosts Lync s databases as well. SharePoint can be used for many different purposes, but it is important to remember this SharePoint implementation has been validated only for one SharePoint site for collaboration purposes, following Microsoft s Best Practices for Virtualization (SharePoint Server 2010). 5 Reference Implementation of Microsoft Exchange, Lync and SharePoint for 5,000 users The design principles and their implications on each of server applications must be considered while implementing architecture with up to 5,000 users for Exchange Server 2010, SharePoint Server 2010 and Lync Server With that target of 5,000 users in mind, this design follows the principles for all three applications with 5,000 users who are accessing all three services simultaneously from their respective client devices. As can be seen in Table 2, the solution does not include Active Directory and DNS within the architecture, but these will be required to be hosted somewhere in the customer environment. Furthermore, it presents a suggested Lync edge server configuration to allow for external user access, but these servers are not included in Active System. Table 2. Solution Requirements Specification Targeted users Up to 5,000 Concurrency 100% Required but not included in solution 5.1 Virtual Machine Configurations Details Active Directory and DNS and edge access servers Each application requires specific virtual CPU, memory, networking, and storage volumes to be configured following the design principles so that the application has the appropriate resources. In this design, Exchange, Lync, and SharePoint are deployed on virtual machines with the roles 11

17 distributed according to Microsoft best practices. Each VM runs Windows Server 2008 R2 SP1, with a 250 GB thick eagerly provisioned VMDK hard drive format. This thick VMDK is recommended by Microsoft for performance reasons. Utilizing a hardware load balancer virtual appliance reduces complexity of the network design by taking advantage of vsphere virtual switch port groups in order to connect to the application networks. This guide presents suggestions for the hardware load balancer VM configuration, but the reader must refer to the respective vendor s load balancer virtual appliance manual for appropriate configuration. Table 3 summarizes these aspects of all VMs in the solutions, and the following sections discuss more specifics about each individual VM as dictated by the application. Table 3. VM Configuration Specification VM Operating System VM Hard Drives Hardware Load Balancer Details Windows Server 2008 R2 SP1 250 GB Thick Eagerly Provisioned VMDK Virtual Machines with High Availability See hardware load balancer manual for specific VM configuration Exchange VM Configuration The deployed Exchange solution uses Exchange Server 2010 SP2 in a VMware vsphere-based virtualized infrastructure. For application-level high availability, a two copy DAG is used in conjunction with the hypervisor high availability. From the hardware abstraction principle, this Exchange solution makes use of virtual servers with appropriately sized processor and memory. The virtual processor and memory sizing is carried out based on Microsoft s sizing best practices for multiple server role configuration. From the application best practices and performance principle, the memory is locked per virtual machine. The two-copy DAG leverages a dedicated storage array per copy that has dedicated storage controllers and spindles. The VMs running the mailbox server role make use of Raw Device Mappings to host the database volumes. The Exchange storage design for the DAG is described in Section of this paper. For consolidation, the Exchange server deployment consists of three multi-role Exchange virtual machines running Windows Server 2008 R2 SP1 as the guest operating system. The multi-role configuration consists of Mailbox, Hub Transport, and Client Access Server roles collocated on a single virtual server. One virtual network adapter is dedicated to each of the public and private networks. Note that each VM type lists an additional virtual NIC for the management network which can be configured according to customer specifications. A summation of this configuration is presented in Table 4. 12

18 Table 4. Exchange VMs Configuration Server Role Exchange Multi-role VMs Configuration 3 x Mailbox, Hub Transport and Client Access server roles collocated on each VM. 6 vcpus per VM 48 GB Memory per VM 2 x VMXNet 3 Virtual Network Adapter per VM with one each for public network and private network. 1 x VMXNet 3Virtual Network Adapter per VM for the optional management network Lync VM Configuration The Lync VMs use Lync Server 2010 Enterprise Edition and SQL Server 2008 R2 SP1 Enterprise Edition on Windows Server 2008 R2 SP1. Lync Server requires three different types of application VMs and a database server VM. The Lync database server configuration is presented in Table 5. In this configuration, the SQL backend database and the Monitoring and Archiving database are consolidated on a single SQL VM. This is different from the Microsoft recommendation of two VMs, per the Scale Comparison Table Physical-Virtual section in the Server Virtualization in Microsoft Lync Server 2010 guide. In this study, the SQL VM was provisioned with 28 GB of memory and four vcpus as shown in Table 7. Tests showed that these resources were more than enough to meet resource requirements for up to 5,000 users. In Table 5, each VM type lists an additional VMXNet 3 Virtual Network Adapter for the management network, which can be configured according to customer specifications. The VMs are sized according to application best practices and the individual information can be seen below: Table 5. Lync VMs Configuration Server Role Front End VMs Audio/Video Conferencing Server VMs Collocated Archiving and Monitoring VM Configuration 2 x Front End Lync Server Role VMs 4 vcpus per VM 11 GB Memory per VM 1 x VMXNet 3 Virtual Network Adapter per VM for Lync Application Network 1 x VMXNet 3 Virtual Network Adapter per VM for the optional management network 2 x Audio, Video Conferencing Lync Server Role VMs 4 vcpus per VM 11 GB Memory per VM 1 x VMXNet 3 Virtual Network Adapter per VM for Lync Application Network 1 x VMXNet 3Virtual Network Adapter per VM for the optional management network 1 x Collocated Archiving and Monitoring Lync Server Role VMs 4 vcpus 8 GB Memory 13

19 Server Role Configuration 1 x VMXNet 3 Virtual Network Adapter per VM for Lync Application Network 1 x VMXNet 3 Virtual Network Adapter per VM for the optional management network SharePoint VM Configuration The SharePoint Server deployed in this guide is based on SharePoint Server 2010 SP1 Standard edition, utilizing two Web Front End VMs for client access, two application VMs for search services, and storing its data in a SQL server mirror. Table 6 summarizes the configuration for the Web Front End VMs and Application VMs. Note the SQL servers are detailed in Section 5.1.4, since they are consolidated with the Lync application. This solution remains unchanged from the previous SharePoint 2010 Implementation on Active System 800v, relying on a web network, an application network, and a SQL private network that is included in the SQL VM configuration section. Note that each VM type lists an additional virtual network adapter for the management network, which can be configured according to customer specifications. Table 6. SharePoint VMs Configuration Server Type Web Front End VMs Application VMs Configuration 2 x VMs with SharePoint Application Service 6 vcpus per VM 16 GB Memory per VM 1 x VMXNet 3 Virtual Network Adapter per VM for SharePoint Web Network 1 x VMXNet 3 Virtual Network Adapter per VM for SharePoint Farm Network 1 x VMXNet 3 Virtual Network Adapter per VM for the optional management network 2 x SharePoint Service VMs with two Search services configured 4 x vcpus per VM 8 GB memory 1 x VMXNet 3 Virtual Network Adapter per VM for SharePoint Farm Network 1 x VMXNet 3 Virtual Network Adapter per VM for the optional management network SQL VM Configuration This solution requires three Microsoft SQL Server 2008 R2 SP1 Enterprise Edition installations. To create a highly-available SharePoint application, SharePoint requires a SQL mirror pair with a SQL witness that is configured on the SQL VM shared with Lync. The SQL pair consists of a primary and secondary VM with a configuration of six vcpus and 64 GB virtual memory per VM. The SharePoint content is stored in the primary SQL server and is copied to the secondary SQL server. 14

20 Table 7. SQL Server VM Configuration Specification SharePoint SQL VMs SharePoint SQL witness and Lync Database VM Details 2 x SharePoint SQL Database VMs with Primary and Secondary in a Mirror Configuration 6 x vcpus per VM 64 GB Memory per VM 1 x VMXNet 3 Virtual Network Adapter per VM for SQL Private Network 1 x VMXNet 3 Virtual Network Adapter per VM for SharePoint Farm Network 1 x VMXNet 3 Virtual Network Adapter per VM for the optional management network 1 x SharePoint SQL witness Instance and 1 x Lync SQL Instance VM 4 x vcpu 28 GB Memory 1 x VMXNet 3 Virtual Network Adapter per VM for Lync Application Network 1 x VMXNet 3 Virtual Network Adapter per VM for SharePoint Farm Network 1 x VMXNet 3 Virtual Network Adapter per VM for the optional management network In case the primary SQL server is not available on the SharePoint Farm Network, the SQL Witness will switch the database connection to the secondary SQL server automatically. For consolidation, this SQL server witness instance is collocated with the Lync SQL Server instance. Therefore, this server contains two SQL instances: one for SharePoint SQL witness that utilizes the SharePoint Farm Network and one to store the Lync s databases which are accessed through the Lync Application Network. These databases are on two separate instances for easy maintenance and service separation. As can be seen in Table 7, this SQL witness and Lync Database VM has been provisioned with 4 vcpus and 28 GB of virtual memory with 3 network adapters, with one for a management network that is configured according to customer specifications. 5.2 Storage There are two components to storage. The first component is the VM datastore, which is needed for vsphere high availability. By storing the VMs on shared iscsi EqualLogic storage, each PowerEdge M620 virtual host can run the Exchange, Lync, or SharePoint VMs. A single EqualLogic array is used for this store configured as RAID 10, as recommended by Active System. The second component contains the Application storage. It consists of two EqualLogic PS6110X arrays for Exchange and two arrays for Lync and SharePoint. The arrays for Exchange are separated from the arrays for Lync and SharePoint to minimize disk contention. Further details are shown in Table 8 15

21 Table 8. Storage Configuration Storage Array VM Storage Array 1 Exchange Storage Array 2-3 SPL Storage Array 4-5 Purpose VMFS Virtual Hard Drive shared with Active Infrastructure 1 x Dell EqualLogic PS6110X; 900GB 10k hard drives 2 x Dell EqualLogic PS6110X; 900GB 10k hard drives for Exchange Mailboxes 2 x Dell EqualLogic PS6110X; 900GB 10k hard drives for Lync and SharePoint Storage Exchange Storage Sizing storage for Exchange primarily consists of two aspects: sizing for the capacity requirements per copy in the DAG and identifying the IOPS requirements per copy. The reference storage solution requirements considered in this guide are identical to those considered in the Design and Implementation guide for Exchange. Please refer to the Sizing and Configuring Storage section described in the earlier study for more information. Per the design, there are a total of 18 Mailbox Databases with nine Active Mailbox databases and nine Passive Mailbox databases spread across two EqualLogic arrays, so that each Active Mailbox and its corresponding Passive Copy are on separate arrays. The summary of the DAG and the DAG layout is shown in Figure 2 and Table 9. Volume Table 9. Database Availability Group Storage Volumes Size per DB/volume Storage Array 5 x Active Mailboxes Databases 1.2 TB Exchange Storage Array 2 4 x Passive Mailboxes Databases 1.2 TB Exchange Storage Array 3 4 x Active Mailboxes Databases 1.2 TB Exchange Storage Array 2 5 x Passive Mailbox Databases 1.2 TB Exchange Storage Array 3 Restore Volume TB Exchange Storage Array 2 Restore Volume TB Exchange Storage Array 3 16

22 Figure 2. Exchange Storage Mapping Note: The restore LUNs are not shown in above figure. Accurately balancing the storage LUNs across the available virtual SCSI adapters at the VM level is crucial for performance. VMware provides four virtual SCSI adapters for each VM and fifteen disks per virtual SCSI adapter. A virtual device node can be mapped as SCSI (controller: disk). It should be ensured that the LUNs corresponding to the active and passive databases should be evenly balanced across the available virtual SCSI adapters. Typically, controller 0 is utilized to map the device node for the guest OS image. It is not recommended to use the same SCSI controller as that of the guest OS image for Exchange database LUNs. The remaining three SCSI controllers can be used to map six device nodes as six database LUNs. One such mapping for one of the three Exchange Multi-role servers is shown in Figure 3. 17

23 Figure 3. Example SCSI Mapping for Exchange Server SQL Storage for Lync and SharePoint Both SharePoint and Lync store all their data in a SQL database. SharePoint uses two SQL servers configured in a mirror. This mirror requires a SQL witness server, which is consolidated with Lync s databases. Besides combining the SQL witness and Lync SQL databases, the configuration remains exactly the same as the previous SharePoint Design and Implementation Guide and Lync Design and Implementation Guide. Since SQL stores all the data for SharePoint, its availability and performance is critical. For application best practice, each database requires its own separate EqualLogic volume mapped using Raw Device Mappings (RDMs). For a summary of all the database volumes, refer to Table

24 Table 10. SQL Database Volumes Application Requiring Databases Volume Size Storage Array Primary Content Database 2 TB SPL Storage Array 4 Secondary Content Database 2 TB SPL Storage Array 5 SharePoint Lync Primary Content Logs 200 GB SPL Storage Array 4 Secondary Content Logs 200 GB SPL Storage Array 5 Primary Temp Database 50 GB SPL Storage Array 4 Secondary Temp Database 50 GB SPL Storage Array 5 Primary Search Database 200 GB SPL Storage Array 4 Secondary Search Database 200 GB SPL Storage Array 5 WSSUsage Database 100 GB SPL Storage Array 4 Primary Config Admin Database 100 GB SPL Storage Array 4 Secondary Config Admin Database 100 GB SPL Storage Array 5 Rtcdyn Log 10 GB SPL Storage Array 4 Rtc Log 20 GB SPL Storage Array 4 Rtcdyn Data, Rtc Data, ABS Data, AppStore Data 250 GB SPL Storage Array 4 ABS Log, AppStore Log 25 GB SPL Storage Array 4 Archiving Log, Monitoring Log, CDR Log Archiving Data, Monitoring Data, CDR Data 320 GB SPL Storage Array GB SPL Storage Array 5 19

25 Figure 4. SQL Storage Mapping The placement of these database storage volumes is important to create high availability. The primary SQL databases for SharePoint included Content DB Data, Content Log, Temp DB, Search Property, Config Admin, and WSS Usage should exist on one storage array while the secondary copies Content DB data, Content Log, Temp DB, Search Crawl, and Config Admin should reside on another storage array. To achieve this, each storage array is given its own EqualLogic pool and the volumes are then mapped according to the specific SQL primary or secondary VM. For Lync, the databases are not mirrored and but can still exist on the same storage arrays as SharePoint without impacting application performance. This assertion is shown in the Validation section. However, to allow the Archiving, Monitoring, CDR Log, and Archiving, Monitoring, and CDR Data to grow, they are placed on the secondary storage array. 20

26 Microsoft Exchange, Lync, and SharePoint Server 2010 on Dell Active System 800v Figure 5. Lync Storage Mapping Lync Front End Pool Lync Front End LFE1 Lync Front End LFE2 Lync Archive & Monitor LAM1 SharePoint SQL Witness and Lync Database SPLSQL3 RTC Dyn RTCdyn, RTC, ABS, AppStore Log Data RTC Log ABS, AppStore Log SPL Storage Array 4 Archiving, Monitoring, CDR Log Archiving, Monitoring, CDR Data SPL Storage Array 5 As can be seen in the Figure 5, the storage volumes are mapped to the SharePoint SQL witness and Lync Database (SPLSQL3) and from there are accessed by the Lync Front End and Lync Archive and Monitor VMs through the Lync application network. Since application and infrastructure best practices cause all of these storage volumes to be mapped through RDMs, balancing the connections across separate virtual SCSI controllers is important. For all VMs, the first SCSI 0 controller is used to map to the VM datastore. In Figure 6, the volumes are then distributed evenly across virtual SCSI controllers 1, 2, and 3 for the Primary SQL Server, Secondary SQL server, and the SQL witness and Lync Database SQL server. 21

27 Figure 6. SQL SCSI Mapping SharePoint Search Service Storage SharePoint also requires four search index volumes. These volumes provide storage for the search service which is installed and configured on SharePoint App 1 and 2 VMs. This storage volume is mapped directly to these VMs, instead of being mapped to the SQL Primary Server or SQL Secondary Server. As shown in Figure 7, Search Index 1, Search Index 1m, Search Index 2, and Search Index 2m storage volumes are mirrored by the search service installed on the SharePoint Application VMs. Again, these volumes should be added to the VMs using RDM and mapped across two virtual SCSI controllers per VM. 22

28 Figure 7. SharePoint Storage Mapping 5.3 Networking Active System 800v enables rapid deployment of the application networks. According to Active Infrastructure principles, each application network is deployed as a separate workload VLAN that is defined in the datacenter core network. As shown in Figure 8, Active system provides two 10 Gigabit Ethernet ports labeled as Broadcom All of the Workload VLANs are created as port groups on a single vswitch across these two network connections. These VLANs include the Exchange Public VLAN, which provides connectivity between the Exchange servers and the Active Directory domain, and the Exchange private VLAN for the traffic between its servers. Lync traffic, on the other hand, is carried on a single VLAN, the Lync Public VLAN. For the SharePoint application, Web VLAN and Farm VLAN are dedicated to the application s Web traffic and Farm traffic respectively. Additionally, a SQL Private VLAN is created for the SharePoint SQL mirror replication traffic. Lastly, an application management network for every VM can be added, typically requiring an additional VLAN according to the customer s needs. 23

29 Figure 8. Network Partitioning vswitch Lync App (VLAN L) SharePoint Web (VLAN M) SharePoint Farm (VLAN N) Exchange Public (VLAN P) Exchange Private (VLAN Q) HLB Private (VLAN R) SQL Private (VLAN S) vswitch vswitch vswitch Management (VLAN B) vmotion vmk (VLAN C) iscsi-1 (VLAN E) iscsi-2 (VLAN E) NIC 0 NIC 2 NIC 4 NIC 6 NIC 1 NIC 3 NIC 5 NIC 7 NPAR NPAR 1 2 Broadcom To maintain application best practices, networks should be segregated through the use of VLANs, and each application is load balanced to allow end user access. In order to achieve network load balancing the Exchange Public, Lync App and SharePoint Web VLANs are connected to a pair of highly available virtual hardware load balancers, HLB1 and HLB2. One VM is configured as the active load balancer, while its peer is the standby load balancer; the latter becomes primary in the event of a failover. These virtual load balancers can move across hosts only when they are in the passive state and have no active connections. As seen in Figure 9, all client connections to the Exchange, Lync Front End and SharePoint Web Front End servers are routed to the primary load balancer through a virtual IP address. The connections are then load balanced across all servers for each application. Figure 9 shows these hardware load balancers and how they connect to the external customer datacenter. Note that the domain controller, firewalls, edge servers, and datacenter networking are outside the scope of Active System, and Dell services can help design a specific solution for each individual customer s environment. 24

30 Microsoft Exchange, Lync, and SharePoint Server 2010 on Dell Active System 800v Figure 9. External Datacenter Connectivity Active System 800 Lync 2010 Servers Hardware Load Balancer HLB1 Hardware Load Balancer HLB2 Network Key SharePoint 2010 Servers additional resources for other workloads SharePoint Web SharePoint Farm Lync App Exch Public HLB Private Customer Defined Hardware Load Balancer Pool Exchange 2010 Servers Internal Network Edge Server Pool Active Directory Domain Active Directory Domain Controller(s) 5.4 INTERNET Reverse Proxy Internal Firewall External Firewall Co-Existence of Exchange, Lync, and SharePoint When these three application servers co-exist on Active System, there is an opportunity to consolidate hardware resources. Thereby fewer storage arrays and servers are needed as compared to them being deployed in their own standalone silos. As can be seen in the Table 11, Exchange requires three VMs with a total of 24 vcpus and 144 GB of memory configured. It utilizes a private and a public network, and requires 20 storage volumes. Lync requires five VMs with a total of 20 vcpus and 52 GB of total memory with one network. Lync stores its data on the SQL databases, so its data resides on the SQL VM storage. SharePoint also stores its data in the SQL server, but still requires four volumes for search services, for a total of four VMs, 20 vcpus, and 48 GB memory and two networks. SQL server consists of three VMs a SharePoint primary database, a SharePoint secondary database, and a SharePoint SQL witness collocated with Lync s databases. Since SQL is used for both Lync and SharePoint, it requires three VMs, 16 vcpu, 156 GB of memory, and three networks with 17 volumes. Finally, the virtual hardware load balancer appliance is a VM that supports high availability, so it will need a high availability network and client network as well. The required vcpu, total memory, and storage volumes will be dictated by the specific hardware load balancer virtual appliance selected; however, an approximate number of vcpu and memory is presented for reference purposes. 25

31 Table 11. Application VM Resource Summary Purpose VMs Total vcpu Total Memory Exchange GB Lync GB SharePoint GB SQL GB Virtual Load Balancer Appliance Approx. 2 Approx. 4 Approx. 8 GB Networks -Exchange Public Network -Exchange Private Network -Lync Application Network -SharePoint Farm Network -SharePoint Web Network -SQL Private Network -HLB Private Network - Customer Defined Client Network Application Data Storage Volumes -9 Active Database + Log volumes -9 Passive Database + Log volumes -2 Restore Volumes None -4 Search Application Volumes -6 Primary Databases for SharePoint -5 Secondary Database for SharePoint -4 Databases for Lync Application -2 Database for Lync Archive+Monitoring None Table 11 presents all the VMs, their associated application layer availability groups, and network connectivity. The arrangement of the application VLANs can be seen in Figure 10. The three-tiered SharePoint architecture uses the SharePoint Farm network for application traffic, SharePoint Web network to connect the application to the Hardware Load Balancer, and the SQL private network to maintain database high availability. The SQL Witness and Lync Database VM (SPLSQL3) is utilized by SharePoint to provide failover from the SQL primary server to the secondary server when the primary server cannot be reached on the SharePoint Farm network. Note that it does not need access to the SQL Private network because it is not used in syncing content between the Primary and Secondary SQL servers. Lync s flat network carries front end access for the hardware load balancer and access to its database. Exchange contains a private network for replication and a public network for hardware load balancer access. Notice the presence of several pools and groups. This grouping of VMs represents application high-availability so that either one of the servers in the pool can fault, but the service will stay online. 26

32 Microsoft Exchange, Lync, and SharePoint Server 2010 on Dell Active System 800v Figure 10. Logical View Active System 800 SharePoint Application Pool SharePoint SQL Primary SPSQL1 SharePoint SQL Mirror SPSQL2 SharePoint Application SPAPP1 SharePoint Front End Pool SharePoint Web Front End SPWFE1 SharePoint Application SPAPP2 Lync AV Conferencing Pool SharePoint SQL Witness and Lync Database SPLSQL3 Lync Archive & Monitor LAM1 Lync AV Conferencing LAVC1 SharePoint Web Front End SPWFE2 Lync Front End Pool Lync Front End LFE1 Lync AV Conferencing LAVC2 Lync Front End LFE2 Exchange Database Availability Group Exchange App & Mailboxes 2 EXCH2 Exchange App & Mailboxes 2 EXCH2 Exchange App & Mailboxes 3 EXCH3 Hardware Load Balancer HLB1 Hardware Load Balancer HLB2 Hardware Load Balancer Pool Network Key additional resources for other workloads SharePoint Farm SharePoint Web SQL Private Customer Defined Lync App Exch Public Exch Private HLB Private Customer Environment: See External Datacenter Figure Not Pictured Management Network All VMs presented in Figure 10 have a network connection to a management network as well. This management network allows for administrator access to each application s management suite without interrupting end user traffic. This network is not shown on the above figure. 5.5 Virtualization Rules To fully abstract the application VMs from their physical hosts, dynamic VM placement is critical. VMs must be load balanced across servers depending upon their workload type and their relationship to other VMs. To achieve server load balancing, the cluster is configured with vsphere Distributed Research Scheduler (DRS) to automatically vmotion VMs to less utilized hosts. To adhere to application best practices, DRS must be made aware of the VM s relationships with other VMs. To provide this, DRS rules based upon each VM s workload were configured. Figure 11 summarizes these rules. 27

33 Figure 11. Virtualization Rules Each rectangular shape in Figure 11 represents a VM-VM anti-affinity rule. These rules mean that the grouped VMs will not coexist on the same ESXi host server. There are five of these VM-VM anti-affinity rules. One of these rules - Heavy Storage Use Rule, includes all databases and mailboxes. These VMs use storage heavily and could overwhelm the iscsi connections if they ever exist on the same ESXi host server. The two SharePoint rules and two Lync rules exist to ensure that the SharePoint Application Pool and SharePoint Web Front End Pool can be maintained. These pools exist to allow application high-availability, so if one of the VMs in the pool goes down, the other VM can maintain connectivity. As a result, if both VMs were allowed to exist on the same server and that server were to fail, both VMs in the pool would be down and the application would not achieve high availability. With these four rules, no SharePoint or Lync pool will go down because all VMs in a pool will exist on separate servers. 28