Communigate pro outlook домен настройка групповыми политиками
Каждый кто устанавливал новые сложные системы в организациях сталкивался с тем, что разработчики программного обеспечения не предусмотрели их специфической потребности в административном или пользовательском интерфейсе.
- Автоматизации административных задач
- Обработки писем и звонков
- Подключения сторонних программ и скриптов
- Построения HTML интерфейсов
- Создания UC клиентов и утилит на различных платформах
Интерфейс командной строки — стандартный способ управления многими продуктами. Удобен для автоматизации административных задач. Формат и полное описание команд выходит за рамки статьи, но их можно посмотреть в мануале, приведем лишь несколько примеров:
Доступ по poppwd
В сервере есть несколько способов доступа к CLI. Одним из самых удобных для ознакомления с командами можно считать модуль PWD. При стандартной конфигурации сервера достаточно набрать в коммандной строке ОС «telnet server.address 8106» (или «telnet server.address 106», в зависимости от ОС и версии). Изначально этот модуль был просто реализацией протокола смены пароля — poppwd:
Но нет никакой причины, чтобы останавливаться на одной текстовой команде:
Слово macnt в этом ответе означает Multi-mailbox Account
Бибилиотеки
Поскольку для практических задач «голый» текстовый доступ не очень удобен, мы создали Perl и Java библиотеки для работы с CLI.
На нашем сайте есть специальный раздел, где представлены примеры CLI скриптов для решения часто попадающихся задач.
Выполнение команд CLI также возможно в протоколе XIMSS (команда «cliExecute») и в CG/PL программе (функция ExecuteCLI()), о чем мы поговорим в соответствующих разделах.
Почтовые и сигнальные правила
Наверное, причисление правил к API можно назвать натяжкой, но в Communigate Pro правила применяются не только для перенаправления писем и звонков между учетными записями и ящиками, но и передают письма сторонним программам (например различным фильтрам), запускают CG/PL программы и даже запускают скрипты в операционной системе — вобщем, активно используются для интеграции как сами по себе, так и в связке с другими API.
Сигналами в Communigate Pro называют специальные объекты, которые применяются в коммуникациях «реального времени» (Real-time). Сигнал — это единица Real-time комуникации. Различные участники(SIP, XMPP клиенты, PBX приложения, . ) пересылают друг другу сигналы для организации, обрыва и обновления статусов диалогов и других действий .
Как работают правила
Правила разбиты на три уровня — серверные, доменные и уровень учетной записи (аккаунта). На каждом из этих уровней есть отдельные правила для сигналов и для почты.
У каждого правила есть имя и приоритет, у сигнальных правил есть еще условие «Когда». Чем выше приоритет — тем раньше, при одинаковых остальных условиях, сработает правило. Условие «Когда» определяет в какой момент сработает правило — на какой секунде обработки сигнала или при возникновении ошибки с определенным кодом (Не отвечает, Занято или другие ошибки):
- Применяются все серверные правила
- Те письма, которые в результате маршрутизации попали в локальные учетные записи, обрабатываются доменными правилами и правилами в учетных записях следующим образом:
- Доменные правила с приоритетом >5
- Правила в учетной записи
- Доменные правила с приоритетом <=5
- Применяются серверные сигнальные правила с пустым полем «Когда» (это означает, что они применяются сразу)
- Те сигналы, которые в результате маршрутизации попали в локальные учетные записи, обрабатываются оставшимися серверными правилами (поле Когда не пустое), доменными правилами и правилами в учетных записях следующим образом:
- Серверные правила с приоритетом >5
- Доменные правила с приоритетом >5
- Правила в учетной записи
- Доменные правила с приоритетом <=5
- Серверные правила с приоритетом <=5
Примеры использования
Ограничение пересылки в рамках домена:
Все звонки с адресатами вне определенных доменов перенаправляются на заданный адрес:Helper
В Communigate Pro реализован Helper протокол, который позволяет пользоваться внешними по отношению к серверу программами для различных задач.
При выполнении определенных условий, например, почтовое правило запускает фильтр для письма, которое обрабатывает или в домене срабатывает внешняя аутентификация, сервер запускает Helper программу. После чего, начинает через стандартный ввод присылать команды Helper протокола и считывает ответы из стандартного вывода.
Пример некоторой обобщенной сессии для хелпер протокола (I — ввод в программу, O — вывод):
- Обработки тела письма
- Внешней аутентификация
- Подключения баннерной системы
- Добавления RADIUS запросов в аутентификацию
- Управление распределением нагрузки в кластере
Все они подключаются на странице Настройки->Общие->Помощники WebAdmin интерфейса.
Все пути к исполняемым файлам отсчитываются от Базовой директории Communigate Pro (директория с пользовательскими данными).
Обработка тела письма
Обработчики писем запускаются почтовым правилом, например таким:
![]()
Детальное описание команд этого и других хелперов можно найти в мануале. В статье будем приводить лишь общее описание.
Хелперы такого типа используются в основном для подключения к CGPro анти-вирус и анти-спам движков.
Внешняя аутентификация
- Нужен метод аутентификации не поддерживаемый сервером напрямую
- Часть аккаунтов расположена в другой системе (например AD)
- Нужен сложный роутинг
- Нужно внешнее управление услугами\настройками учетной записи
Примеры хелперов этого типа можно найти на этой странице.
Остальные помощники
WSSP (Web Server-side Pages) — это язык для шаблонов Web страниц.
Перед тем как говорить о WSSP, нужно замолвить пару слов про организацию Web скинов на сервере.- Статические файлы — графика, стили, .
- WSSP файлы
- Языковые и строковые файлы
Вместе с дистрибутивом Communigate Pro поставляется небольшой набор стандартных (stock) Web интерфейсов. Один из них безымянный (Unnamed), остальные именнованные. Эти демонстрационные скины хранятся в Application папке сервера (папка в ОС, где находится исполняемый файл) и поэтому они заменяются при обновлении сервера. Администраторы не должны изменять демонстрационные скины в своих конфигурациях, при установке обновления эти изменения могут потеряться. Вместо этого нужно воспользоваться тем, что файлы скинов образуют иерархию.
Иерархия файлов в скинах
Каждый скин может быть серверным, доменным или стандартным.
При обработке запросов от браузера пользователя серверу обычно нужно достать файлы с определенными именами из скина. При этом если файл не найден в доменном скине, то его ищут в серверном скине с таким же именем. А если не нашли в серверном, то ищут в стоковом. Если же файл по прежнему не найден и текщий скин именованный, то файл ищется в безымянных скинах.
Таким образом загружая собственные файлы в безымянный серверный скин, администратор сервера может добиться того, что будут использованы его файлы, а не стандартные.
То есть при таком подходе можно как проделывать небольшие изменения в стандартных скинах, так и разрабатывать свои с нуля.
Строковые файлы
.data файлы содержат текстовые данные (UFT-8) в формате CG/PL словаря эти данные используются различными модулями сервера для формирования строк в интерфейсе или в качестве значений настроек.
Эти файлы также образуют иерархию, но уже на уровне ключей в словаре, то есть если какой-то ключ отсутствует в файле strings.data домена, сервер пытается найтиего в файле strings.data на уровне сервера и т.д.
Английский язык является языком по-умолчанию для строк в интерфейсе. Если же язык пользователя (сессии) отличен от английского, значения ключей из языковых файлов (french.data, russian.data) замещают значения из strings.data файла.
Такая система позволяет включать в слегка модифицированные интерфейсы (файлы strings.data) включать только те ключи значения которых были изменены (например название компании, фирменные бренды), а не их полный набор.
Обработка запросов
- текст ограниченный с двух сторон двойным символом % (%%element%%)
- структуры такого формата —
После обработки сервером все специальные конструкции будут заменены на строки или массивы строк из «окружения» — значения ключей из .data файлов в скине, имя домена или других объектов в сервере, значения настроек.
Любые другие файлы просто отдаются клиенту.
Базовые демонстрационные web интерфейсы можно рассматривать как отличные иллюстрации возможностей WSSP страниц. Но WSSP довольно ограничены в вопросах преобразования форматов данных или обращения к различным модулям и выполнения каких либо действий на сервере. И тут уже на помощь приходит более мощный инструмент.
Про язык CG/PL и разработку PBX приложений на нем мы уже рассказывали на Хабре в этой статье.
После этого запрос к URL вида:
Запустит программу на выполнение.
Запустит на выполнение от имени аккаунта с предварительной аутентификацией
Этот запрос ищет программу только в серверном Unnamed скине и запускает от имени пользователя postmaster (серверный администратор)В качестве примера рассмотрим небольшой скрипт выполняющий CLI команду «listaccounts» и преобразующий результат в JSON формат:
![]()
XIMSS
Как решение этих проблем мы разработали протокол XIMSS — XML Interface to Messaging, Scheduling and Signaling.
Все команды этого протокола — простые XML документы с прозрачными по смыслу атрибутами. Например эта простая команда перенаправит (fork) входящий звонок на двух пользователей:
Все форматы данных (MIME, vCard) приходят XIMSS клиенту в удобном для использования виде.
Также этот протокол позволяет выполнять все CLI команды доступные на сервере — через него можно регулировать все виды настроек, включая административные
Для ряда платформ нами разработаны готовые XIMSS библиотеки.
В заключение
Communigate Pro это платформа, поведение которой можно регулировать на разных уровнях. От клиента до доступа в основные коммуникационные модули и разработки собственной функциональности на базе стандартных протоколов. При этом решение стабильно и выдерживает большие нагрузки.
Несмотря на то, что входной порог во все Communigate API в совокупности может казаться довольно большим, они покрывают большинство задач стоящих перед администраторами коммуникационных сервисов.
В доменах CommuniGate Pro могут быть созданы Группы. Группа содержит несколько участников группы. Участниками Группы могут быть другие объекты в этом же Домене и/или внешние адреса электронной почты. Каждая Группа имеет свои собственные Настройки.
Создание Новой Группы
Администратор Сервера с правами "Может менять установки Всех Доменов и Пользователей" может создавать Группы в любом Домене.
Администратор Домена может создавать и удалять Группы в Домене, только если ему предоставлено право доступа "Может создавать Группы".
Чтобы создать новую Группу, напечатайте её имя в поле, находящемся справа от кнопки Создать Группу.
Выбранное имя Группы должно отвечать требованиям к именам Доменных объектов.Нажмите на кнопку Создать Группу. После создания новой Группы, её имя появится в списке. Сервер автоматически покажет страницу Настроек для вновь созданной Группы.
Задание Настроек Группы
Для того, чтобы изменить Настройки Группы, на странице со списком Объектов нажмите на имя Группы. Появится страница с настройками Группы.
Обработка Участников Группы
Сервер CommuniGate Pro может выполнять некую "обратную обработку" операций с участниками Группы, находя группы, содержащие определённый объект Домена (такого как Пользователя, Группу или Переадресатор).
Когда объект Домена удаляется, Сервер удаляет имена этого объекта из всех Групп в этом Домене.
Когда объект Домена переименовывается, Сервер изменяет имена этого объекта во всех Группах в этом Домене.
Когда Пользователь пытается открыть Чужую Папку, то Сервер проверяет Права Доступа к Папке, предоставленные всем Группам, куда входит этот Пользователь.
Обратите внимание: чтобы позволить Серверу находить объекты в списках участниках Группы, список участников должен содержать "реальные" имена объектов, а не их Псевдонимы (или любые другие адреса, указывающие на имя объекта).
Переименование Группы
Если вы хотите переименовать Группу, откройте страницу Настройки, заполните поле Новое имя Группы и нажмите на кнопку Переименовать Группу.
Если не существует Объекта с именем, совпадающим с новым именем Группы, то Группа переименовывается, и страница с её Настройками должна появиться на экране под новым именем.
Удаление Группы
Если вы хотите удалить Группу, откройте страницу с её Настройками и нажмите на кнопку Удалить Группу.
![]()
30%) касается стандартных протоколов, либо широко применяемых практик и поэтому актуальна не только для Communigate Pro.
Админка
Создание учетных записейПродолжим настройку с того места на котором остановились в предыдущей статье. У нас уже установлен сервер и выбрано имя главного домена. Настало время завести пользователей. Заходим на страницу адмнки и выбираем главный домен:
![]()
В домене уже есть 2 служебных пользователя — postmaster — главный администратор и pbx — техническая учетная запись от имени и с настройками которой запускаются голосовые приложения установленные по-умолчанию (подробнее о голосовых функциях расскажем в следующих статьях)
Создать нового пользователя легко — вводим имя, например recipient в текстовое поле возле кнопки «Create account» и нажимаем на нее. У вас откроется страница настроек нового пользователя, где можно будет ввести пароль для учетной записи — поле «Communigate password»:
![]()
Прием
Это самый трудоемкий по настройке раздел почты, связано это в первую очередь с борьбой со спамом. Мы, с одной стороны, не хотим принимать лишние письма (чтобы не прогонять слишком много писем через лексический спам фильтр, если он есть, да и просто лишний раз сервер не нагружать мусором), с другой — не хотим отказывать нормальным отправителям.
Хотя мы уже можем принять письма в только что созданные учетные записи, но необходимо будет использовать IP адрес в доменной части имени получателя. Это довольно неудобно для пользователей, поэтому все почтовые протоколы пользуются DNS.
Основным протоколом для доставки почты является SMTP, он используется как между серверами, так и от клиента к серверу (но не наоборот).
При этом процесс доставки письма от почтового клиента на сервер для отправки дальше мы будем называть регистрацией (submission) письма, а отправкой именно процесс доставки письма адресату (в случае SMTP адресаты находятся на других серверах).Для полноценной работы этого протокола необходимы DNS записи типа MX. Они содержат три поля — имя почтового домена, приоритет и имя сервера обслуживающего домен. Для каждого имени сервера должна существовать DNS запись типа A.
Запись с наивысшим приоритетом считается основным почтовым сервером, а остальные — backup серверами.
Клиентские IP адреса (Client IPs)
В Communigate Pro существует понятие Клиентских адресов. По сути это доверенные IP адреса — они обычно имеют ряд привилегий по сравнению с обычными и в некоторых настройках отвечающих за безопасность можно выбирать значения «только для клиентов» и «для всех кроме клиентов».
В админке CGPro клиентские адреса задаются полем типа «список адресов», этот тип поля активно используется и в других настройках (страница Setting->Network->Client IPs):
![]()
Приемники (Listeners)
У каждого протокола, для которого Communigate Pro умеет принимать соединения есть свой список приемников (объекты сервера создающие сокеты), например SMTP (Settings->Mail->SMTP->Receiving->«Listener»):
![]()
Каждый приемник открывает сокеты на определенном порту и определенном IP адресе (это необходимо, чтобы CGPro мог стоять на одной машине, с Web сервером — web сервер занимает 80-й порт на одном IP, а CGPro на другом).
По умолчанию в SMTP модуле настроен только 25 порт, добавим сразу еще 2, положенных по стантарту:
![]()
В современной версии SMTP порт 25 предназначен в основном для серверов, клиенты же должны пользоваться 587-м, его отличие в обязательном использовании аутентификации через команду SMTP AUTH.
Protection
Существует множество протоколов помимо SMTP позволяющих зарегистрировать письмо на сервере, но все они работают с аутентификацией от имени одного из аккаунтов. SMTP в ряде случаев не может позволить себе такой роскоши, поскольку предназначен для получения писем от произвольных серверов.
Из-за этого есть ряд мер, которые необходимо предпринять, чтобы хоть немного усложнить жизнь спаммерам.
Релеинг
Релеинг это прием письма сервером, для пересылки его дальше адресату.
SMTP в принципе позволяет регистрировать письма предназначенные для сторонних серверов, но на практике такую возможность лучше закрыть для всех отправителей, кроме доверенных, так как если позволить пересылку на чужие сервера с IP адреса под контролем спаммеров, администраторы этих серверов скорее всего заблокируют все письма от вас.
![]()
Настройки релея находятся на странице <nobr/>Settings->Mail->SMTP->Relaying и значения по-умолчанию вполне оптимальны:
Главное не изменить их случайно или без конкретной причины.Проверки заголовков
Основными заголовками при получении SMTP письма являются отправитель и получатель. Рассмотрим пример SMTP сессии:
Тут отправитель задается командой MAIL FROM, а получатель RCPT TO. Самое главное, что должен знать администратор, это то, что поле которое показывается всеми без исключения почтовыми клиентами как «От кого» (заголовок «From» в письме) на самом деле является не отправителем, а просто частью тела письма. Большая часть проверок заголовков (включая популярные Remote BlackLists) работают именно с отправителем установленным командой протокола, а о теле письма понятия не имеют. В MIME формате отправителю соответствует поле «Return-path».
![]()
(Письмо полученное в SMTP сессии приведенной выше в MIME формате и интерфейсе)Суть проверок «Return-path» в том, что при получении команды Mail From сервер извлекает доменную часть адреса и проверяет наличие этого домена в DNS. Есть также усиленная версия этой проверки — Reverse Connect, при использовании этой проверки, CGPro производит подключение к серверу отправителя и проверяет принимает ли этот сервер письма для отправителя с именем из команды Mail From.
Довольно популярной проверкой Return-path является SPF-проверка. Она требует DNS записей типа TXT специального формата, эти записи называют SPF записями. Они содержат имя почтового домена и список IP адресов, которые являются легитимными отправителями писем с данной доменной частью. Например:
Основной минус этого способа — работает только с отправителями, администраторы серверов которых знают и используют эту проверку. В WebAdmin настройки приема почты собраны на одной странице
![]()
RBL и обычный blacklist рассматривать не будем так как эти типы проверок довольно известны (в основном из-за того, что многие люди из России и СНГ регулярно обнаруживают себя в них) и никаких сложностей по настройке быть не должно.
Обработка письма
При получении письма оно сразу начинает записываться на жесткий диск в папку Queue базовой директории с расширением .tmp. Как только процесс получения завершается расширение меняется на .msg и модуль принявший письмо ставит его в общую очередь.
При внезапной перезагрузке или отключении сервера письма из очереди (.msg файлы папки Queue) просто ставятся в нее заново.
Queue
В очереди с письмом происходят следующие события:
- Анализ и преобразование адреса получателя.
- Применяем общесерверные правила.
- Файл очереди ставиться в одну или несколько логических очередей (в зависимости от того какие модули являются получателями письма)
- Применяем доменные или пользовательские правила
- Обработка писем в модулях-получателях.
Маршрутизатор(Router)
Каждый раз когда Communigate Pro сталкивается с почтовыми адресом он пропускает его через модуль Router. У администратора, помимо вспомогательных средств управления роутингом письма (такие как правила, псевдонимы доменов и пользователей), есть мощный инструмент обеспечивающий удобный доступ непосредственно в процесс обработки адресов — таблица роутинга:
![]()
формат каждой строки в этой таблице:
[префикс релея:][префикс типа записи:]left=right[; комментарий]
Схема работы таблицы следующая — записи просматриваются по одной, начиная с верхней, если очередную удалось применить для преобразования адреса, то новый адрес подается на вход в модуль роутинга с самого начала.
По-умолчанию записи в таблице работают для адресов встречающихся во всех операциях и функциях сервера. Запись может также работать только для одного из 3 типов операций если отмечена соответствующим префиксом — «Mail», «Access» и «Signal».
Существует еще один тип префикса — «Relay». Если для какого-то получателя сработала запись с таким префиксом, то письмо получает специальную пометку и оно будет отправленно вне зависимости от того пришло оно от доверенного источника (с клиентского IP или от аутентифицированного пользователя ) или нет. Это довольно опасная настройка, так как она позволяет спаммерам беспрепятственно отправлять письма на сервер на который у вас стоит перенаправление.
Логические очереди
Есть 4 вида очередей на отправку писем — на другие сервера (SMTP), в локальные ящики (LOCAL), в сторонние программы (PIPE) и в списки рассылки (LIST).
Каждая из этих очередей делится на несколько других. Например есть SMTP очередь на каждый домен — получатель, и есть LOCAL очередь на каждый аккаунт. Это позволяет доставлять письма большими порциями — по многу писем за одно соединение или открытие почтового ящика.
Правила
Правила применяются в два подхода — в начале Серверные правила ко всем письмам (до постановки в очереди доставки), а потом Доменные и Пользовательские правила, но только для писем из очереди локальных ящиков LOCAL. Доменные правила с точки зрения внутреннего устройства абсолютно неотличимы от правил Пользователей, но применяются ко всем аккаунтам домена.
Подобная система применения правил означает, что Доменные и Пользовательские правила могут влиять только на входящие письма (исходящие письма в LOCAL очередь не попадают). То есть для выполнения каких-либо манипуляций над исходящими письмами подходят только Серверные правила.
Получение ящиков
Никаких особых настроек у этих протоколов нет — все должно заработать сразу «из коробки».
Имя пользователя в настройках клиентов желательно указывать полностью, включая доменную часть (если ваш клиент, как некоторые версии Outlook, автоматически отрезает доменную часть по символу '@' можно использовать '%' вместо него).
Подводим итоги
Мы рассмотрели самые важные настройки с которыми сталкивается начинающий администратор почты на Communigate Pro. В этой статье есть небольшой перекос в сторону настроек регистрации и отправки писем, связано это с тем, что такие обширные темы как Router и Правила тяжело уместить в рамки небольшой статьи. Рекомендуем ознакомиться с ними дополнительно в онлайн мануале:
Разрозненные каналы коммуникации – серьезная проблема для любой компании. Особенно, в ситуации, когда хочется получать корреспонденцию, общаться письменно и устно с клиентами и партнерами-контрагентами в одном месте, позволяющем решать эту задачу наиболее эффективно.
«А теперь на миг представьте, что всё многообразие средств общения и обмена файлами можно объединить в рамках одной платформы»Можно не городить огород и взять готовый проект – например Zimbra. Таким образом, по-меньшей мере, можно обойтись без изобретений велосипедов (когда уже есть мотоцикл) и, даже возможно, получится обойти большую часть расставленных граблей, благо, собаку-поводыря создатели решения предоставляют, для их (граблей) обхода.
Возможно, дело обстоит лучше в категории платного софта? Ведь «всегда есть» Microsoft – бесспорный лидер в офисном программном обеспечении, которое здорово поддержано серверной архитектурой. Ведь и архитектура, сама по себе, это довольно сложная (отдельный сервер для почты/календарей, отдельный для коммуникаций в реальном времени, обязательный сервер Active Directory, плюс что-то ещё «по-мелочи») конструкция, но проблем с интеграцией внутри данного хозяйства быть не должно или количество таких проблем будет минимально.
Сложности начнутся ровно в тот момент, когда вы попытаетесь прикрутить нечто, отсутствующее в стандартной «коробке» или будете пытаться взаимодействовать с продуктами других производителей – даже по стандартным протоколам. Потому что стандарты не указ «Большому Брату» – за вас подумали и решили, как лучше.
«Так, неужели, все настолько сложно в мире унифицированных коммуникаций и серебрянной пули, убивающей нескольких зайцев сразу – нет?» На самом деле – есть. Это продукт, который одним исполняемым модулем способен поддержать все многообразие протоколов коммуникации с поддержкой клиентов других производителей и, в качестве вишенки на торте, предоставляет приложений – тонкий клиент, способное надежно контролировать и управлять всем этим букетом. Клиент-сервер единой коммуникационной платформы – что это и зачем?
Так как мы работаем на существующем рынке, то и используем в своем продукте наиболее широко распространенные протоколы. Для электронной почты и группового взаимодействия мы используем безальтернативный SMTP, а для коммуникации в реальном времени – SIP и XMPP протоколы.
![]()
![]()
![]()
![]()
![]()
Составляющие мощного комбайна, который подходит крупнейшим корпоративным и государственным заказчикам:![]()
Мультидоменная архитектура (подтверждённая на практике работа более чем 120 000 доменов на одной системе), поддержка конфигураций как с выделенными, так и с совместно используемыми IP адресами.
Концепция Пользователя, включающая в себя «Хранилище Почты», «Хранилище Файлов», «Настройки Пользователя» и базы данных, содержащие в себе полную информацию о «Пользователе».
Мета-Справочник, объединяющий Локальные и Удалённые Тома.
LDAP доступ в «Справочник» и в базы данных, хранящие информацию «Пользователей».
Механизм внешней аутентификации для интеграции с решениями сторонних производителей.
Тарификационная система, поддерживающая различные типы «Остатков» для каждого «Пользователя» и предварительное резервирование средств.
Форматы папок - текстовые файлы, папка (директория), другие контейнеры данных.
Хранение файлов в публичных и личных папках, виртуальные файлы.
ESMTP и LMTP механизмы обмена почтой.
Анти-Спам и другие встроенные механизмы защиты.
Правила автоматической обработки почты.
Извлечение почты с других почтовых серверов через POP3 протокол.
Автоматическая обработка приглашений при планировании встречи и совместном использовании ресурсов.
Механизмы прохождения NAT («ближний» и «дальний») для XIMSS, SIP, RTP и медиа-протоколов, использующих TCP.
Правила автоматической обработки сигналов.
STUN сервер для решений по прохождению NAT на стороне клиента.
• Среда для приложений реального времени
Настраиваемые на уровне домена среды для приложений.
Компонент Медиа Сервер для терминации звонков и организации конференций со встроенной поддержкой прохождения NAT и шифрования.
Язык программирования CG/PL для быстрой разработки надежных приложений.
Встроенные операции для управления вызовами, медиа-потоками и для организации многосторонних конференций.
Одновременный доступ с разных клиентов ко всем данным «Пользователя» с помощью различных протоколов.
POP3 и IMAP4 протоколы доступа к почте клиентских программ.
MAPI интерфейс для почтовых клиентов, работающих под «Microsoft® Windows» (Outlook и другие приложения, работающие через MAPI).
Поддержка различных языков и настраиваемый внешний вид для HTML, WAP/WML, и I-Mode интерфейсов.
AirSync интерфейс для электронной почты и данных групповой работы для клиентов, работающих под управлением «Microsoft® Windows Mobile» (серверный ActiveSync).
CalDAV интерфейс для доступа к папкам «Календаря» и «Заданий».
CardDAV интерфейс для доступа к папкам «Контактов».
SASL методы для безопасной аутентификации.
GSSAPI аутентификация (включая Kerberos V5), единый механизм входа пользователя (single sign-on).
Безопасная Почта , встроенные в веб-интерфейс средства для работы с S/MIME (шифрование/расшифровка, подписывание цифровой подписью и проверка цифровой подписи).
Автоматическое шифрование для безопасного хранения информации.
Веб-интерфейс администратора для администрирования сервера, управления услугами и мониторинга.
CLI/API интерфейс для автоматизации выполнения задач по администрированию, управлению услугами и мониторингу.
SNMP агент для удалённого мониторинга.
Триггеры для упреждающего мониторинга.
Poppwd протокол для удалённого изменения пароля.
Управление через LDAP (опционально) для интеграции с действующими системами.
BSD syslog - Сервер консолидированного ведения «Журналов работы» сторонних программ.
Распределённые домены для работы в конфигурациях с несколькими одиночными серверами.
Статические кластеры для распределения пользователей по нескольким серверам.
Динамические кластеры для высокоэффективного масштабирования без распределения пользователей. Решение промышленного класса, обеспечивающее безотказную работу в течении 99.999% времени эксплуатации, на практике доказавшее свою эффективность в обслуживании более чем 5,000,000 активных пользователей.
Кластер из кластеров для сверхбольших сайтов (свыше 10 000 000 активных пользователей).
Как это работает: SMTP, SIP, IMAP, XMPP, LDAP, XIMSS, CalDAV, WebDAV и т.д. в «одной коробке»
Итак, разобравшись со структурой клиент-сервера CommuniGate Pro, обратим чуть больше внимания на то, как все это работает.
По нашему мнению, CommuniGate Pro является лучшим масштабируемым решением для объединенных коммуникаций, доступным на сегодняшний день на рынке. Есть очень небольшое количество решений, которые помимо обмена данных в реальном времени с другими серверами по протоколам SIP и XMPP предоставляют возможности взаимодействия с клиентами посредством XIMSS, ParlayX и скриптов CG/PL.
Наш медиа-сервер использует для обмена данными прокол RTP и позволяет связывать более двух собеседников в аудиоконференциях с применением различных аудиокодеков, а встроенный модуль STUN и поддержка ICE, вкупе с интегрированным медиа прокси-сервером, позволяют решать проблемы, характерные для VoIP-клиентов за NAT-файрволлами.
Динамический же кластер реализует архитектуру, в которой все его узлы «активны». По нашему опыту, другие продукты довольствуются схемами восстановления после падения или горячей замены, но только не наше решение. В динамическом кластере все системы работают в виде одной логической сущности, соответственно все узлы берут на себя долю нагрузки. В то же время, каждый узел можно извлечь в любом момент или, аналогично, можно добавить новый. Таким образом, мы позволяем проводить обслуживание любого члена динамического кластера и увеличивать, или уменьшать, задействованные мощности прямо во время работы без прерывов в предоставлении сервиса пользователям.
Каковы ключевые преимущества динамического кластера? Рассмотрим их чуть детальнее:
Техническое обслуживание узлов без остановки сервиса
Как правило обновления програмного и/или аппаратного обеспечения могут привести к ухудшению времени доступности системы. В мире корпоративных технологий и решений подобные события часто называют «запланированные отключения» или «техническое обслуживание». Однако, в мире SaaS-решений операторского уровня такие отключения являются недопустимыми – это все-равно что ваш телефон бы отключался по выходным на «тех. обслуживание».
Для того чтобы избавиться от столь неприятной вещи, в динамическом кластере нами был реализован механизм поочередных обновлений – он позволяет администратору кластера деактивировать узел, распределяя открытые соединения на другие члены кластера до тех пор, пока узел не уйдет в оффлайн полностью и станет доступен для обслуживания. После того как дело сделано, узел просто возвращается в кластер.Единая система
Динамический кластер CommuniGate Pro позволяет оператору рассматривать всю систему как единую сущность, даже если она состоит из более чем 40 серверов. Таким образом, управление масштабной инфраструктурой на порядки проще, чем в случае с системами корпоративного уровня.SaaS-провайдерам, предоставляющим услуги для малого бизнеса и индивидуальных предпринимателей, нужна легко масштабируемая система. И динамический кластер обычно представляется в виде облаков, обслуживающие более 20 000 небольших (5-30 конечных пользователей) компаний.
В то же время, в случае с IP АТС и почтовыми решениями, которые не разрабатывались с прицелом на использование как SaaS платформы, управление резко усложняется с ростом пользовательской базы из-за того, что количество отдельный частей увеличивается — прокси сервера, базы данных, LDAP сервера, медиа шлюзы и т.д.
Динамический кластер — элегантное и эффективное решение, без лишних затрат растущее вместе с пользовательской базой.
Эффективность
Платформа эффективно осваивает имеющиеся аппаратные ресурсы. Как следствие, провайдер может достигнуть гораздо большей плотности пользователей на каждом сервере по сравнению с корпоративными решениями. Плотность пользователей критична в дата-центрах, так как позволяет сильно снизить расходы на администрирование, электричество, охлаждение – общую стоимость владения.На большинстве 64-битных систем операторского класса (Solaris, Linux, BSD) CommuniGate Pro может достичь 90 000 сессий на одну систему. Также существуют проверенные на практике работающие конфигурации для более чем 450 000 конечных пользователей на одной системе.
Предсказуемая масштабируемость
Динамический кластер — система с минимальными накладными расходами на масштабирование. Для увеличения емкости системы достаточно простых дешевых серверов форм-фактора 1U или блейд-серверов.Так как исходный код платформы хорошо распараллелен, вычислительные ресурсы и память используются максимально эффективно, а прогнозирование объема необходимых ресурсов при увеличении пользовательской базы прозрачно и близко к линейной зависимости. Все узлы кластера CommuniGate Pro используют один и тот же исполняемый файл, и поэтому отсутствуют различия в производительности узлов, характерные для неоднородных архитектур.
Структура динамического кластера позволяет провайдерам анализировать и прогнозировать свои затраты с высокой точностью, будь то сервера или хранилища данных.
Высокая доступность
Одним из основных свойств и целей разработки динамического кластера является сведение к нулю времени отсутствия сервиса. Все ноды кластера активные, и при падении одной из них другие члены кластера берут на себя пользовательскую нагрузку.Читайте также:
