В сервере Lync анонсирована поддержка распределения запросов SIP с помощью DNS. Это позволяет построить отказоустойчивую систему с меньшим количеством аппаратных балансировщиков, стоящих достаточно дорого. Кроме того аппаратные балансировщики не поддерживают  новую возможность MS Lync Server - недопуск новых соединений (connection draining), позволяющую отключить один из серверов для выполнения операций обслуживания.

Microsoft Office Communication Server 2007 и Microsoft Office Communication Server 2007 R2 для обеспечения полной отказоустойчивости пула серверов Enterprise требовали наличия аппартаных балансировщиков. Однако с помощью дорогих аппартных балансировщиков достаточно сложно настраивать распределение запросов SIP. Основное их предназнанчение - балансировка трафика http. Для снижения зависимости от аппаратных балансировщиков в Lync сервере была анонсирована альтернатива - балансировка запросов с помощью DNS.

Что же такое распределение запросов с помощью DNS?

Распределение запросов с помощью DNS внедряется на уровне приложений как на серверах, так и на клиентах - они оба принимают участие в этом процессе.

Процеcс  распределения нагрузки состоит в следующем:

1. FrontEnd сервер регистрирует свое полное доменное имя (FQDN) как запись типа A в DNS

2. При создании пула серверов Enterprise полное доменное имя такого пула (по сути запись SRV) будет содержать список IP адресов FrontEnd серверов, находящихся в пуле

3. Клиент соединяется с одним из адресов из списка. В случае неудачности попытки соединения клиент совершит попытку соединения со следующим из списка сервером и так будет до тех пор пока не произойдет удачное соединение.

Можно ли считать этот механизм подобным round robin? Не совсем. Механизм распределения round robin также подразумевает наличие у одной записи нескольких IP адресов, однако при обработке запросов клиентов, механизм выдает по одному адресу последовательно выбирая их из имеющегося списка. То есть первый клиент получит первую запись из списка, второй - вторую и так далее. Для кажого запроса выдается одна запись. Кроме того механизм round robin не знает о том «живой» ли сервер, адрес которого он выдает или нет. То есть по сути просто методом распределения нагрузки без обратной связи.

Механизм распределения нагрузки в MS Lync учитывает состояние серверов и мало того позволяет перенаправлять клиентов в случае если Вам необходимо выключить какой-либо сервер для обслуживания (connection draining)

Как же это работает.

Давайте представим, что у нас есть один пул, состоящий из четырех Front-End серверов и одного back-end сервера с базой MS SQL как это показано на рисунке 1.

Рис. 1 Пул серверов

DNS настроена в соотвествии с Таблицей 1. Обратите внимание, что запись для пула состоит из нескольких адресов, каждый из которых соотвествует одному серверу в пуле.

Таблица 1. Настройка DNS

Клиент делает запрос на разрешение имени в IP адрес для пула серверов (pool.contoso.ru) . Клиенту возвращается список серверов front-end как это показано в таблице 1. В предыдущих версиях сервера клиенту возвращался бы один виртуальный адрес аппартного балансировщика.

Клиент выбирает случайным образом один из адресов и делает попытку установления соединения. При неудачности попытки клиент идет дальше по списку до тех пор, пока соединение не будет успешно установлено.

Регистрация клиента.

В предыдущих версиях клиент мог успешно зарегистрироваться на любом сервере front-end, который хранил информацию о регистрации в базе SQL, общей для всех серверов. В MS Lync каждый сервис (регистратор), отвечающий за регистрацию пользователей и находящийся на одном из серверов front-end ведет свою собственную локальную базу регистраций. Каждому пользователю назначается один из серверов, как первичный для регистрации. В нашем примере вероятность того, что пользователь подключится к своему первичному серверу с первой попытки составляет 25%. Кроме того, если пользователь регистрирует несколько устройств все его устройства должны быть зарегистрированы на одном и том же регистраторе. Это необходимо для упрощения логики маршрутизации звонков.

