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

发布时间：2020-12-13 17:25:11 所属栏目：Linux 来源：网络整理

导读：我尝试过的：我有两个电子邮件存储架构.新旧. 旧：几个(18)1TB存储服务器上的courier-imapds. 如果其中一个显示磁盘空间不足的迹象,我们会将一些电子邮件帐户迁移到另一台服务器. 服务器没有副本.也没有备份. 新： dovecot2在单个巨大的服务器上,具有16TB(

我尝试过的：

>我有两个电子邮件存储架构.新旧.

旧：

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

解决方法

我在大中型公司看到的是冗余存储设备,如NetApp或EMC.事实上,我刚刚与一位关于电子邮件存储的EMC代表谈过,他说巨大的电子邮件服务器对他们来说非常普遍.

基本上,它们会将所有存储问题从应用程序中解放出来.使用SSD或电池支持的内存缓存可以实现大量短随机读取的性能.所有存储都在一个位置,具有多个到冗余服务器模块的路径,因此没有复制延迟.

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

就应用服务器上的冗余而言,最便宜的是软件集群包.还有像Big-IP这样的设备可以在网络级别处理它并且与操作系统无关.它依赖于应用程序是否可以在NFS上与其他实例并行地可靠地工作.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!