Динамические Кластеры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2* (число Бэкенд-Серверов + число Фронтенд-Серверов)

  Так как дополнительные PWD соединения могут открываться Фронтенд и Бэкенд серверами для обслуживания административных запросов и запросов пользователя, лучше увеличить число каналов на:

  5* (число Бэкенд-Серверов) + 3*(число Фронтенд-Серверов)

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

  Обратите внимание: если создание символьной ссылки является проблематичным (как, например, на платформах MS Windows), то вы должны указать месторасположение "смонтированной" файловой директории в опции --SharedBase в Командной Строке:

  --SharedBase H:\Base

• Если вы мигрируете с односерверной конфигурации, вы можете сделать какие-либо из существующих доменов общими, и они будут обслуживаться всем Кластером. В этом случае, вам необходимо передвинуть директорию с доменом из директории {base}/Domains в директорию {base}/SharedDomains (размещённую на совместно используемом устройстве хранения).
• Измените опции Запуска для каждого из ваших Бэкенд-Серверов так, чтобы у всех у них в Командной Строке присутствовала опция --ClusterBackend.
• Запустите один из Бэкенд-Серверов.

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

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

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

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

Вы можете добавить дополнительные Бэкенд-Серверы в Кластер в любой момент. Они должны быть настроены точно также, как был настроен первый Бэкенд-Сервер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Обработка периодических общекластерных задач Chronos.
• Распределённая обработка Очереди.
• Распределённая обработка Сигналов.
• Распределённая обработка задач RPOLL и RSIP.
• Общекластерное освобождение очереди SMTP (через команду ETRN или сообщение пробуждения).
• Общекластерная синхронизация жетонов Аутентификации (nonce).
• Общекластерные Тома Хранения Справочника.

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

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

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

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

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

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

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

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

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