Главная Exchange/UC, Без рубрики, Новое Введение в архитектуру Lync Server 2010 (Часть 2)
  • Введение в архитектуру Lync Server 2010 (Часть 2)

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

     

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

     

    Резюмирую, внешние клиенты бывают:

     

    • Сотрудники вашей компании, запустившие Lync клиента снаружи
    • Сотрудники других организации, использующих Lync (федеративные клиенты)
    • Анонимные пользователи, не имеющий учетных данных, но приглашенные в конференции
    • Клиенты публичных клиентов обмена мгновенными сообщениями

    Если все это вам нужно, то можно смело разворачивать пограничный Edge, который будет контролировать трафик между внешними клиентами и внутренним пулом Front End.

     

    Edge сервер состоит из нескольких сервисов:

     

    Access Edge – предоставляет единую точку входа SIP трафика. Дает возможность подключаться Lync клиентам снаружи и общаться с федеративными и публичными клиентами. Сервис обязательный, от него отказаться нельзя.

    Web Conferencing Edge – позволяет внешним пользователям подключаться ко встречам, организованным внутренними сотрудники.

    A/V Edge – открывает возможности аудио, видео общения для внешних и со внешними пользователями. (а так же передачу файлов и общий доступ приложений)

     Edge

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

    Еще одним сервером в DMZ является Reverse Prozy, которым является либо IIS, либо TMG, позволяющий внешним клиентам:

     

    • Скачивать содержимое встреч
    • Скачивать адресную книгу
    • Разворачивать  группы рассылок
    • Использовать simple URLs и многое другое

     

    Single Consolidated Edge Perimeter Network diagram

    С портами открываемыми на брандмауэрах получается интересная история, их довольно много. (один диапазон 50000-59999 уже неплохо) В качестве шпаргалки я использую картинку с technet, показывающую протоколы и порты для консолидированной топологии с одним Edge. (протоколы все те же, что и внутри RTP, PSOM, STUN,SIP)

     

    Сертификаты

     

    Открыть порты дело не сложное, гораздо сложней решить вопрос с сертификатами. Внедряя Lync нужно понимать, что без сертификатов X.509 вам не обойтись. Lync Server 2010 шифрует практически все коммуникации. Вам понадобится сертификат для внутреннего Front End сервера, для Edge сервера, причем как для внутренних так и для  внешних коммуникаций.

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

    Для Front End сервера можно сэкономить и получить сертификат от внутреннего центра сертификации (если он есть). Т.к подразумевается что внутренние клиенты доверяют внутреннему центру, могут получить доступ к CRL, построить цепочку, проверить подпись, т.е выполнить все штатные проверки.

    Сертификат Front End сервера выдается на FQDN пула, а поскольку в стандарте FQDN пула совпадает с FQDN сервера, следовательно на него. В качестве SAN задаются Simple Url (есть такие ссылки), имена веб-серверов, указанных при построении топологии и конструкции состоящей из имени сервера и имени sip домена.

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

    Сертификат для внешних коммуникаций придется покупать, связано это с доверием. Поскольку общение будет осуществляться с другими системами, то  выданного внутренним центром сертификата недостаточно. В качестве основного имени внешнего сертификата указывается имя sip интерфейса (а-ля access.contoso.com), в качестве SAN указываются опять же имя sip интерфейса (а-ля access.contoso.com)!!! Так же в SAN добавляется имя Web Conferencing Edge (webcon.contoso.com) по ваш sip домен имя sip.contoso.com.

    К чему я это пишу? К тому, что нужно четко понимать, внедрение Lync Server 2010 требует от вас сертификатов и кроме того, что они должны быть доверенные, очень важным аспектом являются имена, прописанные в SAN. (Subject Alternate Name)

     

    Маршруты трафика

     

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

     

    Удаленный пользователь Lync звонит пользователя из локальной сети:

    [Lync] <-> [Edge] <-> [Lync]

     

    Если оба клиента подключаются удаленно:

    Первая попытка установки соединения точка-точка:  [Lync] <-> [Lync]

    Если соединение точка-точка не возможно: [Lync] <-> [Edge] <-> [Lync]

     

    Важно: Стоит отметить, что медиа данные передаются между клиентами в режиме "точка-точка" только в ситуации, когда в конференции участвуют 2 клиента, три и более это всегда передача через сервер.

     

    В случае когда из одной компании, где используется Lync Server 2010 звонят в другую компанию, где так же есть  Lync Server 2010:

    [Lync] <-> [Edge1] <-> [Edge2] <-> [Lync]

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

     

    Требование к каналам.

    Один из самых частых вопросов касается требований к каналам. Если кратко, требования очень сильно зависят от того, что вы используете (голос, видео), какое при этом задано разрешение и какой кодек используется. На текущий момент из кодеков доступны RTAudio, RTVideo,Siren, G.711, G.722. У производителя есть таблица требований к каналам, о нее и предлагаю отталкиваться.

    Получается, что соединении точка-точка для разговора с видео понадобится 62 Кбит/с на аудио (кодек RTAudio Wideband) и 610 Кбит/с  (кодек RTVideo и режим Main video VGA)

    В случае аудио / видео конференций, а именно когда начальное количество участников больше двух, требования меняются. Кодек RTAudio теперь применяться не может (не работает он в конференциях) и используется G.722 или Siren. А у того же G.722 требование 100  Кбит/с. По видео ситуация не меняется там так же может использоваться RTVideo и все те же  610 Кбит/с (режим Main video VGA)

    Полная информация по требования к каналу есть на сайте technet. Либо же можно воспользоваться Lync 2010 Bandwidth Calculator, предствляющим из себя Excel файл для расчета необходимой ширины каналов.

     

    Calc

    Сам калькулятор, как документ требует вдумчивого отношения, но результат того стоит.

     

    Внешние DNS записи

     

    В прошлой статье я говорил о том, что во внутреннем DNS необходимо добавить SRV запись _sipinternaltls._tcp.<domain> для автоконфигурирования внутренних клиентов.  После установки Edge сервера так же придется править DNS, но уже внешнюю зону вашего SIP домена. Прежде всего нужно добавить три записи типа А, по которым ваш сервер доступен снаружи. (Даже если Edge установлен со всеми сервисами, т.е консолидировано)

     

    Обычно это :

     

    • access.contoso.com (Имя Access Edge)
    • webcon.contoso.com (Web Conferencing Edge)
    • av.contoso.com (A/V Edge )

     

    Далее создаем SRV записи:

     

    • _sip._tls.contoso.com 443 ссылающуюся на access.contoso.com (запись нужна для авто конфигурирования внешних клиентов Lync)
    • _sipfederationtls._tcp.contoso.com 5061 ссылающуюся на access.contoso.com (запись нужна для того, чтобы другие организации могли найти ваш Edge для установки соединений)

     

    Выводы

     

    Для полноценного внедрения Lync Server 2010 второй сервер в DMZ необходим. При  появлении Edge сервера важную роль начинают играть сертификаты,  в данном случае внутренним уже не отделаться, будет необходимо покупать. Понятно, что по каждому вопросы можно писать отдельный труд, но в задачу входило кратко осветить основные моменты.

     

     

    MCT/MVP Илья Рудь

