小编nar*_*hov的帖子

我试过的：

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

老的：

• 多个 (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 对象存储？