>我有两个电子邮件存储架构.新旧.
旧：
>几个(18)1TB存储服务器上的courier-imapds.
>如果其中一个显示磁盘空间不足的迹象,我们会将一些电子邮件帐户迁移到另一台服务器.
>服务器没有副本.也没有备份.
新：
> dovecot2在单个巨大的服务器上,具有16TB(SATA)存储和一些SSD
>我们将新鲜邮件存储在SSD上并运行doveadm清除以将超过一天的邮件移动到SATA磁盘
>有一个相同的服务器,它具有来自主服务器的最长15分钟的rsync备份
>更高层/管理层希望为每台服务器提供尽可能多的存储空间,以最大限度地降低每台服务器的SSD成本
> rsync’完成是因为GlusterFS在高小的/随机IO下没有很好地复制.
>预计将通过配置另一对如此庞大的服务器来完成扩展
>面对像旧架构中的磁盘紧缩问题,手动移动电子邮件帐户将会完成.
关注/疑虑：
>我不相信同步复制的文件系统理念适用于重随机/小IO. GlusterFS还没有为我们工作,我不确定这个用例是否还有另一个文件系统.我们的想法是保持相同的对并使用DNS循环来进行电子邮件传递和IMAP / POP3访问.如果服务器由于某种原因(计划/未计划)而关闭,我们会将IP移动到该对中的另一台服务器.
>在像Lustre这样的文件系统中,我获得了单个命名空间的优势,因此我不必担心手动迁移帐户并更新MAILHOME路径和其他元数据/数据.
问题：
>使用传统软件(courier-imapd / dovecot)扩展/缩小的典型方法是什么？
>存储在本地安装的文件系统上的传统软件是否会出现问题,以最小的“问题”进行扩展？是否必须重新编写(部分)这些以使用某种对象存储 – 例如OpenStack对象存储？
解决方法
基本上,它们会将所有存储问题从应用程序中解放出来.使用SSD或电池支持的内存缓存可以实现大量短随机读取的性能.所有存储都在一个位置,具有多个到冗余服务器模块的路径,因此没有复制延迟.
应用程序服务器使用NFS或iSCSI访问存储,这种灵活性较低,但有时需要应用程序在NFS中表现不佳.这允许存储由高速以太网上的任意数量的服务器共享,因此您可以扩展到存储盒的最大I / O性能,然后您可以根据需要进行扩展.
就应用服务器上的冗余而言,最便宜的是软件集群包.还有像Big-IP这样的设备可以在网络级别处理它并且与操作系统无关.它依赖于应用程序是否可以在NFS上与其他实例并行地可靠地工作.
