SimpliVity OmniStack and Microsoft Exchange Reference Architecture

Transcription

1 White Paper SimpliVity OmniStack and Microsoft Exchange Reference Architecture Page 1 of 1

2 Table of Contents 1. Executive Summary Introduction Exchange on OmniStack: The Optimal Enterprise Solution Design Consideration Common Microsoft Exchange Configurations Exchange Database Availability Groups Overview DAG Configuration Planning OmniStack Overview OmniStack for Exchange: A Robust Enterprise Class Solution Backup Policies Locking Backups Overview of OmniStack Reference Architectures Summary Table Reference Architecture #1: 13,000 mailboxes with DAG on OmniCube Federation 2+2 configuration Hardware Configuration Network configuration for OmniCube Logical View of the OmniCube 2+2 DAG deployment Reference Architecture #2: 26,000 mailboxes without DAG on OmniCube Hardware Network configuration OmniCube Solution Test Methodology Microsoft Exchange Testing Overview Test Details Configurations to support the Reference Architectures Methodology Introduction to Jetstress Infrastructure System IO and Functionality Testing Jetstress Test Configuration Microsoft Exchange Performance results on OmniCube Backup, Replication and Restore Backup Performance Results Restore Results Configuration Best Practices Resource reservations for MS Exchange mailbox server VMs Networking bandwidth and latency to remote sites MS Exchange database volume cluster size Conclusion Glossary Works Cited Page 2 of 26

3 1. Executive Summary This paper documents SimpliVity validated reference architectures for Microsoft Exchange running on OmniStack, SimpliVity s market-leading hyperconverged infrastructure platform. The purpose of the document is to provide the reader with specific examples of OmniStack configurations that support real-world Exchange deployments in virtualized environments, meeting the performance, reliability and data protection requirements of the enterprise customer. The document also highlights the many unique advantages of OmniStack that make it a superior infrastructure platform for Exchange. The reference architectures that are documented are based on detailed, rigorous testing conducted. The results of the test exemplify many benefits of running Exchange on OmniStack. The intended audience for the document include IT decision makers who are responsible for the successful deployment and ongoing operation of the Exchange environment. This includes IT professionals responsible for Exchange, VMware, data center operations, infrastructure, and data protection. Through this validation testing, SimpliVity has successfully demonstrated various Microsoft Exchange configurations for the midsize-to-large enterprise, highlighting OmniStack s ability to serve as a robust infrastructure for Exchange, while highlighting the many unique benefits of OmniStack that make it the optimal infrastructure choice for Exchange. SimpliVity s OmniStack, a 2U infrastructure building block for the virtual environment, is the only truly hyperconverged platform on the market, providing 3X Total Cost of Ownership savings by converging previously disparate technologies including server and storage, virtualization, backup and disaster recovery, and WAN optimization, among others. As the testing demonstrates, when deployed as the infrastructure for Exchange, the native benefits of OmniStack significantly enhance the value of Exchange. As the number of mailboxes roughly equates to the number of employees in an organization, the testing that was conducted demonstrates real-world configurations with real-life workloads that span a range of organization sizes on the common SimpliVity platform. In addition to demonstrating production workloads of Microsoft Exchange running on OmniStack, the testing also highlights OmniStack s data protection capabilities including the successful restore of a 2TB Exchange database in just 10 seconds. The testing demonstrated the core attributes of SimpliVity OmniStack, namely: 1. Accelerated Data Efficiency: OmniStack performs inline data deduplication, compression and optimization on all data at inception across all phases of the data lifecycle, all handled with fine data granularity of just 4KB-8KB. On average, SimpliVity customers achieve 40:1 data efficiency while simultaneously increasing application performance. 2. Built-In Data Protection: OmniStack includes native data protection functionality, enabling business continuity and disaster recovery for critical applications and data, while eliminating the need for special-purpose backup and recovery hardware or software. OmniStack s inherent data efficiencies minimize I/O and WAN traffic, reducing backup and restore times from hours to minutes. 3. Global Unified Management: OmniStack s VM-centric approach to management eliminates manually intensive, error-prone administrative tasks.system administrators are no longer required to manage LUNs and volumes; instead, they can manage all resources and workloads centrally, using familiar interfaces such as VMware vcenter and VMware vrealize Automation. Leveraging these attributes in an Exchange environment gives the IT department the ultimate enterprise solution. The paper also details best practices for implementing virtualized Microsoft Exchange environments on OmniStack. SimpliVity has tested single copy and Database Availability Group (DAG) configurations, reaching 26,000 mailboxes on commonly deployed configurations of OmniStack Federations. Page 3 of 26