Для сопоставления пользователя определенному регистратору, а также для определения порядка подключения пользователя в случае сбоя его сервера используется механизм хеширования.

Давайте разберем на примере что происходит при подключении пользователя к пулу, а также что произойдет, если пользователь подключится не к своему регистратору.

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

Представим себе, что пользователю из нашего пула (рисунок 1) при подключении был присвоен следующий порядок подключений FE4, FE2, FE1, FE3. Пользователь подключается и выполняет DNS запрос на разрешение имени в IP адрес для нашего пула (pool.contoso.ru). В ответ получает список из четырех адресов и случайным образом выбирает один из них. Допустим,  он выбрал адрес сервера FE3. При подключении к серверу производится сверка по хешу какой регистратор у пользователя является первичным. В нашем случае это FE4. Сервер FE3 перенаправит пользователя на его первичный регистратор.

Что же произойдет в случае если один из регистраторов будет недоступен.

В случае если недоступен регистратор, который клиент выбрал, то он просто выберет следующий сервер, а дальше все произойдет как описано выше.

В случае если недоступен его первичный регистратор, сервер который должен произвести перенаправление будет знать о его неработоспособности в текущий момент времени и перенаправит его на сервер который является для пользователя резервным в соответствии с порядком присвоенным ему при первом входе.

Давайте немного усложним задачу и представим что наш пул состоит из максимально возможного количества серверов (10). При добавлении серверов в пул с помощью инструмента Topology Builder каждому из них случайным образом присваивается определённый идентификатор ID от 1 до 10.

Давайте посмотрим на процесс регистрации пользователя в разных сценариях. На рисунке 2 представлен такой пул. Значки х означают, что эти сервера или неработоспособны или еще не были установлены.

Рис 2. Пул из десяти серверов

На рисунке 3 представлена логическая последовательность регистраций для двух различных пользователей. Она задает порядок регистрации пользователя на пуле.

Рис 3. Логические последовательности регистрации двух пользователей

Используя две последовательности регистраций - логическую пользователя и физическую присвоенную при создании сервера (ID) выбирается регистратор, который будет обслуживать пользователя. У пользователя 1 будет выбран сервер {7} - это FE3.

Рис 4. Пример выбора пользователем регистратора.

Во втором случае у пользователя первые три регистратора будут недоступны {3, 6, 2}. Пользователь подключится к следующему регистратору по его логической последовательности -  им будет FE3. Пользователь подключается в резервном режиме.

Сбой и восстановление работоспособности сервера.

Итак, пользователь зарегистрировался. Что произойдёт в случае сбоя сервера?

В случае отказа одного из серверов происходит обновление состояния и между всеми оставшимися работоспособными серверами происходит обмен информацией об отказавших участниках пула. Вся логика подключений будет соответствовать описанному выше процессу.

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

В случае введения в пул нового сервера пересчитывается логическая последовательность регистраций для каждого пользователя что в итоге может привести к изменению домашнего регистратора для некоторых пользователей.

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

Роли серверов, сервисы и клиентское ПО, поддерживающие механизм распределения нагрузки с помощью DNS.

В таблице 2 перечислены роли серверов (включая сервисы) и клиентское ПО, механизм распределения нагрузки с помощью DNS.

Механизм распределения нагрузки с помощью DNS это одна часть процесса подключения пользователей, вторая часть - внутреннее распределение пользователей между серверами.

Распределение нагрузки с помощью DNS не означает полную независимость решения от аппаратных балансировщиков, они  продолжают быть необходимыми при распределении  http трафика (например, для сервиса адресной книги). Однако использования этого механизма для распределения SIP трафика существенно снижает комплексность и сложность внедрения.

В средах состоящих из серверов OCS 2007 (R2) и Lync аппаратный балансировщик необходим.

В следующих заметках мы продолжим знакомство с новым функционалом сервера Lync.

В Microsoft Lync Server 2010 появилась возможность обеспечения прохождения звонков в случае отказа сервера, обслуживающего пользователя (домашнего пула). При этом данная возможность реализована как для офисов, где непосредственно установлены пулы серверов Lync,  так и для филиалов в которых не развернуты пулы Lync (например при пропадании соединения с головным офисом).

Рассмотрим эти два сценария. В этой заметке будет рассмотрена логика обеспечения отказоустойчивости звонков в офисах, где установлены сервера MS Lync. Во второй части будет рассказано об обеспечении отказоустойчивости в офисах где не планируется установка серверов Lync.

Отказоустойчивость телефонных звонков в офисе, где установлены пулы серверов Lync.

В MS Lync 2010 появилась новый сервис – регистратор (Registrar). Этот сервис устанавливается вместе с другими компонентами на серверах редакций Standard, Enterprise или на серверах с ролью Director. Также этот компонент содержится в Устройствах для обеспечения связи в филиалах (Survival Branch Appliance) которые будут рассмотрены во второй части. Сервисы регистраторов объединяются в пулы, распределение нагрузки к которым осуществляется с помощью механизма DNS (также может быть использован аппаратный балансировщик). Пользователь подключается к FQDN имени пула регистраторов и с помощью механизма распределения нагрузки перенаправляется к одному из регистраторов в пуле.

Каждому пользователю, которому разрешено использование Enterprise Voice, присваивается определённый пул регистраторов, считающийся с момента присвоения его домашним пулом.

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

При этом построение таких сценариев возможно как с редакцией Enterprise, так и с помощью редакции Standard.

На рисунке 1 представлен сценарий обеспечения прохождения звонков в случае отказа одного из дата-центров.

Рис 1. Пример инфраструктуры, состоящей из двух дата-центров с обеспечением отказоустойчивости звонков.

В случае если у Вас небольшое количество пользователей и Вы собираетесь использовать для их обслуживания редакцию Standard, то Вы также можете настроить такой сценарий.

На рисунке 2 представлен такой сценарий. В случае отказа одного сервера пользователи будут подключаться ко второму.

Рисунок 2. Пример инфраструктуры, состоящей из серверов редакций Standard с обеспечением отказоустойчивости звонков.

Ага, могут подумать многие – теперь я могу построить отказоустойчивую систему с помощью редакции Standard. Не совсем так. Все таки этот механизм разработан для аварийных сценариев и не обеспечит весь функционал передачи голоса для клиентов.

В случае если происходит отказ сервера, и клиент перенаправляется на резервный пул, то многие возможности по передаче голоса ему не будут доступны, пока он обслуживается им.

При работе с резервным пулом пользователю будут доступны следующие возможности:

·         Входящие звонки (в случае обеспечения возможности маршрутизации, например провайдером SIP транкинг)

·         Исходящие звонки

·         Звонки внутри текущего расположения пользователя и между офисами

·         Удерживание и перевод звонков

·         Аутентификация и авторизация

·         Двустороннее внутрисайтовое общение с помощью мгновенных сообщений и адудио/видео

·         Запись деталей звонков

·         Делегирование звонка, групповой звонок, одновременный звонок на нескольких телефонах (Simulations Ringing)

·         Участие в конференциях, созданных другими пользователями (на других – работоспособных на этот момент пулах)

Пользователю будет недоступно

·         Создание конференций самим пользователем любых типов

·         Информация о доступности и маршрутизация на основе статуса «Не беспокоить»

·         Изменение настроек перенаправления звонков

·         Парковка звонков и группа ответа

Таким образом это решение предоставляет как мы видим лишь базовые сервисы в случае отказа домашнего сервиса.

Пользователь который будет обслуживается не основным, а резервным пулом увидит оповещение в своем клиенте.

Рис. 3. Интерфейс при Lync при подключении к домашнему пулу и к резервному.

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

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

На рисунке 4 показан процесс подключения клиента. На рисунке также присутствует опциональная роль Director. Она не обязательна, вместо нее могут выдаваться адреса  пулов.

Рис 4. Получение информации о пулах с помощью DNS.

Процесс будет следующий

