Microsoft Exchange 针对 EMC 存储的最佳做法和设计指导方针

Presentation on theme: "Microsoft Exchange 针对 EMC 存储的最佳做法和设计指导方针"— Presentation transcript:

1 Microsoft Exchange 针对 EMC 存储的最佳做法和设计指导方针
Exchange 2010 和 Exchange 2013 VNX 和 VMAX 存储系统 战略解决方案工程部门 更新时间 — 2013 年 10 月

2 主题 Exchange — 发生的变化 Exchange 虚拟化 Exchange 存储设计和最佳做法 Exchange 备份最佳做法
其他参考资料

3 Exchange 用户配置文件变化 Exchange I/O 特征 后台数据库维护 数据库可用性组 (DAG) 存储选择

4 Exchange...发生的变化 Exchange 2007 Exchange 2010 Exchange 2013
◊ 64 位 Windows ◊ 32+ GB 数据库缓存 ◊ 8 Kb 数据块大小 ◊ 1:1 DB 读/写比率 ◊ IOPS 比 Exchange 2003 减少 70% Exchange 2010 ◊ 100 GB 数据库缓存 (DAG) ◊ 32 Kb 数据块大小 ◊ 3:2 DB 读/写比率 ◊ IOPS 比 Exchange 2007 减少 70% Exchange 2013 ◊ IOPS 比 Exchange 2010 减少 33%

5 Exchange 2010 每个邮箱估计的 IOPS （活动或非活动）
每天每个邮箱发送/ 接收的邮件数 Exchange 2010 每个邮箱估计的 IOPS （活动或非活动） Exchange 2013 每个邮箱 估计的 IOPS （活动或非活动） 邮箱恢复能力 独立 50 0.05 0.06 0.034 100 0.100 0.120 0.067 150 0.150 0.180 0.101 200 0.200 0.240 0.134 250 0.250 0.300 0.168 300 0.360 0.201 350 0.350 0.420 0.235 400 0.400 0.480 0.268 450 0.450 0.540 0.302 500 0.500 0.600 0.335

6 Exchange 处理器要求变化 每天每个邮箱发送或接收的邮件数 每个用户的兆周数 活动 DB 拷贝或独立 （仅限 MBX）
50 1 2.13 N/A 2.66 0.15 0.69 100 2 4.25 5.31 0.3 1.37 150 3 6.38 7.97 0.45 2.06 200 4 8.50 10.63 0.6 2.74 250 5 13.28 0.75 3.43 300 6 12.75 15.94 0.9 4.11 350 7 14.88 18.59 1.05 4.80 400 8 17.00 21.25 1.2 5.48 450 9 19.13 23.91 1.35 6.17 500 10 26.56 1.5 6.85

7 Exchange I/O 特征 Exchange Server 2010/2013 的用户 IOPS 下降，但 I/O 的大小显著增加
8 KB 随机写入 I/O 32 KB 随机 I/O 后台数据库维护 (BDM) I/O N/A 256 KB 顺序读取 I/O 日志 I/O 大小从 512 字节到日志 缓冲区大小 (1 MB) 不等 大小从 4 KB 到日志缓冲区 大小 (1 MB) 不等

8 Exchange 2010/2013 邮箱数据库 I/O 读/写比率
每天每个邮箱发送/接收的邮件数 独立数据库 参与邮箱恢复的数据库 50 1:1 3:2 100 150 200 250 300 2:3 350 400 450 500

9 了解 Exchange I/O Exchange 2010/2013 的数据库 (.edb) I/O 分为两种类型：
事务性 I/O（又称用户 I/O） 数据库卷 I/O（数据库读取和写入） 日志卷 I/O（日志读取和写入） 在调整存储时以及在 Jetstress 验证过程中，仅测量数据库 I/O 非事务性 I/O 后台数据库维护（校验和）(BDM) 有关更多详细信息，请参阅文档“了解数据库和日志性能因素”：

10 后台数据库维护 (BDM) BDM 的定义及其作用
它是 Exchange Server 2010/2013 数据库维护的过程，其中包括在线碎片整理和在线数据库扫描 将同时扫描活动和非活动的数据库拷贝 Exchange 2010 Exchange 2013 读取 I/O 大小 256 KB 数据库扫描完成 1 周 每 4 周 每个数据库的 IOPS 30 9 带宽 7.5 MB/s* 2.25 MB/s* * 基于 EMC 的 JetStress 2010/2013 测试

11 后台数据库维护 (BDM) 将同时扫描活动和非活动的数据库拷贝 可能的 BDM 相关问题（大多数针对 Exchange 2010）：
Jetstress 没有非活动拷贝概念，全部都是活动拷贝 可能的 BDM 相关问题（大多数针对 Exchange 2010）： BDM 和 BDM IOPS 所需的带宽/吞吐量 FE 端口不够、BE 端口不够、RAID 配置不当

12 Exchange 内容索引注意事项 内容索引空间注意事项： 在 Exchange 2010 中，内容索引空间估计约占数据库大小的 10%。
必须额外增加 20%，以确保内容索引维护任务（如主合并过程）正常完成。

13 Exchange 高可用性 数据库可用性组 (DAG)
Microsoft Exchange Server 2010/2013 中内置的高可用性 和站点恢复能力框架的基本组件 一个 DAG 就是参与 Windows 故障切换群集的一组服务器， 有 16 台服务器和 100 个数据库的数量限制。 参与某个 DGA 的所有服务器都可以有该 DAG 中的任何数据库 的一个拷贝 每个 DAG 成员服务器都可以承载每个数据库的一个拷贝，最多可以有 16 个拷贝，但只有一个活动、非活动或滞后拷贝 不需要配置任何群集服务，Exchange 2010/2013 会处理整个安装 在站点灾难恢复手动工作中，必须运行脚本 DAG 不提供逻辑数据库损坏恢复 数据库可用性组 MBX1 MBX2 MBX3 A P P DB1 拷贝 拷贝 P A P 拷贝 DB2 拷贝 P P A 拷贝 拷贝 DB3 A = 活动 P = 非活动

14 Exchange 高可用性 确保所有设计元素都有可恢复组件 DAG 拷贝应存储在单独的物理磁盘轴上
存储处理器 服务器连接 存储磁盘轴 灾难恢复方案中的多个阵列 DAG 拷贝应存储在单独的物理磁盘轴上 前提是源站点实现所有恢复能力 在 SAN 上，考虑一个阵列中的非活动和活动拷贝的性能

15 Exchange 存储选项 DAS 还是 SAN？ EMC 同时提供这两个选项 了解哪种存储类型最能满足设计要求
最佳长期 TCO = SAN 虚拟化就绪 = SAN Iomega VNXe VNX VMAX 了解哪种存储类型最能满足设计要求 物理还是虚拟？ 专用于 Exchange 还是与其他应用程序共享？ 遵循每个平台经 EMC 验证的指导 经验证的解决方案白皮书 EMC 存储解决方案提交到 Microsoft ESRP 计划

16 Exchange Server 的每磁盘 IOPS
在计算 Exchange 2010/2013 的磁盘要求时，使用下表中每个驱动器的 IOPS 值 根据将来的测试结果，推荐内容可能会变化 磁盘类型 每个磁盘的 Exchange /2013 数据库 IOPS （随机工作负载） 每个磁盘的 Exchange /2013 数据库 日志 IOPS （顺序工作负载） VNX/VMAX VNX VMAX VNX 和 VMAX 7.2K rpm NL-SAS/SATA 65 60 180 10K rpm SAS/FC 135 130 270 15K rpm SAS/FC 450 闪存 1250 2000

17 建议和支持能力 设计最佳做法参考 支持的部署配置 配置最佳做法
Exchange 虚拟化 建议和支持能力 设计最佳做法参考 支持的部署配置 配置最佳做法

18 Exchange 2010/2013 虚拟化 虚拟机管理程序供应商必须参加 Windows Server 虚拟化验证计划 (SVVP)
建议和支持能力 虚拟化是一种经验证且云就绪的技术 Exchange 不识别虚拟化，但适合虚拟化 对于大多数部署，EMC 都建议根据用户要求进行 Exchange 虚拟化 在 Hyper-V 和 VMware 以及其他虚拟机管理程序上受支持 虚拟机管理程序供应商必须参加 Windows Server 虚拟化验证计划 (SVVP)

19 Exchange 虚拟化 Exchange 2010/2013 支持的部署配置（示例） 独立虚拟机管理程序上的 Exchange DAG
VMware DRS/HA 或 Windows 群集 VMware DRS/HA 或 Windows 群集

20 Exchange 虚拟化 了解您的虚拟机管理程序限制： 注意虚拟机管理程序 CPU 开销： 配置最佳做法 — 常规
每个主机（或群集）256 个 SCSI 磁盘 处理器限制（每个虚拟机的 vCPU 数） 内存限制 注意虚拟机管理程序 CPU 开销： Microsoft Hyper-V：~10-12% VMware vSphere：~5-7%

21 Exchange 虚拟化 核心 Exchange 设计原则仍然适用 调整特定于 Exchange 角色的虚拟机 物理调整仍适用 配置最佳做法
性能和高可用性设计 用户工作负载设计 调整特定于 Exchange 角色的虚拟机 物理调整仍适用 物理虚拟机管理程序服务器必须适应将支持的来宾系统 DAG 拷贝必须分布在物理主机间，以最大程度地减少发生物理服务器问题时的宕机

22 Exchange 虚拟化 在放置虚拟机时考虑常识 配置最佳做法 — 虚拟机放置建议 用同一个角色在多个主机中部署虚拟机
不在同一个主机服务器上部署来自同一个 DAG 的 MBX 虚拟机

23 Exchange 虚拟化 配置最佳做法 禁用保存状态和迁移的迁移技术 为邮箱虚拟机配置/保留专用 CPU 和内存，并且不过量使用
始终实时迁移或完全关闭虚拟机 为邮箱虚拟机配置/保留专用 CPU 和内存，并且不过量使用 pCPU 与 vCPU 的比率：2:1 可行，1:1 是最佳做法 禁用基于虚拟机管理程序的自动调整功能 无动态内存 虚拟机管理程序服务器应至少有 4 个存储路径 (HBA/CNA/iSCSI) — 共 4 个端口 在虚拟机管理程序服务器上安装 EMC PowerPath，以实现最大吞吐量、负载平衡、 路径管理和 I/O 路径故障检测

24 Exchange 虚拟化 Exchange 存储应位于独立于来宾操作系统物理存储的磁盘 轴上 Exchange 存储必须是数据块级
配置最佳做法 — 存储 Exchange 存储应位于独立于来宾操作系统物理存储的磁盘 轴上 Exchange 存储必须是数据块级 不支持网络连接存储 (NAS) 卷 没有 NFS、SMB（SMB 3.0 除外）或其他任何 NAS 技术 存储必须是固定的 VHD/VHDX/VMDK、SCSI 直通设备/RDM 或 iSCSI Hyper-V Live Migration 建议采用具有固定 VHD 的群集共享卷（更短的“中断”期间）

25 SMB 3.0 支持 仅在虚拟化配置中 VHD 可以驻留在提供给 Hyper-V 主机的 SMB 3.0 共享上
不支持 Exchange 数据库和日志卷的 UNC 路径 (\\server\share\db1\db1.edb)

26 支持的 SMB 3.0 配置示例

27 Exchange 虚拟化 虚拟 SCSI（直通或固定磁盘） iSCSI 配置最佳做法 — Hyper-V 存储
主机上的 VHD — 建议用于操作系统和程序文件 主机上的直通磁盘 — 建议用于 Exchange 数据库和日志卷 iSCSI 直接来自来宾虚拟机的 iSCSI 主机上的 iSCSI 启动器以及作为直通设备提供给来宾系统的磁盘 来自来宾系统的 iSCSI 启动器性能良好，并且配置更方便 MPIO 或 EMC PowerPath — 推荐 PowerPath

