Running Microsoft Office Communications Server 2007 R2 in a Virtualized Topology

Transcription

1 Running Microsoft Office Communications Server 2007 R2 in a Virtualized Topology Best Practices and Performance Considerations Writers: Jerome Berniere, Rui Maximo Technical Reviewers: John Kenerson, Shubhada Zunjarwad, Ravi Krishnamaneni, Jens Trier Rasmussen, Francois Doremieux, Sasa Juratovic Applies to: Microsoft Office Communications Server 2007 R2, Windows Server 2008, SQL Server 2008 Summary Hyper-V in the Windows Server 2008 operating system is a powerful virtualization technology that can be used by corporate IT departments to consolidate servers that are under used. Using these servers reduces total cost of ownership (TCO) and maintains or improves Quality of Service (QoS). This document uses a series of test scenarios that represent fundamental Office Communications Server 2007 R2 applications to provide best practice recommendations for running Office Communications Server 2007 R2 and SQL Server 2008 in Windows Hyper-V environment or other hypervisor technologies.

2 Contents Summary Introduction Supported Functionality Virtualized Configurations Two-Tier Enterprise Pool and Edge Server Topology... 8 Topology... 8 Test Results User Profile Two-Tier Enterprise pool Topology Topology Test Results User Profile Single-Tier Enterprise Pool Topology Topology Test Results User Profile Single Tier Enterprise Pool + Edge Server Topology Topology Test Results User Profile Planning Office Communications Server on Hyper-V Hypervisor Recommendations SQL Server Recommendations Office Communications Server Recommendations Performances Testing Stress Simulator Deploying Stress Simulator Monitoring performance Monitoring performance of Hyper-V Monitoring Performance of SQL Server Monitoring Performance of Office Communications Server Microsoft Introduction 2

3 Front-End Server Performance Counters Edge Server Performance Counters Group Chat Performance Counters Client Performance Counters Examples of Failed Performance Runs ,000 Internal Users Address Book size Typical pattern of good performance run Enterprise Pool Group Chat Server Conclusion Additional Resources Appendix A: Lab Hardware Hypervisor Hardware Office Communications Server Stress Client Hardware Appendix B: User Profiles Appendix C: Virtualization Checklist Microsoft Introduction 3

4 1. Introduction Based on hypervisor technology, the Hyper-V virtualization feature in the Windows Server 2008 operating system is a thin layer of software between the hardware and the operating system that enables multiple operating systems to run, unmodified, on a host computer at the same time. Hyper-V is a powerful virtualization technology that can be used by corporate IT departments to consolidate underused servers that are under used. This reduces TCO and maintains or improves QoS. Hyper-V opens the opportunity for more development and test environment types that otherwise might be constrained by hardware availability. Office Communications Server 2007 R2 can be deployed onto Windows Server 2008 Hyper-V, or onto any virtualization solution that is a certified partner through the Server Virtualization Validation Program (SVVP) certified partners for the following workloads: Presence IM (including remote access, federation, and Public IM Connectivity) Group Chat For more information about the Server Virtualization Validation Program, see Enterprise Voice, Remote Call Control (RCC), Response Group Service, dial-in conferencing, audio/video conferencing, Web conferencing, and Communicator Web Access desktop sharing workloads are not supported in a virtualized Office Communications Server 2007 R2 deployment. This occurs because of several factors, including packet loss, delay, jitter, and clock skew. These factors impact the quality and performance of real-time media when virtualized. However, these factors do not impact other workloads such as instant messaging and presence because these workloads are less susceptible to delay and can use the natural retry mechanisms in the SIP protocol and the underlying TCP transport. It is challenging to maintain the correct size hardware to consolidate current workloads and still provide room for growth. Adding virtualization can increase the capacity planning challenges. To help build virtualization topologies, we have released Microsoft Office Communications Server 2007 R2 Capacity Planning Tool. The Capacity Planning Tool can simulate user load for most of the available workloads. This helps quickly validate the hypervisor load and scalability before going into production. This document does the following: Identifies which server roles are supported in a virtualized environment Provides guidance for scaling users and workloads in a virtualized environment This document describes the results of a series of configurations that were run in a Hyper-V environment to validate that Office Communications Server on Hyper-V provides stable performance and scalability for production use. Microsoft Introduction 4

5 2. Supported Functionality Table 1 lists the server roles and corresponding features that are tested and supported in a virtualized environment. We recommend that all virtual machines that are running Office Communications Server be installed on Windows Server bit Edition. Table 1 Supported server roles and corresponding features in a virtual environment Role Supported Supported features Unsupported features Enterprise front-end server Yes (3) Presence, IM Enterprise Voice, audio/video Standard Edition Server IM Conferencing Server Yes IM Conferencing Access Edge Server Yes Remote Access Federation, Public IM Connectivity SQL Server back-end server Yes (3) Office Communications Server Backend Group Chat Channel Server Yes (3) Channel Server Group Chat Look-up Server Yes Channel and Load balancing management Group Chat back-end server Yes (3) Group Chat database Group Chat Compliance Yes Compliance Server Group Chat Compliance Yes Compliance database back-end server Director Audio/Video Conferencing Server Application Sharing Conferencing Server Web Conferencing Server Telephony Conferencing Server Archiving Server (1) Monitoring (2) Web Conferencing Edge Server A/V Edge Server Mediation Server Outside Voice Control Service Conferencing Attendant Service Response Group Service Microsoft Supported Functionality 5

6 Conferencing Announcement Service Update Server Communicator Web Access (1) Archiving Server can perform archiving from a virtualized Enterprise pool, but must itself be deployed on a physical server. Virtualization of the Archiving Server is currently not supported. (2) Monitoring Server can perform call detail record (CDR) collecting for a virtualized Enterprise pool, but must itself be deployed on a physical server. Virtualization of the Monitoring Server is currently not supported. Because voice workload is not supported with a virtualized Enterprise pool, the QoE Service (component of the Monitoring Server) was not tested and therefore is currently not supported in a virtualized Enterprise pool. (3) Deploying an Enterprise pool back-end database on a physical server with a Front End pool that runs on a virtualized server and deploying a Group Chat back-end database on a physical server with one or more Group Chat Channel Servers that run on a virtualized server are supported. Table 2 lists the clients and corresponding features tested and supported that are connected to a virtualized Office Communications Server pool. Desktop virtualization is not supported. The client should be installed on physical client computers. Table 2 Supported clients and corresponding features in a virtual environment Client Office Communicator 2007 R2 Office Communicator 2007 R2 Group Chat Console Office Communicator Mobile Live Meeting Console Office Communicator 2007 R2 Attendant Office Communicator Phone Edition Tested and Supported Yes Yes Unsupported feature(s) Enterprise Voice, PBX integration, audio/video, Remote Call Control Autoupdate, desktop sharing, conferencing, Response group Table 3 lists the supported workloads tested and supported in a virtualized Enterprise pool. Table 3 Supported workloads in a virtual Enterprise pool Workload Instant messaging IM conferencing Tested and supported Yes Yes Microsoft Supported Functionality 6

7 Presence Group Chat Enterprise Voice Remote Call Control Peer-to-peer voice and video Audio/video conferencing Web conferencing Communicator desktop sharing Yes Yes 3. Virtualized Configurations Because Office Communications Server can have multiple roles that are collocated on the same server, the first objective is to verify that running the different server roles of Office Communications Server in a virtualized environment did not cause any issues for the following functionality: IM, presence, and Group Chat. Given a particular configuration that addresses a specific scenario, the second objective was to determine the scalability of the selected virtualized configurations. These topologies target commonly deployed usage scenarios that the reader can then select that most closely matches their environment. te The Enterprise pool in expanded configuration is not supported. The following four topologies were tested: Two-tier Enterprise pool and Edge Server topology Two-tier Enterprise pool topology Single-tier Enterprise pool topology Single-tier Enterprise pool and Edge Server topology For each of these topologies, virtualizing the Active Directory domain controllers did not affect the performance of the virtualized Office Communications Server environment. For more information about running domain controllers in Hyper-V, see When load testing each of these configurations, Office Communications Server 2007 R2 Capacity Planning Tool (OCSStress) stressed the Office Communications Server virtual environment by using the user model defined on Microsoft TechNet at This user model defines the stress load and frequency characteristics that each client computer applies to the virtualized configuration. This provides a common benchmark that makes it possible to compare the performance results between the virtualized topologies. Microsoft Virtualized Configurations 7

8 3.1. Two-Tier Enterprise Pool and Edge Server Topology In this topology, all Office Communications Servers are virtualized. This configuration serves as a benchmark to determine the maximum number of users that a virtualized Enterprise pool can support. Topology This topology includes the following: Hypervisor 1: 4 front-end server virtual machines Hypervisor 2: 1 SQL Server virtual machine Hypervisor 3: 2 Group Chat Channel Server virtual machines, 1 Group Chat compliance server virtual machine, and 1 SQL Server back-end database virtual machine that is running 2 instances (Group Chat and Group Chat Compliance) Hypervisor 4: 1 Access Edge Server virtual machine and 2 Active Directory domain controller virtual machines. Figure 1 shows how the virtual machines are connected to one another over a virtual internal network. For more information about the hardware that is used during the tests, see Appendix A : Lab Hardware later in this document. Microsoft Two-Tier Enterprise Pool and Edge Server Topology 8

9 Hyper-V server 1 FE1.contoso.com FE2.contoso.com Hyper-V server 2 FE3.contoso.com POOLBE.contoso.com F (VIP) Admin: FE4.contoso.com Hyper-V server 4 Ocstress1-5.contoso.com Hyper-V server 3 GCCS1.contoso.com AD1.contoso.com Ocstress6-10.contoso.com GCCS2.contoso.com AD2.contoso.com Ocstress11-15.contoso.com (edge client) GCCOMPS1.contoso.com GCCBE.contoso.com edge.contoso.com External.contoso.com Microsoft Two-Tier Enterprise Pool and Edge Server Topology 9

