Динамический кластер CommuniGate Pro

Динамический кластер 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 записями) и один или несколько у балансировщика. Например:

Балансировщик, 64.10.1.1, uc.domain.com

frontend1.domain.com ->64.10.1.11
frontend2.domain.com ->64.10.1.12
frontend3.domain.com ->64.10.1.13

Конечные пользователи при этом в своих клиентских приложениях используют только 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 адресов и присваивать их конкретным доменам, которые обслуживает.

Иногда администратор может добиться большей производительности от узла кластера, просто перенастроив немного операционную систему. Типичные настройки, подлежащие корректировке:

Лимит на число открытых файлов
Лимит на число процессов, запущенных одним пользователем
Сетевые буферы и кэши
Настройки частей ядра ОС, управляющих сетью
Настройки кэша файловой системы

Конкретные настройки и значения различны в каждом отдельном случае.

Всегда уточняйте у вендора ОС побочные эффекты настроек.

Выбор файловой системы

Выбор файловой системы зависит от выбора ОС и системы доступа к данным. Но в любом случае файловая система должна:

Поддерживать одновременные операции с файлами из одной папки, выполняемые разными узлами кластера
Справляться с миллионами небольших файлов
Справляться примерно с 10,000 файлов в одной папке
Поддерживать путь к файлу длиннее 255-ти байт
Поддерживать многобайтовые символы в именах файлов и папок

Требования к ОС

Имя сервера должно соответствовать имени главного домена в лицензионном ключе (например, лицензия — *.domain.com, сервер — frontend1.domain.com)
Все IP адреса, используемые при администрировании, настраиваются до установки CommuniGate Pro
В ОС не установлены другие почтовые сервера
В конфигурации ОС есть рабочие DNS сервера
На момент установки в системе нет firewall-ов (могут быть установлены позднее)

Помимо перечисленного настоятельно рекомендуется тщательно проверить бэкенды на производительность до установки CommuniGate Pro и монтирования хранилища.

Практические примеры выбора аппаратного обеспечения

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

Типы предоставляемого сервиса (почта, VoIP, синхронизация с мобильными устройствами, Pronto! (Flash клиент к серверу), ожидаемое число аудио конференций, объем данных, который будут хранить пользователи, ...)
В случае VoIP, IM, Presence сервисов использование перенаправления\транскодинга медиа потока будет занимать ресурсы. Идеальным вариантом было бы, если бы все медиа потоки шли от пользователя к пользователю напрямую, но сети со сложной топологией и несовпадение аудио кодеков часто приводят к тому, что медиа поток должен быть обработан сервером.
Число пользователей, разбитые по типам сервисов, которые они используют.
Процент загрузки — количество активных сессий к общему количеству аккаунтов в пиковые часы, разбитые по типам подключения.
Шаблоны использования сервисов (разные пользователи могут значительно отличаться по количеству почтовых клиентов, мобильных и звонков за единицу времени).

Все эти факторы должны быть оценены для формирования требований к аппаратному обеспечению. Основываясь на них и на практике развертывания множества Динамических Кластеров, команда CommuniGate Systems может помочь с выбором платформы и ее параметров.

Примеры:

1. Почтовый сервис с Push нотификациями и мгновенными сообщениями

Тип пользователя	Число пользователей
Всего	70 000
POP	70 000
IMAP/MAPI	70 000
WebMail & Pronto! (Flash)	70 000
Синхронизация с мобильными устройствами	5 000
Сообщения (XMPP/SIP) и статусы (Presence)	70 000

2. Предполагаемый трафик в процентном соотношении:

Протокол	Доля в трафике (%)
POP	20
IMAP	20
MAPI	5
WebMail	35
Сигналы (XMPP/SIP)	20

Предполагаемое количество одновременно подключенных пользователей: 4 000.

3. VoIP сервис с Pronto! в качестве софтфона, HD Аудио с преобразованием медиа потоков

Тип пользователей	Количество пользователей
Всего	2 000 000
VoIP	90 000

Соотношение типов трафика:

Протокол	Доля трафика(%)
RTP	80%
XIMSS (Pronto! — сигнализация, почта, календари)	20%

Общее число одновременных звонков: 9 000.

Число одновременно открытых пользовательских сессий: 90 000.

Рекомендуемая архитектура:

Динамический кластер 3х3.

Фронтенды

DELL PowerEdge R710
CPU: 2 x Intel® Xeon® Processor X5550 (2.66 GHz, 8MB L3 Cache, 95W, DDR3-1333, HT, Turbo 2/2/3/3)
Память: 24 GB
Сетевые контроллеры: 2 x HP NC382i Dual Port Multifunction Gigabit Server Adapters
Контроллер хранилища: HP Smart Array P410i/512MB with BBWC
Операционная система: SuSE or Redhat Linux 64bit

Бэкенды

DELL PowerEdge R710
CPU: 2 x Intel® Xeon® Processor X5550 (2.66 GHz, 8MB L3 Cache, 95W, DDR3-1333, HT, Turbo 2/2/3/3)
Память: 16 GB
Сетевые контроллеры: 1GbE NC373i Multifunction 2 Ports
Контроллер хранилища: Smart Array P400i/512MB BBWC
Операционная система: SuSE or Redhat Linux 64bit

Советы по настройке хранилища данных для кластера

В кластерном домене все учетные записи пользователей должны быть доступны всем бэкендам. Мы рекомендуем использовать для организации хранилища NAS с NFS протоколом, так как кластер CommuniGate Pro не использует блокировку файлов на уровне файловой системы, NFS является самым подходящим протоколом для него.

Несколько точек доступа и несколько NFS серверов могут использоваться в одном и том же кластере. Примеры используемых решений:

NETAPP FAS2000	EMC Celerra NS-120	SUN Storage 7110

Структура файлов в кластере

Учетные записи в общем домене сохраняются в папках с подобным путем:

SharedDomains/domainName/accountName.macnt/

Например:

SharedDomains/company.com/aivanov.macnt/

Сохранять десятки тысяч учетных записей в одной директории неудобно (большинство файловых систем медленно открывают папки с большим количеством объектов). Поэтому был придуман механизм "Account-level foldering", он заключается в том, что учетные записи сохраняются в набор подпапок:

SharedDomains/company.com/a.sub/aivanov.macnt/

или

SharedDomains/company.com/a.sub/i.sub/aivanov.macnt/

или

SharedDomains/company.com/ai.sub/v.sub/aivanov.macnt/

Если на кластере размещается много доменов (примерно от 5 000), то имеет смысл задействовать "Domain-level foldering":

SharedDomains/c.sub/company.com/aivanov.macnt/
SharedDomains/c.sub/o.sub/company.com/aivanov.macnt/

Или в случае большого количества больших доменов:

SharedDomains/c.sub/company.com/a.sub/i.sub/aivanov.macnt/

Лучше всего выбрать способ разбиения на папки, как только станет известно число пользователей и доменов. Но менять эти настройки можно и в процессе работы кластера.

Оптимизация хранилища с помощью SSD

У CommuniGate Pro есть особенность, которую можно использовать для оптимизации хранилища с помощью SSD.

У каждой учетной записи в папке есть файлы account.setting и account.info. Эти файлы считываются каждый раз, когда пользователь заходит под этой учетной записью, и .info файл изменяется каждый раз, когда метаданные учетной записи меняются (например, при регистрации SIP устройства).

Для повышения общей эффективности хранилища можно сохранить эти файлы отдельно на более дорогом и эффективном носителе(SSD). Для 1 миллиона учетных записей суммарный размер всех таких файлов будет 5-20 Гб.

Например, пусть при стандартной конфигурации кластера файлы хранятся в папке:

SharedDomains/company.com/a.sub/aivanov.macnt/account.settings
SharedDomains/company.com/a.sub/aivanov.macnt/account.info

Тогда если мы включим использование "Fast Storage Type" (установим его на ненулевое значение, например, 1), тогда путь к .info и .settings файлам станет:

SharedDomains/company.com/fast/a.sub/aivanov.settings
SharedDomains/company.com/fast/a.sub/aivanov.info

Таким образом, можно установить быстрое хранилище по адресу

SharedDomains/company.com/fast/,

и все .settings и .info файлы будут на него сохранены.

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

Кластер CommuniGate Pro можно сконфигурировать таким образом, что каждый узел работает и как фронтенд, и как бэкенд. Это называется симметричной конфигурацией:

Супер Кластер (кластер из кластеров)

Эта конфигурация применяется, когда необходимо обеспечить:

Региональное распределение мощностей для лучшего качества соединения и локальный доступ для пользователей.

Сервис для очень большого количества пользователей (более 15 млн. учетных записей) для разделения нагрузки между несколькими Динамическими Кластерами.

Динамический Кластер в конфигурации SIP ферма

SIP ферма это технология компании CommuniGate Systems для кластеризации VoIP и достижения времени доступности сервиса 99.999%, запаса прочности и масштабируемости.

И обычный Динамический Кластер, и Супер Кластер могут быть настроены как SIP ферма (в этом случае мы говорим, что часть узлов выделены в SIP ферму).

Входящие SIP UDP пакеты или TCP соединения распределяются, как обычно, через балансировщики нагрузки. Сервер, получивший пакет, определяет, не должен ли он обрабатываться на другом члене SIP фермы (если это ответ или ACK для уже существующего запроса или пакет для задачи, созданной на конкретном сервере), и пересылает его при необходимости.

Пакеты, не предназначенные конкретным узлам, распределяются между членами фермы по внутрикластерным алгоритмам в соответствии с нагрузкой и доступностью узлов в SIP ферме.

Итоги

Динамический Кластер по праву считается флагманом всех возможных конфигураций сервера CommuniGate Pro. Исторически, именно "use cases" подобные приведенным в статье — высокопроизводительные сервисы, предназначенные для массового использования, всегда являлись основой дизайна продукта.

Если у Вас есть какие-либо вопросы по продукту, не стесняйтесь обращаться на почту russia@communigate.ru. Для сложных технических вопросов — support@communigate.ru

Скачать бесплатную (до 5-ти пользователей, без кластера) версию можно на нашем сайте.