28 Exchange 虚拟化 配置最佳做法 — VMware VMFS 和 RDM 权衡 VMFS RDM
卷可以承载许多虚拟机（也可以专用于一个虚拟机） 将单个 LUN 映射到一个虚拟机，隔离 I/O 提高存储利用率，提高灵活性，简化管理 更多 LUN = 更易达到 LUN 限制（可向 ESX Server 提供 256 个 LUN） 不能有硬件支持的 VSS 备份 与 Exchange 数据库集成的硬件 VSS 和复制工具所必需 大规模第三方生态系统，利用 V2P 产品在特定的支持情形下提供帮助 可以帮助减少物理到虚拟迁移的时间 共享磁盘群集不支持 共享磁盘群集所必需 完全支持 VMware Site Recovery Manager

29 虚拟化 Exchange 最佳做法 对于 Hyper-V： 对于 VMware： 参考资料
使用 Windows Server 2008 R2 Hyper-V 虚拟化 Exchange Server 2010 最佳做法 虚拟化和管理 Exchange 2013 的最佳做法 对于 VMware： VMware 上的 Microsoft Exchange 2010 最佳做法指南 VMware 上的 Microsoft Exchange 2010 设计和调整示例 VMware 上的 Microsoft Exchange 2013 最佳做法指南 VMware 上的 Microsoft Exchange 2013 可用性和恢复选项 VMware 上的 Microsoft Exchange 2013 设计和调整指南

30 邮箱服务器存储设计方法 建议和支持能力 设计最佳做法参考 支持的部署配置 配置最佳做法
Exchange 存储设计和最佳做法 邮箱服务器存储设计方法 建议和支持能力 设计最佳做法参考 支持的部署配置 配置最佳做法

31 Exchange 邮箱服务器存储设计方法 第 1 阶段： 第 2 阶段： 第 3 阶段： 验证设计 用户总数 每台服务器的用户数
收集要求 第 2 阶段： 设计构造块和存储体系结构 第 3 阶段： 验证设计 用户总数 每台服务器的用户数 用户配置文件和邮箱大小 用户并发性 高可用性要求（DAG 配置） 备份和恢复 SLA 使用的第三方软件（归档、Blackberry 等） 利用 Microsoft 和 EMC 最佳做法设计构造块 利用 EMC 最佳做法设计存储体系结构 利用 EMC 经验证的解决方案白皮书 利用 Exchange 解决方案审查计划 (ESRP) 文档 使用 Microsoft Exchange 验证工具： Jetstress — 适用于存储验证 LoadGen — 适用于用户工作负载和端到端解决方案验证

32 Exchange 存储设计 什么是构造块？ 为什么采用构造块方法？ Exchange 构造块设计方法
Title Month Year Exchange 存储设计 Exchange 构造块设计方法 什么是构造块？ 构造块表示在单台服务器或虚拟机上支持特定数量的 Exchange 用户所需的资源量 构造块以要求为依据，其中包括： 计算要求（CPU、内存和网络） 磁盘要求（数据库、日志和操作系统） 为什么采用构造块方法？ 可以轻松地复制以支持具有类似用户配置文件特征的所有用户 使 Exchange 环境增加变得更加容易和简单，从而有助于将来的环境增长 在许多实际的客户实施中都非常成功 有关构造块设计流程，请参阅“附录”

33 Exchange 存储设计 Exchange 存储调整 在调整 Exchange 环境时，不要仅依赖于自动化工具
Title Month Year Exchange 存储设计 Exchange 存储调整 在调整 Exchange 环境时，不要仅依赖于自动化工具 请将时间和精力放在计算上，并为您的设计提供真实的支持证据，而不是提供 虚构的计算结果 根据 I/O、邮箱容量和带宽要求调整 Exchange 考虑其他开销变量，如归档、快照保护、病毒防护、移动设备和风险因素 使用特定的阵列调整工具确认 Exchange 存储要求

34 Exchange 存储设计 Exchange 调整工具选项
Title Month Year Exchange 存储设计 Exchange 调整工具选项 采用 DIVA 的 EMC Exchange 设计器： Microsoft Exchange Server 角色要求计算器 Exchange 2010： Exchange 2013： VSPEX 调整工具 特定阵列调整工具，即 VNX Disksizer 高级管理员手动计算

35 常规存储设计指导 将 Exchange 服务器工作负载放到它自己的一组磁盘轴中，与其他工作负载隔离以保证性能
最佳做法 将 Exchange 服务器工作负载放到它自己的一组磁盘轴中，与其他工作负载隔离以保证性能 在调整时，始终计算 I/O 要求和容量要求 将数据库和日志分隔到不同的卷上 在单独的物理磁盘轴上部署 DAG 拷贝 使用 DAG 时，可接受大小高达 2 TB 的数据库： 具体大小取决于客户要求 确保您的解决方案可支持大于 2 TB 的 LUN

36 常规存储设计指导 在计算数据库大小时，应考虑备份和恢复时间 将负载尽可能在阵列资源、V-Max 引擎、VNX SP 和后端总线等之间均匀分布
最佳做法（续） 在计算数据库大小时，应考虑备份和恢复时间 将负载尽可能在阵列资源、V-Max 引擎、VNX SP 和后端总线等之间均匀分布 始终使用分配单元大小 64K 格式化用于数据库和日志的 Windows NTFS 卷 尽可能使用 Exchange 构造块设计方法

37 常规存储设计指导 — VNX 池还是 RAID 组？ 任一方法效果都很好，并提供相同的性能（密集池与 RG）
池的效率更高，并且更容易管理 如果打算使用如下高级功能，请使用池： FAST VP、VNX 快照 存储池可以支持单个构造块，也可以支持多个构造块，具体取决于客户要求 通过使用正确的乘数来设计和扩大池，以实现最佳性能（R1/0 4+4、R5 4+1、 R6 6+2）

38 常规存储设计指导 — VNX 密集 LUN 和精简 LUN 都可用于 Exchange 存储（数据库和日志）
建议将密集 LUN 用于具有高 IOPS 用户配置文件的高工作负载 建议将精简 LUN 用于具有低 IOPS 用户配置文件的轻、中工作负载 好处：显著降低初始存储要求 在卷格式化之前使用 VNX Pool Optimizer 可以启用 FAST Cache 或 FAST VP 以快速升级元数据

