| Версия 5.2
Введение
Установка
Администрирование
Сеть
Объекты
Почта
Сигналы
Доступ
Услуги
Справочник
Кластеры
Программы
Разное
Лицензирование
Веб Почта
Pronto!
PBX
Кластеры | Статический | Динамический | Хранилище | Почта | Сигналы | Доступ | Задания
# Динамические Кластера Традиционный подход, использующий Блокировку Файлов Контроллер Кластера Файловые и Операционные системы в Кластерах Конфигурирование Backend Серверов Добавление Backend Серверов в Динамический Кластер Добавление Frontend Серверов в Динамический Кластер Общие Установки Общая Обработка Удаление Серверов из Динамического Кластера Модернизация Серверов из Динамического Кластера Хотя Статические Кластера могут использоваться для обработки очень больших сайтов, они не вполне отвечают промышленным требованием по обеспечению безотказной работы. Обслуживание набора слабо связанных Серверов также становится проблематичным по мере роста количества Серверов. Для решения этих проблем предназначены Динамические Кластера CommuniGate Pro. Они отвечают требованиям безотказной работы "пять девяток" (99,999% времени) и инфраструктура, создающая Образ Единого Сервиса, позволяет Системным Администраторам и Администраторам Домена обслуживать большие Кластерные Системы точно так же, как если бы они обслуживали односерверную систему CommuniGate Pro. Основная разница между Статическими и Динамическими Кластерами заключается в способе хранения информации о Пользователях. В отличие от Статического Кластера, в котором для каждого Пользователя существует его Хост Сервер, и только этот Сервер может получать доступ непосредственно к данным пользователя, в Динамическом Кластере все Backend Сервера могут напрямую получать доступ к данным Пользователя. Наиболее часто используемым методом для реализации в Динамическом Кластере совместно используемого Хранилища Пользователей является развёртывание Файловых Серверов или Кластерной Файловой Системы. Дополнительную информацию об Общих Файловых Системах смотрите в разделе Хранилище.

## Традиционный подход, использующий Блокировку Файлов

Многие из существующих Коммуникационных серверов могут использовать в качестве хранилища данных пользователя файловые сервера. Так как эти сервера обычно реализованы как многозадачные системы (в Unix), то в них используются одинаковые методы синхронизации как в односерверной, так и в многосерверной среде, например, такие, как механизм блокировки файлов, реализованный на уровне Операционной/Файловой системы.

Этот метод имеет следующие проблемы:

- Каждая операция с данными пользователя или данными в папке должна сопровождаться операциями блокировки/разблокировки, плюс, для обеспечения целостности данных, требуются дополнительные операции Файловой Системы. В результате, число операций Файловой Системы увеличивается в 3-5 раз и (так как скорость работы сайта обычно определяется скоростью проведения файловых операций) производительность сайта в целом существенно снижается.
- Современные Файловые Сервера либо вообще не поддерживают механизмы блокировки файлов, либо используют существенно ограниченные версии таковых механизмов, что приводит к тому, что наиболее важная часть сайта - хранение данных пользователя - становится ненадёжной и подверженной сбоям.
- Сбои в работе одного из серверов могут (из-за взаимной блокировки) привести к остановке всего сайта, превратив восстановление работоспособности системы в чрезвычайно сложную задачу.
- Одновременный доступ нескольких клиентов к данным одного пользователя или одной папки также становится невозможным или ненадёжным.

В попытке уменьшить отрицательное влияние блокировки файлов, некоторые из серверов Сообщений поддерживают только формат папки MailDir (один файл на сообщение) и полагаются на "атомарную" природу операций в файловой директории (а не на блокировки файлов). Подобный подход, позволяя в теории решить некоторые из описанных проблем (хотя в реальных ситуациях это едва ли помогает) ведёт к не экономному использованию ресурсов файлового сервера и сильно перегружает внутренние таблицы файловой системы.
Производительность Файловых Серверов сильно снижается, если приложение использует много маленьких файлов вместо нескольких больших.

Хотя простые методы кластеризации, основывающиеся на возможностях параллельного доступа Операционной/Файловой системы работают нормально для Веб Серверов (где данные изменяются не слишком часто), они не работают сколько-нибудь удовлетворительным образом для серверов Сообщений, где общий объём изменяемых данных почти совпадает с объёмом получаемых данными.