4 2. Introduction is the predominant form of communication in the business world. It is how we communicate and collaborate on a daily basis, whether we are in the office or on the road. We send quick notes, long reports, weekly newsletters, and attachments. is a short-term record and long-term archive of almost all business communications. Some think that mobile communication methods (such as SMS and instant messaging technologies) could potentially disrupt the consumer market. But, they are only accelerating the world of business communications. We no longer live in a 9 to 5 world. According to The Radicati Group: The number of worldwide accounts continues to grow from over 4.1 billion accounts in 2014 to over 5.2 billion accounts by the end of The Radicati Group adds: In 2014, the majority of traffic comes from the business world, which accounts for over billion s sent and received per day. remains the most common form of communication in the business space. use is growing in the business sector and by 2018, business will account for over billion s sent and received per day. 2 There are 140 billion messages sent and received every day. That is an astronomical number and a perfect example of what SimpliVity refers to as the growing data problem. What is the data problem? The data problem is the perfect storm that starts with exponential data growth IDC estimates over 40 zettabytes by and is exacerbated by the increasing demands put on that data: management, mobility, protection, and performance. It is no longer enough to simply store data. Now, we live in a virtualized world where data is expected to be mobile. Data is also expected to be: Automated, orchestrated, and associated to virtual machines and applications, all driven by policy. Protected through local backup and off-site disaster recovery. Always available and never experience loss. Perhaps more importantly, businesses expect and demand that IT meets their Service Level Agreements (SLAs), especially for business and mission-critical applications like and collaboration. Tier-1 Applications are Now Virtualized The market for virtualization system software has evolved significantly during the past several years. Initially, virtualization was sold as a standalone server software solution used to consolidate servers. Today, virtualization is being leveraged for extended use cases and benefits, with focus shifting to operational efficiencies, leading to more emphasis on the management layer. 4 -IDC Gone are the days when virtualization was a pet project, relegated to test and development labs. Now, virtualization is the standard. It is the cornerstone technology to help IT organizations meet business demands. Businesses are quickly seeing that virtualization helps: 1 The Radicati Group. Statistics Report, April The Radicati Group. Statistics Report, April IDC. Digital Universe. April IDC. Worldwide Virtual Machine and Cloud System Software Forecast. Dec Page 4 of 26

5 Decrease costs. Increase agility. Break down organizational silos. Build private clouds where single resources pools are created to abstract hardware from the applications and virtual machines that matter. According to CIO.com and IDC: Virtualizing tier-1 applications is critical to the success of a private cloud. To deliver the most value, the private cloud must encompass the majority of workloads already in use and reduce the number of fragmented resource silos that lie outside the cloud. This allows organizations to take advantage of the economies of scale for optimal infrastructure efficiency. In addition, many of the advanced features of the cloud that transform applications from static entities into dynamic IT services will be the most value to mission-critical, complex applications. 5 Microsoft Exchange is the Leader Microsoft currently holds 64% market share in the onpremises messaging and collaboration market, which is expected to rise to 76% over the next four years. 6 Microsoft is pervasive and its increasing presence is due to the release of Microsoft Exchange 2013 and the closer integration among the tools in its collaboration suite, including SharePoint, Lync, and the cloud with SkyDrive and Office365. Typical Challenges Virtualizing Microsoft Exchange The drive towards virtualizing Microsoft Exchange is to solve a number of common issues: Hardware Use: Underused memory, CPU, and storage resources on physical servers due to over-provisioning to accommodate usage spikes that may never actually occur planning for the peak. High Availability: Lost access to when one physical server went down. Manual intervention was needed to migrate users over to another server, which would incur downtime. Data Protection: Difficult and expensive backup and disaster recovery in terms of actual cost and performance leading to a huge risk of experiencing data unavailability and loss. Test and Development: Complicated procedures to test new features in a physical world as you build up a new and separate infrastructure. Virtualization solved these issues at the application level. But what about the data? Even though the computer and memory processes had been virtualized, the storage still was not. Therefore, although the application may have high availability or data protection, for example, the data is still locked to the physical storage array. To deliver the requisite infrastructure capabilities using traditional infrastructure has been a complex and very costly endeavor. Introducing the SimpliVity OmniStack Reference Architecture for Microsoft Exchange SimpliVity s OmniStack hyperconverged infrastructure solution transforms the data center by virtualizing data and incorporating all IT infrastructure and services below the hypervisor into x86 building blocks. OmniStack delivers the best of both worlds: the enterprise-class performance, protection and resiliency that today s organizations require, with the cloud economics businesses demand. Designed to work with any hypervisor or industry-standard x86 server platform, the SimpliVity solution provides a single, shared resource pool across the entire IT stack, eliminating point products and inefficient siloed IT architectures The Radicati Group. Microsoft Office 365, Exchange Server and Outlook Market Analysis, April Page 5 of 26

