Динамический кластер CommuniGate Pro реализует архитектуру, в которой все узлы кластера являются "активными". Многие другие решения довольствуются схемами восстановления после падения или горячей замены, но не Динамический Кластер — в нем все системы работают вместе в виде одной логической сущности и все узлы берут на себя свою долю нагрузки. В то же время, каждый узел в любой момент можно извлечь из кластера или добавить новый в любой роли. Таким образом Динамический Кластер позволяет производить обслуживание любого его члена и увеличивать (и уменьшать) задействованные мощности прямо во время работы без перерывов в предоставлении сервисов.
Ключевыми преимуществами Динамического кластера, о которых мы будем говорить подробнее ниже, являются:
- Техническое обслуживание узлов без остановки сервиса;
- Единая система;
- Эффективное использование серверов;
- Предсказуемая масштабируемость с низкими накладными расходами;
- Высокая доступность сервисов.
Техническое обслуживание узлов без остановки сервиса
Обновления программного и аппаратного обеспечения на узлах могут резко ухудшить время доступности коммуникационной системы. Эти накладки часто называют "запланированные отключения" в мире корпоративных ИТ. К сожалению, такие отключения являются совершенно недопустимыми в области SaaS решений операторского уровня. Представьте ситуацию, в которой кабельный телефон отключался бы по субботам на обслуживание.
Для того чтобы убрать необходимость в отключениях, в Динамическом Кластере реализован механизм поочередных обновлений. Такой механизм обновлений позволяет администратору кластера деактивировать узел, распределяя при этом открытые соединения на другие члены кластера до тех пор, пока узел полностью не уйдет в оффлайн. После этого он доступен для обслуживания, и в дальнейшем его можно будет вернуть обратно в кластер.
Единая система
Динамический Кластер CommuniGate Pro позволяет оператору рассматривать всю систему как единую сущность, даже если она состоит из более чем 40 серверов. Таким образом, управление масштабной инфраструктурой на порядки проще, чем в случае с системами корпоративного уровня.
SaaS провайдерам, предоставляющим услуги для малого бизнеса и индивидуальных предпринимателей, нужна легко масштабируемая система. И для наших клиентов использующих Динамический Кластер совершенно обычным делом являются облака, обслуживающие более 20,000 небольших (5-30 конечных пользователей) компаний.
В то же время, в случае с IP АТС и почтовыми решениями, которые не разрабатывались с прицелом на использование как SaaS платформы, управление резко усложняется с ростом пользовательской базы из-за того, что количество отдельный частей увеличивается — прокси сервера, базы данных, LDAP сервера, медиа шлюзы и т.д.
Эффективность
Платформа CommuniGate Pro очень эффективно использует аппаратные ресурсы. Как следствие, провайдер может достигнуть гораздо большей плотности пользователей на каждом сервере по сравнению с корпоративными решениями. Плотность пользователей критична в дата-центрах, так как позволяет сильно снизить расходы на администрирование, электричество, охлаждение.
На большинстве 64-битных систем операторского класса (Solaris, Linux, BSD) CommuniGate Pro может достичь 90,000 сессий на одну систему. Также существуют проверенные на практике работающие конфигурации для более чем 450 000 конечных пользователей на одной системе.
Предсказуемая масштабируемость
Динамический Кластер — это система с минимальными накладными расходами на масштабирование. Для увеличения емкости системы достаточно простых дешевых серверов форм-фактора 1U или блейд-серверов. В отличие от других архитектур с высокими требованиями на вычислительные мощности, для CommuniGate Pro не рекомендовано использование слишком мощных серверов (таких как 8-way). Например, Динамический Кластер 4х4 с 2-ух процессорными серверами лучше, чем 2х2 с 4-ех процессорными серверами, так как в первом случае удельная нагрузка на один сервер гораздо ниже.
Так как исходный код CommuniGate Pro хорошо распараллелен, вычислительные ресурсы и память используются максимально эффективно и прогнозирование объема необходимых ресурсов при увеличении пользовательской базы прозрачно и близко к линейной зависимости. Все узлы кластера CommuniGate Pro используют один и тот же исполняемый файл, и поэтому отсутствуют различия в производительности узлов, характерные для неоднородных архитектур.
Высокая доступность
Одним из основных свойств и целей разработки Динамического Кластера является сведение к нулю времени отсутствия сервиса. Все ноды кластера активные, и при падении одной из них другие члены кластера берут на себя пользовательскую нагрузку.
Архитектура Динамического Кластера. Основные элементы архитектуры кластера CommuniGate Pro включают в себя:
- Балансировщик нагрузки;
- Топология сети;
- Фронтенд;
- Бэкенд;
- Общее хранилище типа NFS/CFS.
Балансировщик нагрузки
В кластер входит несколько серверов, поэтому для того, чтобы пользователи могли заходить на него по одному URL или IP адресу, нужен балансировщик нагрузки. В мире существует множество работающих Динамических Кластеров, и на них используются самые разные балансировщики. Мы рекомендуем использовать только качественные L4 устройства с хорошей пропускной способностью от Cisco, F5, Foundry. Более детальная информация по конфигурации балансировщиков доступна в мануале.
Кроме того, фронтенды на Linux сами могут выполнять функции балансировщиков с помощью встроенной в ядро технологии IPVS.
Топология сети
При организации Динамического Кластера используются по крайней мере 4 отдельные сети и несколько высокоскоростных свитчей для достижения оптимальной производительности. Мы рекомендуем Cisco, F5, Foundry, HP или другие свитчи похожего уровня, которые обеспечивают гигабитные скорости. При этом это должны быть максимально простые и надежные устройства, для примера укажем серию Cisco Catalyst 2960.
Каждый сервер в кластере должен иметь по крайней мере 3 сетевых интерфейса. Следующий набор сетевых конфигураций необходим для корректной работы Динамического Кластера:
Публичная сеть — эта внешняя сеть с белыми IP адресами. Обычно у каждого фронтенда есть по одному такому адресу (вместе с DNS записями) и один или несколько у балансировщика.
Конечные пользователи при этом в своих клиентских приложениях используют только uc.domain.com. А балансировщик, в свою очередь, раскидывает запросы по активным фронтендам. ДНС записи для фронтендов нужны для удобства администраторов.
Сеть для внутрикластерного обмена — внутренняя сеть из серых IP адресов используется для передачи информации между узлами кластера, никакой другой трафик не допускается, поэтому на фронтендах для этой сети используется отдельный (второй) интерфейс.
Сеть для хранилища — внутренняя сеть, использующаяся для связи бэкендов с хранилищем, это должна быть высокоскоростная сеть, оптоволокно или 10-гигабитный Ethernet.
Управляющая сеть — закрытая сеть, обычно это локальная сеть провайдера. Она предназначена для администраторов, а также для вызова API биллинга, плагинов и прочих задач по управлению кластером.
Фронтенды. В кластере фронтенды выполняют следующие функции:
- Обмен почтой по протоколу SMTP c другими серверами.
- Организация SIP сигнализации и выполнение PBX приложений (выполнение этой функции синхронизировано между узлами, и такие кластеры мы еще называем SIP фермы, SIP-farm)
Защитные функции — RBL, счетчики ошибок и количества принятой информации с одного адреса, черные\белые списки по IP и DNS адресам, и др.
- Организация клиент-серверных соединений (IMAP, POP, HTTP, XIMSS). После организации соединения фронтенд обращается к бэкенду уже только за данными.
- Обработка SSL соединений.
В Динамическом Кластере бэкенды — ядро платформы. Они ответственны за:
- Доменные настройки;
- Настройки учетных записей;
- Письма и другие объекты, созданные пользователями;
- Вспомогательные данные для кластера;
- Управление кластером;
- Аутентификацию;
- енерирование HTML страниц по технологии WSSP.
Технология синхронизации на уровне учетной записи, используемая в бэкендах, гарантирует, что только один сервер имеет доступ к файлам аккаунта в каждый момент времени (6-ти секундные интервалы). Кластер CommuniGate Pro таким образом убирает необходимость в блокировке файлов на уровне файловой системы (за исключением одного — heartbeat.data, блокировку которого которого осуществляет Контроллер Кластера). Из-за того, что кластер не рассчитывает на механизмы блокировки в файловой системе, производительность NFS увеличивается в 5-7 раз.
Динамический кластер поддерживает поочередное обновление узлов и автоматическое восстановление после падения любого узла в любое время; рекомендуемая конфигурация в этом случае — кластер 3х3 (3 фронтенда, 3 бэкенда). Но для запланированного отключения рекомендуется использовать “мягкое” отключение — настройка “Make Not-Ready” в WebAdmin интерфейсе на странице Monitors->Clusters.
Безопасность
Помимо поддержки современных механизмов шифрования, в качестве дополнительной защиты информации, хранящейся на бэкендах, для обмена данными между фронтендами и бэкендами используется проприетарный протокол разработки CommuniGate Systems. Информация о нём и его спецификация не хранится в открытом доступе и может быть передана только специально авторизованным партнёрам компании. Наличие этого протокола является дополнительным препятствием для доступа к пользовательской информации, даже в случае взлома бэкендов.
Установка кластера
Самая критичная часть Динамического Кластера это хранилище данных. Рекомендуется использовать либо NAS, либо SAN решения в зависимости от операционной системы и доступных возможностей, таких как NFS протоколы и различные файловые системы (CFS). Сам процесс установки состоит из следующих шагов:
- Настройка сети;
- Настройка операционной системы;
- Выбор файловой системы и хранилища данных;
- Выполнение требований к операционной системе;
- Конфигурирование CommuniGate Pro.
Настройка сети Кластер CommuniGate Pro позволяет определенную гибкость в настройках сети, есть возможность:
- Разместить все подсети кластера за NAT;
- Использовать прямые WAN адреса;
- Сети смешанного вида, фронтенды при этом находятся в DMZ а бэкенды в защищенной сети.
CommuniGate Pro может управлять сотнями IP адресов и присваивать их конкретным доменам, которые обслуживает. Иногда администратор может добиться большей производительности от узла кластера, просто перенастроив немного операционную систему. Типичные настройки, подлежащие корректировке:
- Лимит на число открытых файлов;
- Лимит на число процессов, запущенных одним пользователем;
- Сетевые буферы и кэши;
- Настройки частей ядра ОС, управляющих сетью;
- Настройки кэша файловой системы;
- Конкретные настройки и значения различны в каждом отдельном случае.
