Изучая Lync 2013 Preview. Отказоустойчивость между двумя дата центрами

Как вы наверное уже знаете недавно вышла новая версия Lync 2013. В состав версии вошло достаточно много новых функций со списком Вы можете познакомиться в официальной документации https://technet.microsoft.com/en-us/library/gg398676(v=ocs.15).

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

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

В заметке есть

- теоретический материал по технологиями отказоустойчивости между сайтами

- описание изменений в области отказоустойчивости в новой версии

- подробное описание по настройке и разбор логов клиента для понимания как это работает

Собственно для полного понимания, что изменилось и как это работает давайте вспомним как реализованы сервисы, предоставляемые клиенту начиная с Lync версии 2010.

Для обеспечения сценариев отказоустойчивости с версии 2010, сервисы обслуживающие клиентов Lync разнесены по двум разным компонентам. Были разделены компоненты, отвечающие за регистрацию пользователя и за предоставление так называемых пользовательских сервисов (user services).

Компонент регистрар, отвечающий за регистрацию пользователей устанавливается вместе с ролями Front End, Standard edition, Director и SBA (SBS), пользовательские же сервисы находятся на Back End, то бишь на сервере SQL. При пропадании связи с SQL пользователь может использовать компонент регистрар (например на SBA) но не может использовать функционал, зависящий от доступности пользовательских сервисов. К такому функционалу, например, относится адресная книга, контакты, участие в конференциях, информация о доступности.

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

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

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

Рис 1. Обеспечение отказоустойчивости между сайтами в Lync 2010

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

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

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

Картинка для Lync 2013 будет выглядеть следующим образом.

Рис 2. Обеспечение отказоустойчивости между сайтами в Lync 2013

Однако, есть одно ограничение при отказе сервера происходит автоматическая регистрация клиента на резервной регистраре в режиме отказоустойчивости (доступны все сервисы кроме зависящих от User Services)

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

Давайте посмотрим как это настраивается и заглянем в логи клиента при переключении с основного на резервный.

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

Pool02.contoso.com

Один Front End (192.168.100.180), SQL 2008 R2 (192.168.100.151)

Pool03.contoso.com

Один Front End (192.168.205.15), SQL 2008 R2 (192.168.205.10)

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

Пулы находятся в разных сайтах, pool02 находится в сайте Redmond, pool03 находится в сайте Toronto.

Рис 3. Топология тестовой инфраструктуры

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

Рис 4. Настройка резервного пула.

После этой процедуры необходимо запустить мастер установки Lync. даже если он у Вас уже настроен. Мастер установит новую службу Lync Backup и, затем, запустить ее

Start-CsWindowsService -Name LYNCBACKUP

Служба Lync Backup это новая служба, отвечающая за копирование данных между пулами.

Ниже приведены скриншоты служб Lync 2010 и Lync 2013. Обратите внимание на новую службу.

Рис 5. Службы Lync 2010

Рис 6. Службы Lync 2013

Видно что добавились новые службы LyncBackup и RTCXMPPGATEWAY (в Lync 2013 встроен XMPP шлюз позволяющий настраивать федерацию с XMPP службами, такими как Google Talk)

Для проверки того, что репликация происходит можно воспользоваться командлетом

Get-CsBackupServiceStatus  -poolFQDN имя_пула

Рис 7. Статус синхронизации данных между пулами.

Обратите внимание что в репликацию в том числе входят User Services и Conferencing Services.

Примечание: По умолчанию право запустить этот командлет предоставлено только входящим в группу RTCUniversalServerAdmins (администратор и группа CSAdministrator в эту группу не входят) Для возможности мониторинга репликации необходимо дать право использовать этот командлет. Ниже команда для предоставления права группе CSAdministrator

Set-CSBackupServiceConfiguration –Identity Global –AuthorizedUniversalGroups “CSAdministrator”

На этом настройка закончена, можно переходить к тестированию.

Итак имеется пользователь с домашним пулом pool02.contoso.com, я эмулировал отказ всего пула путем остановки службы rtcsrv на пуле pool02 и остановки службы SQL обслуживающей этот пул.

Клиент автоматически входит в режим resiliency (недоступен функционал, зависящий от User Services) Для возврата User Services ниже мы сделаем процедуру Failover.

Рис 8. Клиент в режиме resiliency

Давайте посмотрим на логи.

Итак первоначальная регистрация, видим что пользователь зарегистрировался на домашнем пуле pool02 (192.168.100.180)

Рис 9. Первоначальная регистрация пользователя на домашнем пуле.

Далее произошла остановка служб, клиент обратился к Director для перерегистрации, Director вместо ответа 200ОК на регистрацию выдал 301 Redirect в  котором предоставил основной и резервный пулы (адрес Director 192.168.100.154)

Рис 10. Перенаправление клиента ролью Director

Так как клиент не видит основного пула, он пытается зарегистрироваться на резервном, резервный пул зарегистрирует его по прошествии времени указанного в поле Voice Failover при настройке резеевного пула (в нашем случае 150 сек см рис. 4)

Рис 11. Регистрация клиента на резервном регистраре

Обратите внимание, что пользователь зарегистрирован на pool03 (192.168.205.15) сервер CS-FE13 (участник домашнего пула pool02) говорит о недоступности сервисов и в поле presense-state видно, что пользователь сидит на резервном пуле и ему пока недоступны пользовательские сервисы. Register action = added

При этом пользователь постоянно пытается перерегистрироваться, посылая команду Register, пока User Services недоступны службы недоступны сервер ему выдает результат register action = refreshed, User Services Unavailable. Это определяется полем Expires: 180

Рис 12. Попытки перерегистрации клиента

Для воврата пользовательских сервисов (по сути использования второго SQl  в другом сайте) необходимо вызвать процедуру failover путем выполнения командлета

Invoke-CsPoolFailover –PoolFQDN pool02.contoso.com -DisasterMode –Verbose

Рис 12. Вызов процедуры Failover

После этой процедуры в ответ на следующий Register от клиента, сервер присылает ответ fixed, и, ставит тайме Expired = 7200. Клиент переходит в состояние работы в полном функционале.

Рис 13. Ответ сервера

Рис 14. Клиент перешел автоматически в режим полного функционала.

Для возврата клиента на домашний пул (после восстановления работоспособности) необходимо выполнить команду

Invoke-CsPoolFailback –PoolFQDN pool02.contoso.com -Verbose

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

Николай

Comments

• Anonymous
  August 09, 2012
  Добрый день! Я правильно понимаю, что новый механизм отказоустойчивости работает одинаково как для Enterprise-пула, так и для Standard? Т.е. установив 2 сервера Front-End Standard в разных сайтах можно будет обеспечить точно такой же сценарий отказоустойчивости?

• Anonymous
  February 13, 2014
  Да, верно.

• Anonymous
  June 09, 2015
  Здравствуйте! Скажите пожалуйста, а как такое перемещение скажется на пользовательских политиках, маршрутизации вызовов? Ведь он по сути будет использовать свои Voice Rule и обращаться к своим PSTN шлюзам которые уже недоступны. Как отрабатывается такой сценарий?