6 3. Exchange on OmniStack: The Optimal Enterprise Solution As detailed in Section 2 above, Microsoft s Exchange has established itself as the far and away market leader for enterprise , and for good reason. The level of both end-user and administrator functionality, performance, and reliability drives the market success that the application enjoys. These benefits put high demands on the underlying infrastructure, making the choice of supporting hardware and software critical to any decision to deploy Exchange, and presenting the IT team with significant challenges: a. Using traditional server-storage infrastructure brings a host of management challenges, carries a very high acquisition cost and total cost of ownership (TCO), and offers limited, complex data protection functionality that relies on multiple disparate products. b. Conversely, seeking economic infrastructure solutions has historically come with significant risks. Selecting an infrastructure solution that cannot meet the high demands for performance, availability, and scalability undermines the value that companies seek when investing in Exchange. The optimal infrastructure for Exchange should not only support and enable the benefits of Exchange, but in fact enhance them. OmniStack SimpliVity s market-leading hyperconverged infrastructure offering is the optimal infrastructure solution for Exchange, delivering all core performance and availability requirements demanded by Exchange while enabling several significant infrastructure management, data management, and overall TCO advantages to the IT team. Subsequent sections of this document demonstrate the benefits of running virtualized Microsoft Exchange deployments on OmniStack, and provide reference architectures for the reader. OmniStack delivers a number of fundamental innovations critical to the success of a Microsoft Exchange environment in a virtualized world: 1. Hyperconvergence: OmniStack provides the functionality of the core data infrastructure-- server, storage, network in addition to backup, disaster recovery, WAN optimization and cloud enablement, creating a single shared resource pool abstracting applications and VMs from the underlying hardware. a. Benefit to Microsoft Exchange: simplify operations, integrate data protection; dramatically save on Total Cost of Ownership (TCO) across CAPEX and OPEX. 2. Scale-Out Architecture: Each OmniStack node is a 2U infrastructure building block optimized for the virtual environment; expanding the environment is a simple operation of adding a new OmniStack to an existing Federation. a. Benefit to Microsoft Exchange: As the environments grow and change, extending the Exchange environment on OmniStack is a simple and low-cost operation. 3. Accelerated Data Efficiencies: inline deduplication, compression and optimization of ALL data at inception, once and forever across all stages of the data lifecycle. a. Benefit to Microsoft Exchange: Significantly increase data efficiency with the elimination of redundant data; increase performance by maximizing utilization of available CPU, Memory, and IOPS for the application, instead of wasting them on storage processes and backup. b. With the release of Exchange 2010 several years ago Microsoft announced the end of Single Instance Storage (SIS). 7 This has led to a proliferation of copies of s and attachments persisting on storage where they were once eliminated by Microsoft. SimpliVity s data virtualization platform returns the space savings that were lost when Microsoft removed this feature. 4. Global Unified Management: manage all resources globally from a single pane of glass, provide VM-centricity and mobility to backup, restore, move virtual resources and their associated data from a click of a button without the manual efforts of the past around LUNs, shares, volumes, disk groups, masking, mapping, etc. a. Benefit to Microsoft Exchange: Tie the Exchange data to the Exchange application, instead of to the legacy storage infrastructure; quickly spin up and spin down test and development environments; simplify management with a single pane of glass. 7 Page 6 of 26

7 4. Design Considerations This section details the major factors and considerations in designing a high performance and resilient Exchange deployment on OmniStack. Given the importance of data protection to any Exchange environment, this section highlights the native capabilities of Exchange and provides details on the many features of OmniStack that customers use to enhance the levels of data protection for their Exchange deployment. In addition, several best practices were leveraged in our testing and are detailed below. 4.1 Common Microsoft Exchange Configurations Although Microsoft (MS) Exchange was traditionally deployed on physical servers connected to SAN storage, in recent years, customers have increasingly been deploying Exchange in virtualized environments. Virtualization brings many benefits to the Exchange environment, including ease of management, more rapid provisioning, improved resource utilization, simpler scalability, and ability to manage changing infrastructure. This document describes several reference architectures for running Exchange in a virtual environment on OmniStack. Just as with physical deployments, it is critical to properly size and configure the virtual Exchange deployment to ensure proper the performance and data uptime requirements will be met. In Section 5, this document provides details of the sizing that was conducted as part of the reference architecture development Exchange Database Availability Groups Overview MS Exchange is deployed across a wide range of organizations, ranging from small environments with less than 100 users, to global organizations with hundreds of thousands of employees. As communication has become a mission critical application, having the system always available is a requirement. Exchange provides application-level redundancy across multiple mailbox servers and sites as part of its architecture, called the Exchange Database Availability Group (DAG). DAG is the base component of the high availability and site resilience framework built into Microsoft Exchange Server When leveraging a robust underlying infrastructure, such as OmniStack, a DAG can ensure almost 100% uptime of the Exchange environment. Given the mission criticality of Exchange, many companies opt to deploy using a DAG. To configure properly, a minimum of two copies of every mailbox server database (one active and one passive) is required to ensure that all services remain available during the failure of a single component (virtual host, mailbox server VM, etc.). Given the need to maintain two copies of every database, deploying in such a configuration requires a much higher infrastructure investment than in a non-dag environment. Customers opt for DAG when they have the requisite budget and have decided that they cannot tolerate any Exchange downtime nor the loss of any Exchange data. Despite the many benefits, a large number of customers legitimately opt for a non-dag deployment; economics drives the decision. A non-dag deployment typically requires half of the infrastructure of the DAG that would be needed to support the same number of users. When deploying a non-dag environment, alternative methods of backup and data protection are required. The native backup and DR capabilities of OmniStack enhance the value of the Exchange deployment in both DAG and non-dag environments. In DAG environments, OmniStack allows the customer to maintain a series of local and remote backups, in addition to the real-time synchronous replication that keeps both sites in synch. In all cases where a restore from previous point in time is required, restoring from a recent backup is required. In a non-dag environment, OmniStack not only delivers the backup capabilities described above, but also serves as the primary DR method, allowing the customer to restore the full Exchange environment at a remote site if needed. Given the prominence of both deployment options, SimpliVity supports both types of deployment on OmniStack DAG Configuration Planning The design of a DAG deployment begins with the database configurations for the Exchange mail servers. Using standard Exchange database layouts, active and passive copies of each database are deployed across data centers (Figure 1 shows an example of a typical two site DAG deployment). A DAG can group up to 16 Mailbox servers that host a set of databases, thereby providing automatic database-level recovery from failures that affect individual servers or databases. In deploying Exchange using the DAG capability, the user leverages the guidance of the Exchange role calculator, and rotates the active and passive copies across all mailbox servers to ensure approximately equal workloads run across the infrastructure. This will ensure that no single mailbox server is overloaded, and all users will get the required response times. In any Exchange deployment, the Client Access Server (CAS) and Hub Transport Server Page 7 of 26