Комментарии

  1. такой калькулятор – мозгопудрилятор

  2. С сертификатами полнростью согласен, притом для понимания того что же нужно покупать хорошо бы пользоваться Lync Planning Tool. Можно юзать и сертификаты ваыданые внут реним центром сертификации, но тогда есть нюанся с подключением мобильных клиентов, в особенности iOS и WP7. Так же потребуется устанавливать свой корневой сертификат на Edgе федеративного партнера, но и тут будут нюансы.

  3. интересно будет почитать про федерации, например хотя бы с майкрософт. )

  4. “про федерации хотя бы с майкрософт” – это в основном нужно самим интеграторам, если они работают на субподряде у MCS. А больше вроде как и незачем. Раньше, наверное, был смысл устраивать федерацию ради доступа в ICQ, но сейчас шлюзование отрублено (со стороны mail.ru).

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

  6. Не раскрыт вопрос по реверс-прокси совсем, хотя с ним больше всего проблем как правило.
    Нужен ли третий сервер по Reverse Proxy? можно ли совместить эти роли?
    официально Microsoft саппортит только TMG кажется, который вместе с Lync Edge не живет.

    С мобильными клиентами кстати штука в том, что они обязательно ходят через периметр, даже находясь внутри. Поэтому для мобильных клиентов автоматом выскакивают и edge и reverse proxy.

  7. Константин
    В общем ваши заявления по поводу не возможности работы мобилной части без эйд не очень основательны.
    В большей части возникает проблема с федерацией. зачем? Push. вот тут начинаются танцы.
    Остальной функционал в общем-то работает без проблем. весь вопрос в правильной настройке днс.
    Ну и сертификаты у вас должны быть с правильными Alias.

  8. Илья, не полный перечень кодеков – так же доступен кодек H.263 http://technet.microsoft.com/en-us/lync/hh239757.aspx

    Если вы просматривали когда-нибудь трафик с клиента SDP это так же отчетливо видно:

    a=rtpmap:121 x-rtvc1/90000
    a=rtpmap:34 H263/90000
    a=encryption:rejected

  9. Спасибо, буду знать.

  10. Хотел еще оставить комменты по поводу TMG. И вправду официально TMG, как натирующий сервер не поддерживается MS для развертывания Lync. Лично я до конца не понимаю почему, хотя причины то четко описаны Static NAT TMG якобы не поддерживает. Дл тестовых сред и небольших пилотов которые не планируется поддерживать тех саппортом от MS, TMG можно рассматривать.
    Я лично через TMG не тестировал только федерацию, но удаленный голос, видео, собрания, шаринги(доска, десктоп и т.д ) тестировал.

  11. Здравствуйте, я развернул в тестовой сети Lync 2010, создал DNS записи и интегрировал с OWA. Проблема в том , что в OWA я не могу залогинится в IM. Там отображается надпись “Instant Messaging isn’t available right now. The Contact List will appear when the service becomes available.” и никаких ошибок ни в Exchange ни в Lync. Через Lync-Client все работает и корректно отображается.