Académique Documents
Professionnel Documents
Culture Documents
© 2010 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual
property laws. This product is covered by one or more patents listed at
http://www.vmware.com/download/patents.html.
VMware, VMware vSphere, VMware vCenter, the VMware “boxes” logo and design, Virtual SMP and VMotion are
registered trademarks or trademarks of VMware, Inc. in the United States and/or other jurisdictions. All other marks
and names mentioned herein may be trademarks of their respective companies.
VMware, Inc
3401 Hillview Ave
Palo Alto, CA 94304
www.vmware.com
Contents
1. Introduction .................................................................................. 5
1.1 Overview ........................................................................................................................ 5
1.2 Benefits of Running Exchange 2010 on vSphere .......................................................... 6
1. Introduction
1.1 Overview
Microsoft® Exchange can be a very complex application to deploy and there are many design decisions
to be made to ensure a solid solution. We know that running Microsoft Exchange Server 2010 on VMware
vSphere® can positively impact design, deployment, availability, and operations, but what does such a
solution look like?
In this document, we’ll explore a sample architecture design that illustrates an Exchange 2010
environment running on VMware vSphere™. The focus of this architecture is to provide a high-level
overview of the solution components with diagrams to help illustrate key concepts. For detailed best
practices, please refer to the Microsoft Exchange 2010 on VMware: Best Practices Guide. The sample
design covers the following:
Design Concepts
o Resource Management
o Sample Physical Layout
o Capacity Planning Process Overview
Building Block Examples (for standalone mailbox servers)
o 8,000 mailboxes – 150 sent/received
o 16,000 mailboxes – 150 sent/received
o 64,000 mailboxes – 150 sent/received
DAG Examples (for clustered Mailbox Servers – 8K, 16K, and 64K mailboxes)
o 8,000 active mailboxes – 150 sent/received
o 16,000 active mailboxes – 150 sent/received
o 64,000 active mailboxes – 150 sent/received
Deployment Considerations
Summary
The examples show how these components contribute to the overall design and are intended only to
provide a guideline. Customers should work with their infrastructure vendors to develop a detailed sizing
and architecture plan designed for their individual requirements. After describing some important design
concepts, we’ll take a look at sizing examples of Exchange 2010 on vSphere for three different sized
organizations. We’ll make one pass with the VMware Building Block process for standalone mailbox
servers, and a second pass for mailbox servers configured in a DAG.
8,000 mailboxes – 150 sent/received
16,000 mailboxes – 150 sent/received
64,000 mailboxes – 150 sent/received
It is important to note that this document describes samples that should be viewed as a model to help
understand components and concepts. Official sizing for Exchange environments will vary based on
business and technical requirements as well as server and storage hardware platforms. VMware
recommends that you engage your server and storage vendors in your design plans or use one of the
detailed, hardware-specific reference architectures found on our website and in the Microsoft Exchange
2010 on VMware: Partner Resources Catalog.
2. Design Concepts
2.1 Resource Management
2.1.1 Resource Pools
When working in vSphere environments it is important to classify and structure virtual machines logically
as you would physical servers, and using resource pools is a great way to accomplish this goal. Resource
pools allow for easy grouping and logical separation of production, test, and development workloads. You
can also employ some physical separation as a part of your infrastructure, separating the test and
development environments from the production environment on different ESX hosts as was done in the
figure below, but it is not necessary to do so.
Resource pools have the added benefit of ensuring that the most important workloads maintain priority for
the use of the physical resources. To do this, each resource pool is allowed a certain number of “shares.”
The number of shares designated for each resource pool depends on the workloads for each virtual
machine. For instance, a Production Resource Pool would be given the most number of shares and a
Development or Test Resource Pool would be given the least. In the event of resource contention, where
two or more virtual machines are trying to use the same resource (e.g., vCPU), the virtual machine with
the most shares assigned to it takes priority while the other virtual machines have to wait for the vCPU to
become available. Please refer to the latest VMware Resource Management Guide on the vSphere
documentation website for more details on configuring and managing resource pools.
Table 1. Building block CPU and RAM requirements for mailboxes with 150 messages sent/received per day
(based on http://technet.microsoft.com/en-us/library/ee712771.aspx).
The sizing process begins with understanding and applying Microsoft guidelines for each server role, as
represented by the following high-level processes:
Design the mailbox server building block.
o Define current workloads using the Microsoft Exchange Server Profile Analyzer.
o Choose an appropriate building block (500, 1000, 2000, and 4000 user blocks have been tested
and validated, although larger building blocks may be possible).
o Apply Microsoft guidelines to determine the CPU requirements.
o Apply Microsoft guidelines to determine the amount of memory required.
o Use the Exchange 2010 Mailbox Server Role Requirements Calculator from Microsoft to
determine storage requirements.
3.3.2 VM Distribution
Now that we understand the physical resource requirements and associated virtual hardware
configuration, we can plan physical ESX host hardware to meet those requirements. To build
infrastructure availability into the architecture, we distribute the six total VMs across two ESX hosts. Initial
placement of VMs is relatively unimportant, especially if you’re using DRS. Because we’re not running a
DAG, HA and DRS are perfectly fine and fully supported for the mailbox servers.
Table 5. Exchange Virtual Machine Distribution
3.4.2 VM Distribution
In this example, we’ve chosen to use four ESX hosts connected to shared storage to use advanced
VMware features such as HA and DRS.
To build infrastructure availability into the architecture, we distribute the nine total VMs across four
physical ESX hosts. Initial placement of VMs is relatively unimportant, especially if you’re using DRS.
Because we’re not running a DAG, HA and DRS are fine and fully supported for the mailbox servers.
Table 8. Exchange Virtual Machine Distribution
The sizing process begins with understanding and applying Microsoft’s guidelines for each server role, as
represented by the following high-level processes:
Design the Mailbox Server DAG nodes.
o Define current workloads using the Microsoft Exchange Server Profile Analyzer.
o To greatly simplify the capacity planning process, utilize the Exchange 2010 Mailbox Server Role
Requirements Calculator to calculate CPU, memory, and storage sizing.
o Alternatively, if you prefer a manual process:
Apply Microsoft guidelines to determine the CPU and memory requirements. Inputs
include, number of mailboxes, mailbox profile, number of servers in the DAG, number of
passive database copies, and several other custom parameters.
4.3.5 VM Distribution
Now that we understand the physical resource requirements and associated virtual hardware
configuration, we can plan physical ESX host hardware to meet those requirements. To build
infrastructure availability into the architecture, we distribute the eight total VMs across three physical
VMware ESX host servers. Initial placement of VMs is relatively unimportant, especially if you’re utilizing
DRS. Remember you must disable HA and DRS for your mailbox servers that are running in a DAG.
Table 16. Exchange Virtual Machine Distribution
Figure 10. Building Block Virtual Machine Interaction with Shared Storage
4.4.5 VM Distribution
In this example, we’re using four ESX hosts connected to shared storage to use advanced VMware
features such as HA and DRS.
To build infrastructure availability into the architecture, we distribute the 10 total VMs across four physical
VMware ESX host servers. Initial placement of VMs is relatively unimportant, especially if you’re utilizing
DRS. Remember that you must disable HA and DRS for your mailbox servers that are running in a DAG.
Table 21. Exchange Virtual Machine Distribution
Figure 12. Building Block Virtual Machine Interaction with Shared Storage
6. Summary
This guide shows sample configurations of Exchange 2010 on VMware. These examples provide only a
high-level guideline and are not intended to reflect customer-specific workloads. Customers need to work
with their infrastructure vendors to build a detailed sizing and architecture design that meets their
individual requirements.