8 (HUB) are additional roles in the Exchange architecture, managing client connections and mail flow. Figure 1 below shows a typical two-site Exchange deployment with DAG providing full site redundancy. environment and provides enterprise class functionality that Exchange environments demand, including: High availability Data Center A Data Center B Scalability Efficient data protection, including backup and disaster recovery Client Access Server Mailbox Server DB3-P Client Access Server DB4-P Figure 1. Database redundancy across mailbox servers in each site. Deploying all mailbox servers within the same DAG creates a site-redundant solution that can withstand the failure of an Exchange database, mailbox server, or an entire site. 4.2 OmniStack Overview DAG1 Client Access Server Client Access Server Mailbox Server DB1-A DB2-A DB1-P DB2-P DB3-A DB4-A SimpliVity s OmniStack is an ideal infrastructure platform for Microsoft Exchange deployments. OmniStack is a hyperconverged solution spanning 8-12 formerly disparate technologies including server, virtualization, storage, backup, replication, and others. It is optimized for the VMware Global federated management SimpliVity packages OmniStack on popular x86 platforms either on 2U servers marketed as OmniCube, or with partner systems from Cisco or Lenovo, marketed as OmniStack Integrated with Cisco UCS and OmniStack Solution with Lenovo System x, respectively. An individual OmniStack node includes: A compact hardware platform - a 2U industry-standard virtualized x86 platform containing compute, memory, performance-optimized SSDs and capacity-optimized HDDs protected in hardware RAID configurations, and 10GbE network interfaces A hypervisor such as VMware vsphere/esxi OmniStack virtual controller software running on the hypervisor An OmniStack Accelerator Card a special-purpose PCIe card with an FPGA, flash, and DRAM, protected with super capacitors; the accelerator card offloads CPU-intensive functions such as data compression, deduplication and optimization from the x86 processors. Figure 2. OmniStack Global Federation Page 8 of 26

9 High availability, dynamic resource sharing, and efficient data movement are standard benefits of an OmniStack Federation. An OmniStack Global Federation (Figure 2) is a network of OmniStack nodes. OmniStack nodes are deployed in a minimum of two units within vcenter Server. OmniStack s building block, scale-out architecture allows the IT team to scale their infrastructure with linear simplicity. As application capacity and performance requirements increase, more OmniStack nodes can be dynamically added to the Federation for on-demand, nondisruptive scalability. A minimum configuration of two OmniStack nodes provides high performance and high availability for the deployed virtual machines. Remote data centers can link together within the OmniStack Federation, providing for simplified, bandwidth-efficient DR and data migrations across sites, in addition to unified management of all applications, VMs, and the underlying infrastructure across the globe. Organizations large and small are taking advantage of the above functionality for their Exchange environments, deploying robust, highly available and scalable infrastructure solutions while achieving radical TCO savings. Customers are leveraging the native data protection features of OmniStack in both DAG and non-dag environments, as the next section describes in detail. 4.3 OmniStack for Exchange: A Robust Enterprise Class Solution As is viewed as one of the most mission-critical of all applications, operational continuity during various failure scenarios, and recovery to a fully operational state are of utmost importance in an Exchange environment. OmniStack running Exchange offers the highest levels of resiliency and data protection, leveraging both the builtin capabilities of Exchange 2013 and the native resiliency, availability, performance, and data protection attributes of the OmniStack hyperconverged infrastructure. In addition to the fundamental reliability and availability of the solution, the Exchange OmniStack solution offers the industry s best fault tolerance and graceful failure handling characteristics. The table below (Table 1) summarizes these attributes of both Exchange and OmniStack, demonstrating that the combination is an optimal enterprise-class solution. Exchange-OmniStack Resiliency Details Failure Type Solution Description Exchange database Fully Redundant databases per mailbox server When using DAG, redundant passive copies of mailbox server databases ensure continued uptime through various failure scenarios Mailbox server Multiple mailbox servers per OmniStack When using DAG, spreading the user load across multiple mailbox servers minimizes the number of users affected by a given component failure. It also allows the remaining mailbox servers to use all of the resources in the Federation. OmniStack component Native OmniStack fault tolerance and redundancy OmniStack nodes have many different availability features and redundant hardware components that can survive a single and even double simultaneous failure OmniStack OmniStack HA Multiple mailbox servers per data center OmniStack s backup capabilities enhance DAG by enabling point-intime restores, both locally and remotely. Additionally, because OmniStack is a flexible building block using DAG, customers can spread the user load across multiple OmniStack nodes, which will eliminate or dramatically reduce downtime due to a hardware failure. In a non-dag configuration, restoring an Exchange server from SimpliVity backups is nearly instantaneous. Site Exchange DAG or Remote backups In a site redundant DAG deployment (as depicted in Figure 1), a site failure can be tolerated without service interruption. In a non-dag deployment, OmniStack remote backups are used to rapidly restore operations at the second site. OmniStack global deduplication and compression enable efficient transfer of data across the wires, and space efficiency at the remote site. Recovering an Exchange server from a remote site is optimized to complete in the fastest time possible. Page 9 of 26

