Регистрация...

Eserv Forum / E4 / Mail / отказоустойчивость почтового сервера

recent wikipost // (v1)
Продукты и услуги Скачать Документация Купить Поддержка Форумы Партнёрам Статьи О компании
Одновременно с переползанием с E3 на E4 проверяю разные стороны работоспособности Eserv в рамках требований, сформулированных нач-м...
Один из аспектов — варианты реализации отказоустойчивости почтового сервера на платформе Eserv4. Т.е. например — самый тяжёлый вариант — сломался комп-сервер, или серверная вдруг стала обесточена, в праздники, надолго...
Как в этом случае правильно организовать резервирование сервиса? У кого-нибудь есть практический опыт?
Я попытался реализовать это в виде NLB-кластера с перемещением папки DATA в DFS.
Т.е. прописал
[Dirs]
Data=\\mmm-dmz.mydomen.ru\data-mail\E4DATA
Stat=..\DATA\stat — т.е. локально, иначе вообще не стартует.
HTTP=..\DATA\http — т.е. локально, иначе вообще не стартует.

Перезапустил сервисы — вроде всё работает. Почта отправляется и принимается. Но в acIMAP.log с интервалом в 1 сек (примерно) непрерывно пишется сообщение
FSM err=87 FSM err=87 ...
это он о чём?
И в acFilter.log аналогично.

Далее запускаю сервисы на втором узле и пытаюсь работать одновременно через оба узла кластера. Почти сразу-же acSMTP пишет в лог
EXCEPTION! CODE:C0000006 ADDRESS:6090D4B7 WORD:<?not found> USER DATA: 0455057C THREAD ID: 00000B3C HANDLER: 02C4ED6C ** Exception time: Fri, 20 Dec 2013 12:39:29 +0800 ** Thread number/reuse/id:6 0 2876 ** API Calls: GetTickCount sqlite3_prepare_v2 STACK: (1509) 6090D939 02C4E834 60961D30 00000094 60920D21 02C4E8D4 [029A0000] RETURN STACK: ....... и далее на все письма строчки вида Can't add message into index. ERR=30000 \\mmm-dmz.mydomen.ru\data-mail\E4DATA\mail\arc4\201312\2013-12-20\\вырезано.eml Или в другом случае строчки вида INJ ERR:30011 database disk image is malformed Delivery err=30005 Т.е. что, все так безнадёжно, или как-то можно выкрутиться в этой ситуации?
 
Комментарии к этой версии (20.12.2013 13:33) [~pavlad] af655f6f
Комментарии к версии 2 (20.12.2013 13:37) [~pavlad] ce3720d7
АвторДатаТекстtags
ac20.12.2013 19:47
Да, на сетевой файловой системе SQLite нормально работать не будет...

Классическая схема резервирования для SMTP — это дополнительные MX (с меньшим приоритетом). Доставка в SMTP так устроена, что при недоступности серверов перебирает MX'ы домена получателя по указанным в DNS приоритетам. Если у вас два MX, то при поломке одного почта пойдёт на запасной и будет там помещаться в очередь для доставки на основной, когда тот починится. Там тоже можно поставить Eserv. Если основной ломается надолго, то можно на втором организовать раздачу почты.

Правда эта схема не предусматривает раздачу старой почты, которая шла на первый MX, когда тот еще работал — она станет недоступной вместе с ним. Если это недопустимо, то можно делать "сквозной" первый MX, чтобы он дублировал всю проходящую почту на второй. Тогда почтовые архивы будут на обоих.
wikipost
pavlad21.12.2013 07:49
ac пишет: резервирования для SMTP — это дополнительные MX

Ну это очень частный случай — и только для Входящего потока.
А у меня стоит задача обеспечения непрерывности функционирования именно СЕРВИСа "Электронная почта" в рамках предприятия, это и SMTP и POP3 и IMAP. Т.е. к примеру временный выход из строя одной серверной не должен приводить к отказу предоставления сервиса пользователям, если все остальные части сети продолжают функционировать. И одновременно с этим данные в ящиках пользователей должны быть максимально актуальны. Единственное, что пришло мне на ум на платформе Wndows — это NLB кластеризация. Всё прекрасно работает, и почтовый сервис на Eserv тоже. За малым неудобством — полное отсутствие синхронизации каких-либо данных между серверами, поскольку все их данные сугубо локальны.

ac пишет: на сетевой файловой системе SQLite нормально работать не будет...

Судя по проведённому эксперименту — проблема проявляется не столько при расположении на сетевой файловой системе, сколько при монополизации доступа к файлам процессами почтового сервера.
wikipost
ac22.12.2013 15:44
pavlad пишет: Судя по проведённому эксперименту — проблема проявляется не столько при расположении на сетевой файловой системе, сколько при монополизации доступа к файлам процессами почтового сервера.

Так это связанные явления: как раз монополизация доступа (блокировки файлов) плохо работает на сетевой ФС. И прежде всего именно для БД это и требуется. Также странности возникают при отображении файлов в память. В Eserv это используется для встроенной статистики. И в SQLite тоже используется для взаимодействия между его потоками в разных процессах, если я правильно понимаю назначение е shm-файлов.
wikipost
Работает на Eserv/5.05567 (10.02.2020)