放大/缩小电子邮件存储服务器的典型方法是什么？

我所见过的大中型公司是冗余存储设备，如NetApp或EMC。 事实上，我刚才在跟一位EMC的电子邮件存储代表谈话，他说大量的电子邮件服务器对他们来说是非常普遍的销售。

基本上他们把所有的存储问题都从应用程序中移走。 使用SSD或电池支持的内存caching可以实现大量短暂的随机读取。 所有的存储都在一个地方，多条path到冗余服务器模块，所以没有复制延迟。

应用程序服务器使用NFS或iSCSI来访问存储，但这种方式的灵活性较差，但有时在应用程序中需要使用不适合NFS的应用程序。 这使得存储可以通过高速以太网由任意数量的服务器共享，因此您可以扩展到存储箱的最大I / O性能，然后根据需要进行扩展。

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

我对大铁的方法有点小心 – 通常很难扩展，人们倾向于采用构build故​​障转移解决scheme的方法，希望在出现中断时能够正常工作。 大多数人很久以前就停止将这种方法应用于磁盘和网卡等组件，但将其应用于服务器则更为棘手。 您可以通过LDAP分割用户来分割数据 – 但这直接解决了复制问题，但是通过运行8对负载平衡的服务器，争用可能会less得多。 当然glusterFS恕我直言在高度事务性的系统上不能正常工作。 我也不认为近线型系统（如AFS）也是一个好主意。 问题在于需要在所有镜像上同步进行很多小的更改 – 实际上最好在应用程序级别上进行以保持一致性/

尽pipeDovecot旨在与共享存储上的多服务器一起使用，但NFS / iscsitypes的方法仍然意味着SPOF或故障转移types的方法，而不是负载平衡。 我听到很多关于GFS2用于事务性工作负载的好消息 – 通过减less到更小的系统，然后在DRBD之上运行这个服务就可以实现所需的复制。 但是尝试隔离专用交换机上的对（或使用交叉以太网连接）来保持主networking的噪声。

也就是说，我很抱歉地说，虽然dovecot对于这种types的手术来说可能比信使好很多，但是我认为你的新架构是倒退的。

（我猜你正在使用maildir而不是mbox）

我同意有一套固定的用户映射到集群是一个开销 – 而不是可用资源的最有效的使用 – 也许最好的妥协可能是在GFS2 SAN之上的LVS，让SAN处理复制的东西。 对于一个更便宜的解决scheme，尽pipe这是一个猜测，并且需要一些调查/testing，可能运行带有数据库后端的FUSE文件系统，并使用数据库复制function（例如mysqlfs）

除了你正在做的后端工作之外，你可能还想调查Nginx中的imap代理。 它旨在允许您将用户连接路由到特定的后端服务器。 这可能比尝试迁移用户的数据更容易，以平衡stream量和IO负载。