10 4.3.1 Backup Policies In an OmniStack federation, creating a backup policy is as simple as setting a few rules in the graphical user interface (GUI) all through VMware vcenter and applying it to a VM. Backups, and backup policies, are VM-centric. They are defined once, and applied to new VMs as you deploy them in the OmniStack datastore. Different VMs can have different policies from other VMs in the same datastore. The backup policy is an attribute of the VM, and move with the VM if it is migrated to a different part of the federation Locking Backups Backups are deleted automatically according to the individual backup policy. If for any reason a backup needs to be retained for a longer period (compliance, litigation hold), locking the backup (Figure 4) ensures that it will be prevented from being deleted. This feature is particularly useful in Exchange environments, given the need for archiving. It gives users the ability to ensure that all s that must be preserved can be kept within a locked Omni- Stack backup. Perhaps even more powerful is the concept of the Global Federated Architecture. Instead of backing up with a separate 3rd party application to a separate backup appliance of logical units (LUNs) on a disk shelf in a storage array, with SimpliVity you click a location and click backup. That backup could be in the local location or remote. Either way, only the unique blocks of data at granular 4KB or 8KB increments are backed up and sent over the network (if remote). This saves capacity, IOPS and bandwidth. Backup policies (Figure 3) specify: 1. Where to send the backup (local or remote data center) 2. How often to back up 3. How long to keep previous backup policy After a backup policy is applied to a virtual machine, it automatically creates a backup according to the schedule. Figure 3. Backup policies consist of one or more rules Figure 4. Prevent deletion according to a policy by locking the backup Page 10 of 26

11 5. Overview of OmniStack Reference Architectures Through a series of detailed and rigorous lab tests, SimpliVity has developed three SimpliVity-validated Reference Architectures for deploying and running Microsoft Exchange on OmniStack hyperconverged infrastructure. SimpliVity OmniCube CN5400 were used in the tests. 9 This section provides the high level details of each Reference Architecture. The subsequent section elaborates on the detailed test methodologies and testing results. 5.1 Summary Table The three reference architectures that are covered in detail in this section are summarize in the table below. Table 2: Summary Table of SimpliVity-Validated OmniCube-Exchange Reference Architectures Exchange configuration OmniCube 2+2 DAG Mailboxes ,000 OmniCube 4+4 DAG Hardware Configuration OmniCube Nodes Memory CPU Storage Four OmniCube CN-5400s in 2+2 configuration (local and remote) 384 GB GHz Intel Xeon CPU E GHz 2 CPU sockets, 12 cores per socket, 48 Logical processors, HT Active 4 x 400GB SSD 20 x 1.2 TB 10K HDD OmniStack Accelerator version Network configuration for OmniCube 2+2 The testing used four OmniCube nodes configured with both 10GbE and 1GbE networking. The network configuration (Figure 5) uses redundant cabling to prevent against the loss of a network port or wiring. In a production environment, best practice is to deploy multiple network switches in a redundant configuration to prevent against the loss of a single network switch. Mailbox servers 4 8 Databases per mailbox server 4 (2 active, 2 passive) 4 (2 active, 2 passive) Users per database 1,625 1, Reference Architecture 1: 13,000 mailboxes with DAG on OmniCube Federation 2+2 configuration A common deployment for OmniCube is a two-site environment, in which two OmniCube nodes are deployed in each of two data centers, and connected within the same Federation (also known as 2+2 ). This configuration provides high availability and local backup recoverability in each site. It also delivers elegant disaster recovery and simplified management as the OmniCube nodes and all associated VMs are managed from a single user interface in VMware vcenter. SimpliVity s validation testing proved this configuration to be optimal in a standard Exchange environment with DAG, and demonstrated that such a configuration can successfully manage up to 13,000 mailboxes. 9 We use the term OmniCube in sections 5 and 6 as those were the specific OmniStack nodes tested. Page 11 of 26

12 vcenter Server 1GbE Network Management Network Storage and Federation Networks 10GbE Network 1GbE Network 10GbE Network Figure 5. OmniCube 2+2 redundant network configuration Page 12 of 26

13 5.2.3 Logical View of the OmniCube 2+2 DAG deployment The validation testing demonstrates that OmniCube is an ideal platform to deploy a resilient Microsoft Exchange DAG to protect across two sites. Figure 6 below shows the underlying logical view of the simulated Exchange environment. Las Vegas Datacenter (LAS) Boston Datacenter (BOS) Client Access Server Hub Transport Server Client Access Server Hub Transport Server Mailbox Server 1 1-A 2-A Mailbox Server 2 3-A 4-A Database Availability Group (DAG) Mailbox Server 3 1-P 2-P Mailbox Server 4 3-P 4-P 5-P 6-P 7-P 8-P 5-A 6-A 7-A 8-A OmniCube Global Federation Active Database Copy Passive Database Copy Figure 6. Exchange DAG layout on OmniCube 2+2 Page 13 of 26

14 This scenario tested uses best practices to spread the Exchange databases and mailbox servers across all available hardware (Figure 6). This ensures that there is even loading across all server and storage, and no single part of the system becomes a performance bottleneck The configuration supports up to 13,000 users with DAG redundancy (Table 3). Table 3: Supported mailboxes in Reference Architecture Hardware OmniCube Nodes Memory CPU Eight OmniCube CN-5400 in 4+4 configuration (local and remote) 384 GB GHz Intel Xeon CPU E GHz 2 CPU sockets, 12 cores per socket, 48 Logical processors, HT Active Exchange configuration DAG, two copies Storage 4 x 400GB SSD 20 x 1.2 TB 10K HDD OmniStack Accelerator version Mailboxes 13,000 Mailbox servers 4 Databases per mailbox server 4 Users per database 1, Reference Architecture 2: 26,000 mailboxes with DAG on OmniCube Network configuration OmniCube 4+4 The testing used OmniCube configured with both 10GbE and 1GbE networking. The network configuration (Figure 7) uses redundant cabling to prevent against the loss of a network port or wiring, and should use multiple network switches deployed in a redundant configuration to prevent against the loss of a single network switch. The OmniCube Federation scales linearly to support increased virtual workloads. For larger organizations, an OmniCube 4+4 configuration (four OmniCube nodes in each datacenter, one global federation) provides both high availability and disaster recovery for up to 26,000 mailboxes in a DAG environment. Page 14 of 26

15 vcenter Server 1GbE Network Management Network Storage and Federation Networks 10GbE Network 1GbE Network 10GbE Network Figure 7. OmniCube 4+4 redundant network configuration In the validation testing, SimpliVity successfully demonstrated that OmniCube comfortably supports the workload of 26,000 mailboxes in DAG (Table 4), while staying within the latency limitations. Table 4: Supported 26,000 for a redundant OmniCube 4+ Exchange configuration DAG, two copies Mailboxes 26,000 Mailbox servers 8 Databases per mailbox server 4 Users per database 1,625 Page 15 of 26

16 6. Solution Test Methodology In order to produce the validated OmniCube Reference Architectures for Exchange detailed in Section 5 above, a series of rigorous tests that simulate real-world customer environments were defined and executed. This section of the paper describes the details of the testing, including: 1. Test Objectives 2. Test Environment 3. Test Methodology The overarching objective of the testing project was to simulate real world customer environments and validate the performance and functionality of OmniCube when deployed as the infrastructure for Microsoft Exchange. In addition to validating the core functionality and value of OmniCube for Exchange, two specific goals of the testing project included: 1. Determine the maximum number of MS Exchange users in 2+2 and 4+4 configurations 2. Deliver a recovery point objective (RPO) of under 10 minutes, and rapid Recovery Time Objective (RTO) of under 10 minutes. The project consisted of performance and operational testing, which was conducted to exemplify the application workload capacity, performance and functionality of OmniCube using typical workloads in a Microsoft Exchange 2013 infrastructure. 6.1 Microsoft Exchange Testing Overview The testing conducted covered three scenarios across two primary OmniCube Federation configurations ,000 mailboxes with DAG on OmniCube Test Details The testing used generally available (GA) hardware and software. Hardware configurations used for testing are described in Section 5. The software used is detailed below: OmniCube Test virtual machine VMware vcenter Server, 6.0.0, build VMware ESXi, 6.0, build OmniStack (8 CPU s per socket) Jetstress vcpu, 16GB RAM Microsoft Windows 2012 R2 1 OS Disk 40 GB 4KB NTFS Cluster Size 1 DB Disk 2046GB 64KB NTFS Cluster Size 1 LOG Disk 400GB 64KB NTFS Cluster Size This testing used standard Microsoft configurations, best practices, and the Jetstress benchmarking tool to simulate common Microsoft Exchange 2013 deployments. Jetstress is described in section below. The tests demonstrate production workloads, across realworld configurations for the key elements of performance, availability, and data protection Configurations to support the Reference Architectures The testing configuration began with two CN-5400 local OmniCube nodes and two remote OmniCube nodes in a four-omnicube configuration. This deployment configuration allows for high availability and data protection local to each data center, in addition to remote backups and DR to the second site. Once the initial 2+2 testing was completed, the testing environment was scaled up online, and non-distruptively. by adding two additional OmniCube nodes to each site, yielding a 4+4 configuration. All tests were then repeated with the new scaled-up environment ,000 mailboxes with DAG on OmniCube 4+4 Page 16 of 26

