对于支持大约50个用户的小型Exchange服务器部署，您build议采用什么样的存储configuration？ 三年内可能不会超过75位用户。 多数将是“中等”用户，有一些“重”用户和黑莓客户端。
到目前为止，我读过的所有内容都build议将Exchange数据库和事务日志保存在不同的物理驱动器上，并将这两者都closures在系统驱动器上。 它还说要把事务日志放在一个快速的东西上，比如一个Raid 1 + 0数组。 考虑到所有的数据都需要保护，看起来这将是一个最佳的设置：
系统驱动器 – RAID 1中的2个小型驱动器Exchange数据库 – RAID 1中的2个大型驱动器事务日志 – RAID 1 + 0中的4个快速驱动器
然而，使用8个驱动器的小型Exchange服务器似乎令人难以置信的矫枉过正。 在哪里可以安全地减less？
即使拥有大量的用户和大量的空间，每个用户的IOPS也不会超过2 IOPS，如果是像这样的小环境，您甚至可能永远不会让每个用户的IOPS达到1 IOPS（请参阅Technet文章 。 即使采用相当保守的每个驱动器80 IOPS（假设您select大型7200rpm SATA驱动器作为数据），并考虑了IO IO的双IOPS开销，您仍然可以将所有Exchange数据和日志集中到两个驱动器RAID1包。 如果您有select并希望隔离日志，那么请务必继续，但是您永远不会强调使用Exchange环境即将生成的那种IO设置的一半体面的双驱动器RAID-1在75个用户。
我想说，削减的第一个地方是不会使用条纹的t日志。 在这样一个小型的服务器上，你并不需要条带化的性能。
你也可以考虑不把日志放在一个单独的存储上，但是我要削减的第一件事就是将两个额外的驱动器分开，然后在RAID 1中运行两个驱动器来处理t日志。
每个用户将产生多lessstream量？ 这是一个非常重要的考虑因素。 每个用户有多less存储空间？ 一天多less的增长？
不pipe你做什么，都不要削减RAID。 每个卷至less使用RAID 1。 由于单个磁盘故障导致服务器崩溃肯定是你不想要的。
此外，将数据库与事务日志进行物理分离还有一个很好的理由：灾难恢复。 把它们放在同一个卷上是非常糟糕的，因为你可能会同时失去两者。 如果偶然会丢失数据库，则希望准备好事务日志，否则最多可以执行的操作是恢复最后一次完整备份（可能是崩溃前几天）。
简介：针对操作系统的RAID 1，针对事务日志的RAID 1，针对数据库的RAID 1,5或10（取决于您的存储需求）。
由于您拥有的用户数量不多，我认为您不应该过多地优化存储。 底线是，除非你做了一件完全愚蠢的事情，否则存储子系统不会成为瓶颈。 所以，采取一些基本的常识性build议，不要太担心。