39 使用 FAST VP 的 Exchange 存储设计
建议配置（VNX 和 VMAX） 考虑不同的工作负载，将数据与日志分开 数据 — 有热点的随机工作负载；FAST VP 有大优势 日志 — 无热点的顺序数据；FAST VP 无优势 使用专用池 提供更好的 SLA 保证 提供故障域 Microsoft 建议用于最具决定性的行为 使用密集池 LUN 以获得最佳性能（在 VNX 上） 在 FAST Cache 或池中采用闪存时，可接受精简池 LUN 在 VMAX 上使用精简 LUN

40 Exchange 存储设计 FAST Cache 使存储系统可以向整个系统中访问最频繁的数据 块提供闪存驱动器级性能
FAST Cache（仅限 VNX） FAST Cache 使存储系统可以向整个系统中访问最频繁的数据 块提供闪存驱动器级性能 吸收应用程序激增的 I/O，从而降低后端硬盘的负载 自动吸收池元数据 提高存储解决方案的性能 可以按存储池启用/禁用

41 Exchange 存储设计 FAST Cache 使用 FAST Cache 调整指导 FAST Cache（仅限 VNX）
包含精简 LUN 的池（用于元数据跟踪） 包含精简和密集 LUN 的池（使用 VNX Snapshots 时） 包含密集 LUN 的池 不是必需的，但也没有限制 使用 VNX Snapshots 时是必需的  FAST Cache 调整指导 经验法则：对于每 1 TB 的 Exchange 数据集，调配 1 GB 的 FAST Cache 监视和调整 FAST Cache 大小，具体过程可能会有所不同 仅在包含数据库 LUN 的池上启用 FAST Cache

42 Exchange 存储设计 — VMAX 确保初始磁盘配置可以支持 I/O 要求
使用 Unisphere for VMAX 监视精简池利用率，防止精简池耗尽空间 在您环境中的 Windows Server 2012 主机上安装 Microsoft 热修复 程序 KB 。

43 Exchange 存储设计 — VMAX 使用 Symmetrix Virtual Provisioning
设计最佳做法 使用 Symmetrix Virtual Provisioning 可以在相同的磁盘之间共享数据库卷和日志卷，但将它们 单独放到同一个主机上的不同 LUN 中 为了取得最佳 Exchange 性能，请使用分条元卷

44 VMAX FAST VP 与 Exchange 设计最佳做法 为 VMAX 上的 Exchange 2010/2013 设计 FAST VP 时，请遵循以下 指导准则： 将数据库和日志单独放到其自身的卷中 可以在相同的磁盘间共享数据库卷和日志卷。 将事务日志卷从 FAST VP 策略中排除，或者将所有日志卷固定到创建这些卷的层中 选择按 FAST 策略分配以允许 FAST VP 根据性能和容量限制将所有层用于新分配 Enginuity™ 5876 代码中引入的新功能 将 FAST VP 与 Exchange DAG 配合使用时，不要将同一数据库的 DAG 拷贝放置在 同一池中的相同磁盘上

45 Exchange 验证工具 Exchange JetStress 和 Load Generator 工具 — Exchange 2010 邮箱服务器角色要求计算器 — to-the-exchange-2010-mailbox-server-role-requirements- calculator.aspx

46 XtremCache 与 Exchange 什么是 XtremCache？ XtremCache 是一种服务器闪存缓存解决方案，可利用智能软件和 PCIe 闪存技术缩短延迟并提高吞吐量，从而提升应用程序性能。 对于要求最高 IOPS 和/或最短响应时间的应用程序，XtremCache 可加快其数据块 I/O 读取速度。 XtremCache 可使用到网络存储的直写缓存，提供持久的高可用性和灾难恢复，从而加快读取速度和 保护数据。 使用基于阵列的 FAST 和 FAST Cache 软件 针对物理和虚拟环境而优化

47 为何选择针对 Exchange 的 XtremCache？
有一个 I/O 绑定 Exchange 解决方案 不确定预期的工作负载 需要为特定用户（VIP 服务器、数据库等）保证高性能和低延迟 经验证，XtremCache 可以借助以下方面提高 Exchange 性能： 减少读取延迟 提高 I/O 吞吐量 消除几乎所有高延迟峰值 随工作负载增加提供更多改进 减少 RPC 延迟 通过 XtremCache 重复数据消除减少后端存储写入

48 XtremCache 与 Exchange 可在以下位置安装 XtremCache PCI 闪存卡：
配置建议 可在以下位置安装 XtremCache PCI 闪存卡： 物理 Exchange 邮箱服务器 承载 Exchange 邮箱虚拟机（VMware 或 Hyper-V）的虚拟机管理程序服务器 仅在数据库卷上启用 XtremCache 加速 XtremCache 调整指导： 对于 1,000 GB 的工作数据集，配置 10 GB 的 XtremCache 设备

49 XtremCache 与 Exchange 实施 XtremCache 与 VMware vSphere 时，考虑以下事项： 配置建议
要部署的 PCI 缓存卡的大小 在将要使用 XtremCache 的每个 vSphere 主机上部署的 Exchange 虚拟机 数量 Exchange 工作负载特征（读:写比率、用户配置文件类型） Exchange 数据库大小 缓存所有工作数据集读取时，可获得最大优势

50 XtremCache 与 Exchange 将 XtremCache 设备添加到 Exchange 虚拟机时：
配置建议 将 XtremCache 设备添加到 Exchange 虚拟机时： 将缓存页设置为 64 KB，将最大 IO 大小设置为 64 KB（不会缓存 BDM I/O） 在将缓存设备添加到虚拟机时，可以使用 VSI 插件或 XtemCache CLI 命令将缓存页大小设置为 64 KB，将最大 I/O 大小设置为 64 KB： vfcmt add -cache <缓存设备> -set_page_size 64 -set_max_io_size 64)