17 6.2.2 Methodology The testing methodology used is similar to one an Exchange administrator would follow when architecting, configuring, and deploying a new Exchange environment in production: 1. Model each scenario with the Microsoft Exchange Server Role Calculator. 2. Deploy hardware according to performance and availability requirements. 3. Configure and tune Jetstress for optimal performance. 4. Execute 24-hour Jetstress tests. 5. Test operational features and performance of backups and restores. The tests also highlighted best practices for OmniCube, specific to Microsoft Exchange, which are detailed in Section Introduction to Jetstress Jetstress is the de facto benchmarking tool for Microsoft Exchange environments. Microsoft strongly recommends that Jetstress be run against any server and storage system that will run Exchange before they are put into production. Jetstress simulates a production MS Exchange mailbox server I/O workload on the storage system. Several parameters can be specified, such as the number of Exchange databases, the percent of capacity used, and number of worker threads. Specific criteria of the latency of the storage and its impact on MS Exchange determines if the storage is appropriate for the expected production workloads. This criteria is used by Jetstress to determine if a test outcome is PASS or FAIL. PASS thresholds for Jetstress Test Lenient mode (> 6 hour test) Average Database Read Latency Average Log File Write Latency Max Database Read Latency Max Log File Write Latency 20 ms 10 ms 200 ms 200 ms After the test passes, Jetstress determines the sustained transaction I/O rate, which accounts for both the database and transaction log workloads. This transaction I/O rate can then be used to size a possible solution with the Microsoft Exchange 2013 Server Role Requirements Calculator. Over the years, Microsoft Exchange has improved considerably by optimizing and reducing the I/O workload required from the storage subsystem. This testing with Jetstress 2013 mimics MS Exchange 2013, which has reduced I/O workloads compared to the Exchange 2010 version Infrastructure System IO and Functionality Testing For each scenario, the testing started with several brief Jetstress tests of a few hours each to validate proper configuration and end-to-end throughput. This ensured that there were neither configuration issues nor problems with the deployment that would limit the desired throughput of the tests. All core functionality of OmniCube was also tested concurrently to the Jetstress workload, including frequent backups, remote replication, and selective restores. This baseline functionality testing was used to validate baseline compatibility and functionality of both Exchange and OmniCube features. After the initial testing, sustained tests of 24-hours or longer were run. These longer tests were used to validate that the SimpliVity OmniCube hyperconverged infrastructure solution meets the stringent throughput and latency requirements needed to deploy Microsoft Exchange in production. When designing the reference architecture, the Microsoft Exchange Server Role Calculator was used to determine the appropriate configuration required for each scenario: 1. Scenario 1: 13,000 in a DAG deployment 2. Scenario 2: 26,000 users in a DAG environment For each scenario, the calculator s analysis included all resources required--i/o, capacity, CPU, and memory for all required server roles in a Microsoft Exchange deployment, (Mailbox Server, Client Access Server, Hub Transport Server) to show that they could be deployed on the Omni- Cube hyperconverged architecture. In scenarios 1 and 2, initial testing validated the configuration, network, test infrastructure and baseline functional compatibility. Then a series of 24-hour tests were run to simulate the production workload of 13,000 users in a siteresilient DAG configuration. Subsequently, 26,000 users in a non-dag configuration were tested according to the same criteria. Page 17 of 26

18 In the next test phase, several policies were enabled for local backups and replication, and the 24-hours tests were re-run to confirm that OmniCube could deliver the required RPO and RTO goals while passing the Jetstress tests without performance degradation. To verify the success of the backup and replication functionality, VMs in the environment were frequently restored and verified to be intact. These tests included recovery of an Exchange database from a dirty shutdown state, in which some database entries have not been committed. Using the Exchange ESEUTIL tool, the database from the most recent OmniCube backup was recovered and brought to a clean shutdown state, a state of consistency that allows the IT team to proceed with confidence that the database is being restored with data integrity and that risks of data loss or data unavailability have been minimized. After running the OmniCube 2+2 testing for scenarios 1, the reference architecture was scaled out, online, and nondisruptively, at each site to yield a 4+4 topology. Similar to the 2+2 testing, the 4+4 testing involved several iterations of 24-hour testing to verify that OmniCube delivers the required performance and reliability. After confirming the performance results, SimpliVity backup and replication jobs where turned on and run in parallel to the Jetstress testing. Periodic restores were conducted using the ESEUTIL tool to verify a clean recovery Profile Description The main factor for storage performance is the average profile of the users. This data can be developed from knowledge of existing deployment details or collected from an existing Exchange deployment with the Microsoft Exchange Server Profile Analyzer. For this testing, a representative profile from Microsoft best practices and typical Microsoft Exchange users was used. Table 5 below shows the mailbox profile for Scenario 1 and Scenario 2 for 13,000 and 26,000 mailboxes respectively. Tier-1 User Mailbox Configuration Projected Mailbox Number Growth Percentage Total Send/Receive Capability / Mailbox / Day 5% Average Message Size (KB) 75 Mailbox Size Limit (MB) 1024 Personal Archive Mailbox Size Limit (MB) 100 messages 0 Value Given that a primary goal of the testing project was to demonstrate that the OmniCube reference architectures deliver the required performance measured in IOPS, latency, and system-wide throughput, throughout the testing, performance metrics were collected from multiple points in the infrastructure. Microsoft perfmon, SimpliVity s performance monitor and Jetstress results were collected and compared to ensure they were aligned Jetstress Test Configuration When deploying MS Exchange, different factors can have a significant impact on the I/O workload presented to the storage systems. The users profile and mailbox server layout are two of the primary factors in MS Exchange performance. Page 18 of 26

