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