www.SimpliVity.com
Table of Contents
1. Executive Summary ...3
2. Introduction ...4
3. Exchange on OmniStack: The Optimal Enterprise Email Solution ...6
4. Design Consideration...7
4.1 Common Microsoft Exchange Configurations ...7
4.1.1 Exchange Database Availability Groups Overview ...7
4.1.2 DAG Configuration Planning...7
4.2 OmniStack Overview ...8
4.3 OmniStack for Exchange: A Robust Enterprise Class Email Solution ...9
4.3.1 Backup Policies ...10
4.3.2 Locking Backups ...10
5. Overview of OmniStack Reference Architectures ...11
5.1 Summary Table ...11
5.2 Reference Architecture #1: 13,000 mailboxes with DAG on OmniCube Federation 2+2 configuration ...11
5.2.1 Hardware Configuration ...11
5.2.2 Network configuration for OmniCube 2+2...11
5.2.3 Logical View of the OmniCube 2+2 DAG deployment ...13
5.3 Reference Architecture #2: 26,000 mailboxes without DAG on OmniCube 2+2 ...14
5.3.1 Hardware ...14
5.3.2 Network configuration OmniCube 4+4...14
6. Solution Test Methodology ...16
6.1 Microsoft Exchange Testing Overview ...16
6.2 Test Details ...16
6.2.1 Configurations to support the Reference Architectures ...16
6.2.2 Methodology ...17
6.2.3 Introduction to Jetstress ...17
6.2.4 Infrastructure System IO and Functionality Testing ...17
6.2.5 Jetstress Test Configuration ...18
6.3 Microsoft Exchange Performance results on OmniCube ...19
6.4 Backup, Replication and Restore ...20
6.4.1 Backup Performance Results ...20
6.4.2 Restore Results ...21
7. Configuration Best Practices ...22
7.1 Resource reservations for MS Exchange mailbox server VMs ...22
7.2 Networking bandwidth and latency to remote sites ...23
7.3 MS Exchange database volume cluster size ...23
8. Conclusion ...24
9. Glossary ...25
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 sup-port real-world Exchange deployments in virtualized envi-ronments, 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 success-ful 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 success-fully demonstrated various Microsoft Exchange configu-rations 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 hypercon-verged 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 infra-structure for Exchange, the native benefits of OmniStack significantly enhance the value of Exchange.
SimpliVity has tested single copy and Database Availability Group (DAG) configurations, reaching 26,000 mailboxes on commonly deployed configurations of OmniStack Federations.
As the number of mailboxes roughly equates to the num-ber 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 data-base 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 optimiza-tion on all data at incepoptimiza-tion 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 conti-nuity and disaster recovery for critical applications and data, while eliminating the need for special-purpose backup and recovery hardware or software. OmniS-tack’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 email solution.
The paper also details best practices for implementing vir-tualized Microsoft Exchange environments on OmniStack.
www.SimpliVity.com
2. Introduction
E-mail is the predominant form of communication in the business world. It is how we communicate and collabo-rate on a daily basis, whether we are in the office or on the road. We send quick notes, long reports, weekly newslet-ters, and attachments.
E-mail 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 e-mail 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 world-wide email accounts continues to grow from over 4.1 bil-lion accounts in 2014 to over 5.2 bilbil-lion accounts by the end of 2018.”1
The Radicati Group adds: “In 2014, the majority of email traffic comes from the business world, which accounts for over 108.7 billion emails sent and received per day. Email remains the most common form of communication in the business space. Email use is growing in the business sector and by 2018, business email will account for over 139.4 bil-lion emails sent and received per day.”2
There are 140 billion e-mail 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 20203 −and is exacerbated by the increasing
demands put on that data: management, mobility, protec-tion, 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), espe-cially for business and mission-critical applications like e-mail 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-IDCGone 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. “Email Statistics Report, 2014-2018.” April 2014. 2 The Radicati Group. “Email Statistics Report, 2014-2018.” April 2014. 3 IDC. “Digital Universe.” April 2014.
• 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 appli-cations 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 on-premises 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 e-mail 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 perfor-mance–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 infrastruc-ture capabilities using traditional infrastrucinfrastruc-ture 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 sin-gle, shared resource pool across the entire IT stack, elimi-nating point products and inefficient siloed IT architectures.
5http://www.cio.com/article/705248/How_to_Virtualize_Mission_Critical_Applications
www.SimpliVity.com
3. Exchange on OmniStack: The Optimal Enterprise Email Solution
As detailed in Section 2 above, Microsoft’s Exchange has established itself as the far and away market leader for enterprise email, and for good reason. The level of both end-user and administrator functionality, performance, and reliability drives the market success that the appli-cation 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 chal-lenges:
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 function-ality that relies on multiple disparate products. b. Conversely, seeking economic infrastructure
solu-tions 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 solu-tion for Exchange, delivering all core performance and avail-ability requirements demanded by Exchange while enabling several significant infrastructure management, data man-agement, and overall TCO advantages to the IT team. Subsequent sections of this document demonstrate the benefits of running virtualized Microsoft Exchange deploy-ments on OmniStack, and provide reference architectures for the reader.
OmniStack delivers a number of fundamental innovations critical to the success of a Microsoft Exchange environ-ment in a virtualized world:
1. Hyperconvergence: OmniStack provides the functional-ity of the core data infrastructure-- server, storage, net-work—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
opera-tions, 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
environ-ments 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 maximiz-ing utilization of available CPU, Memory, and IOPS for the application, instead of wasting them on stor-age 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
prolifera-tion of copies of emails 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 glob-ally 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 with-out 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.
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 custom-ers 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 deploy-ing Exchange in virtualized environments. Virtualiza-tion brings many benefits to the Exchange environment, including ease of management, more rapid provisioning, improved resource utilization, simpler scalability, and abil-ity 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.
4.1.1 Exchange Database Availability Groups Overview
MS Exchange is deployed across a wide range of organiza-tions, ranging from small environments with less than 100 users, to global organizations with hundreds of thousands of employees. As e-mail communication has become a mission critical application, having the email system always available is a requirement.
Exchange provides application-level redundancy across multiple mailbox servers and sites as part of its architec-ture, called the Exchange Database Availability Group (DAG). DAG is the base component of the high avail-ability and site resilience framework built into Microsoft Exchange Server 2013. When leveraging a robust underly-ing 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 e-mail
ser-vices remain available during the failure of a single compo-nent (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; econom-ics 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.
4.1.2 DAG Configuration Planning
The design of a DAG deployment begins with the data-base configurations for the Exchange mail servers. Using standard Exchange database layouts, active and passive copies of each database are deployed across data cen-ters (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 mail-box 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
www.SimpliVity.com
(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.
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
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
Data Center A DAG1 Data Center B Client Access Server
Mailbox Server Mailbox Server
Client Access Server Client Access Server Client Access Server DB3-P DB4-P DB1-A DB2-A DB1-P DB2-P DB3-A DB4-A
environment and provides enterprise class functionality that Exchange environments demand, including:
• High availability
• Scalability
• Efficient data protection, including backup and disaster recovery
• Global federated management
SimpliVity packages OmniStack on popular x86 plat-forms—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.
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 lin-ear simplicity. As application capacity and performance requirements increase, more OmniStack nodes can be dynamically added to the Federation for on-demand, non-disruptive scalability.
A minimum configuration of two OmniStack nodes provides high performance and high availability for the deployed vir-tual machines. Remote data centers can link together within the OmniStack Federation, providing for simplified, band-width-efficient DR and data migrations across sites, in addi-tion to unified management of all applicaaddi-tions, 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
infrastruc-ture solutions while achieving radical TCO savings. Cus-tomers 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 Email Solution
As email 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 built-in 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 character-istics. The table below (Table 1) summarizes these attri-butes 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 databases ensure continued uptime through various failure scenariosWhen using DAG, redundant passive copies of mailbox server 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 redun-dant 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-in-time restores, both locally and remotely. Additionally, because Om-niStack 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 Sim-pliVity 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.
www.SimpliVity.com
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. Perhaps even more powerful is the concept of the Global Federated Architecture. Instead of backing up with a sepa-rate 3rd party application to a sepasepa-rate 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
4.3.2 Locking Backups
Backups are deleted automatically according to the indi-vidual 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 email archiving. It gives users the ability to ensure that all emails that must be preserved can be kept within a locked Omni-Stack backup.
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 Micro-soft Exchange on OmniStack hyperconverged infrastruc-ture. 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 OmniCube 4+4 DAG Mailboxes 13000 26,000
Mailbox servers 4 8 Databases per
mailbox server
4 (2 active, 2
passive) 4 (2 active, 2 passive) Users per database 1,625 1,625
5.2 Reference Architecture 1: 13,000 mailboxes with DAG on OmniCube Federation 2+2 configuration
A common deployment for OmniCube is a two-site envi-ronment, 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 con-figuration 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.
5.2.1 Hardware Configuration
OmniCube
Nodes Four OmniCube CN-5400s in 2+2 configuration (local and remote)
Memory 384 GB
CPU
24 CPUs @ 2.5 GHz
Intel Xeon CPU E5-2680 v3 @2.5 GHz
2 CPU sockets, 12 cores per socket, 48 Logical processors, HT Active
Storage 4 x 400GB SSD 20 x 1.2 TB 10K HDD OmniStack Accelerator version 3.0.8.312
5.2.2 Network configuration for OmniCube 2+2
The testing used four OmniCube nodes configured with both 10GbE and 1GbE networking. The network configu-ration (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.
www.SimpliVity.com Figure 5. OmniCube 2+2 redundant network configuration
Management Network
Storage and Federation Networks 1GbE Network 10GbE Network vCenter Server 1GbE Network 10GbE Network
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) Client Access Server Mailbox
Server 1 MailboxServer 2
Active
Database Copy PassiveDatabase Copy Hub Transport Server Boston Datacenter (BOS)
OmniCube
Global
Federation
Database
Availability Group
(DAG)
5-P 6-P 1-A 2-A 7-P 8-P 3-A 4-A Client Access Server MailboxServer 3 MailboxServer 4 Hub Transport Server 1-P 2-P 5-A 6-A 3-P 4-P 7-A 8-A
www.SimpliVity.com
This scenario tested uses best practices to spread the Exchange databases and mailbox servers across all avail-able 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 1
Exchange configuration DAG, two copies Mailboxes 13,000
Mailbox servers 4 Databases per mailbox server 4 Users per database 1,625
5.3 Reference Architecture 2: 26,000 mailboxes with DAG on OmniCube 4+4
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.
5.3.1 Hardware
OmniCube
Nodes Eight OmniCube CN-5400 in 4+4 configuration (local and remote)
Memory 384 GB
CPU
24 CPUs @ 2.5 GHz
Intel Xeon CPU E5-2680 v3 @2.5 GHz
2 CPU sockets, 12 cores per socket, 48 Logical processors, HT Active
Storage 4 x 400GB SSD 20 x 1.2 TB 10K HDD OmniStack Accelerator version 3.0.8.312
5.3.2 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.
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
Management Network
Storage and Federation Networks 1GbE Network 10GbE Network vCenter Server 1GbE Network 10GbE Network
www.SimpliVity.com
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 test-ing, 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 applica-tion workload capacity, performance and funcapplica-tional- functional-ity 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.
1. 13,000 mailboxes with DAG on OmniCube 2+2 2. 26,000 mailboxes with DAG on OmniCube 4+4
6.2 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
VMware vCenter Server, 6.0.0, build 2776511 VMware ESXi, 6.0, build 2716716
OmniStack 3.0.8.312 (8 CPU’s per socket)
Test virtual machine
Jetstress 2013 2 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 6.2.3 below.
The tests demonstrate production workloads, across real-world configurations for the key elements of performance, availability, and data protection.
6.2.1 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 configura-tion allows for high availability and data protecconfigura-tion 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.
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 avail-ability 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 Sec-tion 7.
6.2.3 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 sys-tem that will run Exchange before they are put into pro-duction.
Jetstress simulates a production MS Exchange mailbox server I/O workload on the storage system. Several param-eters 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 age and its impact on MS Exchange determines if the stor-age is appropriate for the expected production workloads. This criteria is used by Jetstress to determine if a test
out-come is PASS or FAIL.
PASS thresholds for Jetstress Test “Lenient” mode (> 6 hour test)
• Average Database Read Latency 20 ms • Average Log File Write Latency 10 ms • Max Database Read Latency 200 ms • Max Log File Write Latency 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 Micro-soft Exchange 2013 Server Role Requirements Calculator. Over the years, Microsoft Exchange has improved con-siderably by optimizing and reducing the I/O workload required from the storage subsystem. This testing with Jet-stress 2013 mimics MS Exchange 2013, which has reduced I/O workloads compared to the Exchange 2010 version.
6.2.4 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 con-figuration 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, includ-ing 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 solu-tion meets the stringent throughput and latency require-ments 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 deploy-ment, (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 configura-tion, 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 site-resilient DAG configuration. Subsequently, 26,000 users in a non-DAG configuration were tested according to the same criteria.
www.SimpliVity.com
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 suc-cess 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 non-disruptively, at each site to yield a 4+4 topology.
Similar to the 2+2 testing, the 4+4 testing involved sev-eral 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.
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, SimpliV-ity’s performance monitor and Jetstress results were col-lected and compared to ensure they were aligned.
6.2.5 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’ email profile and mail-box server layout are two of the primary factors in MS Exchange performance.
6.2.5.1 E-mail Profile Description
The main factor for storage performance is the average e-mail profile of the users. This data can be developed from knowledge of existing deployment details or col-lected from an existing Exchange deployment with the Microsoft Exchange Server Profile Analyzer. For this test-ing, 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 Value
Projected Mailbox Number
Growth Percentage 5% Total Send/Receive Capability /
Mailbox / Day 100 messages Average Message Size (KB) 75
Mailbox Size Limit (MB) 1024 Personal Archive Mailbox Size
6.2.5.2 Jetstress configuration
In this testing, Jetstress virtual machines were configured to run on separate OmniCube systems in the Federa-tion, 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 mail-box servers running as VMs on the system, each of which supports 4 databases and 1625 mailboxes. The simula-tions also include the workload and resource require-ments for the VMs dedicated to the other key roles in an Exchange environment, specifically the Hub Transport servers and the Client Access servers.
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.
Figure 8. Scenario 3 Virtual Machine inventory for a data center in the OmniCube 4+4 configuration
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, addi-tional 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
Microsoft Exchange Jetstress 2013 Stress Test Result Report
Overall Test Result Pass
Machine Name WIN-CV2QULJT141
Test Description 12-hour Exchange Transaction Load Test Test Start Time 11/12/2015 12:47:32 PM Test End Time 11/13/2015 12:48:16 AM Collection Start Time 11/12/2015 12:48:14 PM Collection End Time 11/13/2015 12:48:06 AM Jetstress Version 15.00.0995.000 ESE Version 15.00.0847.030
Operating System Windows Server 2012 R2 Standard (6.2.9200.0) Performance Log C:\Jetstress_Results\Stress_2015_11_12_12_47_35.blg
Figure 9. OmniCube 2+2 sample Jetstress run
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 perfor-mance and for these reference Exchange environments.
www.SimpliVity.com Microsoft Exchange Jetstress 2013
Stress Test Result Report
Overall Test Result Pass
Machine Name WIN-CV2QULJT141
Test Description 12-hour Exchange Transaction Load Test Test Start Time 11/13/2015 8:55:12 PM Test End Time 11/14/2015 8:55:59 AM Collection Start Time 11/13/2015 8:55:56 PM Collection End Time 11/14/2015 8:55:46 AM Jetstress Version 15.00.0995.000
ESE Version 15.00.0847.030
Operating System Windows Server 2012 R2 Standard (6.2.9200.0) Performance Log C:\Jetstress_Results\Stress_2015_11_12_12_47_35.blg
Figure 10. Jetstress performance results for 24-hour test on OmniCube 4+4 6.4 Backup, Replication and Restore
As described in previous sections, a significant portion of the testing conducted to validate each OmniCube refer-ence architecture was dedicated to the native backup and disaster recovery capabilities of OmniCube, and the Omni-Cube Federation. This section of the document elabo-rates 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.
6.4.1 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 simultane-ously 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 repli-cated 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 bet-ter 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 per-formed to validate the success of the backup and the data integrity of the Exchange database that was backed up.
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.
Figure 11. 30 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 capac-ity 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 capabil-ity. 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.
6.4.2 Restore Results
Restores were done using the normal administrative capa-bilities of OmniCube, all of which are managed through the SimpliVity user interface (UI) which is deployed as a tab within VMware’s vCenter.
To restore a backup of a virtual machine, the specific backup in the SimpliVity tab was selected and the process was driven by the simplified native restore wizard. Figure 12 demonstrates the selection of the backup to restore.
Figure 12. Restoring a VM from backup
The wizard (Figure 13) allows the user to input options, specifying if the restored VM should create a new VM or replace the existing one, as well as selecting the destina-tion of the restored VM. The testing conducted validated all options available to the user during the restore process.
Then specify if you want to replace the existing virtual machine, or create a new one, as well as the destination of the restored VM.
Figure 13. Restoring a virtual machine to a specific data center and datastore
As mentioned above, because the result of every Omni-Cube backup is a full backup of the VM, restoring a backup is very fast. The testing within each test scenario validated the restore speeds, consistently demonstrating the ability to restore a local VM in seconds. Figure 14 shows that the restore of a 2 TB Exchange VM took only 10 seconds.
www.SimpliVity.com
7. Configuration Best Practices
Configuration and usage best practices were incorporated into the testing methodology and are captured within sections 5 and 6. This section includes additional best practices that were captured during the Exchange validation testing, and/or through SimpliVity’s interaction with customers and partners.
7.1 Resource reservations for MS Exchange mailbox server VMs
Microsoft Exchange has dramatically improved performance over successive versions with a significant increase in mailbox server caching. This can cause a problem when virtualized, and memory is oversubscribed on the ESXi host. Exchange is expecting data to be in main memory cache, but memory overprovisioning can reduce the physical memory available to the mailbox server. Both Microsoft and VMware recommend disabling CPU and memory overprovisioning for mailbox server virtual machines.
This can be done in ‘Resources’ tab in the virtual machine settings (Figure 15).
Figure 15. Add CPU reservation for Exchange mailbox servers
In later versions of vSphere, you can explicitly ‘Reserve all guest memory’, instead of setting a memory reservation in MB (Figure 16).
7.2 Networking bandwidth and latency to remote sites
Performance of the network between sites is the limiting factor of backup performance. Though the latency is not as important, the bandwidth determines how much data can be transferred per backup cycle.
Having too large a change rate, or not enough bandwidth, causes backups to run slower than expected. If the backup cycle is too short, subsequent backups will queue behind the active backup.
7.3 MS Exchange database volume cluster size
As Exchange databases are on the order of hundreds of GB to several TB, best practices are designed to configure the NTFS volumes to efficiently handle these very large files. Using the largest file systems cluster size of 64 KB reduces the overhead and ensures that they are stored in an efficient manner.
You must set this parameter when you first create the Exchange database volumes. It is difficult to change the NTFS cluster size after deploying the Exchange databases. Set the cluster size (also called Allocation unit size) when formatting the NTFS volume (Figure 17).
Figure 17. Format MS Exchange database volumes with a 64KB cluster size.
After formatting the Microsoft Exchange database vol-umes, check the NTFS cluster size with fsutil (Figure 18).
C:\Users\Administrator> fsutil fsinfo ntfsinfo E: NTFS Volume Serial Number : 0x149ca6c99ca6a4a8 Version : 3.1
Number Sectors : 0x00000000ffbfe7ff Total Clusters : 0x0000000001ff7fcf Free Clusters : 0x0000000000a77f5f Total Reserved : 0x0000000000000000 Bytes Per Sector : 512
Bytes Per Cluster : 65536
Bytes Per FileRecord Segment : 1024 Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 0x0000000000040000 Mft Start Lcn : 0x000000000000c000 Mft2 Start Lcn : 0x0000000000000001 Mft Zone Start : 0x000000000000c000 Mft Zone End : 0x000000000000cca0 RM Identifier: 57D47C76-F371-11E3-B53F-005056BE726A Figure 18. Use fsutil to check for 64 KB cluster size
For additional best practices, see the following:
• Microsoft Exchange 2013 on VMware - Best Practices Guide
• Microsoft Exchange 2013 on VMware - Design and Sizing Guide
www.SimpliVity.com
8. Conclusion
This paper documents several SimpliVity validated refer-ence architectures for Exchange, and demonstrates the benefits of SimpliVity’s OmniStack in a virtualized Micro-soft Exchange environment of up to 26,000 mailboxes. The SimpliVity OmniStack is the only truly hyperconverged
platform on the market and the validation testing has suc-cessfully demonstrated, using standard Microsoft tools, that it is the perfect platform to run production Exchange workloads, delivering the requisite performance and avail-ability, while enhancing the data protection attributes of Exchange with OmniStack’s native backup and DR capa-bilities.
Through the detailed testing across a range of real-world customer scenarios, the document demonstrates that OmniStack provides several core benefits for the Exchange environment of:
1. Hyperconvergence: a single shared resource pool abstracting applications and VMs from the underlying hardware across not just server, storage, network, but also backup, disaster recovery, WAN optimization and cloud enablement.
2. Scale-Out Architecture: the ability to grow the
infrastructure by adding incremental building blocks to an existing deployment, while the application remains online.
3. Accelerated Data Efficiencies: inline deduplication, compression, and optimization of ALL data at inception, once and forever across all stages of the data lifecycle. 4. Global Unified Management: manage all resources
globally from a single pane of glass, provide VM-cen-tricity 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.
For Microsoft Exchange, SimpliVity OmniStack:
a. Enhances the native data protection capabilities of Exchange, by providing an economical alternative to DAG for some customers, while providing point-in-time restores for all deployments
b. Ties the Exchange data to the Exchange application, instead of to the legacy storage infrastructure for simplified management with a single pane of glass. c. Simplifies operations, integrates data protection
and dramatically reduces TCO
d. Significantly increases data efficiency with the elimi-nation of redundant data, increasing performance by maximizing utilization of available CPU, Memory, and IOPS for the application, instead of wasting them on storage processes and backup.
Through the rigorous testing across a range of scenarios, the SimpliVity testing has demonstrated that OmniStack is the ultimate infrastructure solution for Microsoft Exchange.
9. Glossary
Database Availability Group (DAG)
A base component of the Mailbox server high availability and site resilience framework built into Microsoft Exchange Server 2013. A DAG is a group of up to 16 Mailbox servers that hosts a set of databases and provides automatic database-level recovery from failures that affect individual servers or databases.
OmniStack Federation A network of two or more OmniStack nodes that provides an elastic, infinitely scalable pool of shared resources.
www.SimpliVity.com
10. Works Cited
Johnson, N. (2013, September 17). Jetstress 2013, Jetstress Field Guide. Retrieved from Microsoft Office TechCenter:
http://gallery.technet.microsoft.com/office/Jetstress-2013-Field-Guide-2438bc12
Microsoft Corporation. (2010, March 4). Microsoft Exchange Server Profile Analyzer. Retrieved from Microsoft Download Center: http://www.microsoft.com/en-us/download/details.aspx?id=10559
Microsoft Corporation. (2013, September 11). Microsoft Exchange Server Jetstress 2013 Tool. Retrieved from Microsoft Download Center: http://www.microsoft.com/en-us/download/details.aspx?id=36849
Microsoft Corporation. (2014, April 2). Exchange 2013 Server Role Requirements Calculator. Retrieved from Microsoft Office TechCenter: http://gallery.technet.microsoft.com/office/Exchange-2013-Server-Role-f8a61780
VMware, Inc. (2013). Microsoft Exchange 2013 on VMware - Best Practices Guide. Retrieved from vmware.com:
http://www.vmware.com/files/pdf/Exchange_2013_on_VMware_Best_Practices_Guide.pdf
VMware, Inc. (2013). Microsoft Exchange 2013 on VMware - Design and Sizing Guide. Retrieved from vmware.com:
http://www.vmware.com/files/pdf/Exchange_2013_on_VMware_Design_and_Sizing_Guide.pdf
For more information, visit:
www.simplivity.com
® 2015, SimpliVity. All rights reserved. Information described herein is furnished for informational use only, is subject to change without notice. SimpliVity, the SimpliVity logo, OmniCube, OmniStack, and Data Virtualization Platform are trademarks or registered trademarks of SimpliVity Corporation in the United States and certain other countries. All other trademarks are the property of their respective owners.