19 Jetstress configuration In this testing, Jetstress virtual machines were configured to run on separate OmniCube systems in the Federation, similar to how Exchange mailbox servers would be deployed in a typical Exchange production environment - see Figure 8 below. In each of the test scenarios that were conducted, a Jetstress virtual machine simulated the workload of a portion of a live Exchange environment. In this testing, a Jetstress VM represented a portion of the Exchange environment including several Exchange mailbox servers running as VMs on the system, each of which supports 4 databases and 1625 mailboxes. The simulations also include the workload and resource requirements for the VMs dedicated to the other key roles in an Exchange environment, specifically the Hub Transport servers and the Client Access servers. 6.3 Microsoft Exchange Performance results on OmniCube Each performance test was run at least three times to ensure consistency of the results. During the tests, additional performance metrics were collected from the Omni- Cube and VMware vcenter and compared with the results from the Jetstress testing. Figure 9, below, shows the Jetstress report card from the 2+2 testing Overall Test Result Machine Name Test Description Microsoft Exchange Jetstress 2013 Stress Test Result Report Pass WIN-CV2QULJT hour Exchange Transaction Load Test The graphic below is a section of the VMware vsphere User Interface from Scenario 3, showing the four OmniCube systems in the Las Vegas Data Center and the associated Jetstress deployments. Test Start Time Test End Time Collection Start Time Collection End Time 11/12/ :47:32 PM 11/13/ :48:16 AM 11/12/ :48:14 PM 11/13/ :48:06 AM Jetstress Version ESE Version Operating System Performance Log Figure 9. OmniCube 2+2 sample Jetstress run Windows Server 2012 R2 Standard ( ) C:\Jetstress_Results\ Stress_2015_11_12_12_47_35.blg Figure 11, below, shows the results of scenario #2, the 26,000 environment with DAG. In both cases, the passing results from these Jetstress tests demonstrate that Omni- Cube can effectively support the requirements of performance and for these reference Exchange environments. Figure 8. Scenario 3 Virtual Machine inventory for a data center in the OmniCube 4+4 configuration Page 19 of 26

20 Overall Test Result Machine Name Test Description Microsoft Exchange Jetstress 2013 Stress Test Result Report Pass WIN-CV2QULJT hour Exchange Transaction Load Test Figure 11 below is a screenshot from the OmniCube GUI demonstrating the status of recent backups taken during the testing. In this case, the policy was set to backup the Jetstress VM locally every 30 minutes. Test Start Time Test End Time Collection Start Time Collection End Time 11/13/2015 8:55:12 PM 11/14/2015 8:55:59 AM 11/13/2015 8:55:56 PM 11/14/2015 8:55:46 AM Jetstress Version ESE Version Operating System Performance Log Windows Server 2012 R2 Standard ( ) C:\Jetstress_Results\ Stress_2015_11_12_12_47_35.blg Figure 10. Jetstress performance results for 24-hour test on OmniCube Backup, Replication and Restore As described in previous sections, a significant portion of the testing conducted to validate each OmniCube reference architecture was dedicated to the native backup and disaster recovery capabilities of OmniCube, and the Omni- Cube Federation. This section of the document elaborates in more detail on the backup and restore testing, providing the reader with details on how the OmniCube functionality can be applied to an Exchange environment Backup Performance Results In all three testing scenarios, OmniCube backup policies were applied to the VMs running Jetstress. Importantly, backups were running in parallel to, and in conjunction with, the Jetstress IO testing that was used to validate the workload of each configuration. While running simultaneously during the Jetstress testing, these backups had no noticeable impact on performance of the benchmark. In most of the testing, the backup policies were set to take both a full local backup hourly, and a full backup replicated to the second site hourly, continuously during the multi-day test runs. In some of the testing, the policies were adjusted to take local and remote backups at a more frequent rate to demonstrate the ability to achieve better recovery point objectives. Tests were run with backup frequencies of every 30 minutes, every 15 minutes and every 10 minutes. For each set of tests, restores were performed to validate the success of the backup and the data integrity of the Exchange database that was backed up. Figure minute virtual machine backups These backups ran simultaneously during the Jetstress testing, and had no noticeable impact on the performance of the benchmark. This testing demonstrates a key differentiator of Omni- Cube. The result of each OmniCube backup is a true full backup of the VM. A restore of the VM is rapid, as there is no need to build a full copy from multiple incremental snapshots or backups. While the result is a full backup, the effort to take a backup and the associated capacity required to store each backup is relatively very small. Because the VM backups reside within the OmniCube Federation (whether they are stored locally or remotely), they benefit from OmniCube s deduplication capability. The actual backup generates only the incremental IO and consumes the incremental capacity of whatever new data was created since the prior backup of that VM. When backups are set to a frequency of an hour or less in an Exchange environment, the impact of these backups on the overall system is quite low. Page 20 of 26