1.       Клиент запрашивает SRV запись DNS для SIP домена. Например  _sipinternaltls._tcp.contoso.ru

2.       Ответ включает две DNS записи:

·         CSDirectorPool.contoso.ru:5061, Priority=0, Weight=10

·         CSPool2.contoso.ru:5061, Priority=1, Weight=10

3.       Клиент подключается к пулу серверов Director, производит аутентификацию.

4.       Пул серверов Director определяет к какому домашнему пулу принадлежит клиент и отправляет ответ SIP 301, содержащий первичный и резервный пулы для этого клиента

5.       В случае доступности первичного пула клиент подключается к нему

6.       При его недоступности клиент подключается к резервному пулу.

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

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

В предыдущей заметке мы познакомились с механизмом обеспечения прохождения звонков в случае отказа домашнего сервера пользователя. Как мы видели прохождение звонков осуществлялось с помощью второго пула серверов Standard или Enterprise.

Однако в силу ряда причин может быть неоправданным установка еще одного пула для филиалов, особенно если в них работает достаточно небольшое количество сотрудников. Кроме того для филиалов помимо отказа серверов может быть актуальна проблема пропадания связи между ним и головным офисом.

В этом случае на помощь может прийти такое устройство как Survival Branch Appliance (Устройство для обеспечения связи в филиалах) и именно оно будет освещено более подробно в ходе этой заметки.

Однако это не единственный вариант обеспечения связью сотрудников филиалов.

Давайте рассмотрим рекомендуемые варианты обеспечения связи в филиале в зависимости от его размера.

Мы можем разделить филиалы на три типа в зависимости от количества  - малый филиал с количеством пользователей до 25, средний филиал с количеством пользователей от 25 до 1 000 и большой филиал с количеством пользователей свыше 1 000.

С точки зрения экономической эффективности малые филиалы проще подключить с помощью интернета к пулу серверов в головном офисе. Основное предназначение этого устройства - средние филиалы с количеством пользователей от 25 до 1 000.  Для крупных филиалов с количеством пользователей свыше 1 000 рекомендуется устанавливать отдельные сервера, например редакции Standard.

Рис. 1 Позиционирование решений для филиалов.

Основное предназначение устройства SBA  - это филиалы с количеством пользователей от 25 до 1 000.

Устройства поставляются в виде аппаратного решения и содержат в себе следующие компоненты

• Windows Server® 2008 R2
• Роль Mediation сервера Lync
• Компонент регистратор (подробное описание компонента в части 1)
• Шлюз IP-PSTN (способен перенаправлять звонки через телефонную сеть в случае пропадания канала связи с головным офисом)
• SQL Express для хранения конфигурации

Устройство управляется из головного офиса, способно функционировать как в штатном режиме (при наличии связи с работоспособным пулом в головном офисе) так и в нештатном режиме (при отказе канала связи с головным офисом или пула серверов). При этом обеспечивает соединение с телефонными сетями общего пользования, маршрутизацию голосовых сообщений, перенаправление трафика через телефонные сети. Способно поддерживать до 1 000 пользователей.

Устройства поставляются партнерами по Объединенным коммуникациям. На данный момент о выпуске таких устройств объявили компании Audiocodes, Dialogic, Ferrari, Hewlett-Packard, NET.

Рис 2. Устройства SBA

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

• Входящие звонки
• Исходящие звонки
• Звонки внутри текущего расположения пользователя и между офисами (маршрутизируются через телефонную сеть)
• Удерживание и перевод звонков
• Аутентификация и авторизация
• Запись сообщений в голосовые почтовые ящики (перенаправляются в ExchangeUM в головной офис по телефонной линии)
• Чтение сообщений в голосовых почтовых ящиках (через телефонную линию)
• Двустороннее внутрисайтовое общение с помощью мгновенных сообщений и аудио/видео
• Запись деталей звонков
• Групповой звонок, одновременный звонок на нескольких телефонах (Simulations Ringing), звонки босс-админ
• Поиск контакта
• Участие в аудиоконференциях через телефонную сеть

Пользователю будет недоступно

• Межсайтовое общение (мгновенные сообщения, общий доступ к приложениям и т.д)
• Участие в конференциях мгновенных сообщений, видео и веб
• Информация о доступности и маршрутизация на основе статуса «Не беспокоить»
• Изменение настроек перенаправления звонков или информации о доступности
• Парковка звонков и группа ответа
• Список контактов

То есть Устройство обеспечивает базовые возможности голосовой связи для пользователей даже при отсутствии канала связи с головным офисом.

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

Рассмотрим процесс первого подключения пользователя.

Рис 3. Процесс первого подключения пользователя.

• 1. Клиент выполняет запрос на DNS SRV записи для своего SIP домена,  получает ответ, указывающий на пулы серверов Director (при их отсутствии на пулы серверов FrontEnd)

• 2. Пул серверов определяет что это первое подключение и перенаправляет для получения сертификата (401)
• 3. Клиент подключается к службам сертификации, проходит аутентификацию, получает сертификат
• 4. Сертификат реплицируется на SBA
• 5. Клиент пытается выполнить SIP регистрацию, получает ответ, перенаправляющий его на SBA и содержащий указания на основной регистратор (SBA) и резервный (пул серверов в головном офисе)
• 6. Клиент производит SIP регистрацию на устройстве SBA при этом кеширует его имя и IP адрес.

После первого подключения обеспечивается полная независимость клиента от головного офиса.

Рассмотрим процесс регистрации пользователя при различных сценариях.

Сценарий 1. Штатная ситуация, канал работоспособен - все устройства доступны.

В этом случае пользователь будет регистрироваться на устройстве SBA, даже в том случае, если он находится вне офиса. При нахождении вне офиса пользователь будет подключаться к серверам Edge головного офиса (находит его по записям в DNS), которые все равно перенаправляют его для регистрации на SBA.

Сценарий 2. Отказ канала связи.

Для пользователя, находящегося в филиале процесс регистрации не изменится, регистрация проходит на устройстве SBA. Пользователи находящиеся вне офиса будут регистрироваться на резервном регистраторе (пул серверов в головном офисе).

Сценарий 3. Отказ устройства SBA

В этом случае все пользователи будут регистрироваться на пуле серверов в головном офисе.

Рис 4. Регистрация пользователей при различных сценариях.

Как же будет проходить сигнальный и медиа трафик в различных сценариях.

Сценарий 1. Канал связи доступен, все устройства работоспособны.

В случае совершения звонков внутри филиала весь трафик (сигнальный и медиа) будет проходить внутри филиала. При звонках на внешние телефонные номера трафик будет проходить через SBA и далее в телефонную сеть.

Рис.5 Прохождение трафика при звонках внутри филиала и из филиала в телефонную сеть.

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

Если же пользователь филиала находится вне филиала, он регистрируется через Edge головного офиса (находит по записям DNS). Сигнальный трафик проходит через Edge, затем через SBA. Медиа трафик проходит через Edge между устройствами, участвующими в звонке.

Рис 6. Прохождение трафика при звонках в головной офис и при нахождении пользователя вне филиала.

Сценарий 2. Недоступен канал WAN или устройство SBA

Звонки внутри филиала проходят как обычно, также работает функционал передачи видео/мгновенных сообщений/предоставления доступа к приложениям внутри филиала, все сигналирование происходит через устройство SBA. Звонки в головной офис будут проходить через телефонную сеть. Медиа трафик будет приниматься шлюзом в голо��ном офисе и направляться вызываемому абоненту.

Рис 7. Прохождение трафика внутри филиала и при звонках в головной офис при неработоспособности канала WAN

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

В случае отказа устройства SBA все устройства будут регистрироваться на серверах головного офиса. Пользователям будет доступен весь функционал.

Рис 8. Прохождение трафика от внешнего пользователя и при отказе устройства SBA.

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

В следующих заметках мы продолжим знакомство с новым функционалом сервера Lync.