Кластеры |
|---|
| ||||||||
|
|
Версия 6.2 |
|||||||||||||||||||||||||||||||
|
|
Многие из существующих Коммуникационных серверов могут использовать в качестве хранилища данных пользователя файловые сервера. Так как эти сервера обычно реализованы как многозадачные системы (в Unix), то в них используются одинаковые методы синхронизации как в односерверной, так и в многосерверной среде, например, такие, как механизм блокировки файлов, реализованный на уровне Операционной/Файловой системы.
Этот метод имеет следующие проблемы:В попытке уменьшить отрицательное влияние блокировки файлов, некоторые из серверов Сообщений поддерживают только формат папки MailDir (один файл на сообщение) и полагаются на "атомарную" природу операций в файловой директории (а не на блокировки файлов). Подобный подход, позволяя в теории решить некоторые из описанных проблем (хотя в реальных ситуациях это едва ли помогает) ведёт к не экономному использованию ресурсов файлового сервера и сильно перегружает внутренние таблицы файловой системы.
Производительность Файловых Серверов сильно снижается, если приложение использует много маленьких файлов вместо нескольких больших.
Хотя простые методы кластеризации, основывающиеся на возможностях параллельного доступа Операционной/Файловой системы работают нормально для Веб Серверов (где данные изменяются не слишком часто), они не работают сколько-нибудь удовлетворительным образом для серверов Сообщений, где общий объём изменяемых данных почти совпадает с объёмом получаемых данными.
Простая Кластеризация не даёт никакого дополнительного выигрыша (например, не создаёт Образ Единого Сервиса), так что администрирование 30-серверного кластера становится даже более трудоёмким, чем администрирование 30 независимых Серверов.
Программное обеспечение CommuniGate Pro поддерживает возможность Внешний INBOX, так что основанная на файлах кластеризация так же может быть реализована в системах с CommuniGate Pro. Но, ввиду описанных выше проблем, настоятельно рекомендуется избегать решений такого типа и использовать вместо них настоящий Динамический Кластер CommuniGate Pro.
Серверы CommuniGate Pro входящие, в Динамический Кластер, не используют механизмы блокировок Операционной/Файловой Системы для синхронизации операций доступа Пользователей. Как и в Статическом Кластере, только один Сервер в Динамическом Кластере имеет прямой доступ к любому отдельно взятому Пользователю в некоторый произвольный момент времени. Все другие Сервера, если они хотят получить доступ к этому Пользователю, работают через этот Сервер. Но это назначение не является статическим: любой сервер может открыть напрямую данные любого Пользователя, если этот Пользователь не открыт каким-либо другим Сервером.
Такая архитектура обеспечивает максимальное время бесперебойной работы: сбой, происшедший на Бэкенд-Сервере, не приводит к остановке работы - все Пользователи смогут работать через другие Бэкенд-Серверы без какого бы то ни было ручного вмешательства и без простоя системы. Сайт будет продолжать работать и обеспечивать доступ ко всем Пользователям до тех пор, пока будет работать хотя бы один Бэкенд-Сервер.
Один из Бэкенд-Серверов в Динамическом Кластере действует как Контроллер Кластера. Он синхронизирует все другие Серверы в Кластере и выполняет операцииЖ создание Общих Доменов, создание и удаление Пользователей в Общих Доменах, и так далее. Контроллер Кластера также обеспечивает функциональность Образа Единого Сервиса: не только пользователь сайта, но также и администратор сайта может соединиться с любым из серверов в Динамическом Кластере и выполнить любую операцию с Пользователем (даже если в это же время Пользователь открыт на другом Сервере) или с Доменом (произвести изменение Установок Домена) и все произведённые изменения автоматически будут использоваться всеми Серверами, входящими в Кластер.
Обратите внимание: распространение на все Сервера, входящие в Кластер, большинства изменений на уровне Домена, таких, как изменение Установок Домена, Установок Пользователя по Умолчанию, Установок Веб Интерфейса Пользователя и Предупреждений уровня Домена может занять до 30 секунд. Изменения уровня Пользователя вступят в силу на всех Серверах немедленно.
Контроллер Кластера собирает с Бэкенд-Серверов информацию о их загрузке. Когда Фронтенд-Сервер получает запрос на установление сессии с Пользователем, который в это время не открыт ни на каком Бэкенд-Сервере, Контроллер направляет Фронтенд-Сервер на наименее загруженный Бэкенд-Сервер. Такая вторичная балансировка нагрузки для Бэкенд-Серверов основывается на их фактическом уровне загрузки и дополняет основную балансировку нагрузки (через циклический DNS или по трафику) Фронтенд-Серверов.
Если в Динамическом Кластере есть два или более Бэкенд-Сервера, то Контроллер Кластера назначает обязанности Запасного Контроллера на один из оставшихся Бэкенд-Серверов. Все остальные члены Кластера поддерживают соединения с Запасным Контроллером. Если Запасной Контроллер прекращает работу, то в качестве Запасного Контроллера выбирается какой-либо другой Бэкенд-Сервер.
Если основной Контроллер прекращает работу, то активным Контроллером Кластера становится Запасной Контроллер. Все Сервера отправляют информацию ресинхронизации на Запасной Контроллер и Кластер продолжает работу без остановок.
Хотя Динамический Кластер может обслуживать Справочник с записями о Пользователях, функциональность Динамического Кластера не полагается на Справочник. Если Справочник все же используется, то он должен быть реализован как Общий Справочник.
Полная конфигурация Фронтенд-Бэкенд Динамического Кластера использует также Балансировщик Нагрузки и работает в нескольких отдельных сетях:
Так как все Бэкенд-Серверы в Динамическом Кластере имеют прямой доступ к данным Пользователя, то они должны работать под управлением операционной системы, использующей одинаковые правила относительно EOL (конца строки). Это означает, что все Бэкенд-Серверы должны работать либо под управлением ОС семейства Unix, либо они должны работать под управлением ОС семейства Windows. Фронтенд-Серверы не имеют прямого доступа к данным Пользователя и, следовательно, вы можете использовать для Фронтенд-Серверов любую ОС (например, на сайте могут использоваться какая-нибудь из ОС Unix на Бэкенд-Серверах и Microsoft Windows на Фронтенд-Серверах).
Некоторые из современных операционных систем обладают встроенным возможностями для Кластеризации. Большинство из этих возможностей Кластеризации предназначены для того, чтобы облегчить перенос "обычных", не кластерных приложений на эти Кластерные платформы. Но некоторые из возможностей, предоставляемые этими ОС, очень полезны для реализации Динамического Кластера CommuniGate Pro.
Эти возможности включает в себя:Кластерная Файловая Система позволяет всем Серверам в Кластере ОС монтировать и использовать единую файловую систему на совместно используемых устройствах. В отличие от Сетевой Файловой Системы (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), так и от типа Общей Файловой Системы (Сетевая Файловая Система или Кластерная Файловая Система).
Используйте кнопку Создать Домен в Динамическом Кластере, чтобы создать дополнительные Общие Домены, которые будут обслуживаться Динамическим Кластером.
После того, как Контроллер Кластера заработал, сайт может начинать обслуживание клиентов (если вы не используете другие Фронтенд-Сервера). Если в вашей конфигурации развёрнуты также и Фронтенд-Сервера, то как минимум один из них должен быть запущен.
Вы можете добавить дополнительные Бэкенд-Серверы в Кластер в любой момент. Они должны быть настроены точно также, как был настроен первый Бэкенд-Сервер.
Чтобы добавить Бэкенд-Сервер в Динамический Кластер, запустите его с параметром Командной Строки --ClusterBackend (этот параметр может быть добавлен в сценарий автоматического запуска CommuniGate Pro). Сервер будет опрашивать все указанные IP адреса Бэкенд-Серверов до тех пор, пока он не обнаружит Активный Контроллер Кластера.
Используйте Веб Интерфейс Администратора, чтобы убедиться, что Бэкенд-Сервер работает. Используйте страницу Домены, чтобы проверить, что Сервер видит все Общие Домены, и что вы можете управлять пользователями в Общих Доменах.
Если работает Контроллер Кластера и, как минимум, один Бэкенд-Сервер, то они оба могут обслуживать всех пользователей Общих Доменов. Если вы не используете Фронтенд-Серверы, то балансировка нагрузки должна быть реализована через обычный коммутатор, балансирующий нагрузку, циклический DNS или подобные им техники, равномерно распределяющие входящие запросы между всеми Бэкенд-Серверами.
Вы можете добавить дополнительные Фронтенд-Серверы в Кластер в любой момент.
Установите и настройте программное обеспечение CommuniGate Pro на компьютере с Фронтенд-Сервером. Так как Фронтенд-Серверы не имеют прямого доступа к данным Пользователя, то, соответственно, нет необходимости делать директорию SharedDomains доступной ("смонтированной" или "отображённой") для какого бы то ни было Фронтенд-Сервера.
Используя в Веб Интерфейсе Администратора Фронтенд-Сервера страницу Установки->Общее->Кластер, укажите адреса всех Бэкенд-Серверов.
Чтобы добавить Фронтенд-Сервер в ваш Динамический Кластер, остановите его (сервер) и перезапустите его с параметром Командной Строки --ClusterFrontend (этот параметр может быть добавлен в сценарий автоматического запуска CommuniGate Pro). Сервер будет опрашивать все указанные IP адреса Бэкенд-Серверов до тех пор, пока он не обнаружит Активный Контроллер Кластера.
Используйте Веб Интерфейс Администратора этого Фронтенд-Сервера чтобы убедиться, что он работает. Используйте страницу Домены чтобы проверить, что Сервер видит все Общие Домены.
Когда Фронтенд-Серверы пытаются открыть данные одного из Пользователей Общего Домена, Контроллер направляет их на один из Бэкенд-Серверов, равномерно распределяя нагрузку между всеми доступными Бэкенд-Серверами.
Для Общих Доменов Динамический Кластер имеет отдельный набор "Установок по Умолчанию" .
Эти установки включает в себя:Когда Администратор Сервера использует Веб Интерфейс Администратора для изменения этих установок, то на страницах Веб Администрирования отображается ссылка, позволяющая Администратору переключатся между Общесерверными установками (которые применяются для всех не Общих Доменов) и Общекластерными установками. Общекластерные установки автоматически изменяются на всех членах Кластера и применяются для всех Общих Доменов.
Общекластерные Установки также включают в себя:Компонент Образ Единого Сервиса Динамического Кластера обеспечивает синхронизацию Установок Пользователей, Установок Доменов и ряда других настроек.
Дополнительная функциональность "общей обработки" включает в себя также:Для удаления Серверов из Динамического Кластера используйте Веб Интерфейс Администратора. Откройте страницу Кластеры в области Наблюдение и нажмите на кнопку Убрать Готовность.
Когда Фронтенд-Сервер не находится в состоянии Готовности, все его UDP порты и все его TCP порты (кроме портов, используемых для Администрирования по HTTP) закрываются.
Балансировщик нагрузки, доставляющий входящие соединения на Фронтенд-Сервер, должен обнаружить это состояние и прекратить отправку соединений и пакетов на этот Фронтенд-Сервер.
Когда Бэкенд-Сервер не находится в состоянии Готовности, Контроллер не отправляет на этот Сервер новые сессии. Подождите окончания всех существующих сессий и выключите Бэкенд-Сервер.
Если Бэкенд-Сервер является Активным Контроллером, то перевод его из состояния Готовности заставит Контроллер отправлять все новые сессии на другие Бэкенд-Сервера. Если в Кластере нет других Бэкенд-Серверов, то Контроллер будет продолжать самостоятельно обслуживать новые сессии.
Вы можете нажать на кнопку Установить Готовность на этой же странице для того, чтобы заново включить Сервер. Если Сервер является Бэкенд-Сервером, то Контроллер начинает отправлять на него новые сессии.
Необходимо иметь право доступа "Может управлять Кластером", чтобы устанавливать или сбрасывать Готовность.
Если Бэкенд-Сервер заканчивает работу из-за сбоя, то сессии всех Пользователей Общих Доменов открытых на этом Сервере не смогут продолжаться. Они смогут продолжить работу снова через 5-10 секунд, когда Контроллер Кластера обнаружит этот сбой. Сбой в работе Бэкенд-Сервера не приводит к потере данных.
Динамический Кластер создавался таким образом, чтобы сделать возможным плавную модернизацию всех входящих в него серверов. Для установки более новой версии программного обеспечения CommuniGate Pro вы должны обновлять сервера один за одним, поочерёдно: сначала уберите сервер из Кластера, затем обновите программное обеспечение и снова добавьте сервер обратно в Кластер. Эта процедура позволяет вашему сайту работать без остановок во время обновления.
Определённые изменения в программном обеспечении CommuniGate Pro могут накладывать определённые ограничения на процесс "плавной модернизации". Всегда проверяйте раздел История перед тем, как обновить ваш Кластер и убедитесь, что там отсутствуют ограничения на Обновления Кластера.