Простая Кластеризация не даёт никакого дополнительного выигрыша (например, на создаёт Образ Единого Сервиса), так что администрирование 30-серверного кластера становится даже более трудоёмким, чем администрирование 30 независимых Серверов.

Программное обеспечение CommuniGate Pro поддерживает возможность Внешний INBOX, так что основанная на файлах кластеризация так же может быть реализована в системах с CommuniGate Pro. Но, ввиду описанных выше проблем, настоятельно рекомендуется избегать решений такого типа и использовать вместо них настоящий Динамический Кластер CommuniGate Pro.

## Контроллер Кластера

Сервера CommuniGate Pro входящие, в Динамический Кластер, не используют механизмы блокировок Операционной/Файловой Системы для синхронизации операций доступа Пользователей. Как и в Статическом Кластере, только один Сервер в Динамическом Кластере имеет прямой доступ к любому отдельно взятому Пользователю в некоторый произвольный момент времени. Все другие Сервера, если они хотят получить доступ к этому Пользователю, работают через этот Сервер. Но это назначение не является статическим: любой сервер может открыть напрямую данные любого Пользователя, если этот Пользователь не открыт каким-либо другим Сервером.

Такая архитектура обеспечивает максимальное время бесперебойной работы: сбой, происшедший на Backend Сервере, не приводит к остановке работы - все Пользователи смогут работать через другие Backend Сервера без какого бы то ни было ручного вмешательства и без простоя системы. Сайт будет продолжать работать и обеспечивать доступ ко всем Пользователям до тех пор, пока будет работать хотя бы один Backend Сервер.

Один из Backend Серверов в Динамическом Кластере действует как Контроллер Кластера.. Он синхронизирует все другие Сервера в Кластере и выполняет операции по созданию Общих Доменов, созданию и удалению пользователей в общих доменах и т.п. Контроллер Кластера также обеспечивает функциональность Образа Единого Сервиса: но только пользователь сайта, но также и администратор сайта может соединиться с любым из серверов в Динамическом Кластере и выполнить любую операцию с Пользователем (даже если в это же время Пользователь открыт на другом Сервере) или с Доменом (произвести изменение Установок Домена) и все произведённые изменения автоматически будут использоваться всеми Серверами, входящими в Кластер.

Обратите внимание: распространение на все Сервера, входящие в Кластер, большинства изменений на уровне Домена, таких, как изменение Установок Домена, Установок Пользователя по Умолчанию, Установок Веб Интерфейса Пользователя и Предупреждений уровня Домена может занять до 30 секунд. Изменения уровня Пользователя вступят в силу на всех Серверах немедленно.

Контроллер Кластера собирает от Backend Серверов информацию о загрузке. Когда Frontend Сервер получает запрос на установление сессии с Пользователем, который в это время не открыт ни на каком Backend Сервере, Контроллер направляет Frontend Сервер на наименее загруженный Backend Сервер. Такая вторичная балансировка нагрузки для Backend Серверов основывается на их фактическом уровне загрузки и дополняет основную балансировку нагрузки (через циклический DNS или по трафику) Frontend Серверов.

Если в Динамическом Кластере есть два или более Backend Сервера, то Контроллер Кластера назначает обязанности Запасного Контроллера на один из оставшихся Backend Серверов. Все остальные члены Кластера поддерживают соединения с Запасным Контроллером. Если Запасной Контроллер прекращает работу, то в качестве Запасного Контроллера выбирается какой-либо другой Backend Сервер.

Если основной Контроллер прекращает работу, то активным Контроллером Кластера становится Запасной Контроллер. Все Сервера отправляют информацию ресинхронизации на Запасной Контроллер и Кластер продолжает работу без остановок.

Хотя Динамический Кластер может обслуживать Справочник с записями о Пользователях, функциональность Динамического Кластера не полагается на Справочник. Если Справочник все же используется, то он должен быть реализован как Общий Справочник.

Полная конфигурация Frontend-Backend Динамического Кластера использует также Балансировщик Нагрузки и работает в нескольких отдельных сетях:

Так как все Backend Сервера в Динамическом Кластере имеют прямой доступ к данным Пользователя, то они должны работать под управлением операционной системы, использующей одинаковые правила относительно EOL (конца строки). Это означает, что все Backend Сервера должны работать либо под управлением ОС семейства Unix, либо они должны работать под управлением ОС семейства Windows. Frontend Сервера не имеют прямого доступа к данным Пользователя и, следовательно, вы можете использовать для Frontend Серверов любую ОС (например, на сайте могут использоваться какая-нибудь из ОС Unix на Backend Серверах и Microsoft Windows на Frontend Серверах).