51 XtremCache 与 Exchange 先评估您的工作负载，然后再考虑启用重复数据消除以加快 Exchange LUN 速度
配置建议（重复数据消除） 先评估您的工作负载，然后再考虑启用重复数据消除以加快 Exchange LUN 速度 在启用重复数据消除时考虑 CPU 开销 根据工作负载特征设置重复数据消除率： 如果观察到的重复数据消除率小于 10%，EMC 建议关闭重复数据消除（或将其设置为 0%），这样有利于延长缓存设备寿命。 如果观察到的比率高于 35%，EMC 建议提高重复数据消除收益，使其与观察到的重复数 据消除匹配。 如果观察到的比率在 10% 和 35% 之间，EMC 建议保持重复数据消除收益不变。

52 备份选项 硬件和软件 VSS 提供程序 备份最佳做法

53 Exchange 备份最佳做法 确保您了解备份的重要性，并确定是否有长期保留要求
Title Month Year Exchange 备份最佳做法 确保您了解备份的重要性，并确定是否有长期保留要求 可以选择将 DAG HA 拷贝/滞后拷贝用于时间点备份，但要考虑以下事项： 备份经常要遵守监管要求 延长保留时间 存在 DAG HA/滞后拷贝无效的情况 如果激活了滞后拷贝，则必须重新创建新拷贝 53

54 Exchange 备份最佳做法 Exchange 2010/2013 中不再允许或支持流备份
Title Month Year Exchange 备份最佳做法 Exchange 2010/2013 中不再允许或支持流备份 EMC 建议利用 VSS 技术实现 Exchange 数据库和日志文件复制和备份的一致性，原因如下： 通过硬件 VSS 提供程序提供快速恢复 降低备份的硬件要求 集成重复数据消除机制 缓解服务器级别的硬件和资源争用 54

55 Exchange 备份最佳做法 有两种 VSS 提供程序：基于硬件的提供程序和基于软件的提供程序。了解区别： 基于硬件的提供程序：
Title Month Year Exchange 备份最佳做法 有两种 VSS 提供程序：基于硬件的提供程序和基于软件的提供程序。了解区别： 基于硬件的提供程序： 用作卷影拷贝服务与硬件级别之间的接口：与硬件存储适配器或控制器配合使用 通过操作系统外部的存储应用装置执行卷影拷贝 依靠硬件来生成克隆/快照 包括 VNX SnapView、VNX Snapshots 和 Symmetrix TimeFinder 基于软件的提供程序： 在文件系统与卷管理器之间的软件层截取和处理 I/O 请求 以用户模式 DLL 和内核模式设备驱动程序形式实施。卷影拷贝由软件执行 不依赖于硬件，因此平台支持范围更大 包括 Avamar、Networker NMM 和 NetBackup 55

56 Exchange 备份最佳做法 快照最好使用 VSS 可以使用保护克隆，但要考虑以下事项： 备份和恢复具有相同的硬件 VSS 粒度：
Title Month Year Exchange 备份最佳做法 快照最好使用 VSS 不再需要对两个或更多 DAG 拷贝执行一致性检查 所需存储空间更少 可以使用保护克隆，但要考虑以下事项： 数据库大小更大 从非活动 DAG 拷贝执行备份 一致性检查过程中的活动，备份 备份和恢复具有相同的硬件 VSS 粒度： 恢复在 LUN 级别进行 在设计和布局过程中要考虑这一点 考虑利用 AppSync 与 ItemPoint 进行单项恢复 56

57 Exchange 验证的解决方案

58 VNX5700 上的 Exchange 2013 ESRP

59 Exchange 与 XtremSW Cache

60 Exchange 的 VSPEX 解决方案

61 利用 EMC XtremCache 提高 Microsoft Exchange 性能 EMC VNX 存储和 VMware vSphere
2013 年 3 月完成的解决方案

62 解决方案体系结构

63 Exchange 2010 构造块详细信息 每台服务器的邮箱总数 5,000 个邮箱/服务器 邮箱大小 每个用户 1.5 GB 用户配置文件
150 封邮件/用户/天 (0.150 IOPS) 目标平均邮件大小 75 KB 数据库设计 6 个数据库/服务器 每个数据库 833 个用户 数据库大小约 1300 GB（LUN 大小 1650 GB） 日志设计 6 个日志 LUN（90 GB LUN 大小） 每个 ESX 的 Exchange 邮箱虚拟机数 3 每台服务器的磁盘配置 18（16 个数据库 + 2 个日志），2TB NL-SAS 驱动器 每个虚拟机推荐的内存/CPU 32 GB RAM，29040 CPU 兆周 删除项保留窗口（“垃圾箱”） 14 天 日志保护缓冲区 3 天 24x7 BDM 配置 已启用 数据库读/写比率 3:2（在邮箱恢复能力配置中）

64 使用 XtremSW Cache 的存储设计 为数据库创建两个存储池 每个池包含来自不同虚拟机的多个拷贝
每个池 48 个 2 TB 7.2k rpm NL-SAS，RAID 1/0 每个池包含来自不同虚拟机的多个拷贝 3 个构造块（3 个虚拟机） 18 个 1.6 TB LUN（每个虚拟机 6 个 LUN） 根据每台 vSphere 服务器上的 tremCache PCI 卡创建 326 GB VFMS 数据存储区 根据 VMFS 缓存数据存储区为每个 Exchange 虚拟机创建 50 GB 缓存设备 为可从其他 vSphere 服务器迁移的虚拟机保留剩余容量

65 其他参考资料

66 其他参考资料 《Exchange 存储最佳做法和 EMC 存储设计指导准则》白皮书： EMC 社区网络
design-guid-emc-storage.pdf EMC 社区网络 EMC 和合作伙伴 Exchange 2010 经测试的虚拟化解决方案 Exchange 解决方案审查计划 (ESRP) 提交 Exchange 邮箱服务器存储设计 (Microsoft TechNet)

67 其他参考资料 Exchange 虚拟化可支持性指导 — 了解 Exchange 性能 — 服务器虚拟化验证计划 — Exchange 2010 经 EMC 测试的 OEM 解决方案（在 Hyper-V 上） 通过虚拟资源调配在 EMC 存储上部署 20,000 个用户 通过 EMC REE 在 EMC 存储上部署 32,400 个用户

68 附录 构造块设计流程 ESI for VNX 池优化

69 构造块设计流程

70 Exchange 邮箱服务器存储设计方法 第 1 阶段： 收集要求 第 2 阶段： 设计构造块和存储体系 结构 第 3 阶段： 验证设计
用户总数 每台服务器的用户数 用户配置文件和邮箱大小 用户并发性 高可用性要求（DAG 配置） 备份和恢复 SLA 使用的第三方软件（归档、Blackberry 等） 利用 Microsoft 和 EMC 最佳做法设计构造块 利用 EMC 最佳做法设计存储体系结构 利用 EMC 经验证的解决方案白皮书 利用 Exchange Solution Review Program (ESRP) 文档 使用 Microsoft Exchange 验证工具 Jetstress — 适用于存储验证 LoadGen — 适用于用户工作负载和端到端的解决方案验证

71 要求收集示例 项目 值 Exchange 版本。环境中活动用户（邮箱）的总数 Exchange 2013，20,000 站点恢复能力要求
单站点 存储基础架构 SAN 部署类型（物理还是虚拟） 虚拟 (VMware vSphere) 硬件要求 一个 DAG（包含两个数据库拷贝） 邮箱大小限制 2 GB 最大配额 用户配置文件 每个用户每天 200 封邮件 (0.134 IOPS) 目标平均邮件大小 75 KB Outlook 模式 缓存模式，100% MAPI 邮箱服务器数量 8 每个服务器的邮箱数量 5,000（2,500 个活动邮箱/2,500 非活动邮箱） 每个服务器的数据库数量 10 每个数据库的用户数量 500 删除项保留 (DIR) 期限 14 天 日志保护缓冲区（应对日志截断故障） 3 天 BDM 配置 启用 24x7 数据库读/写比率 在 DAG 配置中为 3:2 (60%/40%) 用户并发要求 100% 影响空间或 I/O 的第三方软件（例如，Blackberry、快照） 用于数据保护的存储快照 磁盘类型 3 TB NL-SAS (7,200 rpm) 存储平台 VNX

72 构造块设计 在我们的示例中，要将构造块定义为： 每个构造块支持两个数据库拷贝。 支持 5,000 个用户的邮箱服务器 定义和设计构造块
2,500 个用户在正常运行时期间处于活动状态，其他 2,500 个用户在发生邮箱 服务器切换之前处于非活动状态。 每个构造块支持两个数据库拷贝。

73 构造块调整和扩展过程 执行 IOPS 要求计算 根据不同的 RAID 类型执行容量要求计算 确定最佳选项 扩展构造块
多个构造块可以组合到一起，形成最终配置和存储布局（池或 RG）

74 构造块调整和扩展过程 前端 IOPS ≠ 后端 IOPS 了解各 RAID 类型的磁盘 IOPS
前端 IOPS = Exchange 邮箱服务器 IOPS 总数 后端 IOPS = 存储阵列 IOPS（包括 RAID 性能损失） 了解各 RAID 类型的磁盘 IOPS 块前端 Exchange 应用程序工作负载根据使用的 RAID 类型转换成不同的后端磁盘工作负载。 对于读取操作，RAID 类型没有影响： 1 个应用程序读取 I/O = 1 个后端读取 I/O 对于像 Exchange 这样的随机写入： RAID 1/0：1 个应用程序写入 I/O = 2 个后端写入 I/O RAID 5：1 个应用程序写入 I/O = 4 个后端磁盘 I/O（2 个读取 I/O + 2 个写入 I/O） RAID 6：1 个应用程序写入 I/O = 6 个后端写入 I/O（3 个读取 I/O + 3 个写入 I/O）

75 数据库 IOPS 要求 事务性 IOPS 总数 = 每个邮箱的 IOPS * 每台服务器的邮箱数 +（Microsoft 建议的开销百分比）
公式和计算 事务性 IOPS 总数 = 每个邮箱的 IOPS * 每台服务器的邮箱数 +（Microsoft 建议的开销百分比） 事务性 IOPS 总数 = 5,000 个用户 * 每个用户 IOPS + 20% Microsoft 建议的开销 = = 804 IOPS 前端 IOPS 总数 =（事务性 IOPS 总数）+（EMC 要求的开销百分比） 前端 IOPS 总数 = % EMC 要求的开销 = 965 IOPS（964.8 向上取整）

76 数据库磁盘性能要求 (IOPS) 公式 Exchange 数据库 IOPS 所需的磁盘 =（后端数据库读取 IOPS 总数）+ （后端数据库写入 IOPS 总数）/每个磁盘的 Exchange 随机 IOPS 其中： 后端数据库读取 IOPS 总数 =（前端 IOPS 总数）*（读取 IOPS 的百分比） 后端数据库写入 IOPS 总数 = RAID 写入性能损失 *（前端 IOPS 总数）* （读取 IOPS 的百分比）

77 数据库磁盘性能要求 (IOPS) 计算 RAID 选项 RAID 性能损失 需要的磁盘 RAID 1/0 (4+4) 2
(965 * 0.60) + 2(965 x 0.40) = = /65 = 21（向上取整为 24 个磁盘） RAID 5 (4+1) 4 (965 * 0.60) + 4(965 x 0.40) = = /65 = 33（向上取整为 35 个磁盘） RAID 6 (6+2) 6 (965 * 0.60) + 6(965 x 0.40) = = /65 = 45 个磁盘（向上取整为 48 个磁盘）

78 事务性日志 IOPS 要求 公式和计算 Exchange 日志 IOPS 所需的磁盘 =(后端数据库写入 IOPS 总数* 50%)+ (后端数据库写入 IOPS 总数 * 10%)/每个磁盘的 Exchange 顺序 IOPS Exchange 日志 IOPS 所需的磁盘 =((772 个后端写入 IOPS * 50%)+ (772 *10%))/每个磁盘 180 个 Exchange 顺序 IOPS =( )/ 180 = 2.57(向上取整为 4 个磁盘)

79 存储容量计算 计算磁盘上的用户邮箱 计算磁盘上的数据库大小 计算数据库 LUN 大小 公式
磁盘上邮箱大小 = 邮箱最大大小 + 空白空间 + 垃圾箱 磁盘上数据库大小 = 每个数据库的邮箱数 * 磁盘上的邮箱大小 数据库 LUN 大小 = 邮箱数 * 磁盘上邮箱大小 *（1 + 索引空间 + 用于维护的额外索引空间）/（1 + LUN 可用空间）

80 磁盘上邮箱大小 公式 磁盘上邮箱大小 = 邮箱最大大小 + 空白空间 + 垃圾箱 其中：
每个邮箱的估计数据库空白空间 = 每个用户的日常邮件概况 * 邮件平均大小 垃圾箱 =（每个用户的日常邮件概况 * 邮件平均大小 * 删除项保留窗口）+（邮箱配额大小 * 0.012）+（邮箱配额大小 * 0.03）

81 磁盘上邮箱大小 计算 空白空间 = 200 封邮件/天 * 75 KB = 14.65 MB
垃圾箱 =（200 封邮件/天 * 75 KB * 14 天）+（2GB * 0.012）+ （2GB * 0.03）= = MB 磁盘上邮箱大小 = 2 GB 邮箱配额 MB 数据库空白空间 MB 垃圾箱 = 2,354 MB（2.3 GB）

82 磁盘上数据库大小以及 LUN 大小 计算 在我们的示例中：
磁盘上数据库大小 = 每个数据库 500 个用户 * 每个磁盘上 2,354 MB 邮箱 = 1,177 GB（1.15 TB） 数据库 LUN 大小 = 1,177 GB *（ ）/（ ）= 2,060（2 TB） 在我们的示例中： 增加 20% 用于索引 增加 20% 用于索引维护任务 增加 20% 用于 LUN 可用空间保护

83 日志空间计算 公式和计算 日志 LUN 大小 =（日志大小）*（每个数据库的邮箱数）*（备份/截断故障容错天数）+（用于支持邮箱移动的空间）/（1 + LUN 可用空间） 用于支持 3 天截断故障的日志容量 =（每个数据库 500 个邮箱 * 每天 40 个日志 * 1 MB 日志大小）* 3 天 = GB 用于支持每周 1% 邮箱移动的日志容量 = 每个数据库 500 个邮箱 * 0.01 * 2.3 GB 邮箱大小 = 11.5 GB 日志 LUN 大小 = 58.59GB GB /( ) = GB（向上取整为 88 GB）

84 每个构造块的总容量 每台服务器所需的 LUN 总容量 =（每台服务器的数据库 LUN 大小）+（每台 服务器的日志 LUN 大小）*（每台服务器的数据库数） LUN 容量类型 每台服务器所需的 LUN 容量 数据库 LUN 容量 每个 LUN 2,060 GB * 每台服务器 10 个 LUN = 20,600 GB 日志 LUN 容量 每个 LUN 88 GB * 每台服务器 10 个 LUN = 880 GB 每台服务器的 LUN 总容量 20, = 21,480 GB

85 所需磁盘总数 数据库磁盘 日志磁盘 Exchange 数据库容量所需的磁盘数 = 数据库 LUN 总大小/物理磁盘容量 * RAID 乘数

86 基于容量的磁盘要求 RAID 选项 所需数据库磁盘数 RAID 选项 所需的日志磁盘数 RAID 1/0 (4+4)
20,600/ * 2 = 7.37 * 2 = 14.74（向上取整为 16 个磁盘） RAID 5 (4+1) 20,600/ * 1.25 = 7.37 * 1.25 = 9.2（向上取整为 10 个 磁盘） RAID 6 (6+2) 20,600/ * 1.33 = 7.37 * 1.33 = 9.8（向上取整为 16 个 磁盘） RAID 选项 所需的日志磁盘数 RAID 1/0 (1+1) 880/2,794.5 * 2 = 0.63（向上取整为 2 个磁盘）

87 最终存储计算结果 构造块摘要 卷类型 RAID 选项 性能磁盘需求 (IOPS) 容量磁盘需求 最佳选项 Exchange 数据库
24 个磁盘 16 个磁盘 RAID 5 (4+1) 35 个磁盘 10 个磁盘 RAID 6 (6+2) 48 个磁盘 Exchange 日志 RAID 1/0 (1+1) 4 个磁盘 2 个磁盘 每个构造块的磁盘总数 28 个磁盘

88 最终存储计算结果 构造块可扩展性 包含两个拷贝的 DAG 中整个 20,000 用户解决方案所需的磁盘总数 = 每个构造块 28 个磁盘 * 8 个构造块 = 共 224 个磁盘

89 构造块调整和扩展过程 （数据库吞吐量 * 每个总线的数据库数）= Exchange 数据库吞吐量
带宽计算 Exchange 的阵列吞吐量 MB/s 验证涉及： 确定客户需要的数据库数 确认数据库 LUN 在后端总线和存储处理器之间平均分布。 确定每个总线是否可以容纳 Exchange 数据库吞吐量峰值 使用此计算方法可计算所需的吞吐量 （数据库吞吐量 * 每个总线的数据库数）= Exchange 数据库吞吐量 将该数量与阵列总线吞吐量比较 数据库吞吐量 = 每个数据库的事务性（用户）IOPS 总数 * 32 K + 每个数据库的 BDM 吞吐量 （以 MB/s 为单位） 每个总线的数据库数 = 每个总线的活动和非活动数据库总数

90 存储带宽要求 带宽验证过程涉及以下步骤： 流程 确定 Exchange 环境中的数据库数量 确定每个数据库的带宽要求
确定每个阵列总线的带宽要求 确定每个总线是否可以容纳 Exchange 数据库吞带宽峰值 使用针对 VNX 的 DiskSizer，或者与您当地的存储专家联系以获取阵列和总线吞吐量数据 DiskSizer 可通过您当地的 USPEED 联系人获得 在后端总线和存储处理器之间均匀分布数据库 LUN 统一分布是获得最佳性能的关键 FE/BE/RAID 组/池和 DAE 统一分布到池上的数据库 对 SAS 循环使用偶数（0 或 2）以实现最大性能

91 存储带宽要求 计算 每个数据库的带宽 (MB/s) = 每个数据库的事务性 IOPS 总数 * 32 KB + 每个数据库估计的 BDM 吞吐量 (MB/s) 其中： 32 KB 是 Exchange 页面大小 每个数据库估计的 BDM 吞吐量是 7.5 MB/s (Exchange 2010) 和 2.25 MB/s (Exchange 2013) 每个总线所需的吞吐量 (MB/s)= 每个数据库的吞吐量 (MB/s)* 每个总线的 活动和非活动数据库总数

92 存储带宽要求 计算 如果阵列支持每个总线最大 3,200 MB/s 吞吐量，那么从吞吐量上来看，可以支持 200 个 数据库。
每个数据库的事务性 IOPS 总数 = 500 * * 32 KB = 2.1 MB/s  每个数据库的吞吐量 = 2.1 MB/s MB/s = 4.35 MB/s  每个总线所需的吞吐量 = 4.35 MB/s * 每个总线 200 个数据库 = 870 MB/s 示例假设： 500 个用户，每个数据库的 IOPS 为 0.134 每个总线 200 个数据库 如果阵列支持每个总线最大 3,200 MB/s 吞吐量，那么从吞吐量上来看，可以支持 200 个 数据库。

93 最终设计 为每个邮箱服务器配置专用存储池时使用 24 个 3 TB NL-SAS 驱动器。 每个存储池存放来自不同邮箱服务器的两个拷贝。
将 Exchange 日志文件单独放到不同的存储池中 为了提高存储利用率，为每四个邮箱服务器构造块的日志创建一个存储池（包含 16 个 3 TB NL-SAS 驱动器）。

94 存储设计验证 Exchange Server Jetstress
使用 Exchange 可执行程序模拟 I/O 负载（使用相同的版本） 在安装 Exchange Server 之前的预生产过程中初始化和执行 吞吐量和邮箱配置文件测试 — 通过测试可以为存储设计按预期工作提供信心 Exchange Server Load Generator (LoadGen)（可选） 验证必须在隔离的实验室中进行 针对测试的 Exchange 部署生成模拟的客户端工作负载 估计每台服务器的用户数并验证 Exchange 部署 LoadGen 测试可能需要几周时间来配置和填充数据库

95 存储设计验证 Exchange 解决方案审查计划 (ESRP) 结果
用于验证存储供应商的 Exchange 设计的 Microsoft 计划 供应商可以根据性能、压力、磁盘备份和日志文件重放要求运行多个 Jetstress 测试 由 Microsoft 审查和批准

96 ESI for VNX 池优化应用工具 （也称为 SOAP 工具）

97 VNX 存储池优化程序应用工具 它是什么？ 用于优化基于池的（精简或密集）LUN 以获得最佳性能的应用工具
为要跨池中的所有 LUN 统一实现决定性的高性能的 Exchange 或 任何应用程序提供最佳选项 在所有磁盘和私有 RAID 组之间均匀地预分配池中的存储片

98 VNX 存储池优化程序应用工具 为什么需要使用该应用工具？
实现基于池的 LUN（主要是精简 LUN）的最佳性能，并在部署前 存储验证中通过 Jetstress 测试 缓解“Jetstress 效应”

99 何时使用优先程序应用工具 使用情形 对于 CX4 和 VNX OE for Block 版本 32 (Inyo)，使用 SOAP 应用工具
CX4/VNX（OE for Block 5.32 之前版本）— 仅限密集 LUN 对于 VNX OE for Block 5.32，密集池 LUN 是在创建时预分配的 VNX Rockies (OE for Block 5.33) — 精简和密集 LUN（主要是精简 LUN） 对于 CX4 和 VNX OE for Block 版本 32 (Inyo)，使用 SOAP 应用工具 对于 VNX OE for Block 版本 33 (Rockies)，使用新的 ESI for VNX 池 优化应用工具 短期计划是将这两个工具合并成一个 长期计划是在本机 VNX 代码中实现该功能。

100 问题在哪里？ 该问题是如何浮现的？ “JetStress 效应”
进行 Jetstress 测试时，Exchange 服务器上的第一个数据库： 在 LUN 为密集 LUN 时，遇到比其他 LUN 更高的延迟 在 LUN 为精简 LUN 时，遇到比其他 LUN 更低的延迟 “JetStress 效应” Jetstress 数据填充导致池中的底层虚 拟磁盘不平衡

101 Jetstress 初始化过程 Jetstress 初始化阶段工作方式： Jetstress 创建第一个数据库
然后，通过同时将第一个数据库拷贝到 其他数据库来创建其他数据库

102 底层机制… 存储片图 未优化 优化

103 VMDK 优化 未优化 优化

104 密集池 LUN 资源调配选项 两个密集池 LUN 资源调配选项
仅限 VNX OE for Block 32 (Inyo) 两个密集池 LUN 资源调配选项 获得良好性能和最佳性能 — 不需要 SOAP。通过 Unisphere、 NaviSecCLI、EMC ESI 或 EMC VSI 使用默认池 LUN 资源调配 获得最佳性能（最大 IOPS）— 使用 NaviSecCLI 禁用预调配，然后运行 SOAP 通过 CLI 关闭预调配 运行 SOAP 预先启用预调配

105 旧的 SOAP 应用工具 — 位置和方式 旧的 SOAP 应用工具可在 EMC 在线支持站点上获得
必须仅与 CX4/VNX Inyo (OE 5.32) 配合使用 仅支持密集 LUN 优化 Zip 文件中包含该工具、分步说明文档以及演示视频

106 ESI for VNX 池优化应用工具 可从 EMC 在线支持站点下载(2013 年 11 月)
只能与新一代 VNX 系列 (OE 5.33) 配合使用(VNX5200、VNX5400、VNX5600、VNX5800、VNX7600、VNX8000) 支持密集和精简 LUN 优化

107