Microsoft Exchange 2010 on VMware: Availability and Recovery Options
Exchange 2010 on VMware – Technical Workshop Presentation
description
Transcript of Exchange 2010 on VMware – Technical Workshop Presentation
© 2009 VMware Inc. All rights reserved
Confidential
Exchange 2010 on VMware –Technical Workshop Presentation Scott Salyer, Lead Architect – Microsoft Solutions, VMware
Alex Fontana, Technical Solutions Architect – Microsoft Solutions, VMware
2 Confidential
Agenda Introductions Exchange on vSphere Overview and Updates Exchange on vSphere Performance ESX host Best Practices for Exchange Exchange 2010 Capacity Planning Availability & Recovery Options Customer Success Stories
3 Confidential
VMworld 2007• Exchange 2003 performance study (Dell)• Early adopters
VMworld 2008 (US and EMEA)• Exchange 2007 performance studies
16,000 users on one box
• University of Plymouth 46,000 seat deployment• SVVP support
VMworld 2009:• Widespread adoption• Largest enterprise accounts designing for virtualization
Trends Towards Exchange Virtualization
4 Confidential
Exchange 2003 32-bit Windows 900MB database
cache 4Kb block size High read/write
ratio
Exchange 2007 64-bit Windows 32+ GB database
cache 8Kb block size 1:1 read/write
ratio 70% reduction in
disk I/O
Exchange 2010 64-bit Windows 32Kb block size I/O pattern
optimization Further 50% I/O reduction
Exchange is Maturing
5 Confidential
% o
f App
licat
ions
Application Performance Requirements
20,000
800 Mb/s
16 GB
2 vCPU
1. Source: VMware Capacity Planner assessments
ESX 3.5
100,000
9 Gb/s
64 GB
4 vCPU
ESX 4
> 300,000
30 Gb/s
255 GB
8 vCPU
< 10,000
380 Mb/s
< 4 GB
1 vCPU
ESX 3ESX 2
20% - 30% <10% - 20% <2% - 10%30% - 60% Overhead
>95% of Apps Match Native Performance on Virtual Machines
6 Confidential
More physical cores per socket More physical memory Smaller datacenter footprint More network bandwidth (10Gb ethernet) Optimized for virtualization• AMD RVI• Intel EPT
Server Hardware is More Powerful
7 Confidential
Scenario 1:• Support through MS Premier contract• http://support.microsoft.com/kb/897615/en-us
Scenario 2:• Support through Microsoft Server Virtualization Validation Program• ESX 3.5 U2 and above (including vSphere)• Windows Server 2008 and above• Exchange 2007 and above (including Exchange 2010)
Scenario 3:• Support through server OEM• http://www.vmware.com/support/policies/ms_support_statement.html
Scenario 4:• Support through VMware GSS, TSA Net
Support Options
8 Confidential
Server Consolidation:
• Utilize all your server processor cores.
• Maintain role isolation without additional hardware expense.
Operational advantages:
• Design for today’s workload rather than guessing about tomorrow.
• Design for specific business requirements...
• Rapidly provision Exchange Servers with virtual machine templates.
• Reduce hardware and operational Costs of maintaining an Exchange Lab.
• Enhance testing and troubleshooting using cloned production virtual machines.
Higher availability with less complexity:
• Reduce planned downtime due to hardware or BIOS updates with VMware VMotion™.
• Reduce unplanned downtime due to hardware failure or resource constraints.
• Implement simple and reliable Exchange disaster recovery.
Key Benefits of a vSphere platform:
9 Confidential
Agenda Introductions Exchange on vSphere Overview and Updates Exchange on vSphere Performance ESX host Best Practices for Exchange Exchange 2010 Capacity Planning Availability & Recovery Options Customer Success Stories
10 Confidential
Jetstress• Storage performance assessment for Exchange provided by
Microsoft.• Uses Exchange libraries to simulate multi-threaded Exchange-like
workload across storage configuration. LoadGen
• Exchange deployment performance assessment provided by Microsoft.
• Runs end-to-end tests from client to measure typical Exchange activities.
• SendMail, Logon, CreateTask, RequestMeeting, etc.
Exchange 2010 Performance Analysis
11 Confidential
Virtual is within 5% of Physical. Only 25% CPU with 4000 Users.
vSphere Scale Up Performance of Exchange
12 Confidential
Performance remains good with more VMs and Users. CPU Utilization is under 60% with 8,000 users and 4 VMs.
vSphere Scale Out Performance of Exchange
13 Confidential
Heavy Online Profile Double Heavy Online Profile
0
50
100
150
200
250
Fibre ChanneliSCSINFS
Avg
Sen
dMai
l Lat
ency
(ms)
Heavy Online Profile Double Heavy Online Profile
0
10
20
30
40
50
60
70Fibre ChanneliSCSINFS
% C
PU U
tiliz
atio
n
8 VMs with 2000 Heavy Online Users = 16000 Users Total Performance of FC, iSCSI, and NFS on NetApp FAS6030 All three protocols performed great – FC was the Best
Storage Protocol Performance Comparison
14 Confidential
0
2000
4000
6000
8000
10000
12000IOPS Change with LoadGen Load
11 Hours of LoadGen Testing with Four Time Zones
IOPS
Users in Time Zones Start Users in Time
Zones Stop
What happens when Exchange VMs are allowed to roam? vSphere has the ability to load balance with DRS Algorithm for DRS includes cost / benefit analysis
16,000 Users 8 VMs 4 Time Zones Changing Load• Start of Day• End of Day
Testing Exchange in a Private vSphere Cloud
15 Confidential
05
101520253035404550
CPU Utilization Without DRS
Server1Server2
ESX
Hos
t CPU
Util
izat
ion
(%)
0
10
20
30
40
50
60CPU Utilization With DRS
Server 1Server 2VMotion Events
ESX
Hos
t CPU
Util
izat
ion
(%)
Testing Exchange in a Private vSphere Cloud
16 Confidential
Up to an 18% gain in performance, with an average of 8% Although Exchange is not CPU constrained workload, it still
benefits from load balancing Cost / Benefit algorithm of DRS was correct in moving
Exchange VMs even though CPU was not constrained Not supported for MS Cluster Nodes
Testing Exchange in a Private vSphere Cloud
User Groups 1 2 3 4 5 6 7 8 Avg
No DRS 734 584 844 693 795 974 775 1004 800
DRS 684 554 854 673 704 844 745 854 739
% Advantage for DRS 7% 5% -1% 3% 13% 15% 4% 18% 8%
95th Percentile Sendmail Latencies
17 Confidential
Performance has been validated by VMware and Partners.• Minimal CPU overhead observed on ESX 3.5 (5-10%)• Minimal CPU overhead observed on vSphere (2-7%)• No impact on disk I/O latency • RPC latency comparable• No virtualization performance degradation observed
All three storage protocols performed great – FC was the Best. DRS can increase performance and reduce resource consumption
on stand-alone mailbox servers.
Summarizing Performance
18 Confidential
Agenda Introductions Exchange on vSphere Overview and Updates Exchange on vSphere Performance ESX host Best Practices for Exchange Exchange 2010 Capacity Planning Availability & Recovery Options Customer Success Stories
19 Confidential
Considerations• Unavailable pCPUs can result in VM “ready time.”• Idle vCPUs will compete for system resources.
Best Practices for vCPUs• Only allocate multiple vCPUs to a virtual machine if the
anticipated Exchange workload can truly take advantage of all the vCPUs.
• If the exact workload is not known, size the virtual machine with a smaller number of vCPUs initially and increase the number later if necessary.
• For performance-critical Exchange virtual machines (i.e. production systems), try to ensure the total number of vCPUs assigned to all the virtual machines is equal to or less than the total number of cores on the ESX host machine.
Virtual CPUs
20 Confidential
vSphere Memory Management Concepts• Memory sharing across virtual machines that have similar
data (i.e. same guest operating systems);• Memory over-commitment, which means allocating more
memory to virtual machines than is physically available on the ESX host;
• A memory balloon technique whereby virtual machines that do not need all the memory they have been allocated give memory to virtual machines that require additional allocated memory.
Virtual Memory
21 Confidential
Virtual Machine Memory Concepts• Configured = memory size of VM assigned at creation.• Reservation = guaranteed lower bound of memory that the host
reserves for the VM and cannot be reclaimed for other VMs.• Touched memory = memory actually used by the VM. Guest
memory is only allocated on demand by ESX Server.• Swappable = VM memory that can be reclaimed by the balloon
driver or worst case by ESX Server swapping.
Virtual Memory
22 Confidential
Allocating Memory to Exchange Virtual Machines• Memory required by an ESX host comprises memory required by the Console
Operating System (COS), the vmkernel, and each virtual machine (depending on the size of the VM).
• The VMware vSphere Resource Management Guide provides more detail about memory requirements.
• Allocate virtual machines on a single ESX host based on the following formula:
Memory available for Exchange virtual machines =
[total ESX server physical memory] – [memory required by ESX]
– [user-defined “memory buffer”]
Virtual Memory
23 Confidential
Best Practices• Do not over-commit memory until VC reports that steady state
usage is below the amount of physical memory on the server.• Set the memory reservation to the configured size of the VM,
resulting in a per-VM vmkernel swap file of zero bytes. Setting reservations could limit VMotion.• It is important to “right-size” the configured memory of a VM.
Memory will be wasted if the Exchange VMs are not utilizing the configured memory.• Enable DRS to ensure workloads are balanced in the ESX cluster.
DRS and reservations can guarantee critical workloads have the resources they require to operate optimally. • To minimize guest OS swapping, the configured size of the VM
should be greater than the average memory usage of Exchange running in the guest. Follow Microsoft guidelines for memory and swap/page file configuration of Exchange VMs.
Virtual Memory
24 Confidential
Storage Virtualization Concepts• Storage array – consists of physical disks that are presented as logical
disks (storage array volumes or LUNs) to the ESX Server.
• Storage array LUNs – formatted as VMFS volumes.• Virtual disks –
presented to the guest OS; can be partitioned and used in guest file systems.• Raw Device
Mappings (RDM) – can be presented to either VMs or physical servers.
Storage
25 Confidential
Best Practices• Deploy Exchange VMs on shared storage – allows VMotion, HA,
and DRS. Aligns well with mission-critical Exchange deployments, often installed on shared storage management solutions.
• Ensure heavily-used VMs not accessing same LUN concurrently.• Storage Multipathing – Setup a
minimum of four paths from an ESX Server to a storage array (requires at least two HBA ports).• Create VMFS file systems from
VirtualCenter to get best partition alignment.
Storage
26 Confidential
VMFS• Volume can host many virtual machines
(or can be dedicated to one virtual machine).
• Increases storage utilization, provides better flexibility, easier administration, and management.
• Large third-party ecosystem with V2P products to aid in certain support situations.
• Does not support quorum disks required for third-party clustering software.
• Fully supports VMware Site Recovery Manager.
RDM• Maps a single LUN to one virtual
machine; isolated I/O.
• More LUNs = easier to hit the LUN limit of 256 that can be presented to ESX Server.
• Leverage array level backup and replication tools that integrate with Exchange databases
• RDM volumes can help facilitate swinging Exchange between physical servers and VMs.
• Required for Microsoft Clustering. Clustered databases and logs should be on RDM disks.
• Full support for Site Recovery Manager.
VMFS and RDM Trade-offs
27 Confidential
Best Practices• Allocate separate NICs/networks for vMotion, FT logging traffic, and
ESX console access management; or use VLAN tagging.• Allocate at least 2 NICs for Exchange production traffic to leverage
NIC teaming capabilities. Generally, at least 4 NICs per ESX host.• Use the VMXNET3 - a paravirtualized vNIC installed with VMware
Tools. VMXNET3 is optimized for virtual environments and designed to provide high performance.• To support VLANs in vSphere, the virtual or physical network must tag
the Ethernet frames with 802.1Q tags using virtual switch tagging (VST), virtual machine guest tagging (VGT), or external switch tagging (EST). VST mode is the most common configuration.• Follow the networking design guidelines in VMworld 2009 session
TA2105 - Virtual Networking Concepts and Best Practices – this includes designs to efficiently manage multiple networks and redundancy of network adaptors on ESX hosts.
Networking
28 Confidential
Best Practices• The source and target ESX hosts must be connected to the same gigabit
network and the same shared storage.
• A dedicated gigabit network for VMware VMotion is recommended.
• The destination host must have enough resources.
• The VM must not use physical devices like CD ROM or floppy.
• The source and destination hosts must have compatible CPU models, or migration with VMware VMotion will fail.
• To minimize network traffic it is best to keep VMs that communicate with each other together (e.g. Mailbox and GCs) on the same host machine.
• VMs with smaller memory sizes are better candidates for migration than larger ones.
• NOTE: VMware does not currently support VMware VMotion or VMware DRS for Microsoft Cluster nodes; however, a cold migration is possible once the guest OS is shut down properly.
Resource Management & DRS
29 Confidential
Agenda Introductions Exchange on vSphere Overview and Updates Exchange on vSphere Performance ESX host Best Practices for Exchange Exchange 2010 Capacity Planning Availability & Recovery Options Customer Success Stories
30 Confidential
Use the Microsoft Exchange Server Profile Analyzer to collect information from your current environment.
Example: • 1 physical location• 16,000 users• Mailbox profiles
• 150 messages sent/received per day• Average message size of 50KB• 500MB mailbox quota
Collect Current Messaging Stats
31 Confidential
Passive Database Overheads
32 Confidential
Exchange Server Minimums and Recommended Maximums
Exchange 2010 server role Minimum Recommended Maximum
Edge Transport 1 x processor core 12 x processor cores
Hub Transport 1 x processor core 12 x processor cores
Client Access 2 x processor core 12 x processor cores
Unified Messaging 2 x processor core 12 x processor cores
Mailbox 2 x processor core 12 x processor cores
Client Access/Hub Transport combo-role (Client Access and Hub Transport roles running on the same physical server)
2 x processor core 12 x processor cores
Multi-role (Client Access, Hub Transport and Mailbox server roles running on the same physical server)
2 x processor cores
24 x processor cores
33 Confidential
Megacycle
• A Megacycle is a unit of measurement used to represent processor capacity.• To roughly illustrate, a 1 GHz processor can produce approximately
1,000 megacycles of CPU throughput. • For a larger example, a two-socket, quad-core server (8 cores) with
3.33 GHz CPUs can produce approximately 26,400 megacycles.• Each Exchange user placed on the server will subtract from this
capacity, at varying rates depending on the activity and size of the mailbox.• Don’t forget that we must take into account CPU requirements for both
the active and passive mailboxes that will be hosted on the server .
From Microsoft TechNet (link):Megacycles are estimated based on a measurement of Intel Xeon x5470 3.33 GHz processors (2 x 4 core arrangement). A 3.33-GHz processor core = 3,300 megacycles of performance throughput. Other processor configurations can be estimated by comparing this measured platform to server platforms tested by the Standard Performance Evaluation Corporation (SPEC). For details, see the SPEC CPU2006 results at the Standard Performance Evaluation Corporation Web site.
34 Confidential
Mailbox Server Processor Capacity Planning (TechNet)(http://technet.microsoft.com/en-us/library/ee712771.aspx)
User Profile and Message Activity
Messages sent or received per mailbox per day
Database cache per mailbox in megabytes (MB)
Single database copy (stand-alone) with estimated IOPS per mailbox
Multiple database copies (mailbox resiliency) with estimated IOPS per mailbox
Megacycles for active mailbox or stand-alone mailbox
Megacycles for passive mailbox
50 3 0.06 0.05 1 0.15100 6 0.12 0.1 2 0.3150 9 0.18 0.15 3 0.45200 12 0.24 0.2 4 0.6250 15 0.3 0.25 5 0.75300 18 0.36 0.3 6 0.9350 21 0.42 0.35 7 1.05400 24 0.48 0.4 8 1.2450 27 0.54 0.45 9 1.35500 30 0.6 0.5 10 1.5
35 Confidential
Designing for Peak Utilization
• It is recommended that standalone servers with only the mailbox role be designed to not exceed 70% utilization during peak period. If deploying multiple roles on the server, then the mailbox role should be designed not to exceed 35%.• For solutions leveraging mailbox resiliency, it is recommended that the
configuration not exceed 80% utilization after a single or double member server failure when the server only has the mailbox role installed. If deploying multiple roles on the server, then the mailbox role should be designed not to exceed 40%.• CPU utilization is determined by taking the CPU Megacycle
Requirements and dividing it by the total number of megacycles available on the server (which is based on the CPU and number of cores).
36 Confidential
Determining Database Cache Size
• The first step in planning for Mailbox Server memory is to determine the amount of required database cache by multiplying the mailbox count by the memory requirements based on the user profile. • For example, 4,000 users sending/receiving 150 messages per day will
require 36 GB of database cache. (4000 * 9 MB = 36 GB).
Messages sent or received per mailbox per day
Database cache per mailbox in megabytes (MB)
50 3100 6150 9200 12250 15300 18350 21400 24450 27500 30
http://technet.microsoft.com/en-us/library/ee712771.aspx
37 Confidential
Determining Total Memory• The next step is to determine the amount of required physical memory by
determining which server configuration provides 36 GB of database cache.• For example, a single role Mailbox server with 48 GB of physical RAM
will provide 39.2 GB of database cache; therefore, 48 GB of physical RAM is the ideal memory configuration based on this mailbox count/user profile.
Server physical memory (RAM)
Database cache size: (Mailbox role only)
Database cache size: Multiple-role (for example, Mailbox + Hub Transport)
2GB 512 MB Not supported4GB 1 GB Not supported8GB 3.6 GB 2 GB
16GB 10.4 GB 8 GB24GB 17.6 GB 14 GB32GB 24.4 GB 20 GB48GB 39.2 GB 32 GB64GB 53.6 GB 44 GB96GB 82.4 GB 68 GB
128GB 111.2 GB 92 GB
38 Confidential
• Mailbox Server Storage Design (TechNet)• Exchange 2010 Mailbox Server Role Requirements Calculator
Calculating Storage Requirements
39 Confidential
Sample Storage Configuration (4,000 Users – 150 sent/received)
CPU: 6 vCPUMemory: 48 GB
40 Confidential
Server Role Ratios (Processor Cores)Server role ratio Recommended processor core ratio Mailbox:Hub 7:1 (no antivirus scanning on Hub)
5:1 (with antivirus scanning on Hub)Mailbox:Client Access 4:3Mailbox: Combined Hub/CAS 1:1
Memory Requirements
Hub Transport and Client Access Server Planning
Exchange 2010 server role Minimum supported
Recommended
Hub Transport 4 GB 1 GB per core (4 GB minimum)
Client Access 4 GB 2 GB per core (8 GB minimum)
Client Access/Hub Transport combined role
4 GB 2 GB per core (8 GB minimum)
When doing processor core ratios, remember to factor in the expected peak utilization of your mailbox servers.
41 Confidential
Building block CPU and RAM sizing for 150 sent/receivedhttp://technet.microsoft.com/en-us/library/ee712771.aspx
The Building Block Approach (Standalone Mailbox Servers)• Best Practice for Standalone Mailbox Servers• Pre-sized VMs with predictable performance patterns• Improved performance when scaling up (memory page sharing)• Simplified deployment
Scaling Exchange for the Enterprise
Building Block 500 1000 2000 4000Profile 150
sent/received150
sent/received150
sent/received150
sent/received
Megacycle Requirement 1,500 3,000 6,000 12,000vCPU (based on 3.33-GHz processor-based server)
2 (Minimum)(.6 Actual)
2 (Minimum)(1.3 Actual)
4(2.6 Actual)
6(5.1 Actual)
Cache Requirement 4.5 GB 9 GB 18 GB 36 GBTotal Memory Size 16 GB 16 GB 24 GB 48 GB
42 Confidential
• The new DAG feature in Exchange 2010 necessitates a different approach to sizing the Mailbox Server role, forcing the administrator to account for both active and passive mailboxes.• Mailbox Servers that are
members of a DAG can host one or more passive databases in addition to any active databases for which they may be responsible.• The amount of passive mail
hosted changes as you add/delete DAG nodes.
Scaling Exchange for the Enterprise
The DAG Approach (Clustered Mailbox Servers)
43 Confidential
• vSphere Virtual machines are limited to 8 vCPU and 255 GB of RAM.• Each ESX host can only accommodate up to 255 LUNs.• Each vSphere LUN is limited to 2 TB (without SAN extents).
Be sure to take vSphere configuration maximum into account, especially when configuring storage.
For example, when sizing a DAG, limiting database sizes to 1 TB will ensure that we don’t come too close to our 2 TB LUN limit.
vSphere Configuration Maximums
http://www.vmware.com/pdf/vsphere4/r40/vsp_40_config_max.pdf
44 Confidential
Resource Requirements by Server Role
Exchange Role Physical Resources (per server)Mailbox Server (4 servers) CPU: 6 cores (60% max utilization)
Memory: 48 GB OS and Application File Storage:64 GB (OS & Application files)DB Storage:110 x 300 GB 10K RPM FC/SCSI/SAS 3.5"(RAID 1/0)Log Storage:6 x 300 GB 10K RPM FC/SCSI/SAS 3.5"(RAID 1/0)Restore LUN:12 x 300 GB 10K RPM FC/SCSI/SAS 3.5"(RAID 5)Network: 1 Gbps
Client Access Server (3 servers) CPU: 4 coresMemory: 8 GB Storage:24 GB (OS & application files)Network: 1 Gbps
Hub Transport Server (2 servers) CPU: 2 coresMemory: 4 GBStorage:20 GB (OS, application, & log files)32 GB (DB, protocol/tracking logs, & temp files)Network: 1 Gbps
Sample Exchange 2010 Resource Requirements
45 Confidential
Sample Hardware Layout
46 Confidential
http://www.vmware.com/support/pubs/vs_pubs.html.
• vSphere Administration• Advanced vSphere Features
(VMotion, HA, DRS, etc.)• ESX host Installation and
Configuration• Virtual Networking• Storage
Preparing vSphere for Exchange
47 Confidential
Subsystem esxtop Counters VirtualCenter CounterCPU %RDY
%USEDReadyUsage
Memory %ACTVSWW/sSWR/s
ActiveSwapinSwapout
Storage ACTVDAVG/cmdKAVG/cmd
CommandsdeviceWriteLatency & deviceReadLatencykernelWriteLatency & kernelReadLatency
Network MbRX/sMbTX/s
packetsRxpacketsTx
ESXTop counters for Exchange.
vSphere offers integrated support for PerfMon!
Performance Monitoring
48 Confidential
• Follow Microsoft guidelines for processor, memory, and storage of the mailbox server role• Be sure to take into account passive databases if you are using
DAGs• Design for peak utilization – 70% for standalone and 80% for
clustered mailbox servers• Understand and adjust for vSphere Configuration Maximums (256
LUNs, 2 TB LUN size limit, etc.)• Use the building block approach with standalone mailbox servers;
use the DAG method and the storage calculator for clustered mailbox servers• Follow Microsoft guidelines for Hub Transport and Client Access
Server ratios; remember the CAS is much heavier in 2010
Capacity Planning Summary
49 Confidential
Agenda Introductions Exchange on vSphere Overview and Updates Exchange on vSphere Performance ESX host Best Practices for Exchange Exchange 2010 Capacity Planning Availability & Recovery Options Customer Success Stories
50 Confidential
Business-level Approach
• What are you trying to protect?
• What are your RTO/RPO requirements?
• What is your Service Level Agreement (SLA)?
• How will you test/verify your solution?
51 Confidential
Local Site Options
52 Confidential
• Can use Standard Windows and Exchange editions
• Does not require Microsoft clustering
• Simple to configure and easy to manage
• Quickly restore service during host failure
• Combine with application-aware availability solution
• VMotion, DRS, and HA are fully supported!
• Protects from hardware failure only
• Does not provide application protection
Simple Standalone Server with VMware HA
53 Confidential
What is a DAG?
• DAG stands for Database Availability Group and consists of 2 or more mailbox servers that are grouped together for mutual protection.• Unlike a traditional active/passive server configuration, failover
occurs by database rather than by server.• DAGs utilize the Microsoft Clustering Service although there is
no requirement for shared quorum disks.
54 Confidential
How is DAG different from CCR?
X
X
Exchange 2007 CCR• Failover of entire server• 2x storage req.• No shared storage• IP replication
Exchange 2010 DAG• Failover of DBs• No passive servers• 2x or more storage req.• No shared storage• IP replication
55 Confidential
VMware HA + DAGs (no MS support)
• Protects from hardware and application failure
• Immediate failover (~ 3 to 5 secs)
• No passive servers!
• HA decreases the time the database is in an ‘unprotected state’
• Windows Enterprise, Exchange Standard or Enterprise editions
• Complex configuration and capacity planning
• 2x or more storage req.
• Not officially supported by Microsoft
56 Confidential
• Clustering is not supported by VMware on iSCSI or NFS disks• Mixed environments not supported
using Qlogic and Emulex HBAs on the same host using ESX Server 3.x and ESX Server 4.x across ESX hosts
• DRS, and HA must be disabled in the virtual machine properties of Microsoft Clustered VMs• Microsoft does not support migration of running virtual machines
(VMotion) that run cluster software, however internal and customer PoC testing has shown VMotion to have no affect on the operation of a CCR or DAG member.
Caveats & Restrictions
57 Confidential
Remote Site Options
58 Confidential
VMware SRM + DAGs (no MS support)
• DAG provides local site protection
• Storage replication keeps DR facility in sync
• During a site failure, the admin has full control of recovery
• Once workflow is initiated, SRM automates the recovery process
• The entire process can be tested without actually failing over services!
59 Confidential
Stand-Alone Mailbox Server SRM Workflow
Storage replication during normal operations
Primary site failureAdministrator initiates SRM workflow
ESX host(s) is rescanned and relevant datastores/RDMs made writable
Recovery VM Powered on
WAN
Storage ReplicationSAN SAN
Databases mounted and soft-recovery initiates based on checkpoint file
60 Confidential
DAG + Delayed Copy Replay
• DAG provides local site protection
• Log replication keeps DR facility in sync
• Requires manual database activation
• Administrator can remove logs to adjust recovery point
• No redundancy until new passive databases are established
61 Confidential
Backup and Recovery
62 Confidential
Agent-based Backup
• Standard method for physical or virtual• Agent runs in the VM guest and handles database quiescing• Data is sent over the IP network• Can affects CPU utilization in the Guest OS
63 Confidential
Array-based Backup
• Backup vendor software coordinates with VSS to create a supported backup image of the Exchange databases• Snap-shotted databases can later be streamed to tape as flat files with
no IO impact to the production Exchange Server.
64 Confidential
• Understand what the business expects for availability and recovery• For hardware failure protection, VMware HA offers a low cost, much
simpler alternative to Microsoft Clustering• Database Availability Groups can be combined with HA for faster
recovery of mailbox servers (not MS-supported)• Site Recovery Manager allows for the failover of entire datacenters!• Microsoft Clustering IS supported on VMware virtual machines if HA
and DRS are disabled in the VM properties• Either agent-based or array-based backups can be used to protect
virtual Exchange servers
Summary
65 Confidential
Agenda Introductions Exchange on vSphere Overview and Updates Exchange on vSphere Performance ESX host Best Practices for Exchange Exchange 2010 Capacity Planning Availability & Recovery Options Customer Success Stories
66 Confidential
•United States Navy/Marine Corps – 750,000 mailboxes•University of Plymouth – 40,000 mailboxes, replaced MSCS•VMware IT – 9,000 very heavy mailboxes•University of Texas at Brownsville – 25,000 mailboxes,
using vSphere for site resiliency•Undisclosed customer – 20,000+ mailboxes, Exchange
2010 early adopter
Notable Customers