10 Figure 1 Two-Tier Enterprise Pool and Edge Server Topology Test Results After the Capacity Planning Tool ran on all clients for 7 days against this topology, the maximum number of users who can be actively connected to a virtualized Enterprise pool in consolidated configuration with a virtualized SQL Server back-end server is 40,000 users. During testing, the performance of the Enterprise pool was significantly reduced when the number of active users connected to the Enterprise pool passed 40,000 users. The decrease in performance was notably observed on the SQL Server back-end server of the pool. The CPU of the SQL Server virtual machine was pegged at 100% usage for long periods of time. This resulted in many active users being disconnected from the Enterprise pool. CPU usage on the front-end servers was never more than 20% during the test. The increased load was caused by disconnected users trying to reconnect to Office Communications Server. Therefore, the back-end server running SQL Server limits the maximum load capacity of the virtualized Enterprise pool as the back-end server starts dropping SQL connections from the front-end servers. This occurs because of the maximum number of logical CPUs that can be assigned to a virtual machine. Unlike running SQL Server Enterprise Edition on a physical server where the number of processors that are supported by SQL Server can be scaled with the number of CPUs that are supported by the hardware, a maximum of four CPUs can be allocated to a virtual machine that is running under Hyper-V. This limits the scalability of SQL Server when virtualized. User Profile Applying the user model as defined in TechNet ( Table 4 describes the load that was applied to the virtualized Enterprise pool based on a user population of 40,000 users who are homed on the pool. These parameters were configured on each client computer running OCSStress. Table 4 Load applied based on 40,000 users Category Total users Client distribution Remote user distribution Contact distribution IM sessions Description 40,000, including 35,000 internal and 5,000 external. Part of those 40,000 users included 10,000 Group Chat users MPOP % of clients running Office Communications Server 2007 R2 32-bit Server client computers that each had 5,000; 5,000; 5,000; 5,000; 5,000; 7,500; and 7,500 users respectively 90% of users connected internally 10% of users connected through an Edge Server/ 100% contacts within organization 14 users/sec sign-in rate 97% 1:1 IMs 3% IM conferences Microsoft Two-Tier Enterprise Pool and Edge Server Topology 10

11 2 IM sessions/user/hour 10 instant messages per session 24.5-byte average message size As part of this topology, we tested the Group Chat functionality. However, OCSStress does not support testing the Group Chat functionality. Also, we assumed that the load is shared equally among the two Group Chat Servers. In this topology, each Group Chat Server can support up to 5,000 users. Table 5 shows two combinations of user and channel that were used in this topology. A channel is a collection of users exchanging the same messages around the clock. Each combination was assigned small channels (with 30 users connected to the channel), medium channels (150 users), and large channels (2,000 users). Table 5 User-channel combinations applied to this topology Combination 1 Combination 2 Total users : 10,000 Small channels (30 users) : 8,666 Medium channels (150 users) : 1,334 Large channels (2,000 users): 0 Messages/sec: 20 Total users : 10,000 Small channels : 8,666 Medium channels : 200 Large channels : 20 Messages/sec: 8 For example, in combination 2, 8,666 channels were created, that had 30 users, 200 channels had 150 users, and 20 large channels had 2,000 users. Based on those numbers, you could also conclude that each user was connected to 26 small channels (10,000 * 26 / 30 = 8,666), 3 medium channels (10,000 * 3 / 150 = 200), and 1 large channel (10,000 * 1 / 2,000 = 20) Two-Tier Enterprise pool Topology This second architecture is used to verify the maximum user load that one Office Communications Server front-end server can run in the same virtualized pool, on a single hypervisor, and without any other virtual machine load. Topology This topology is shown in Figure 2 and includes the following: Hypervisor 1: 1 front-end server virtual machine and 1 Access Edge Server virtual machine. The Virtual machines are connected to the network using the same virtual gigabit network. Hypervisor 2: 1 SQL Server virtual machine. Hypervisor 3: 2 Active Directory domain controller virtual machines and no other virtual machines installed on that host. Microsoft Two-Tier Enterprise pool Topology 11

12 Hyper-V server 3 AD1.contoso.com Hyper-V server 1 FE1.contoso.com AD2.contoso.com F (VIP) Admin: edge.contoso.com External.contoso.com Hyper-V server 2 Ocsstress1-5.contoso.com POOLBE.contoso.com Figure 2 Two-tier Enterprise pool topology Test Results After running the Capacity Planning Tool on all clients for 7 days against this topology, the maximum number of users who can be actively connected to a virtualized Enterprise pool with a single front-end server and a virtualized SQL Server back-end server is 25,000 users. By extrapolation, it can be concluded that by adding a second virtualized front-end server, the Enterprise pool can scale to 40,000 active users connected to it, which is the bottleneck imposed by the back-end server. Therefore, in the previous Enterprise pool topology, the front-end server was not used to its capacity. The optimal configuration is a virtualized Enterprise pool that has two front-end servers and a back-end server. Because we know from the previous topology that the back-end server's maximum capacity is 40,000 active users, at 25,000 active users the SQL Server is under-used. The bottleneck is the single front-end server in this topology. Microsoft Two-Tier Enterprise pool Topology 12

13 User Profile Applying the user model as defined in TechNet, Table 6 describes the load applied to the virtualized Enterprise pool based on a user population of 25,000 users homed on the pool. These parameters were configured on each client computer running OCSStress. Group Chat Server was not tested in this topology. Table 6 Load applied based on 25,000 users Category Total Users Client distribution Remote user distribution Contact distribution IM sessions Description 25,000 ( 20,000 internal and 5,000 external) MPOP % of clients running OCS 2007 R2 32-bit version 5 client computers each with 5,000 users 80% of users connecting internally 20% of users connecting through Edge 100% of contacts within organization 10 users/sec sign-in rate 97% 1:1 IMs 3% IM conferences 2 IM sessions/user/hour 10 instant messages per session 24.5-byte average message size 3.3. Single-Tier Enterprise Pool Topology In the previous two topologies, the Enterprise pool was deployed on two hypervisors one hypervisor running the pool's front-end servers as virtual machines, and the other hypervisor running just the pool's back-end server. This third topology deploys all servers, including the back-end server, of an Enterprise pool running on a single hypervisor. This topology aims to determine the maximum user load of a virtualized Enterprise pool on a single hypervisor. Topology This topology includes the following: Hypervisor 1: 2 front-end server virtual machines, 1 SQL Server virtual machine, and 1 Access Edge Server virtual machine Hypervisor 2: 2 Active Directory domain controller virtual machines All virtual machines are connected to the same virtual network gigabit adapter on each hypervisor, except the Edge server. The Edge server has a second virtual gigabit adapter that points to another network to emulate a real external network topology as shown in Figure 3. Microsoft Single-Tier Enterprise Pool Topology 13

14 Hyper-V server 1 FE1.contoso.com Hyper-V server 2 FE2.contoso.com AD1.contoso.com F (VIP) Admin: POOLBE.contoso.com AD2.contoso.com Ocsstress1-5.contoso.com edge.contoso.com External.contoso.com Figure 3 Single-Tier Enterprise Pool Topology Test Results After the Capacity Planning Tool ran on all clients for 7 days against this topology, the maximum number of users who can be actively connected to a virtualized Enterprise pool with two front-end servers and a virtualized SQL Server back-end server all running on the same hypervisor is 25,000 users. This result shows that the servers of an Enterprise pool can be consolidated onto a single hypervisor without any degradation of performance. Therefore, reducing the number of physical hypervisors required to support a population of 25,000 users. This topology summarizes the performance counters that you have to look for when virtualizing Office Communications Server on a single hypervisor. These counters include the following: Microsoft Single-Tier Enterprise Pool Topology 14

15 CPU counters on the front-end, back-end, and Edge servers Disconnection counters on the front-end and Edge servers Whenever the limit of one of these counters was reached, the user count or the logon rate for which the OCSStress clients were configured had to be reduced. This last parameter is important. If you have a user population that is spread across different time zones, users will sign in to Office Communications Server in smaller bursts over a longer span of time. Whereas, if your user population was in the same time zone, users will sign in over a shorter amount of time in one or two large bursts. If your user population is in only one time zone, do not decrease the logon rate when testing your environment with OCSStress. Also consider that, whenever one of those counters limits are reached, you will have to move one virtual machine to another hypervisor. It is important to remember that the SQL database virtual machine has a higher demand for resources than most of the virtual machines in the architecture. Therefore, moving the other roles first will be easier. User Profile Applying the user model as defined in TechNet, Table 7 describes the load applied to the virtualized Enterprise pool based on a user population of 25,000 users homed on the pool. These parameters were configured on each client computer running OCSStress. Group Chat Server was not tested in this topology. Table 7 Load applied to virtual Enterprise pool based on 25,000 users Category Total users Client distribution Remote user distribution Contact distribution IM sessions Description 25,000 ( 20,000 internal, 5,000 external) MPOP % of clients running Office Communications Server 2007 R2 32-bit version 5 client computers that each have 5,000 users 80% of users connecting internally 20% of users connecting through an Edge Server 100% of contacts within organization 10 users/sec sign-in rate 97% 1:1 IMs 3% IM conferences 2 IM sessions/user/hour 10 instant messages per session 24.5-byte average message size 3.4. Single Tier Enterprise Pool + Edge Server Topology This fourth topology is similar to the previous topology. In addition to having all servers of an Enterprise pool hosted on a single hypervisor, it also hosts an Access Edge Server virtual machine. Microsoft Single Tier Enterprise Pool + Edge Server Topology 15

16 Topology This topology includes the following: Hypervisor 1: 1 front-end server virtual machine, 1 SQL Server virtual machine, and 1 Access Edge Server Hypervisor 2: 2 Active Directory domain controller virtual machines. All virtual machines are connected to the same virtual network gigabit adapter of each hypervisor. In addition, the Edge Server virtual machine has a second virtual gigabit adapter connected to another virtual network as shown in Figure 4. Hyper-V server 1 Hyper-V server 2 FE1.contoso.com AD1.contoso.com F (VIP) Admin: POOLBE.contoso.com AD2.contoso.com Ocsstress1-5.contoso.com edge.contoso.com External.contoso.com Figure 4 Single Tier Enterprise pool + Edge Server Topology Test Results After OCSStress is run on all clients for 7 days against this topology, the maximum number of users that can be actively connected to a virtualized Enterprise pool with one front-end server, one Edge Server, and one virtualized SQL Server back-end server all running on the same hypervisor is 20,000 users. By comparison with the previous topology, this shows that the maximum Front-End capacity is 20,000 Microsoft Single Tier Enterprise Pool + Edge Server Topology 16

17 users. Adding a second front-end server adds only 5,000 users to the pool that is used by the Access Edge Server. User Profile Applying the user model that is defined in TechNet ( Table 8 describes the load that is applied to the virtualized Enterprise pool based on a user population of 20,000 users who are homed on the pool. These parameters were configured on each client computer running OCSStress. Group Chat Server was not tested in this topology. Table 8 Load applied based on 20,000 users Category Total users Client distribution Remote user distribution Contact distribution IM sessions Description 20,000 ( 15,000 internal and 5,000 external) MPOP % of clients running Office Communications Server 2007 R2 32-bit version 4 client computers that each have 5,000 users 75% of users connecting internally 25% of users connecting through an Edge Server 100% of contacts within organization 8 users/sec sign-in rate 97% 1:1 IMs 3% IM conferences 2 IM sessions/user/hour 10 instant messages per session 24.5-byte average message size 4. Planning Office Communications Server on Hyper-V The planning process for Office Communications Server 2007 R2 is the same regardless of whether or not you plan to virtualize your Office Communications Server environment. The main difference between a virtualized and non-virtualized deployment of Office Communications Server is the capacity planning because the scalability characteristics are different as demonstrated by the four deployment topologies described in this document. In addition to the different scaling characteristics of virtualization, only certain workloads (IM, presence, and Group Chat) are currently supported in a virtualized Office Communications Server environment. For more information about how to deploy Office Communications Server 2007 R2, see When you are planning a virtualized deployment of Office Communications Server, you must consider the following planning phases before you deploy Office Communications Server 2007 R2: Microsoft Planning Office Communications Server on Hyper-V 17

18 Hypervisor, which can be either one of the Server Virtualization Validation Program (SVVP) certified partners or Microsoft Server 2008 Hyper-V. SQL Server 2008 running in a Hyper-V environment. Office Communications Server 2007 R2 running in a Hyper-V environment. Hypervisor Recommendations The following recommendations will help the hypervisor run Office Communications Server optimally on a virtual machine: Use 16 core servers that have 4 GB of RAM for the Windows Server 2008 operating system. Ensure that the four virtual machines have 32 GB of RAM (8 GB each). Use the network adapter that is provided with the guest integration components instead of a legacy network adapter when configuring networking for the virtual machine. Avoid using emulated devices when possible. These devices can result in significantly more CPU overhead when compared to synthetic devices. Do not run additional services on the hypervisor because these can impact the overall performance of the virtual machines. Create the virtual hard disks (VHDs) for the machines on separate physical hard drives from the hypervisor (host) operating system hard drive. For complete instructions about how to create and configure virtual machines in Hyper-V, see Step-by- Step Guide to Getting Started with Hyper-V at SQL Server Recommendations The following recommendations will help run SQL Server optimally on a virtual machine: Create three VHDs for the SQL Server virtual machine: one VHD used by the operating system, the second VHD used for the database, and the third VHD used for the database logs. Configure as follows: o One volume of 50 GB for the virtual machines including the SQL Server virtual machine: The operating system installation (The Windows Server 2008 installation space on the guest computer should not take more than 10 GB) Add 10 GB for additional software installation. Therefore, if required, this volume size could be reduced to approximately 20 GB. Include additional space for future updates, installation, or maintenance operations. o Two 50-GB volumes for each of the database instances and logs when a backend installation is required. Select the best performing storage options when creating VHDs for SQL Server because it is I/O intensive. The recommended options are: o Pass-through disk o Fixed-size virtual hard disks (VHDs) Microsoft Planning Office Communications Server on Hyper-V 18

19 Install SQL Server on Windows 2008 Server 64-bit operating system. Allocate 4 virtual processors to the SQL Server virtual machine to take advantage of multi-core CPUs if available on the hypervisor. When installing SQL Server 2008 in a virtual environment, apply the same best practices as recommended when deploying SQL Server 2008 in a physical environment. Table 9 lists the resources that you should use when installing and configuring the server. Table 9 Installation and configuration resources Hardware Component CPU Hardware Requirement Dual processor, quad-core 2.0 GHz+ Virtual Machine Requirements 4 virtual CPUs Memory 8 GB 8 GB virtual RAM Disk 2x RAID 1 (mirrored), 10K RPM or 15K RPM for system files 1 VHD fixed or pass-through disk over RAID 1 15K RPM disk for system files 2x RAID 1 (mirrored) 15K RPM for database log files 8x RAID 10 (striped and mirrored) 15K RPM disks for database data files 1 VHD fixed or pass-through disk, one RAID1 15K RPM for database log file 1 VHD fixed or pass-through disk on RAID10 15K RPM for database data files Network 2 x 1 Gbps network adapter 1 or 2 Gbps virtual adapter components Office Communications Server Recommendations The following recommendations will help Office Communications Server run optimally on a virtual machine: Use the same memory recommendations for the virtual machines where Office Communications Server is deployed as recommended for physical servers. Install Office Communications Server on Windows Server bit. When installing Office Communications Server in a virtual environment, the same practices should be followed as in a physical environment. Table 10 lists the resources that you should use when installing and configuring the server: Table 10 Office Communications Server Recommendations Hardware Hardware Requirement Component CPU Dual processor, quad-core 2.0 gigahertz (GHz)+ Virtual Machine Requirements 4 virtual CPUs Microsoft Planning Office Communications Server on Hyper-V 19

20 Memory 8 gigabyte (GB) 8 GB virtual RAM Disk 2x 72 GB+, 15K or 10K RPM 1 VHD fixed or pass-through disk over RAID 1 15K RPM disk for system files Network 2 x 1 Gpbs network adapter 1 or 2 Gbps virtual adapter components 5. Performances Testing After deploying Office Communications Server in a virtualized environment, it is important to perform load capacity testing to make sure that it can handle the load imposed by real users. Because the Office Communications Server Planning Guide provides capacity planning based on physical server deployment, this guidance will need to be adjusted for a virtualized deployment. Office Communications Server provides the Capacity Planning Tool (OCSStress) to simulate user activity against Office Communications Server. This tool applies load on your Office Communications Server system based on characteristics that you define. The characteristics used in the tests that are covered in this document are based on the user model that is defined in Table 1 of Capacity Planning located at Based on the performance results of your stress test, you can determine whether your virtual machines need additional resources or should be moved to another hypervisor. Stress Simulator The Microsoft Office Communications Server 2007 R2 Capacity Planning Tool (OCSStress) is capable of simulating user load. Stress testing a virtualized Office Communications Server environment is no different than stress testing an Office Communications Server environment that is deployed on physical servers. This tool is capable of simulating the following user activities: Sign-in users Get presence Send/receive instant messages Create IM conferences and send messages in conferences Address book download and address book query Expand distribution list To download OCSStress, see For more information about how to build test configuration files, see Appendix B later in this document. Deploying Stress Simulator The set of client computers that will run OCSStress is divided into two sets: one set of clients will simulate internal user traffic by connecting directly to the Enterprise pool, and the other set will simulate external user traffic by connecting to the Edge Server. To set up the testing environment, you must complete the following tasks: Microsoft Performances Testing 20

21 1. Use physical computers or virtual machines for each client to simulate up to 10,000 users on each client. 2. Install CapacityPlanningTool.msi on each client computer. 3. Run StressConfig.exe to create test users, contacts, and distribution lists. This tool will configure the users for communications. 4. Run UserProfileGenerator.exe to generate a capacity planning configuration. This configuration defines the user profile that OCSStress will simulate against Office Communications Server. For more information, see Appendix B. 5. Copy the capacity planning configuration file to every client computer. 6. Start the performance test by running OCSStress.exe. te While configuring the OCSStress.exe behavior, it is important to note that the sign-in rate should not exceed the SQL Server user capability. This can be observed from the front-end server by using the performance counter LC:SIP Peers\SIP-000-Connections Active <all instances>. The sub counter SIP-000-Connections Active should show a constant growth in number of active connections until all users sign in to Office Communications Server. At that point, the number of active connections plateaus, as shown in Figure 5. Figure 5 Active client connections 6. Monitoring performance Performance counters expose performance metrics of a Windows service. To measure performance of a virtualized Office Communications Server environment, you should monitor the performance counters for the following servers: Hypervisor host Microsoft Monitoring performance 21

22 Guest virtual machine SQL Server Office Communications Server Where relevant to Office Communications Server, how to monitor performance is detailed Monitoring performance of Hyper-V Because monitoring performance of Hyper-V is not specific to Office Communications Server, we recommend that you see Performance Tuning for Virtualization Servers at for more information. In addition, the recommendations in Measuring Performance on Hyper-V, located at were followed to measure Hyper-V host performance counters. The following is the list of counters that were monitored during each performance run: Logical Disk\Avg.sec/Read <all instances> Logical Disk\Avg.sec/Write <all instances> Memory\Available MBytes Memory\Pages/sec Network Interface\Bytes Total/sec <all instances> Network Interface\Output Queue Length <all instances> Hyper-V Virtual Network Adapter\Bytes/sec <all instances> Hyper-V Hypervisor Logical Processor(_Total)\% Total Run Time Hyper-V Hypervisor Virtual Processor(_Total)\% Total Run Time Hyper-V Hypervisor Virtual Processor\%Guest Run Time <all instances> The most important performance counters for the tests run in this document were the following: Hyper-V Hypervisor Logical Processor(_Total)\% Total Run Time It is recommended that this counter remain less than 75%. For our test runs, we observed this counter was always approximately in the 15% range. Network Interface\Bytes Total/sec <all instances> It is recommended that this counter remain less than 40% of the interface consumed. For our test runs, we observed that our host servers averaged 2.4% network usage Monitoring Performance of SQL Server Because Office Communications Server uses SQL Server as its back-end database, we recommend that you see "Running SQL Server 2008 in a Hyper-V Environment," located at for more information about monitoring the performance of a SQL Server that is running as a virtual machine. Microsoft Monitoring performance of Hyper-V 22

23 The following are the most important performance counters to monitor: Processor(_Total)\% Processor Time This counter indicates the CPU usage. During our tests, this counter remained around 50%. During user sign-ins, this counter would peak to 100% for short periods. This is expected behavior. This counter should remain less than 80%. Figure 6 shows the %_Total Processor Time counter for the back-end server when hosting front-end, back-end, and Edge servers on the same host computer. Figure 6 Processor(_Total)\% Processor Time Network Interface\Bytes Total/sec <all instances> This counter indicates network usage. The average network usage was 2.5%; although, during periods when clients are downloading the address book, network usage reached 25%. This counter should remain less than 40%. Figure 7 shows this counter for the back-end server when hosting front-end, back-end, and Edge servers on the same host computer. Figure 7 Network Interface\Bytes Total/sec <all instances> Microsoft Monitoring Performance of SQL Server 23

24 Avg. Disk/sec Read PhysicalDisk\Avg. Disk Bytes/Read This counter tracks the average latency of the virtual hard disk I/Os. Figure 8 shows the average disk latency for three different workloads: low, medium, and high. As expected, VHD has the most latency, while the latency of the pass-through disk equals the native storage latency. In the case of the VHD, disk latency can be collected from the guest virtual machine or the root partition. There is no difference. Average Disk Latency in Seconds Native OS - Hyper-V Disabled Root Partition - Hyper-V Enabled Single VM (Passthrough Disks) Single VM (Fixed Size VHD) 0 Low OLTP Workload Med OLTP Workload High OLTP Workload Figure 8 PhysicalDisk\Avg. Disk Bytes/Read During our test runs, we used a storage area network that had a fixed VHD for the virtual machines and the database. In all cases the average disk latency counter never reached the limit of Avg. Disk/sec Read. An important result observed from our test runs is that in a virtualized environment, the scalability of an Enterprise pool is not a factor of the number front-end servers, but rather the capacity of the back-end database server. Avoid adding more front-end servers than necessary without scaling the back-end server correspondingly to optimize the scalability of your Enterprise pool. Sign-in rate of users will directly affect the CPU load of the back-end server Monitoring Performance of Office Communications Server The following sections review the performance counters for Office Communications Server 2007 R2, while running in a virtualized infrastructure Front-End Server Performance Counters It is recommended that you monitor the following performance counter on every front-end server: Processor(_Total)\% Processor Time This counter should be less than 80%. The average value observed was 25%. Microsoft Monitoring Performance of Office Communications Server 24

25 Edge Server Performance Counters It is recommended that you monitor the following performance counters on every Edge Server: LC:SIP Access Edge Server Connections\* LC:SIP Access Edge Server Messages\* LC:SIP Access Edge Server - Key Manager\* The most important counter is the sub counter of LC:SIP Access Edge Server Connections. The counter is SIP 002 Accepted Remote User Client Connections. This value determines how many active connections are present to the Edge Server at a given moment. This value should be steadily increasing during sign-ins and should remain constant after the sign-ins are over. Figure 9 shows the SIP 002 Accepted Remote User Client Connections to the Edge Server when hosting front-end servers, back-end server, and Edge Servers on the same host computer. Figure 9 Accepted Remote User Client Connections It is also important to check the %Processor and %Network Interface counters for Edge Server. These values should also be under the limits described earlier in this document Group Chat Performance Counters It is recommended that you monitor the following performance counters on every Group Chat Server: MGC:SERVER MGC Server Chat rooms.\* MGC:SERVER MGC Server Networking.\* MGC:SERVER MGC Server Protocol.\* MGC:SERVER MGC Message processing.\*.net CLR Exceptions\* <all instances> Microsoft Edge Server Performance Counters 25

26 .NET CLR Interop\*<all instances>.net CLR JIT\*<all instances>.net CLR Loading\*<all instances>.net CLR LocksAndThreads\*<all instances>.net CLR Memory\*<all instances>.net CLR Remoting\*<all instances>.net CLR Security\*<all instances> LogicalDisk\*<all instances> Memory\* Network Interface\*<all instances> Paging File\*<all instances> PhysicalDisk\*<all instances> Process\*<all instances> Processor\*<all instances> System\* During the tests that were run for this document, we focused on the following performance counters to identify health of the system: MGC:SERVER MGC Server Networking\ MGCSERVER -003 Active Endpoints This counter shows the number of sign-ins. Because the Group Chat performance tool has a pattern of closing all connections and then re-establishing them every 8 hours, you should see similar pattern in this performance counter over your performance run as shown in Figure 10. Figure 10 MGC:SERVER MGC Server Networking\ MGCSERVER -003 Active Endpoints MGC:SERVER MGC Server Chat rooms\ MGCSERVER Inbound Chat Messages/Sec This counter shows the average value of the messages/sec set in the Microsoft Group Chat Performance Counters 26

27 performance tool configuration. This counter should follow the same pattern as the counter, MGCSERVER -003 Active Endpoints, throughout your performance run as shown in Figure 11. Figure 11 MGC:SERVER MGC Server Chat rooms\ MGCSERVER Inbound Chat Messages/Sec MGC:SERVER MGC Server Chat rooms\ MGCSERVER Outbound Chat Messages/Sec This counter should follow the same pattern as MGCSERVER Inbound Chat Messages/Sec over the course of your performance run as shown in Figure 12. Figure 12 MGC:SERVER MGC Server Chat rooms\ MGCSERVER Outbound Chat Messages/Sec Again, it is important to check the %Processor and %Network Interface counters for the Edge Server also. These values should be under the limits that were described earlier in this document. Microsoft Group Chat Performance Counters 27

28 6.4. Client Performance Counters OCSStress adds a list of performance counters on the client computer while running performance tests. These are useful for determining the performance of the stress run. Table 11 lists the important performance counters for each feature that is monitored during each performance run. Table 11 Important performance counters Performance Counter Description Check on the value OCSStress General Information OCSStress - Presence Information Time Spent In Minutes Active Endpoints Failed Logons Logon Attempts Endpoints Disconnected SetPresence Pass Rate (%) Time spent since the process was started. Number of endpoints currently connected to the server. Total number of endpoint sign-in failures. Total number of endpoint sign-in attempts. Total number of endpoints that have been disconnected. Exactly same as the number of users specified for the given client This should be ZERO Exactly same as the number of users specified for the given client This should be ZERO % pass rate for presence This value can be ~99% SetPresence Calls XXX Responses For SetPresence GetPresence Calls XXX Responses For GetPresence Total number of presence change attempts. For different types of presence changes, see SetPresence(Presence Type) Calls performance counter. Total number of the xxx response code received from the server. Total number of get presence request attempts. Total number of the xxx response code received from the server. OCSStress - ABS Information This category includes counters used to monitor Address Book file downloads and Address Book Web Query Service requests. Address Book file download related ABS Full/Delta File Downloads Attempted. This should be same as number Microsoft Client Performance Counters 28

29 counters: of log ons. OCSStress - DL Information Total number of full or delta file download requests attempted Total number of full or delta file download requests succeeded ABS WS Calls Attempted ABS WS Calls Succeeded ABS WS Calls Failed Calls Attempted Calls Succeeded Calls Failed ABS Full/Delta File Downloads Succeeded. Address Book Web Query Service related counters. Total number of address book web query service requests attempted. Total number of address book web query service requests that returned a successful response code. Total number of address book web query service requests that returned an error response code. Total number of distribution list expansion web service (DLX) requests attempted. Total number of DLX web service requests that returned a successful response code. Total number of DLX web service requests that returned an error response code. OCSStress - IM Call Information The performance counters under this category include Instant Messaging MCU sessions. Calls Active Calls Terminated Calls Received XXX Total number of ongoing incoming/outgoing instant messaging calls. Total number of incoming/outgoing instant messaging calls already terminated. Total number of xxx response code received from the server. This should be same as number of ABS File downloads attempted. This should be ZERO The attempted and succeed numbers should be SAME. This should be ZERO IM Messages Received/Sent Incoming/Outgoing Calls Attempted Incoming/Outgoing Calls Established Total number of messages received or sent for all sessions. Total number of incoming/outgoing instant messaging calls attempted. Total number of incoming/outgoing instant messaging calls established. Microsoft Client Performance Counters 29

30 Number of participants Conference Schedule Failure Join Conference Failure Received 480 (Temporarily Unavailable) Total number of participants currently connected to conferences. Total number of failures while trying to schedule a conference. Total number of failures while trying to connect to a conference. The number of 480s that clients receive This counter should remain near constant after all users sign-in. During user sign-ins, you MAY see some 480s. This is expected behavior. 7. Examples of Failed Performance Runs To better understand how your virtualized Office Communications Server Enterprise pool should function optimally, it is necessary to push the boundaries and observe how the system s performance decreases. This document includes two examples to illustrate this point ,000 Internal Users When a test run that had 50,000 users signing-in to the Enterprise pool was performed, we observed that the %processor% performance counter on the back-end server reached 100% usage in approximately 40 minutes as shown in Figure 13. Figure 13 Back-end server CPU usage Microsoft Examples of Failed Performance Runs 30

31 When we looked at the back-end virtual machine properties on Hyper-V, we saw that the Virtual Machine reserve (percentage) value was set to 0. By increasing this value to 100, we observed that it took 2 hours for the back-end server's CPU usage to reach 100%. After the back-end server's CPU usage reached 100%, the rate of endpoints being ended rapidly increased. This resulted in users not being able to sign-in to the Enterprise pool as shown in Figure 14. Figure 14 Back-end server CPU usage It is recommended that you set the virtual machine reserve to 100% as shown in Figure 15. Figure 15 Virtual Machine CPU Setup Microsoft 50,000 Internal Users 31

32 Address Book size When we enabled address book download on the Enterprise pool, the network throughput quickly decreased shortly after the test began as shown in Figure 16. This resulted in clients failing to download the address book and impacted the performance of front-end servers. These front-end servers started ending client connections as shown by the highlighted portion in Figure 17. Figure 16 Network throughput Figure 17 Front-end user disconnections Analyzing the problem showed, that the size of the address book file was approximately 20 MB for 50,000 users. After the normalization rule in MSFT_SIPAddressbooksetting was turned off, the address book file size reduced to 13 MB. Therefore, it is recommended that you turn off the address book normalization rule. Microsoft Address Book size 32