我尝试过的：
- 我有两种电子邮件存储架构。旧的和新的。
老的：
- 多个（18+）1TB 存储服务器上的 courier-imapds。
- 如果其中一个出现磁盘空间不足的迹象，我们会将一些电子邮件帐户迁移到另一台服务器。
- 服务器没有副本，也没有备份。
新的：
- dovecot2 在单个巨大的配备 16TB (SATA) 存储和一些 SSD 的服务器
- 我们将新邮件存储在 SSD 上，并运行 doveadm purge 将超过一天的邮件移至 SATA 磁盘
- 有一个相同的服务器，它有来自主服务器的最长 15 分钟的 rsync 备份
- 高层/管理层希望在每台服务器上装入尽可能多的存储空间，以尽量降低每台服务器的 SSD 成本
- rsync 之所以完成是因为 GlusterFS 在高小/随机 IO 下无法很好地复制。
- 预计要通过配置另一个一对这样的巨大的服务器
- 当遇到像旧架构中的磁盘紧缩问题时，需要手动移动电子邮件帐户。
顾虑/疑虑：
- 我不相信同步复制文件系统的想法对于重度随机/小 IO 很有效。GlusterFS 还不适合我们，我不确定是否有其他文件系统适合这种用例。这个想法是保持相同的对并使用 DNS 循环进行电子邮件传递和 IMAP/POP3 访问。如果其中一个服务器因某种原因（计划内/计划外）停机，我们会将 IP 移动到对中的另一个服务器。
- 在像 Lustre 这样的文件系统中，我可以获得单一命名空间的优势，从而无需担心手动迁移帐户以及更新 MAILHOME 路径和其他元数据/数据。
问题：
- 使用传统软件（courier-imapd / dovecot）进行扩展/扩大的典型方法有哪些？
- 存储在本地安装的文件系统上的传统软件是否会对以最少的“问题”进行扩展造成障碍？是否必须重写（部分）这些软件才能与某种类型的对象存储（例如 OpenStack 对象存储）配合使用？
答案1
我看到中大型公司都使用冗余存储设备，例如 NetApp 或 EMC。事实上，不久前我曾与 EMC 的一位代表讨论过电子邮件存储问题，他说大型电子邮件服务器对他们来说非常常见。
基本上，它们将所有存储问题都从应用程序中移除。大量短时间随机读取的性能是通过 SSD 或电池供电的内存缓存实现的。所有存储都集中在一个位置，并具有通往冗余服务器模块的多条路径，因此不存在复制延迟。
应用服务器使用 NFS 或 iSCSI 访问存储，这种方式不太灵活，但有时应用程序需要使用 NFS，但 NFS 无法很好地运行。这样，存储就可以通过高速以太网由任意数量的服务器共享，因此您可以扩展到存储盒的最大 I/O 性能，然后根据需要进行扩展。
至于应用服务器上的冗余，最便宜的是软件集群包。还有像 Big-IP 这样的设备可以在网络级别处理它并且独立于操作系统。这在很大程度上取决于应用程序是否可以通过 NFS 与其他实例并行可靠地工作。
答案2
我对大型系统方法有点谨慎——它通常很难扩展，人们倾向于采用构建故障转移解决方案的方法，并希望它在发生中断时能够正常工作。大多数人很久以前就不再将这种方法应用于磁盘和网卡等组件，但将其应用于服务器则有点棘手。您可以通过 LDAP 拆分用户来分片数据——但这确实直接解决了复制问题，但是通过运行 8 对负载平衡的服务器，争用可能会大大减少。当然，在我看来，glusterFS 在高度事务性的系统上效果不佳。我也不认为近线类型系统（例如 AFS）是个好主意。问题是，需要在所有镜像上同步进行许多小更改——实际上，最好在应用程序级别进行，以保持一致性/
尽管 Dovecot 旨在与共享存储上的多台服务器配合使用，但 NFS/iscsi 类型的方法仍然意味着 SPOF 或故障转移类型的方法，而不是负载平衡。我听到很多关于 GFS2 对于事务工作负载的好处 - 通过缩减到较小的系统，然后在 DRBD 上运行它将提供所需的复制。但请尝试隔离专用交换机上的对（或使用交叉以太网连接）以保持主网络的噪音。
即我很遗憾地说，尽管对于这种类型的操作来说 dovecot 可能比 courier 好很多，但我认为你的新架构是倒退了一步。
（我猜你使用的是 maildir 而不是 mbox）
我同意，拥有一组固定的用户到集群的映射有点开销——而且不是最有效的可用资源利用方式——也许最好的折衷方案是在 GFS2 SAN 之上使用 LVS，并让 SAN 处理复制内容。对于更便宜的解决方案，虽然这需要大量的猜测，并且需要一些调查/测试，但也许可以运行带有数据库后端的 FUSE 文件系统——并使用数据库复制功能（例如 mysqlfs）
答案3
除了您正在进行的后端工作之外，您可能还想研究 Nginx 中的 imap 代理。它旨在允许您将用户连接路由到特定的后端服务器。这可能比尝试迁移用户的数据以平衡流量和 IO 负载更容易。