CommuniGate Pro Передача Пошти у Кластерах

У цьому розділі пояснюється, як працює Передача Поштових Повідомлень у кластерному середовищі CommuniGate Pro.

Релеїнг з SMTP

кластерах

Місцева доставка

Повідомлення, яке надсилається локальному користувачеві, може бути поставлене в чергу на "неправильний" Сервер, тобто на Сервер, який не може відкрити дані потрібного Користувача та надіслати йому повідомлення.

Така ситуація може виникнути, якщо повідомлення встановлюється в чергу на Frontend Сервері (Frontend Сервера не можуть безпосередньо відкривати дані Користувача в Загальних Доменах), або якщо повідомлення встановлюється в чергу на Backend Сервері, який не є Хост Сервером для потрібного користувача (Статичний кластер) або не може відкрити його дані, тому що вони відкриті на будь-якому іншому Backend Сервері (динамічний кластер).

Для того, щоб вирішити цю проблему, модуль Місцевої Доставка використовує з'єднання по каналу доставки з правильним Backend Сервером і передає йому повідомлення. Сервер, що отримує Backend, негайно відкриває дані потрібного Користувача, застосовує його Правила рівня Користувача і зберігає передане повідомлення. Цей Backend Сервер не встановлює повідомлення у чергу.

Якщо при доставці повідомлень виникає збій або інша тимчасова проблема, то сервер, що отримує Backend, повідомляє відправника про помилку і повідомлення або затримується в Черзі, або видаляється з Черги (у цьому випадку генеруються повідомлення про помилку).

кластерах

Черги на Backend Серверах

Веб Інтерфейсу Користувача, XIMSS, сесії MAPI, Правила та інші модулі та компоненти можуть створювати на Backend Серверах повідомлення електронної пошти.

Backend Сервер часто не має прямогодоступу до Інтернету і, у разі, він може доставляти створені повідомлення на віддалені системи. Для вирішення цієї проблеми Backend Сервера можуть бути за допомогою символу *, заданого як ім'я Сервера, що пересилає SMTP, налаштовані на релеїнг всіх повідомлень на Frontend Сервера.

У цьому випадку, повідомлення надходить до Черги Backend Сервера, де воно обробляється з використанням Загальносерверних і Загальнокластерних Правил і, якщо воно не надсилається локальному одержувачу, воно надсилається в SMTP модуль, який передає його одному з Frontend Серверів:

кластерах

За такої конфігурації кожне створене на сервері Backend повідомлення обробляється двічі. Якщо в Кластерних Правилах використовуються Додаткові Модулі, що аналізують вміст повідомлення, то подвійна обробка може споживати велику кількість ресурсів системи.

Для того, щоб цього уникнути, може використовуватися метод обробки видаленої черги.

Обробка Видалених Черг

Більшість роботи з обробки Черги відбувається на Frontend Серверах. Frontend Сервера приймають вхідні повідомлення по SMTP і, або ретранслюють їх далі, або, за допомогою спеціального протоколу внутрішньо-кластерної взаємодії, доставляють їх локальним Користувачам на Backend Сервера, не розміщуючи їх у Черзі Backend Серверів.

Деяка кількість повідомлень може створюватись безпосередньо на Backend Серверах.

Такі повідомлення включають:

  • створені у Веб Інтерфейсі Користувача, XIMMS, AirSync, CalDAV сесії;
  • повідомлення, що надійшли через MAPI-Коннектор та механізми XTND XMIT протоколу POP3;
  • повідомлення, створені Правилами рівня Користувача;
  • повідомлення, одержані модулем RPOP;
  • повідомлення, що надійшли черезмодуль PIPE.
Можливо, з різних причин ви захочете уникнути обробки на Backend Серверах Черг Повідомлень, наприклад:
  • відсутність з'єднання з Інтернетом на Backend Серверах;
  • необхідність використання Додаткових Модулів боротьби зі спамом та з вірусами, встановленими тільки на Frontend Серверах;
  • брак обчислювальної потужності та/або дискового простору на Backend Серверах.

Ви також можете обробляти Черги повідомлень тільки на деяких з серверів Frontend.

Для того, щоб вказати опції Обробки Черги, відкрийте через Веб Інтерфейс Адміністратора область Налаштування та виберіть на сторінці Загальне посилання Кластери. Знайдіть панель Обробки Черги:

Надсилання повідомлень Ця настройка вказує, як сформовані або отримані повідомлення електронної пошти надсилаються до компонента Установка до Черги для подальшої доставки. Локально повідомлення передаються в компонент Установка в Чергу того ж Сервера (це звичайний, односерверний режим обробки). Локально для Інших повідомлення передаються до компоненту Встановлення до Черги того ж Сервера. Контролер Динамічного Кластера інформується про те, що цей Сервер може приймати (ставити в чергу) повідомлення електронної пошти, створені або отримані іншими членами Кластера. Контролер Динамічного Кластера збирає та розповсюджує інформацію про всіх активних членів Кластера, у яких обрано цю опцію. Віддалено повідомлення передаються тому члену Кластера, у якого це налаштування має значення Локально для Інших. Вміст тимчасових файлів повідомлень (конверт повідомлення та повідомлення) надсилається іншому члену Кластера за спеціальним протоколом через порт SMTP. Якщо повідомлення не вдається надіслати (Сервер не змігз'єднатися з членами Кластера або передача файлу повідомлення закінчилася неуспішно) те, щоб повідомлення не було втрачено, воно надходить у чергу Сервера: