用于扩展/扩展电子邮件存储服务器的典型方法是什么？

Question

我试过的：

• 我有两个电子邮件存储架构。新旧。

老的：

• 多个 (18+) 1TB 存储服务器上的 courier-imapds。
• 如果其中一个显示磁盘空间不足的迹象，我们会将一些电子邮件帐户迁移到另一台服务器。
• 服务器没有副本。也没有备份。

新的：

• dovecot2 位于具有 16TB (SATA) 存储和几个 SSD的单个大型服务器上
• 我们将新邮件存储在 SSD 上并运行 doveadm purge 以将超过一天的邮件移动到 SATA 磁盘
• 有一个相同的服务器，它有来自主服务器的最多 15 分钟的 rsync 备份
• 高层/管理层希望在每台服务器上尽可能多地装入存储空间，以最大限度地降低每台服务器的 SSD 成本
• rsync'ing 完成是因为 GlusterFS 在高小/随机 IO 下不能很好地复制。
• 预计将通过配置另一对如此庞大的服务器来完成扩展
• 在面临旧架构中的磁盘紧缩问题时，将手动移动电子邮件帐户。

疑虑/疑虑：

• 我不相信同步复制文件系统的想法适用于大量随机/小 IO。GlusterFS 还不能为我们工作，我不确定这个用例是否有另一个文件系统。这个想法是保持相同的对，并使用 DNS 循环进行电子邮件传递和 IMAP/POP3 访问。如果其中一个服务器因任何原因（计划内/计划外）宕机，我们会将 IP 移动到成对中的另一台服务器。
• 在像 Lustre 这样的文件系统中，我获得了单一命名空间的优势，因此我不必担心手动迁移帐户和更新 MAILHOME 路径和其他元数据/数据。

问题：

• 使用传统软件（courier-imapd / dovecot）进行放大/缩小的典型方法是什么？
• 存储在本地安装的文件系统上的传统软件是否会阻碍以最小的“问题”进行横向扩展？是否必须重写（部分）这些以使用某种对象存储 - 例如 OpenStack 对象存储？

Answer 1

我在大中型公司看到的是冗余存储设备，例如 NetApp 或 EMC。事实上，不久前我正在与 EMC 代表谈论电子邮件存储，他说大型电子邮件服务器对他们来说很常见。

基本上，它们消除了应用程序的所有存储问题。大量短随机读取的性能是通过 SSD 或电池支持的内存缓存实现的。所有存储都在一个地方，有多个通往冗余服务器模块的路径，因此没有复制延迟。

应用程序服务器使用 NFS 或 iSCSI 访问存储，这不太灵活，但有时应用程序需要使用 NFS 表现不佳。这允许通过高速以太网由任意数量的服务器共享存储，因此您可以扩展到存储盒的最大 I/O 性能，然后您可以根据需要进行扩展。

就应用服务器上的冗余而言，最便宜的是软件集群包。还有像 Big-IP 这样的设备在网络级别处理它并且独立于操作系统。这在很大程度上取决于应用程序是否可以与其他实例并行地通过 NFS 可靠地工作。