Microsoft Communications Server “14” как телефонная станция. Высокая доступность.

Вместо введения

Не секрет, что с выходом CS "14" в Microsoft перестанут уходить от вопроса – способен ли их продукт заменить УАТС.

Ответ приблизительно такой – CS "14" продукт для объединённых / унифицированных коммуникаций (Unified Communications, UC). Телефония – только один из компонентов UC, и CS «14» его успешно реализует.

Сам глобальный вопрос можно заменить на несколько более конкретных, типа «а реализует ли ваш продукт…»:

  • высокую доступность (все слышали про 5 девяток, то есть 99,999% работы службы или 5,26 минуты простоя в год)
  • решение для удаленныхо офисов (хорошо бы поставить только шлюз с возможностью регистрации на нем телефонов при выходе из строя канала)
  • контроль трафика через каналы между офисами (пять звонков канал «выдержит», при шести не пройдет трафик бизнес-приложений, а канал расширить нельзя; значит нужно «рубить»)
  • базовый и расширенный функционал, доступный пользователю / абоненту (переадресация, конференции, парковка звонка, группы перехвата (pickup groups) и т.д.)
  • базовый и расширенный функционал, доступный администратору (манипуляции c номерами, классы вызовов, маршрутизация, группы поиска (Hunt Groups) и т.д.)
  • мониторинг (нужно иметь возможность выяснить какая «неприличная женщина» наговорила на ####$ в этом месяце или разобраться, почему "Юрий Бенедиктович" при звонках плохо слышит "Виктора Харитоновича")

Сегодня я постараюсь ответить на первые два вопроса. Остальные темы надеюсь осветить позднее.

Высокая доступность – ставим кластер

Стандартная практика построения отказоустойчивого решения для LCS / OCS – создание «пула» из двух и более серверов OCS с ролью Front-End, объединенных балансировщиками нагрузки, и кластера SQL. При любом «чихе» со стороны пользователя, Front-end лезет на SQL и обновляет соответствующую базу.

С выходом CS "14" в этой схеме произойдут небольшие изменения.

Во-первых,

пользователи регистрируются непосредственно на серверах Front-End. Для тех, кто знаком с работой SIP — на серверы перенесен SIP-регистратор (SIP registrar). Специальный механизм отслеживает, чтоб все устройства, на которых пользователь «залогинен», подключались к одному и тому же SIP-регистратору. В результате, даже если выйдет из строя кластер SQL, пользователи смогут зарегистрироваться и совершать телефонные вызовы.

Во-вторых,

благодаря механизму DNS-балансировки, большинство запросов «идет» непосредственно на серверы Front-End, минуя балансировщик. Исключение составляют веб-запросы. Со слов продуктовой группы MS – это позволит упростить настройку балансировщиков и использовать более дешевые варианты. А на мой взгляд, через некоторое время после выхода RTM, в Microsoft всё–таки объявят поддержку ISA / TMG. C балансировкой веб-трафика они неплохо справляются. J Да, возвращаясь к теме: это означает, что при выходе из строя балансировщиков нагрузки пользователи смогут зарегистрироваться, совершать телефонные вызовы и работать с большей частью функционала CS «14».

В-третьих,

даже, если сервер Front-end, на котором вы зарегистрированы, вышел из строя, в то время как вы говорите по телефону или даже участвуете в конференции, связь не прервется. Главное, чтоб был жив хотя-бы один сервер Front-End в пуле.

В-четвертых,

cтало проще выполнять плановое отключение серверов пула или устанавливать обновления. При включении функции «server draining» сервер Front-End начинает перенаправлять новые сессии и вызовы на другие серверы. Как только сессий на сервере не осталось – над ним можно спокойно издеваться / выполнять плановые работы.

Хотелось бы увидеть еще поддержку SQL Database Mirroring, но пока, увы. Я на эту тему прожужжал продуктовой группе все уши. J И не я один. Посмотрим, подождем.

Поиск сервера

В LCS / OCS для поиска сервера используется служба DNS. Клиенты ищут записи «А» и «SRV» с определенными именами в своем домене, обычно определяемом доменной частью SIP-адреса.

Теперь добавился механизм получения имени сервера через DHCP. Опция 120 согласно RFC 3361 как раз отвечает за имя SIP-сервера, так что клиенты без проблем получат адрес сервера в своем филиале при выходе из строя канала до центрального офиса. Раньше это была не очень тривиальная задача, особенно, если говорить об аппаратных телефонах.

Катострофоустойчивость – еще больше надежности

Возможность создания территориально распределенного кластера есть и в OCS 2007 R2. Данная конфигурация описана и официально поддерживается.

В CS «14» идея ГЕО-кластера получила свое развитие, но, кроме того, добавился еще один механизм. Для каждого пула можно указать резервный пул. Единожды подключившись к OCS, клиент сохраняет в КЭШ две записи: Primary pool и Backup pool. Кстати, резервный пул может быть основным для других клиентов. Соответственно, при выходе основанного пула из строя, клиент начнет «долбить» оба пула по очереди. Резервный пул постоянно «мониторит» работу основного, и если обнаруживает, что тот недоступен в течение заранее заданного времени, начнет принимать клиентов с основного. Пользователи, как и в случае с недоступностью SQL, смогут зарегистрироваться и совершать телефонные вызовы.

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

Решение для филиалов

Опять немного истории. Партнеры Microsoft, выпускающие голосовые шлюзы, уже давно стали встраивать в свое оборудование модуль с сервером OCS Mediation, отвечающим за конвертирование голосовых кодеков, используемых Microsoft, в стандартный кодек G.711. Подобные шлюзы, в терминологии Microsoft, называются гибридными. При наличии надежного канала, гибридные шлюзы предлагалось ставить в региональные офисы компаний внедривших OCS. Тем более, что некоторые модели могут выступать маршрутизвторами и организовывать VPN каналы.

В CS "14" к роли Mediation добавили, как вы наверно уже догадались, SIP-регистратор, и обозвали такой шлюз Survivable Branch Appliance или SBA. По заверениям Microsoft, SBA способен регистрировать на себе до 1000 пользователей. При установке, SBA соотносится с одним из пулов и использует его SQL. При выходе из строя канала до центрального офиса, пользователи … правильно… смогут зарегистрироваться и совершать телефонные вызовы. Само собой, звонить они смогут друг другу или в ТфОП. А через ТфОП, если у пользователей в других филиалах прямые номера, и им, без изменения «user experience».

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

Если вам интересно, какой именно функционал потеряют пользователи при выходе из строя какого-либо компонента OCS – смотрите видео доклада "Microsoft Communications Server "14": Voice Architecture and Planning for High Availability" на Teched 2010 или основные слайды доклада в конце статьи.

Если резюмировать сказанное выше, то выводы будет звучать приблизительно так:

  • При минимуме затрат – два сервера CS "14" стандартной редакции и два голосовых шлюза без SBA, возможно обеспечить высокую доступность и катастрофоустойчивость для основных функций телефонии.
  • В зависимости от требуемых показателей доступности телефонии, конфигурации сети и доступных средств, можно подобрать наиболее подходящую конфигурацию CS "14".

 

комментариев 7 to “Microsoft Communications Server “14” как телефонная станция. Высокая доступность.”

  1. Илгиз Says:

    🙂 почему только сейчас MS готова смело ответить, что CS14 готов заменить УАТС?Ведь есть же функционал Enterprise Voice в OCS 2007 R2 собственно реализующий роль УАТС, пусть не так богато как продвинутые, современные АТС, но всё же.

  2. Илгиз Says:

    От чего "смелость" не уходить от вопросов то появляется?—На мой взгляд и CS14, как и OCS 2007 R2, на данный момент не способен заменить АТС в очень большом количестве российских компаний из-за одного ключевого пункта — стоимость конечных устройств — настольных телефонов.

  3. Alexander Says:

    по первому коментарию: Так и есть, но всё зависит от масштабов. Для мелкого и среднего бизнеса ключевым параметром является цена и тут многим не нравилось что для высокой доступности голоса требуется много дорогих компонентов (два балансировщика, 4 сервера, СХД).Для крупного более важен функционал и в особенности, всё что связанно с региональными офисами. Это как раз одни из улучшениний в CS "14"

  4. Alexander Says:

    по второму коментарию: Как я говорил, стоимость телефонов для CS "14" значительно ниже.🙂 Кстати, советую обратить внимание на текущую стоимость CX700. Она тоже снизилась.

  5. Компоненты Lync Server 2010 « всё о Microsoft UC Says:

    […] Back-end database – база данных Front End Server. Располагается на выделенном сервере Microsoft SQL Server. В настоящий момент поддерживаются SQL Server 2005 SP3 или SQL Server 2008 SP1 редакции Standard или Enterprise, обязательно x64. Front End Server обращается к Back-end database практически по каждому чиху. Например, для изменения статуса абонента либо для получения списка контактов абонента для передачи на клиент в момент входа. Однако некоторая информация содержится в SQL Express непосредственно на Front End Server, о чем я уже писал . […]

  6. ITband.ru » Компоненты Lync Server 2010 Says:

    […] Back-end database – база данных Front End Server. Располагается на выделенном сервере Microsoft SQL Server. В настоящий момент поддерживаются SQL Server 2005 SP3 или SQL Server 2008 SP1 редакции Standard или Enterprise, обязательно x64. Front End Server обращается к Back-end database практически по каждому чиху. Например, для изменения статуса абонента либо для получения списка контактов абонента для передачи на клиент в момент входа. Однако некоторая информация содержится в SQL Express непосредственно на Front End Server, о чем я уже писал . […]

  7. Размышления о высокой доступности UC решений от MS « всё о Microsoft UC Says:

    […] 3. Послабление требований. Допустим, из всего функционала Lync для вас критичным является только телефония. И Вы готовы ради существенной экономии на время восстановления какого-либо компонента решения отказаться от IM и различных конференций. В этом случае Вам уже не требуются жутко дорогие дисковые хранилища с синхронной репликацией. Ведь в случае выхода из строя кластера SQL, телефония Lync всё рано будет работать. А если вы готовы на 5-10 минут остаться без телефонии в случае непредвиденной ситуации, вы можете отказаться и от SQL серверов вообще и перейти на использование двух серверов Lync Server Standard вместо кластера Lync Server Front End. Об этом я уже писал в одной из статей. […]

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s


%d такие блоггеры, как: