Microsoft Exchange Best Practices and Design Guidelines on EMC Storage

1. Microsoft ExchangeBest Practices and Design Guidelines on EMC Storage Exchange 2010 and Exchange 2013 VNX and VMAX Storage Systems EMC Global Solutions | Global Solutions Engineering September 2014 Update

2. Topics Exchange – What has changed Exchange Virtualization Exchange Storage Design and Best Practices Exchange DR options Exchange Validated Solutions VNX Pool Optimization Tool (aka SOAP) Building Block Design Example

3. Exchange – What has changed Exchange Virtualization Exchange Storage Design and Best Practices Exchange DR options Exchange Validated Solutions VNX Pool Optimization Tool (aka SOAP) Building Block Design Example

4. Exchange…What has changed

5. Exchange User Profile Changes

6. Exchange Processor Requirements Changes

7. Exchange I/O Characteristics

8. Exchange 2010/2013 mailbox database I/O read/write ratios

9. Understanding Exchange I/O • Exchange 2010/2013 I/O’s to the database (.edb) are divided into two types: • Transactional I/O (aka user I/O) • Database volume I/O (database reads and writes) • Log volume I/O (logs reads and writes) • Non Transactional I/O • Background Database Maintenance (Checksum) (BDM) NOTE: Only database I/O’s are measured when sizing storage and during Jetstress validation For more details see “Understanding Database and Log Performance Factors” at http://technet.microsoft.com/en-us/library/ee832791(v=exchg.141).aspx

10. Background Database Maintenance (BDM) • BDM is the process of Exchange Server 2010/2013 database maintenance that includes online defragmentation and online database scanning • Both active and passive database copies are scanned • On active copy can be scheduled to run during the online maintenance window (default is 24 x 7) • Passive copy is ”hardcoded” to 24 x 7 scan • Jetstress has no concept of passive copy, all are active • Possible BDM related issues (mostly for Exchange 2010): • Bandwidth/throughput required for BDM and BDM IOPS • Not enough FE ports, not enough BE ports, non-optimal RAID configuration

11. Exchange Content Index Considerations • Content Indexing space considerations: • In Exchange 2010 content index space is estimated at about 10% of the database size. • In Exchange 2013 content index space is estimated at about 20% of the database size. • An additional 20% must be added for content indexing maintenance tasks (such as the master merge process) to complete. • Calculations References http://blogs.technet.com/b/exchange/archive/2013/05/06/ask-the-perf-guy-sizing-exchange-2013-deployments.aspx

12. Exchange High Availability Key Terminology

13. Exchange High Availability Key Terminology

14. Exchange High Availability Key Terminology

15. Exchange High Availability Database Availability Group (DAG) • Base component of the high availability and site resilience framework built into Exchange 2010/2013 • A group of servers participating within a Windows failover cluster with a limit of 16 servers and 100 databases.  • All servers participating within a DAG can have a copy of any database within the DAG • Each DAG member server can house one copy of each database, up to 16 copies, with only one being active, passive, or lagged • No configuration of cluster services are required • Exchange 2010/2013 handles the entire installation • During site DR - manual work, scripts must be run • A DAG does not provide recovery for logical database corruption Database Availability Group MBX2 MBX1 MBX3 A P P DB1 Copy Copy P A P Copy Copy DB2 P P A Copy Copy DB3 A = Active P = Passive

16. Exchange High Availability Guidance for deploying DAGs • Ensure all elements of the design have resilient components • Storage processors • Connectivity to the servers • Storage spindles • Multiple arrays in DR scenarios • DAG copies should be stored on separate physical spindles • Provided all resiliency is reached at the source site • On SANs, consider performance of the passive and active copies within one array

17. Exchange – What has changed Exchange Virtualization Exchange Storage Design and Best Practices Exchange Validated Solutions VNX Pool Optimization Tool (aka SOAP) Building Block Design Example References

18. Exchange 2010/2013 virtualization • Virtualizing Exchange is supported on Hyper-V, VMware, and other hypervisors • Hypervisor vendors must participate in the Windows Server Virtualization Validation Program (SVVP) • EMC recommends virtualizing Exchange for most deployments based on customer requirements

19. Exchange virtualization VM placement considerations • Do not deploy VMs from the same DAG on the same host • Deploy VMs with the same role across multiple hosts DAG2 DAG1 DAG1 DAG2

20. Exchange virtualization Configuration best practices • Physical sizing still applies • Hypervisor server must accommodate the guests they will support • DAG copies must be spread out across physical hosts to minimize outage in case of physical server issues • Know your hypervisors limits • 256 SCSI disks per host (or cluster) • Processor limits (vCPUs per virtual machine) and Memory limits • Be aware of the hypervisor CPU overhead • Microsoft Hyper-V: ~10-12% • VMware vSphere: ~5-7% • Core Exchange design principles still apply • Design for performance and high availability • Design for user workloads

21. Exchange virtualization Configuration best practices – Hypervisor and VMs • Hypervisor server • Have at least 4 paths (HBA/CNA/iSCSI) to the storage • Install EMC PowerPath for maximum throughput, load balancing, path management, and I/O path failure detection • Multiple NICs - Segregate management and clients traffic from Exchange replication traffic • Disable hypervisor-based auto tuning features - No dynamic memory • CPU & Memory • Dedicate/reserve CPU and memory to the Mailbox virtual machines and do not over commit • pCPU to vCPU ratios: 2:1 is OK, 1:1 is a best practice • VM migrations • Always migrate live or completely shut down virtual machines

22. Exchange virtualization Configuration best practices - Storage • Exchange storage should be on spindles separate from guest OS physical storage • Exchange storage must be block-level • Network attached storage (NAS) volumes are not supported • No NFS, SMB (other than SMB 3.0), or any other NAS technology • Storage must be fixed VHD/VHDX/VMDK, SCSI pass-through/RDM or iSCSI

23. Exchange virtualization Configuration best practices - SMB 3.0 Support • Only in virtualized configurations • VHDs can reside on SMB 3.0 shares presented to Hyper-V host • No support for UNC path for Exchange db and log volumes (\\server\share\db1\db1.edb)

24. Exchange virtualization Supported SMB 3.0 Configuration Example

25. Exchange virtualization Configuration best practices – Hyper-V Storage • Virtual SCSI (pass-through or fixed disk) • VHD on host – recommended for OS, program files • Pass-through disk on host - recommended for Exchange database and log volumes • iSCSI • iSCSI direct from a guest virtual machine • iSCSI initiator on host and disk presented to guest as pass-through • ISCSI initiator from guest performs well and is easier to configure • MPIO or EMC PowerPath – PowerPath recommended

26. Exchange virtualization Configuration best practices – VMware VMFS or RDM Trade-offs

27. Exchange virtualization References • For Hyper-V: • Best Practices for Virtualizing Exchange Server 2010 with Windows Server 2008 R2 Hyper-V • Best Practices for Virtualizing and Managing Exchange 2013 • For VMware: • Microsoft Exchange 2010 on VMware Best Practices Guide • Microsoft Exchange 2010 on VMware Design and Sizing Examples • Microsoft Exchange 2013 on VMware Best Practices Guide • Microsoft Exchange 2013 on VMware Availability and Recovery Options • Microsoft Exchange 2013 on VMware Design and Sizing Guide

28. Exchange – What has changed Exchange Virtualization Exchange Storage Design and Best Practices Exchange DR options Exchange Validated Solutions VNX Pool Optimization Tool (aka SOAP) Building Block Design Example

29. Exchange Storage Options DAS or SAN? EMC offers both options • For small, low-cost = DAS • For large-scale efficiency = SAN • Best long-termTCO = SAN • Virtualization ready = SAN XtremIO VMAX VNXe VNX • Understand which storage type best meets design requirements • Physical or virtual? • Dedicated for Exchange or shared with other applications? • Follow EMC proven guidance for each platform

30. Exchange Server IOPS Per Disks • Use the following table for IOPS per drive values when calculating disk requirements for Exchange 2010/2013* • *Recommendations may change based on future test results

31. I/O Characteristics for Various RAID Types 1 Depends on the size of RAID group 2Depends on the array

32. Exchange Server Design Methodology

33. Exchange Storage Design Exchange building-block design methodology • What is a building-block? • A building-block represents the required amount of resources needed to support a specific number of Exchange users on a single server or VM • Building blocks are based on requirements and include: • Compute requirements (CPU, memory, and network) • Disk requirements (database, log, and OS) • Why use the building-block approach? • Can be easily reproduced to support all users with similar user profile characteristics • Makes Exchange environment additions much easier and straightforward, helpful for future environment growth • Has been very successful for many real-world customer implementations See Appendix for building-block design process

34. Exchange Storage Design Exchange Sizing Tools options • Microsoft Exchange Server Role Requirements Calculator • Exchange 2010: http://gallery.technet.microsoft.com/Exchange-2010-Mailbox-Server-Role-/ • Exchange 2013: http://gallery.technet.microsoft.com/Exchange-2013-Server-Role-f8a61780 • EMC Exchange 2010-2013 Designer:https://community.emc.com/docs/DOC-13037?et=watches.email.document • VSPEX Sizing Tool: http://express.salire.com/go/emc • Specific array sizing tools, i.e. VNX Disksizer • Perform manual calculations (for advanced administrators)

35. Exchange Storage Design Tools for Performance and Scalability Evaluation • Exchange JetStress for Storage Validation • Exchange 2010 - http://www.microsoft.com/en-us/download/details.aspx?id=4167 • Exchange 2013 - http://www.microsoft.com/en-us/download/details.aspx?id=36849 • Exchange Load Generator (Loadgen) for end-to-end environment validation (must be used in isolated lab only) • Exchange 2010 - http://www.microsoft.com/en-us/download/details.aspx?id=20322 • Exchange 2013 - http://www.microsoft.com/en-us/download/details.aspx?id=40726

36. Storage Design validation • Exchange Solution Reviewed Program (ESRP) Results • Microsoft program for validation of Storage vendor designs with Exchange • Vendor runs multiple JetStress tests based on requirements for performance, stress, backup to disk, and log file replay • Reviewed and approved by Microsoft http://technet.microsoft.com/en-us/exchange/ff182054.aspx

37. Exchange Storage Design Tools for Performance and Scalability Evaluation • Exchange Jetstress • Uses Exchange executables to simulate I/O load (use same version) • Initialized and executed during pre-production before Exchange Server is installed • Throughput and mailbox profile tests – Pass gives confidence that storage design will perform as designed • Exchange Load Generator (Loadgen) (optional) • Validation must be performed in isolated lab • Produces a simulated client workload against a test Exchange deployment • Estimate number of users per server and validate Exchange deployment • LoadGen testing can take many weeks to configure and populate DBs

38. Exchange Storage Design Storage sizing guidance • Do not solely rely on automated tools when sizing your Exchange environment • Place time and effort into your calculations, and provide supporting factual evidence on your designs rather than providing fictional calculations • Size Exchange based on I/O, mailbox capacity and bandwidth requirements • Factor in other overhead variables such as archiving, snapshots protection, virus protection, mobile devices, and risk factor • Confirm Exchange storage requirements with specific array sizing tools

39. Storage Design Guidance Best Practices • Isolate the Exchange server workload to its own set of spindles from other workloads to guarantee performance • When sizing, always calculate I/O requirements and capacity requirements • Separate the database and logs onto different volumes • Deploy DAG copies on separate physical spindles • Databases up to 2 TB in size are acceptable when DAG is being used: • The exact size should be based or customer requirements • Ensure that your solution can support LUNs larger than 2 TB

40. Storage Design Guidance Best Practices - continued • Consider backup and restore times when calculating the database size • Spread the load as evenly as possible across array resources, V-Max Engines, VNX SPs, back-end buses, etc. • Always format Windows NTFS volumes for databases and logs with an allocation unit size of 64K • Use an Exchange building block design approach whenever possible

41. Storage Design Guidance - VNX Pools and RAID Groups • Either method works well and provides the same performance (thick pools versus RGs) • RAID groups are limited to 16 disks per RG, pools can support many more disks • Pools are more efficient and easier to manage • Use pools if planning to use advanced features such as: • FAST VP, VNX Snapshots • Storage pools can support a single building block or multiple building blocks based on customer requirements • Design and expand pools using the correct multiplier for best performance (R1/0 4+4, R5 4+1, R6 6+2)

42. Storage Design Guidance - VNX Thick or Thin LUNs? • Both Thick and Thin LUNs can be used for Exchange storage (database and logs) • Thick LUNs are recommended for heavy workloads with high IOPS user profiles • Thin LUNs are recommended for light to medium workloads with low IOPS user profiles • Benefits: significantly reduces initial storage requirements • Use VNX Pool Optimizer before formatting volumes • Can enable FAST Cache or FAST VP for fast metadata promotions

43. Virtual Server Virtual Server Virtual Server Virtual Server Virtual Server Virtual Server FAST VP and FAST Cache Exchange SharePoint SQL Server Exchange SharePoint SQL Server FAST VP FAST Cache FC SAS Flash NL SAS

44. FAST VP vs. FAST Cache on VNX Storage

45. VNX Considerations for FAST VP and FAST Cache • When the number of flash drives is limited, use flash drives to create FAST Cache first • FAST Cache can benefit multiple pools in the storage system. • FAST Cache uses 64 KB chunks, smaller than 1 GB or 256 MB chunks in FAST VP, which results in higher performance benefits and faster reaction time for changing usage patterns. • Use flash drives to create the FAST VP performance tier for a specific pool • This ensures the performance of certain mission-critical data • The FAST VP tier is dedicated to a storage pool and cannot be shared with other storage pools in the same storage array.

46. Exchange Design with FAST VP Configuration recommendations (VNX and VMAX) • Separate databases from logs, due to different workloads • Data – random workload with skew; high FAST VP benefit • Logs – sequential data without skew; no FAST VP benefit • Use dedicated pools • Provides a better SLA guarantee • Provides fault domains • Recommended for most deterministic behavior • Use Thick Pool LUNs for highest performance (on VNX) • Thin Pool LUNs are acceptable with optimization • Use Thin LUNs on VMAX

47. Tools for FAST VP • Tier Advisor for sizing • Historical performance data is needed from storage arrays. • Workload Performance Assessment Tool • It shows FAST VP heat map. For more information, refer to https://emc.mitrend.com. • VSPEX Sizing Tool (for VNX) • For more information, refer to http://www.emc.com/microsites/vspex-ebook/vspex-solutions.htm. • EMC Professional Services and qualified partners can assist in properly sizing tiers and pools to maximize investment.

48. Exchange Design with FAST Cache VNX only • FAST Cache usage • Pools with Thin LUNs for metadata tracking • Pools with Thin and Thick LUNs when VNX Snapshots are used • Pools with Thick LUNs • Not required but not restricted either • Required with VNX Snapshots •  FAST Cache Sizing guidance • Rule of thumb: for every 1 TB of Exchange dataset, provision 1 GB of FAST Cache • Monitor and adjust the FAST Cache size, your mileage may vary • Enable FAST Cache on pools with database LUNs only

49. Exchange Storage design - VMAX Design Best Practices • Ensure that the initial disk configurations can support the I/O requirements • Can configure a thin pool to support a single Exchange building block or multiple building blocks, depending on customer requirements • Use Unisphere for VMAX to monitor the thin pool utilization and prevent the thin pools from running out of space • Install the Microsoft hotfix KB2870270 on the Windows Server 2012 hosts in your environment.

50. Exchange Storage design - VMAX Design Best Practices • Use Symmetrix Virtual Provisioning • Can share database and log volumes across the same disks, but separate them into different LUNs on the same hosts • For optimal Exchange performance, use striped meta volumes