Комментарии 5
Статья имеет место быть как описание фичи, но вопрос, как это решает озвученную проблему, что есть сервер, которому плохо и на котором "не ходят" письма? Трафика на сервере меньше не стало, появилось только ещё одно промежуточное звено. Проблему решают дополнительные сервера
Спасибо за комментарий, действительно, стоило подробнее описать архитектуру решения. У меня в планах написать ещё одну статью по теме, чтобы раскрыть не только распределение пользователей по почтовым серверам, но и описать работу почтовых шлюзов в сочетании с mail proxy для доставки писем. В контексте данной статьи я показал именно то, что вы описываете, развёртывание дополнительного сервера без влияния на текущую инфраструктуру (Подразумевается, что у вас уже есть настроенная почтовая система, присутствует некий pipeline для обработки писем, но, например, закончилось место для ящиков или медленно работает поиск по письмам). Если вы хотите избавиться от единой точки отказа или распределить трафик по серверам, вы можете развернуть N прокси с nginx, сделать Round-robin DNS для них. Если попытаться развернуть ещё один почтовый сервер без использования решения для маршрутизации пользователей, как, например, описанного в этой статье, вы столкнётесь с синхронизацией содержимого почтовых ящиков, что не всегда может быть удобно. В случае же "умного" проксирования, каждый из почтовых серверов будет загружен только теми пользователями и задачами, которые непосредственно на нём присутствует, что в конечном счёте позволит использовать меньше ресурсов для достижения той же цели.
Сильно понятнее не стало. :) Во-первых, любая вменяемая корпоративная почтовая система уже имеет то самое "решение для маршрутизации писем" (оно же MTA) в качестве составной части, и дополнительный сервер для хранения новых п/я обычно вполне себе прозрачно разворачивается штатно.
Во-вторых, задачу "медленно работает поиск по письмам" даже добавление доп. сервера само по себе не способно решить принципиально, потому что письма уже лежат там, где лежат, и от того, что новые вы начнете класть куда-то еще, с имеющимися ситуация не изменится. И как тогда в итоге ваше элегантное решение заменит "архивный почтовый сервер, перекинуть туда письма старше N лет, сделать скрипты перемещения на основном, но это не для нас" (с), о чем вы прямо с начала пишете? :)
В-третьих:
В случае же "умного" проксирования, каждый из почтовых серверов будет загружен только теми пользователями и задачами, которые непосредственно на нём присутствует, что в конечном счёте позволит использовать меньше ресурсов для достижения той же цели.
Нет. Роль сервера п/я и так загружена "только пользователями, которые на нем присутствуют", ибо других п/я на нем просто нет. :) А роли МТА или клиентского доступа - вообще отдельный слой, могущий работать и на тех же серверах, и отдельно, и вопрос, выгоднее ли их комбинировать с мэйлбоксами или разносить отдельно, сильно зависит от конкретики, тут нет какого-то единственно верного решения, которое позволит "использовать меньше ресурсов".
По сути вы начинаете описывать сценарий "у нас был одинокий почтовик-комбайн, масштабирование никто не продумывал и не закладывал, что же теперь делать?"
Да! Основной вопрос как раз к вменяемости корпоративной почтовой системы :)
В общем случае не во всех почтовых серверах имеются возможности масштабирования из коробки, и, просто развернуть ещё один сервер для почтовых ящиков не всегда возможно, отсюда и упоминание "синхронизации" в комментарии выше.
Не рассматривал в статье MTA, так как доставку писем на нужный сервер можно реализовать множеством способов и без Nginx. Речь идет именно о пользовательских почтовых ящиках и распределению пользователей по серверам, с минимальным вмешательством. Это как раз позволяет сделать imap прокси. При этом мы достигаем большой гибкости и не становимся зависимыми от платформенных почтовых решений, что может быть критично.
Также нужно уточнить, что всё равно потребуется перенос ящиков (если у нас уже перегруженный сервер) при добавлении нового почтового сервера, однако, можно будет отложить\избежать создания архивного сервера, оставив принцип "одного окна" для пользователей.
Надеюсь стало немного понятнее)
Спасибо.
Вот бы в nginx proxy manager завезли поддержку mail.
NGINX Mail Proxy: на пути к INBOX