我正在尝试在 Amazon 上设置一个生产 mongo 系统，用作实时指标系统的数据存储，
我最初在 Marketplace 中使用了 MongoDB AMIs[1]，但我很困惑，因为只有一个数据 EBS。我读过 Mongo 建议在 EBS 存储上使用 RAID 10（每台服务器上 8 个 EBS）。此外，我读到生产的最低要求是带有仲裁器的主要/次要设备。RAID 10 仍然是推荐的设置，还是一个预置的 IOPS EBS 就足够了？
请指教。我们是一家小商店，那么我们可以逃脱并且仍然相当安全的最低限度是多少？
[1] 具有 1000 IOPS 的 MongoDB 2.4 - 数据：200 GB @ 1000 IOPS，日志：25 GB @ 250 IOPS，日志：10 GB @ 100 IOPS
所以，我刚和一位亚马逊系统工程师通了电话，他对这个问题有一些有趣的见解。
首先，如果你要使用 RAID，他说简单地进行条带化，因为 EBS 块无论如何都会在幕后镜像，所以 raid 10 对他来说似乎有点矫枉过正。
标准 EBS 卷倾向于很好地处理尖峰流量（它可能能够在几秒钟内处理 1K-2K iops），但最终它会逐渐减少到平均 100 iops。一个建议是使用许多小型 EBS 卷并将它们条带化以获得更好的 iops 吞吐量。
他的一些客户只使用 EC2 映像上的临时存储，但随后在可用性集中有多个 (3-5) 节点。临时存储是物理机上的存储。显然，如果您将 EC2 实例与 SSD 存储一起使用，您可以获得高达 20K 的 iops。
一些客户会为主服务器制作一个带有 SSD 的巨大 EC2 映像，然后为辅助服务器制作一个带有 EBS 的较小 EC2。主机性能良好，但故障转移可用但性能下降。
确保在启动实例时选中“EBS 优化”。这意味着您拥有通往 EBS 存储（任何类型）的专用通道，而不是共享 NIC。
重要的！预置的 IOPS EBS 很昂贵，并且当您关闭它们所连接的 EC2 实例时，账单不会关闭。（在测试时这很糟糕）他的建议是拍摄 EBS 卷的快照，然后删除它们。当您再次需要它们时，只需创建新的预置 IOPS EBS 卷，恢复快照，然后重新配置您的 EC2 实例以附加新存储。（这比应有的工作要多，但值得不被 IOPS 账单打得一塌糊涂。
我也有同样的问题。Amazon 和 Mongodb 都试图在预置 IOP 上进行大量营销，以咀嚼其相对于标准 EBS 卷的优势。我们在 m2.4xlarge aws 实例上运行 prod 实例，每个服务设置 1 个主服务器和 2 个辅助服务器。在使用率最高的服务集群中，除了一些缓慢的查询之外，监控图表根本没有显示任何性能下降。页面错误很少发生，每天也会出现 0.0001 到 0.0004 次错误。后台刷新以毫秒为单位，到目前为止，锁和队列处于可管理的水平。主节点上的 I/O 等待在 0 到 2% 之间的任何时间范围内，大多小于 1，并且 %idle 稳定保持在 90% 标记以上。考虑到我们，我是否还需要考虑预置的 IOP？是否还有预算来改善任何潜在的性能拖累？任何指导将不胜感激。