## Файловые и Операционные системы в Кластерах

Некоторые из современных операционных систем обладают встроенным возможностями для Кластеризации. Большинство из этих возможностей Кластеризации предназначены для того, что бы облегчить портирование "обычных", не кластерных приложений на эти Кластерные платформы. Но некоторые из возможностей, предоставляемые этими ОС, очень полезны для реализации Динамического Кластера CommuniGate Pro.

Эти возможности включает в себя:

- Кластерную Файловую Систему
- IP Псевдонимы

Кластерная Файловая Система позволяет всем Серверам в Кластере ОС монтировать и использовать единую файловую систему на совместно используемых устройствах. В отличие от Сетевой Файловой Системы (NFS), в Кластерной Файловой Системе отсутствует требование на выделенный сервер в сети. Кластерная Файловая Система может использовать множественные SCSI соединения, предоставляемые некоторыми устройствами хранения SCSI верхнего уровня, которые позволяют каждому Серверу обмениваться данными непосредственно с устройствами хранения через SAN (Storage Area Network, Сеть хранения данных). Для обеспечения целостности системы, Кластерная Файловая Система использует высокоскоростные межсерверные соединения.

SAN протоколы очень эффективны для передачи файлов и Кластерная файловая Система может обеспечить лучшую производительность, чем Сетевая Операционная Система.
Кластерные Файловые Системы могут также обеспечить более высокую надёжность, чем односерверные NFS решения (где NFS сервер является единственной точкой сбоя).
Дополнительную информацию смотрите в разделе Хранилище.

Возможность назначения Псевдонимов для IP позволяет ОС Кластера равномерно распределять нагрузку на сеть между Серверами Кластера, не добавляя отдельное устройство, балансирующее нагрузку.

Динамический Кластер CommuniGate Pro, в котором есть "только Backend Сервера", может использовать обе возможности, предоставляемые Кластерной ОС: Псевдонимы IP используются для равномерного распределения нагрузки между Серверами CommuniGate Pro, а сами Сервера CommuniGate Pro используют Кластерную Файловую Систему для хранения всех данных пользователя в общем Домене:

Кластерная ОС может также использоваться в конфигурациях CommuniGate Pro с Frontend/Backend Серверами. В этом случае одна Кластерная ОС используется для Frontend Серверов CommuniGate Pro, задействуя Псевдонимы IP для равномерного распределения нагрузки, а вторая Кластерная ОС используется для Backend Серверов CommuniGate Pro, на которых активирована Кластерная Файловая Система:

Конфигурация Динамического Кластера CommuniGate Pro не зависит как от типа используемого балансировщика нагрузки (отдельный или Псевдонимы IP), так и от типа Общей Файловой Системы (Сетевая Файловая Система или Кластерная Файловая Система).

## Конфигурирование Backend Серверов

Для того, что бы установить Динамический Кластер, выполните следующие действия:

- Установите и сконфигурируйте программное обеспечение CommuniGate Pro на всех Серверах, которые должны войти в Динамический Кластер.
- Откройте через Веб Интерфейс Администратора страницу Установки->Доступ и измените настройки услуги PWD. Каждый член Кластера (Backend и Frontend) открывает два PWD соединения с Контроллером Кластера, так что максимальное число каналов должно быть увеличено как минимум на
    `2* (число Backend Серверов + число Frontend Серверов)`
  Так как дополнительные PWD соединения могут открываться Frontend и Backend серверами для облуживания административных запросов и запросов пользователя, лучше увеличить число каналов на:
    `5* (число Backend Серверов) + 3*(число Frontend Серверов)`
- Откройте в Веб Интерфейсе Администратора страницу Установки->Общее->Кластер и введите IP адреса всех Backend и Frontend Серверов в Кластере.
- Остановите все Сервера.
- Создайте файловую директорию, в которой будут находится Общие Домены. Вы должны создать эту файловую директорию на таком устройстве хранения, которое будет доступно для всех Backend Серверов в Кластере (например, на файловом сервере). Поместите ссылку на эту директорию в директории данных CommuniGate Pro и назовите эту ссылку `SharedDomains`. Убедитесь, что все Backend Сервера имеют полные права доступа и могут создавать, удалять, читать и изменять файлы и директории внутри директории SharedDomain.

  Обратите внимание: если создание символьной ссылки является проблематичным (как, например, на платформах MS Windows), то вы должны указать месторасположение "смонтированной" файловой директории в опции `--SharedBase` в Командной Строке:
    `--SharedBase H:\Base`
