Главная Exchange/UC, Без рубрики, Новое Обзор нововведений Mirosoft Communications Server «14». Часть 2. Высокая доступность телефонии.
  • Обзор нововведений Mirosoft Communications Server «14». Часть 2. Высокая доступность телефонии.

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

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

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

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

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

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

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

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

    Во-первых,

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

    Во-вторых,

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

    В-третьих,

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

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

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

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

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

    В 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 или основные слайды доклада в конце статьи.

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

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

    Александр Донин

Комментарии

  1. […] This post was mentioned on Twitter by Андрей Ивашенцев, IT. IT said: Обзор нововведений Mirosoft Communications Server «14». Часть 2. Высокая доступность телефонии: Не секрет, что с в… http://bit.ly/bYAlRs […]