由于这是我的第一个设计，我希望确保在部署之前没有错过任何明显的问题。
答案1
Exchange 团队针对 Exchange 2013 的首选架构 (PA) 包括以下引言：
在 2007 年发布之前，基于 SAN 的存储系统一直是 Exchange 的核心，其成本和复杂性促使 Exchange 团队加大对存储堆栈的投资，并改进 Exchange 应用程序，将重要的存储元素直接集成到其架构中。我们认识到，每个 SAN 系统最终都会失败，而使用 SAN 技术实施高度冗余的系统成本过高。为此，Exchange 已从需要昂贵的、可扩展的高性能 SAN 存储和相关外围设备发展到现在能够在廉价的可扩展服务器上运行，这些服务器使用 JBOD 配置中的商用低性能 SAS/SATA 驱动器和商用磁盘控制器。这种架构使 Exchange 能够应对任何与存储相关的故障，同时使您能够以合理的成本部署大型邮箱。
[...]
部署物理硬件而不是虚拟化硬件有两个原因：
虚拟化增加了额外的管理层和复杂性，从而引入了不会增加价值的额外恢复模式，因为 Exchange 提供了开箱即用的等效功能。
通过拥有可以故障转移的虚拟机和外部 SAN 存储，然后在其上分层 Exchange DAG，您不一定会获得“更多更好”，但肯定会获得“更复杂、更昂贵和更多的开销”。
通过拥有两台物理服务器和两台虚拟服务器，您可以进行大量分离，但随后您将使用相同的 RAID5 vDisk 备份所有内容，这消除了单独 Exchange 服务器的一些意义 - 如果存储发生故障，您的两个冗余服务器都会瘫痪。它还增加了一些 IO 争用 - 您的写入将转到数据库、数据库日志，然后复制到另一个数据库和另一个数据库日志，所有这些都写入同一个 RAID5 并在同一个驱动器上生成日志。您是否做过任何 IOPS 或电子邮件吞吐量估算？
您的设置中有相当多的磁盘，因此可能不会成为瓶颈 - 但在 vDisk 中可用的 13TB 中，您的 Exchange LUN 加起来只有 1.5TB。这是否意味着您计划在同一磁盘上安装 11.5TB 的不相关虚拟机？
35-40 个用户。120 个邮箱。>10GB 邮箱大小。以及 500GB Exchange 数据库驱动器，每个驱动器都有一个实时数据库和一个副本？因为看起来它们从一开始就会满满的。
答案2
根据Ignite 的 Exchange Server 首选架构在您的情况下，使用 DAG 毫无意义。简而言之 - 底层基础设施胜过 DAG 的唯一目的。您是否考虑过使用 Office365 进行此类部署？当您支付完 2xExchange 和 CAL 许可证的费用后，客户可能会开始迁移到下一个版本的 Exchange（不是 2016，而是下一个）。如果您要在那里托管大量虚拟机，也许值得考虑将 vCPU 和 vMemory 资源分配给其他几台虚拟机？Exchange 是一个内存怪兽。过去一直如此，将来也永远如此。下一个版本使用的内存比上一个版本更多，一直都是这样。
PS 强烈建议观看演示文稿，它将清楚地了解如何对待和培养 Exchange。