Что я пробовал:
Старый:
Новое:
Опасения / сомнения:
Вопросы:
То, что я видел в компаниях среднего и крупного размера, - это избыточные устройства хранения, такие как NetApp или EMC. На самом деле, недавно я разговаривал с представителем EMC о хранении электронной почты, и он сказал, что огромные почтовые серверы - обычное дело для них.
По сути, они снимают с приложения все проблемы с хранением. Производительность для большого количества коротких случайных чтений достигается с помощью SSD или кеш-памяти с резервным питанием от батареи. Все хранилище находится в одном месте с несколькими путями к избыточным серверным модулям, поэтому нет задержки репликации.
Серверы приложений обращаются к хранилищу с помощью NFS или iSCSI, что менее гибко, но иногда требуется приложению, которое плохо себя ведет с NFS. Это позволяет использовать хранилище для любого количества серверов по высокоскоростной сети Ethernet, поэтому вы можете масштабировать до максимальной производительности ввода-вывода хранилища, которую затем можно расширять по мере необходимости.
Что касается резервирования серверов приложений, то самым дешевым является пакет программной кластеризации. Также существуют такие устройства, как Big-IP, которые обрабатывают его на уровне сети и не зависят от ОС. Это сильно зависит от того, сможет ли приложение надежно работать через NFS параллельно с другими экземплярами.
Я немного опасаюсь подхода «большого железа» - его часто сложно масштабировать, и люди склонны применять подход построения решения аварийного переключения и надеяться, что оно сработает, когда произойдет сбой. Большинство людей давно перестали применять этот подход к таким компонентам, как диски и сетевые карты, но применить его к серверам немного сложнее. Вы можете сегментировать данные, разделив пользователей через LDAP, но это напрямую решает проблему репликации, однако при работе, скажем, с 8 парами серверов с балансировкой нагрузки конкуренция, вероятно, будет значительно меньше. Конечно, glusterFS IMHO плохо работает в высокотранзакционных системах. Я также не думаю, что система ближнего типа (например, AFS) - тоже хорошая идея. Проблема в том, что есть много мелких изменений, которые необходимо выполнять на всех зеркалах синхронно - и на самом деле это лучше всего делать на уровне приложения, чтобы поддерживать согласованность /
Хотя Dovecot предназначен для работы с несколькими серверами в общем хранилище, подход типа NFS / iscsi по-прежнему подразумевает подход типа SPOF или аварийного переключения, а не балансировку нагрузки. Я слышал много хороших отзывов о GFS2 для транзакционных рабочих нагрузок - и если сократить до меньших систем, то запуск этого поверх DRBD даст требуемую репликацию. Но постарайтесь изолировать пары на выделенных коммутаторах (или используйте перекрестные соединения Ethernet), чтобы снизить шум в основной сети.
То есть я с сожалением вынужден сказать, что хотя dovecot, вероятно, намного лучше, чем курьер для этого типа операций, я думаю, что ваша новая архитектура - это шаг назад.
(Я предполагаю, что вы используете maildir, а не mbox)
Я согласен с тем, что наличие фиксированного набора сопоставлений пользователей с кластерами - это немного накладные расходы - и не самое эффективное использование доступного ресурса - возможно, лучшим компромиссом может быть LVS поверх GFS2 SAN и позволить SAN обрабатывать к репликации. Для более дешевого решения, хотя это много предположений и потребует некоторого исследования / тестирования, возможно, запуск файловой системы FUSE с серверной частью базы данных - и использование функции репликации базы данных (например, mysqlfs)
В дополнение к работе с серверной частью, которую вы выполняете, вы можете исследовать прокси imap в Nginx. Он был разработан, чтобы позволить вам маршрутизировать подключения пользователей к определенным внутренним серверам. Это может быть проще, чем пытаться перенести данные пользователя, чтобы сбалансировать трафик и нагрузку ввода-вывода.