- Если вы мигрируете с односерверной конфигурации, вы можете сделать какие-либо из существующих доменов общими и они будут обслуживаться всем Кластером. В этом случае, вам необходимо передвинуть директорию с доменом из директории `{base}/Domains` в директорию `{base}/SharedDomains` (размещённую на совместно используемом устройстве хранения).
- Измените опции Запуска для каждого из ваших Backend Серверов так, что бы у всех у них в Командной Строке присутствовала опция `--ClusterBackend`.
- Запустите один из ваших Backend Серверов.

Используйте Веб Интерфейс Администратора этого первого Backend Сервера что бы убедится, что Контроллер Кластера работает. Откройте страницу Домены и проверьте, что:

- сервер видит все домены, которые вы поместили в директорию SharedDomains;
- Рядом с кнопкой Создать Домен теперь имеется кнопка Создать Домен в Динамическом Кластере.

Используйте кнопку Создать Домен в Динамическом Кластере, что бы создать дополнительные Общие Домены, которые будут обслуживаться Динамическим Кластером.

После того, как Контроллер Кластера работает, сайт может начинать обслуживание клиентов (если вы не используете другие Frontend Сервера). Если в вашей конфигурации развёрнуты также и Frontend Сервера, то как минимум один из них должен быть запущен.

## Добавление Backend Серверов в Динамический Кластер

Вы можете добавить дополнительные Backend Сервера в Кластер в любой момент. Они должны быть сконфигурированы точно также, как был сконфигурирован первый Backend Сервер.

Для того, что бы добавить Backend Сервер в ваш Динамический Кластер, запустите его с параметром Командной Строки `--ClusterBackend` (этот параметр может быть добавлен в сценарий автоматического запуска CommuniGate Pro). Сервер будет опрашивать все указанные IP адреса Backend Серверов до тех пор, пока он не обнаружит Активный Контроллер Кластера.

Используйте Веб Интерфейс Администратора, что бы убедится, что Backend Сервер работает. Используйте страницу Домены, что бы проверить, что Сервер видит все Общие Домены и что вы можете управлять пользователями в Общих Доменах.

Если работает Контроллер Кластера и как минимум один Backend Сервер, то они оба могут обслуживать всех пользователей Общих Доменов. Если вы не используете Frontend Сервера, то балансировка нагрузки должна быть реализована через обычный коммутатор, балансирующий нагрузку, циклический DNS или подобные им техники, равномерно распределяющие входящие запросы между всеми Backend Серверами.

## Добавление Frontend Серверов в Динамический Кластер

Вы можете добавить дополнительные Frontend Сервера Кластер в любой момент.

Установите и сконфигурируйте программное обеспечение CommuniGate Pro на компьютере с Frontend Сервером. Так как Frontend Сервера не имеют прямого доступа к данным Пользователя, то, соответственно, нет необходимости делать директорию SharedDomains доступной ("смонтированной" или "отображённой") для какого бы то ни было Frontend Сервера.

Используя в Веб Интерфейсе Администратора Frontend Сервера страницу Установки->Общее->Кластер, укажите адреса всех Backend Серверов.

Для того, что бы добавить Backend Сервер в ваш Динамический Кластер, остановите его (сервер) и перезапустите его с параметром Командной Строки `--ClusterFrontend` (этот параметр может быть добавлен в сценарий автоматического запуска CommuniGate Pro). Сервер будет опрашивать все указанные IP адреса Backend Серверов до тех пор, пока он не обнаружит Активный Контроллер Кластера.

Используйте Веб Интерфейс Администратора этого Frontend Сервера что бы убедится, что он работает. Используйте страницу Домены что бы проверить, что Сервер видит все Общие Домены.

Когда Frontend Сервера пытаются открыть данные одного из Пользователей Общего Домена, Контроллер направляет их на один из Backend Серверов, равномерно распределяя нагрузку между всеми доступными Backend Серверами.

## Общие Установки

Для Общих Доменов Динамический Кластер имеет отдельный набор "Установок по Умолчанию" .

Эти установки включает в себя:

- Умолчания для Домена для всех Общих Доменов
- Установки Пользователя по Умолчанию и Настройки Веб Интерфейса Пользователя по Умолчанию для всех в Общих Доменов
- Общекластерные Предупреждения - эти предупреждения отправляются всем Пользователям в Общих Доменах

Когда Администратор Сервер использует Веб Интерфейс Администратора для изменения этих установок, то на страницах Веб Администрирования отображается ссылка, позволяющая Администратору переключатся между установками, Общими для Сервера (которые применяются для всех не Общих Доменов) и установками, Общими для Кластера. Установки, Общие для Кластера, автоматически изменяются на всех членах Кластера и применятся для всех Общих Доменов.

Общие для Кластера Установки также включают в себя:

- Общие для Кластера Установки Сети.
- Общие для Кластера Таблицы Маршрутизации.
- Общие для Кластера Установки Центрального Справочника.
- Общие для Кластера Правила.
- Общие для Кластера Установки Защиты.
- Общие для Кластера Именованные и применяемые по умолчанию Виды Интерфейса. Эти Виды Интерфейса используются по умолчанию для Видов Интерфейса в Общих Доменах.
- Общие для Кластера Приложения Реального Времени.
- Общие для Кластера настройки СОРМ - перехвата сообщений.

## Общая Обработка

Компонент Образ Единого Сервиса Динамического Кластера обеспечивает синхронизацию Установок Пользователей, Установок Доменов и ряда других настроек.

Дополнительная функциональность "общей обработки" включает в себя также:

- Общее для Кластера освобождение очереди SMTP (через команду ETRN или сообщение пробуждения).
- Общая для Кластера синхронизация знаков Аутентификации (nonce).

## Удаление Серверов из Динамического Кластера

Для удаления Серверов из Динамического Кластера используйте Веб Интерфейс Администратора. Откройте страницу Кластеры в области Наблюдение и нажмите на кнопку Убрать Готовность.

Когда Frontend Сервер не находится в состоянии Готовности, все его UDP порты и все его TCP порты (кроме портов, используемых для Администрирования по HTTP) закрываются.
Балансировщик нагрузки, доставляющий входящие соединения на Frontend Сервер, должен обнаружить это состояние и прекратить отправку соединений и пакетов на этот Frontend Сервер.

Когда Backend Сервер не находится в состоянии Готовности, Контроллер не отправляет на этот Сервер новые сессии. Подождите окончания всех существующих сессий и выключите Backend Сервер.

Если Backend Сервер является Активным Контроллером, то перевод его из состояния Готовности заставит Контроллер отправлять все новые сессии на другие Backend Сервера. Если в Кластере нет других Backend Серверов, то Контроллер будет продолжать самостоятельно обслуживать новые сессии.

Вы можете нажать на кнопку Установить Готовность на этой же странице для того, что бы заново включить Сервер. Если Сервер является Backend Сервером, то Контроллер начинает отправлять на него новые сессии.

Вам необходимо иметь права доступа "Может управлять Кластером" для того, что бы устанавливать или сбрасывать Готовность.

Если Backend Сервер заканчивает работу из-за сбоя, то все Пользователи Общего Домена, открывшие на этом Сервер свои сессии, не смогут работать в результате сбоя . Они смогут продолжить работу снова через 5-10 секунд, когда Контроллер Кластера обнаружит этот сбой. Сбой в работе Backend Сервер не приводит к потере данных.

## Модернизация Серверов из Динамического Кластера

Динамический Кластер создавался таким образом, что бы сделать возможным плавную модернизацию всех входящих в него серверов. Для установки более новой версии программного обеспечения CommuniGate Pro вы должны обновлять сервера один за одним, поочерёдно: сначала уберите сервер из Кластера, затем обновите программное обеспечение и снова добавьте сервер обратно в Кластер. Эта процедура позволяет вашему сайту работать без остановок во время обновления.

Определённые изменения в программном обеспечении CommuniGate Pro могут накладывать определённые ограничения на процесс "плавной модернизации". Всегда проверяйте раздел История перед тем, как обновить ваш Кластер и убедитесь, что там отсутствуют ограничения на Обновления Обновления Кластера.

Руководство CommuniGate® Pro. Copyright © 1998-2009, Stalker Software, Inc.