Список вебинаров русскоязычной команды технического консалтинга партнеров доступен по ссылке http://aka.ms/RUPTSOnline

Часть 5: Новые возможности сервера Microsoft Lync Server 2010. Распределение запросов с помощью DNS


В сервере 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

FQDN запись

IP/FQDN

Комментарий

_sip._tls.contoso.ru

pool.contoso.ru

Эта запись типа SRV используется для автоматического входа клиентами

fe1.contoso.ru

192.168.1.1

 

fe2.contoso.ru

192.168.1.2

 

fe3.contoso.ru

192.168.1.3

 

fe4.contoso.ru

192.168.1.4

 

pool.contoso.ru

192.168.1.1

192.168.1.2

192.168.1.3

192.168.1.4

Без механизма распределения нагрузки с помощью DNS эта запись должна состоять из IP адреса аппаратного балансировщика, который будет отвественным за распределение трафика между серверами

 

Клиент делает запрос на разрешение имени в 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

Примечание

Регистратор

Presence

Focus

SIPStack

Да

 

Conference Auto-Attendant

Response Group Service

Call Control Server

OOTY

Да

 

Access Edge внутренний

SIPStack

Да

 

Access Edge внешний

SIPStack

Да

 

Web Conferencing Edge внутренний

LDM

Нет

 

Web Conferencing Edge внутренний

LDM

Нет

 

MRAS Authentication сервис

OOTY

Да

 

A/V Edge  - внешний и внутренний

SRTP

Нет

Медиа трафик - да

Mediation

OOTY

Да

 

MS Office Communicator Web Access релиз OCS 2007 R2

Address book сервис

Distribution List Expansion

IIS

Нет

 

Data conferencing server

A/V conferencing server

App sharing conferencing server

 

Нет

Справедливо для клиентского трафика, сервер конференций -> фокус трафик = да

Office Communicator 2007 R2

Attendant Console

Lync

Aries

Add-ins

The 2007 R2 release of Microsoft Office Communicator Mobile

Custom client that uses Microsoft Office Communicator 2007 Automation API

 

Да

Все клиенты должны быть подключены к серверу Lync

 

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

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

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

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

Comments (0)

Skip to main content