Требования DNS для Skype для бизнеса

Skype for Business Server 2015
 

Дата изменения раздела:2016-12-20

Сводка.  В этом разделе представлены рекомендации по DNS, с которыми следует ознакомиться перед реализацией Skype для бизнеса Server 2015.

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

Skype для бизнеса Server использует DNS в следующих целях:

  • для обнаружения внутренних серверов или пулов для межсерверной связи;

  • чтобы позволить клиентам обнаруживать переднего плана или Standard Edition, используемые для различных SIP-транзакций;

  • чтобы позволить устройствам объединенных коммуникаций (UC), которые не вошли в систему, обнаруживать переднего плана или Standard Edition с веб-службой обновления устройств, получать обновления и отправлять журналы;

  • чтобы позволить внешним серверам и клиентам подключаться к Пограничные серверы или обратному прокси-серверу HTTP для обмена мгновенными сообщениями или проведения конференций;

  • чтобы позволить внешним устройствам UC подключаться к веб-службе обновления устройств через Пограничные серверы или обратный прокси-сервер HTTP и получать обновления;

  • чтобы разрешить мобильным клиентам автоматически обнаруживать ресурсы веб-служб без того, чтобы пользователи вручную вводили URL-адреса в параметрах устройства.

Для получения сведений о требованиях к службе доменных имен (DNS) используйте следующую блок-схему.

importantВажно!
Skype для бизнеса Server поддерживает IPv6-адреса. Для использования IPv6-адресов вам потребуется настроить DNS для поддержки протокола IP версии 6, а также настроить DNS-записи AAAA (также называемые "четыре A"). При наличии развертываний, в которых совместно используются IPv4- и IPv6-адреса, рекомендуется настроить как записи A для IP версии 4, так и записи AAAA для IP версии 6. Даже если развертывание полностью переведено на протокол IP версии 6, DNS-записи IP версии 4 могут потребоваться в случае, если внешние пользователи используют протокол IP версии 4.

Определение требований DNS (блок-схема)

Блок-схема DNS без разделения вычислительных мощностей
importantВажно!
По умолчанию имя компьютера, который не присоединен к домену, является именем узла, а не полным доменным именем. топологий использует полные доменные имена, а не имена узлов. Поэтому для компьютера, развертываемого в качестве пограничного сервера, не присоединенного к домену, вам потребуется указать DNS-суффикс. При назначении полных доменных имен серверам под управлением Skype для бизнеса Server используйте только стандартные символы (включая A–Z, a–z, 0–9 и дефисы). Не используйте символы Юникода или символы подчеркивания. Зачастую нестандартные символы в полном доменном имени не поддерживаются внешними DNS-серверами и общедоступными центрами сертификации (например, полное доменное имя должно быть назначено имени субъекта сертификата). Дополнительные сведения см. в разделе Настройка записей узлов DNS для Lync Server 2013

Процедуры Skype для бизнеса и Lync 2013 аналогичны процедурам поиска служб и осуществления доступа к ним клиентам в Skype для бизнеса Server. Примечательным исключением является приложение Магазина Lync Windows, которое использует другой процесс обнаружения служб. В этом разделе приведены два сценария поиска служб клиентами; в первом сценарии задействован традиционный метод с использованием серии записей хоста A и SRV, а во втором сценарии используются только записи службы автоматического обнаружения. Для всех клиентов процесс опроса DNS продолжается до тех пор, пока не будет возвращен успешный запрос или пока список возможных записей DNS не будет исчерпан и клиенту не будет возвращена окончательная ошибка.

Для всех клиентов, кроме Магазина Lync Windows, в ходе поиска DNS выполняется параллельный просмотр записей SRV. Клиент получает записи в следующем порядке:

  1. lyncdiscoverinternal. <domain>    запись A (узла) для службы автоматического обнаружения на внутренних веб-службах

  2. lyncdiscover. <domain>    запись A (узла) для службы автоматического обнаружения на внешних веб-службах

  3. _sipinternaltls._tcp. <domain>    запись SRV (указателя служб) для внутренних подключений TLS

  4. _sipinternal._tcp. <domain>    запись SRV (указателя служб) для внутренних подключений TCP (выполняется только в том случае, если протокол TCP разрешен)

  5. _sip._tls. <domain>    запись SRV (указателя служб) для внешних подключений TLS

  6. sipinternal. <domain>    запись A (узла) для переднего плана или Директор; может разрешаться только во внутренней сети

  7. sip. <domain>    запись A (узла) для переднего плана или Директор во внутренней сети или доступа, когда клиент является внешним

  8. sipexternal. <domain>    запись A (узла) для доступа, когда клиент является внешним

Магазина Lync Windows полностью изменяет этот процесс, так как используются две записи:

  1. lyncdiscoverinternal. <domain>    запись A (узла) для службы автоматического обнаружения на внутренних веб-службах

  2. lyncdiscover. <domain>    запись A (узла) для службы автоматического обнаружения на внешних веб-службах

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

Различие между методами, используемыми для новых клиентов, и методами, использованными для предыдущих клиентов, заключается в том, что служба автоматического обнаружения становится предпочтительным методам поиска всех служб.

После установления подключения служба автообнаружения возвращает все URL-адреса веб-служб для домашнего пула пользователя, включая URL-адреса служб Mobility Service (известных как Mcx в соответствии с виртуальным каталогом, созданным для службы в IIS), Microsoft Lync Web App и веб-планировщика. Однако внутренний и внешний URL-адрес службы Mobility Service связаны с полным доменным именем внешних веб-служб. Следовательно, независимо от того, является ли мобильное устройство внутренним или внешним по отношению к сети, устройство всегда будет подключаться к службе Mobility Service через обратный прокси-сервер.

Служба автообнаружения также возвращает ссылки на Internal/UCWA, External/UCWA и UCWA. Эти записи относятся к веб-компоненту веб-интерфейса API объединенных коммуникаций (UCWA). В настоящее время используется только запись UCWA и предоставляется ссылка на URL-адрес для веб-компонента. UCWA используется мобильными клиентами Skype для бизнеса вместо службы Mcx Mobility Service, используемой клиентами Lync 2010 Mobile.

noteПримечание.
При создании записей SRV важно помнить, что они должны указывать на DNS-записи A и AAAA (при использовании IPv6-адресов) в том же домене, в котором была создана DNS-запись SRV. Например, если запись SRV относится к домену contoso.com, запись A и AAAA (если используется адресация IPv6), на которую она указывает, не может относиться к домену fabrikam.com.
tipСовет.
Конфигурация по умолчанию направляет весь трафик мобильного клиента через внешний сайт. Вы можете изменить параметры для возвращения только внутреннего URL-адреса, если это более предпочтительно в соответствии с вашими требованиями. В этой конфигурации пользователи смогут воспользоваться мобильными приложениями Skype для бизнеса на мобильных устройствах только при нахождении в сети организации. Для определения этой конфигурации необходимо использовать командлет Set-CsMcxConfiguration .
noteПримечание.
Несмотря на то что мобильные приложения также могут подключаться к остальным службам Skype для бизнеса Server, например службе адресной книги, веб-запросы внутреннего мобильного приложения отправляются внешнему полному доменному имени только для службы Mobility Service. Для остальных запросов служб, например запросов адресной книги, эта конфигурация не требуется.

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

  • https:// <ExtPoolFQDN> /Autodiscover/autodiscoverservice.svc/Root для внешнего доступа;

  • https:// <IntPoolFQDN> /AutoDiscover/AutoDiscover.svc/Root для внутреннего доступа.

Вместо обнаружения вручную мы рекомендуем использовать автоматическое обнаружение. Однако обнаружение вручную позволяет устранять неполадки подключения мобильных устройств.

Разделенную службу доменных имен (DNS) иногда называют комбинированной DNS или расщеплением горизонта DNS. Под этим названием понимают конфигурацию DNS, в которой две зоны DNS имеют одно пространство имен, но при этом одна зона DNS обслуживает только внутренние запросы, а вторая зона DNS – только внешние запросы. Однако при этом большинство записей расположения службы (SRV) и записей A, содержащихся во внутренней DNS, будут отсутствовать во внешней DNS и наоборот. Если одна DNS-запись содержится во внутренней и внешней зоне DNS (например, www.contoso.com), возвращаемый IP-адрес будет зависеть от того, какая зона является источником запроса (внутренняя или внешняя).

importantВажно!
В настоящее время разделенная DNS не поддерживается для мобильной службы, а конкретнее для службы автообнаружения или записей DNS LyncDiscover и LyncDiscoverInternal. Запись LyncDiscover должна быть определена на внешнем DNS-сервере, а запись LyncDiscoverInternal – на внутреннем.

В этом разделе будет использоваться термин разделенная DNS.

Ниже приведены сводные данные о типах DNS-записей, требуемых для внутренней и внешней зоны, используемые при настройке разделенной DNS. Дополнительные сведения см. в разделе Сценарии доступа внешних пользователей в Lync Server 2013.

Внутренняя DNS:

  • Содержит доверенную зону DNS contoso.com.

  • Внутренняя зона contoso.com содержит:

    • DNS-записи A и AAAA (при использовании IPv6-адресов) и записи SRV для автоматической настройки внутреннего клиента Skype для бизнеса Server (необязательно).

    • DNS-записи A и AAAA (при использовании IPv6-адресов) или CNAME-записи для автоматического обнаружения веб-служб Skype для бизнеса Server (необязательно).

    • DNS-записи A и AAAA (при использовании IPv6-адресов) для имени интерфейсного пула, имени директора или имени пула директоров и всех внутренних серверов с установленным Skype для бизнеса Server в сети организации.

    • DNS-записи A и AAAA (при использовании адресации IPv6) для внутреннего пограничного интерфейса каждого Skype для бизнеса Server и пограничного сервера в сети периметра.

    • DNS-записи A и AAAA (при использовании IPv6-адресов) для внутреннего интерфейса каждого обратного прокси-сервера в сети периметра (необязательно для управления обратным прокси-сервером).

    • Для разрешения запросов к contoso.com все внутренние пограничные интерфейсы Skype для бизнеса Server  Пограничный сервер в сети периметра используют внутреннюю зону DNS.

    • Для разрешения запросов к contoso.com все серверы Skype для бизнеса Server и клиенты Skype для бизнеса в сети организации используют внутренние DNS-серверы либо используют файл HOSTS на каждом пограничном сервере и просматривают записи A и AAAA (при использовании IPv6-адресов) для сервера следующего перехода, в частности директора, виртуального IP-адреса директора, виртуального IP-адреса интерфейсного пула или сервера Standard Edition.

Внешняя DNS:

  • Содержит доверенную зону DNS contoso.com.

  • Внешняя зона contoso.com содержит:

    • DNS-записи A и AAAA (при использовании IPv6-адресов) и записи SRV для автоматической настройки клиента Skype для бизнеса Server (необязательно).

    • DNS-записи A и AAAA (при использовании IPv6-адресов) или записи CNAME для автоматического обнаружения веб-служб Skype для бизнеса Server, предназначенных для функций мобильной связи.

    • DNS-записи A и AAAA (при использовании IPv6-адресов) и записи SRV для внешнего пограничного интерфейса каждого Skype для бизнеса Server, пограничного сервера или виртуального IP-адреса аппаратного балансировщика нагрузки в сети периметра.

    • DNS-записи A и AAAA (при использовании IPv6-адресов) для внешнего интерфейса обратного прокси-сервера или виртуального IP-адреса пула обратных прокси-серверов в сети периметра.

При использовании разделенной DNS пользователь Skype для бизнеса Server, который выполняет вход из внутренней сети, может воспользоваться преимуществом автоматической настройки, если внутренняя зона DNS содержит запись SRV _sipinternaltls._tcp для каждого используемого домена SIP. Но если разделенная DNS не используется, то внутренняя автоматическая настройка клиентов Skype для бизнеса не будет работать до тех пор, пока не будет реализован один из обходных путей, описанных далее в этом разделе. Это связано с тем, что Skype для бизнеса Server требует, чтобы URI SIP пользователя совпадал с доменом интерфейсного пула, предназначенного для автоматической настройки. Это также имеет место в более ранних версиях Communicator.

Например, при использовании двух доменов SIP потребуются следующие записи службы DNS (SRV):

  • Если пользователь выполняет вход с учетной записью bob@contoso.com, то для автоматической настройки достаточно добавить следующую запись SRV, поскольку домен SIP пользователя (contoso.com) совпадает с доменом автоматической настройки интерфейсного пула:

     _sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com

  • Если пользователь выполняет вход с учетной записью alice@fabrikam.com, то для автоматической настройки второго домена SIP необходимо использовать следующую DNS-запись SRV.

     _sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

Для сравнения: если пользователь выполняет вход с учетной записью tim@litwareinc.com, то для автоматической настройки нельзя использовать следующую DNS-запись SRV, поскольку домен SIP клиента (litwareinc.com) не совпадает с доменом, в котором находится пул (fabrikam.com):

 _sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

Если для клиентов Skype для бизнеса требуется автоматическая настройка, то выберите один из следующих вариантов:

  • Объекты групповой политики.    Используйте объекты групповой политики (GPO) для добавления правильных серверных значений.

    noteПримечание.
    Этот вариант не включает автоматическую настройку, однако он автоматизирует процесс ручной настройки, поэтому при использовании этого варианта записи SRV, связанные с автоматической настройкой, не требуются.
  • Совпадающая внутренняя зона.    Создайте зону во внутренней DNS, которая соответствует внешней зоне DNS (например, contoso.com), и создайте DNS-записи A и AAAA (при использовании IPv6-адресов), соответствующие пулу Skype для бизнеса Server, используемому для автоматической настройки. Например, если пользователь расположен на сервере pool01.contoso.net, но выполняет вход в Skype для бизнеса с учетной записью bob@contoso.com, создайте внутреннюю зону DNS contoso.com, а затем внутри нее создайте DNS-запись A и AAAA (при использовании IPv6-адресов) для pool01.contoso.com.

  • Точное определение внутренней зоны.    Если по каким-либо причинам нельзя создать всю зону во внутренней DNS, вы можете создать точно заданные (выделенные) зоны, которые соответствуют записям SRV, требуемым для автоматической настройки, и затем заполнить их с помощью средства dnscmd.exe. Средство dnscmd.exe является обязательным, поскольку пользовательский интерфейс DNS не поддерживает создание точно заданных зон. Например, при наличии домена SIP contoso.com и интерфейсного пула pool01, который содержит два сервера переднего плана, вам потребуются следующие точно определенные зоны и записи A во внутренней DNS:

    dnscmd . /zoneadd _sipinternaltls._tcp.contoso.com. /dsprimary
    dnscmd . /recordadd _sipinternaltls._tcp.contoso.com. @ SRV 0 0 5061 pool01.contoso.com.
    dnscmd . /zoneadd pool01.contoso.com. /dsprimary
    dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.90
    dnscmd . /recordadd pool01.contoso.com. @ AAAA 
        <IPv6 address>
      
    dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.91 
    dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
    

    Если ваша среда содержит второй домен SIP (например, fabrikam.com), вам потребуются следующие точно определенные зоны и записи A во внутренней DNS:

    dnscmd . /zoneadd _sipinternaltls._tcp.fabrikam.com. /dsprimary
    dnscmd . /recordadd _sipinternaltls._tcp.fabrikam.com. @ SRV 0 0 5061 pool01.fabrikam.com.
    dnscmd . /zoneadd pool01.fabrikam.com. /dsprimary
    dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.90
    dnscmd . /recordadd pool01.contoso.com. @ AAAA 
        <IPv6 address>
      
    dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.91
    dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
    
noteПримечание.
Полное доменное имя интерфейсного пула показано дважды, но с разными IP-адресами. Это связано с использованием балансировки нагрузки на DNS. Однако при использовании аппаратной балансировки нагрузки будет доступна только одна запись интерфейсного пула. Кроме того, значения полных доменных имен интерфейсного пула разные в примерах contoso.com и fabrikam.com, но IP-адреса остаются одинаковыми. Это связано с тем, что пользователи, выполняющие вход с любого домена SIP, используют для автоматической настройки один и тот же интерфейсный пул.

Дополнительные сведения см. в записи блога "Автоматическая конфигурация Communicator и разделенная DNS" по адресу: http://go.microsoft.com/fwlink/p/?linkId=200707. Хотя статья относится к Office Communicator, сведения также применимы и к Skype для бизнеса Server.

noteПримечание.
Содержимое всех блогов и их URL-адреса могут быть изменены без уведомления.

Чтобы настроить DNS для перенаправления веб-трафика Skype для бизнеса Server на сайты аварийного восстановления и отработки отказа, необходимо использовать поставщика DNS, который поддерживает с помощью GeoDNS поиск самого географически близкого сервера, если это возможно, или самого отдаленного, если это требуется. Можно настроить записи DNS для поддержки аварийного восстановления, чтобы компоненты, использующие веб-службы, продолжали работать даже при отказе одного пула переднего плана. Эта функция аварийного восстановления поддерживает простые URL-адреса автообнаружения (URL-адрес Lyncdiscover), собрания и телефонного подключения.

Определите и настройте дополнительные записи узлов DNS (A и AAAA, если используется IPv6) для внутреннего и внешнего разрешения веб-служб у поставщика GeoDNS. В приведенном ниже примере предполагается, что существуют географически разнесенные спаренные пулы и поставщик либо поддерживает GeoDNS с помощью циклического перебора DNS, либо настроен на использование пула Pool1 в качестве основного и пула Pool2 – для отработки отказа в случае потери связи или сбоя оборудования.

 

Запись GeoDNS (пример) Записи пула (пример) Записи CNAME (пример) Параметры DNS (выберите один вариант)

Meet-int.geolb.contoso.com

Pool1InternalWebFQDN.contoso.com

Pool2InternalWebFQDN.contoso.com

Псевдоним Meet.contoso.com для Pool1InternalWebFQDN.contoso.com

Псевдоним Meet.contoso.com для Pool2InternalWebFQDN.contoso.com

Циклический перебор между пулами

Используйте основной, в случае сбоя подключитесь к дополнительному

Meet-ext.geolb.contoso.com

Pool1ExternalWebFQDN.contoso.com

Pool2ExternalWebFQDN.contoso.com

Псевдоним Meet.contoso.com для Pool1ExternalWebFQDN.contoso.com

Псевдоним Meet.contoso.com для Pool2ExternalWebFQDN.contoso.com

Циклический перебор между пулами

Используйте основной, в случае сбоя подключитесь к дополнительному

Dialin-int.geolb.contoso.com

Pool1InternalWebFQDN.contoso.com

Pool2InternalWebFQDN.contoso.com

Псевдоним Dialin.contoso.com для Pool1InternalWebFQDN.contoso.com

Псевдоним Dialin.contoso.com для Pool2InternalWebFQDN.contoso.com

Циклический перебор между пулами

Используйте основной, в случае сбоя подключитесь к дополнительному

Dialin-ext.geolb.contoso.com

Pool1ExternalWebFQDN.contoso.com

Pool2ExternalWebFQDN.contoso.com

Псевдоним Dialin.contoso.com для Pool1ExternalWebFQDN.contoso.com

Псевдоним Dialin.contoso.com для Pool2ExternalWebFQDN.contoso.com

Циклический перебор между пулами

Используйте основной, в случае сбоя подключитесь к дополнительному

Lyncdiscoverint-int.geolb.contoso.com

Pool1InternalWebFQDN.contoso.com

Pool2InternalWebFQDN.contoso.com

Псевдоним Lyncdiscoverinternal.contoso.com для Pool1InternalWebFQDN.contoso.com

Псевдоним Lyncdiscoverinternal.contoso.com для Pool2InternalWebFQDN.contoso.com

Циклический перебор между пулами

Используйте основной, в случае сбоя подключитесь к дополнительному

Lyncdiscover-ext.geolb.contoso.com

Pool1ExternalWebFQDN.contoso.com

Pool2ExternalWebFQDN.contoso.com

Псевдоним Lyncdiscover.contoso.com для Pool1ExternalWebFQDN.contoso.com

Псевдоним Lyncdiscover.contoso.com для Pool2ExternalWebFQDN.contoso.com

Циклический перебор между пулами

Используйте основной, в случае сбоя подключитесь к дополнительному

Scheduler-int.geolb.contoso.com

Pool1InternalWebFQDN.contoso.com

Pool2InternalWebFQDN.contoso.com

Псевдоним Scheduler.contoso.com для Pool1InternalWebFQDN.contoso.com

Псевдоним Scheduler.contoso.com для Pool2InternalWebFQDN.contoso.com

Циклический перебор между пулами

Используйте основной, в случае сбоя подключитесь к дополнительному

Scheduler-ext.geolb.contoso.com

Pool1ExternalWebFQDN.contoso.com

Pool2ExternalWebFQDN.contoso.com

Псевдоним Scheduler.contoso.com для Pool1ExternalWebFQDN.contoso.com

Псевдоним Scheduler.contoso.com для Pool2ExternalWebFQDN.contoso.com

Циклический перебор между пулами

Используйте основной, в случае сбоя подключитесь к дополнительному

Балансировка нагрузки на DNS обычно реализуется на уровне приложений. Приложение (например, клиент Skype для бизнеса) пытается подключиться к серверу в пуле путем подключения к одному из IP-адресов, возвращаемых запросом DNS-записи A и AAAA (при использовании IPv6-адресов) для полного доменного имени пула.

Например, при наличии трех серверов переднего плана в пуле pool01.contoso.com выполняются следующие действия:

  • Клиенты Skype для бизнеса запрашивают pool01.contoso.com в DNS. Запрос возвращает 3 IP-адреса и кэширует их следующим образом (не обязательно в этом порядке):

    pool01.contoso.com      192.168.10.90

    pool01.contoso.com      192.168.10.91

    pool01.contoso.com      192.168.10.92

  • Клиент пытается установить подключение TCP к одному из IP-адресов. Если не удается установить подключение, клиент берет следующий IP-адрес из кэша.

  • Если подключение TCP успешно установлено, клиент согласует TLS для подключения к основному регистратору на pool01.contoso.com.

  • Если не удается установить подключение ни к одной кэшированной записи, пользователь получает уведомление о недоступности серверов Skype для бизнеса Server.

noteПримечание.
Балансировка нагрузки на DNS отличается от циклического перебора DNS (DNS RR), который обычно относится к балансировке нагрузки с помощью DNS для обеспечения другого порядка IP-адресов, соответствующих серверам в пуле. Как правило, циклический перебор DNS обеспечивает только распределение нагрузки, но не отработку отказа. Например, если подключение к одному IP-адресу, возвращаемому запросом DNS-записи A и AAAA (при использовании IPv6-адресов), завершается с ошибкой, подключение разрывается. Следовательно, циклический перебор DNS является менее надежным, чем балансировка нагрузки на DNS. Вы можете использовать циклический перебор DNS вместе с балансировкой нагрузки на DNS.

Балансировка нагрузки на DNS используется в следующих целях:

  • Балансировка нагрузки SIP "сервер-сервер" до пограничных серверов.

  • Приложения балансировки нагрузки Unified Communications Application Services (UCAS), например автосекретарь, группа ответа и парковка. вызовов

  • Запрет новых подключений к приложениям UCAS (также называемое "сток").

  • Балансировка нагрузки всего трафика "клиент-сервер" между клиентами и пограничными серверами.

Балансировка нагрузки на DNS не может использоваться для выполнения следующих задач:

  • Веб-трафик "клиент-сервер" до директора или серверов переднего плана.

Балансировка нагрузки на DNS и федеративный трафик:

Если на запрос записи SRV возвращается несколько DNS-записей, то пограничная служба доступа всегда выбирает DNS-запись SRV с наименьшим числовым приоритетом и наибольшим числовым весом. В документе Internet Engineering Task Force "A DNS RR for specifying the location of services (DNS SRV)" http://www.ietf.org/rfc/rfc2782.txt указано, что, если определено несколько записей DNS SRV, сначала используется приоритет, а затем вес. Например, запись A DNS SRV имеет вес 20 и приоритет 40, а запись B DNS SRV имеет вес 10 и приоритет 50. Будет выбрана запись A DNS SRV с приоритетом 40. Следующие правила применяются к выбору записи DNS SRV:

  • Сначала учитывается приоритет. Клиент ДОЛЖЕН пытаться связаться с целевым узлом, определяемым записью DNS SRV с самым низким числовым приоритетом, который может быть достигнут. Цели с одним и тем же приоритетом ДОЛЖНЫ достигаться в порядке, определяемым полем веса.

  • Поле веса определяет относительный вес для записей с одним и тем же приоритетом. Более крупный вес ДОЛЖЕН присваиваться при наличии пропорционально высокой вероятности выбора. Администраторы DNS ДОЛЖНЫ использовать вес 0 при отсутствии каких-либо серверных операций выбора, которые подлежат выполнению. При наличии записей, вес которых больше 0, крайне маловероятно, что будут выбраны записи, имеющие вес 0.

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

В этом разделе описываются DNS-записи, требуемые для развертывания интерфейсных пулов.

В следующей таблице указаны требования DNS для развертывания интерфейсного пула Skype для бизнеса Server.

Требования DNS для интерфейсного пула

Сценарий развертывания Требование DNS

Интерфейсный пул с несколькими серверами переднего плана и аппаратным балансировщиком нагрузки (независимо от того, развертывается ли в этом пуле балансировка нагрузки на DNS)

При использовании балансировки нагрузки службы доменных имен (DNS) и аппаратной подсистемы балансировки нагрузки требуется создать записи хоста (A). Создайте внутреннюю запись A для каждого сервера переднего плана, которая разрешает полное доменное имя (FQDN) серверного пула для балансировки нагрузки службы DNS. Создайте запись внутреннего хоста (A) для внутренних веб-служб с использованием виртуального IP-адреса (VIP) подсистемы балансировки нагрузки. Необходимо использовать имя внутренних веб-служб, как указано в разделе топологий.

Например, если вы используете и балансировку нагрузки службы DNS, и аппаратную подсистему балансировки нагрузки, вы получите запись A для каждого сервера переднего плана в пуле для балансировки нагрузки DNS и запись A для внутренних веб-служб с указанием на виртуальный IP-адрес подсистемы балансировки нагрузки:

  • Балансировка нагрузки DNS: Pool01.contoso.net   IP-адрес пула   10.10.10.5

    warningПредупреждение.
    Для каждого переднего плана создается отдельная запись A:
    1. FE01.contoso.net    10.10.10.1

    2. FE02.contoso.net    10.10.10.2

    3. FE03.contoso.net    10.10.10.3

    4. FE04.contoso.net    10.10.10.4

  • Аппаратная балансировка нагрузки:   WebInternal.contoso.net   IP-адрес HLB VIP   192.168.10.5

Для всего трафика, кроме трафика HTTP/HTTPS, будет использоваться запись Pool01.contoso.net. Для трафика HTTP/HTTPS будет использоваться определенный адрес внутренних веб-служб 192.168.10.5

Интерфейсный пул с развернутой балансировкой нагрузки на DNS

Набор внутренних записей A, которые разрешают полное доменное имя пула в IP-адрес каждого сервера пула. Для каждого сервера пула должна существовать только одна запись A. Дополнительные сведения см. в разделе Балансировка нагрузки на DNS документации по планированию.

   

Интерфейсный пул с одним сервером переднего плана и выделенной серверной базой данных, но без распределения нагрузки

Внутренняя запись A, которая разрешает полное доменное имя интерфейсного пула в IP-адрес одного сервера переднего плана выпуска Enterprise Edition.

Автоматический вход клиента

Для каждого поддерживаемого домена SIP требуется запись расположения службы (SRV) _sipinternaltls._tcp.<имя_домена> через порт 5061, которая сопоставляется полному доменному имени интерфейсного пула, выполняющего проверку подлинности и перенаправление запросов клиентов для входа. Дополнительные сведения см. в разделе Требования DNS для автоматического входа клиентов в Lync Server 2013.

Обнаружение веб-службы обновления устройств устройствами объединенных коммуникаций

Внутренняя запись A ucupdates-r2.<имя_домена_SIP>, которая разрешается в IP-адрес интерфейсного пула, содержащего веб-службу обновления устройств. Если устройство объединенных коммуникаций включено, но пользователь никогда не входил в систему устройства, то запись A позволит устройству обнаружить интерфейсный пул, содержащий веб-службу обновления устройств, и получить обновления. В противном случае устройства получат эти сведения посредством автоматической подготовки при первичном входе пользователя.

importantВажно!
Если у вас уже есть развертывание веб-службы обновления устройств в Lync Server 2010, то вы уже создали внутреннюю запись A ucupdates. <SIP domain> . Для Microsoft Office Communications Server 2007 R2 потребуется создать дополнительную DNS-запись A ucupdates-r2. <SIP domain> .

Обратный прокси-сервер для поддержки трафика HTTP

Внешняя запись A, которая разрешает полное доменное имя внешней веб-фермы во внешний IP-адрес обратного прокси-сервера. Клиенты и устройства объединенных коммуникаций используют эту запись для подключения к обратному прокси-серверу. Дополнительные сведения см. в разделе Определение требований DNS для Lync Server 2013 документации по планированию.

В следующей таблице показан пример DNS-записей для полного доменного имени внутренней веб-фермы.

Пример DNS-записей для полного доменного имени внутренней веб-фермы

Полное доменное имя внутренней веб-фермы Полное доменное имя пула DNS-записи A

webcon.contoso.com

ee-pool.contoso.com

DNS-запись A для ee-pool.contoso.com, которая разрешается в виртуальный IP-адрес балансировщика нагрузки, используемого серверами переднего плана.

DNS-запись A для webcon.contoso.com, которая разрешается в виртуальный IP-адрес балансировщика нагрузки, используемого серверами переднего плана.

ee-pool.contoso.com

ee-pool.contoso.com

DNS-запись A для ee-pool.contoso.com, которая разрешается в виртуальный IP-адрес балансировщика нагрузки, используемого серверами переднего плана выпуска Enterprise Edition в интерфейсном пуле.

Обратите внимание, что при использовании балансировки нагрузки на DNS в этом пуле ваш интерфейсный пул и внутренняя веб-ферма не могут иметь одинаковые полные доменные имена.

В этом разделе описываются DNS-записи, необходимые для развертывания серверов Standard Edition.

В следующей таблице приведены требования к DNS для развертывания сервера Skype для бизнеса Server Standard Edition.

Требования DNS стандартного выпуска сервера

Сценарий развертывания Требование DNS

Standard Edition

Внутренняя запись A, разрешающая полное доменное имя сервера в IP-адрес.

Автоматический вход клиента

Для каждого поддерживаемого SIP-домена — запись SRV для _sipinternaltls._tcp. <domain> через порт 5061, сопоставленная с полным доменным именем сервера Standard Edition, который проверяет подлинность запросов пользователей и перенаправляет их для входа. Дополнительные сведения см. в разделе Требования DNS для автоматического входа клиентов в Lync Server 2013.

Обнаружение веб-службы обновления устройств устройствами объединенных коммуникаций

Внутренняя запись A с именем ucupdates-r2. <SIP domain> , разрешающаяся в IP-адрес сервера Standard Edition, на котором размещается веб-служба обновления устройств. В ситуации, когда устройство объединенных коммуникаций включено, но пользователь еще никогда не выполнял вход на него, запись A позволяет устройству обнаруживать сервер с веб-службой обновления устройств и получать обновления. В противном случае устройство получает сведения о сервере посредством автоматической подготовки при первом входе пользователя.

Обратный прокси-сервер для поддержки трафика HTTP

Внешняя запись A, которая разрешает полное доменное имя внешней веб-фермы во внешний IP-адрес обратного прокси-сервера. Клиенты и устройства объединенных коммуникаций используют эту запись для подключения к обратному прокси-серверу. Дополнительные сведения см. в разделе Определение требований DNS для Lync Server 2013 документации по планированию.

Система Skype для бизнеса Server поддерживает простые URL-адреса, которые позволяют пользователям легче присоединяться к собраниям, а администраторам упрощают использование средств администрирования Skype для бизнеса Server. Дополнительные сведения о простых URL-адресах см. в разделе Планирование простых URL-адресов в Lync Server 2013.

Skype для бизнеса Server поддерживает три следующих простых URL-адреса: для собрания (Meet), для телефонного подключения (Dial-In) и администраторский (Admin). Вам требуется задать простые URL-адреса для Meet и Dial-In, а простой URL-адрес Admin является дополнительным. Записи службы доменных имен (DNS), необходимые для поддержки простых URL-адресов, зависят от того, как именно вы определили эти простые URL-адреса, а также необходима ли поддержка аварийного восстановления для простых URL-адресов.

В варианте 1 для каждого простого URL-адреса вы создаете новый базовый URL-адрес.

noteПримечание.
Когда пользователь выбирает ссылку собрания с простым URL-адресом, сервер, в который разрешается запись A DNS, определяет правильное клиентское программное обеспечение, которое необходимо запустить. После запуска этого клиентского программного обеспечения оно автоматически соединяется с пулом, где размещается конференция. В этом случае пользователи направляются на подходящий сервер с содержимым собрания независимо от того, в какой сервер или пул разрешаются записи A DNS простого URL-адреса.

Вариант 1 простого URL-адреса

Простой URL-адрес

Пример

Meet

https://meet.contoso.com, https://meet.fabrikam.com и т. п. (по одному на каждый домен SIP в вашей организации)

Dial-in

https://dialin.contoso.com

Admin

https://admin.contoso.com

Если вы используете вариант 1, вам необходимо определить следующее:

  • Для каждого простого URL-адреса Meet вам требуется запись A DNS, которая разрешает этот URL-адрес в IP-адрес директора (если вы его развернули). В противном случае он должен разрешаться в IP-адрес подсистемы балансировки нагрузки интерфейсного пула. Если вы еще не развернули пул и используете развертывание сервера Standard Edition, запись A DNS должна разрешаться в IP-адрес одного сервера Standard Edition в вашей организации.

    Если в вашей организации более одно домена SIP и вы используете данный вариант, вам следует создать простые URL-адреса Meet для каждого домена SIP и использовать по записи A DNS на каждый простой URL-адрес Meet. Например, если у вас есть contoso.com и fabrikam.com, вы создаете записи A DNS как для https://meet.contoso.com, так и для https://meet.fabrikam.com.

    Если же у вас имеется несколько доменов SIP и вы хотите до минимума сократить потребность в записях DNS и сертификатах для этих простых URL-адресов, воспользуйтесь описанным ниже вариантом 3.

  • Для простого URL-адреса Dial-in вам требуется запись A DNS, которая разрешает этот URL-адрес в IP-адрес директора (если вы его развернули). В противном случае он должен разрешаться в IP-адрес подсистемы балансировки нагрузки интерфейсного пула. Если вы еще не развернули пул и используете развертывание сервера Standard Edition, запись A DNS должна разрешаться в IP-адрес одного сервера Standard Edition в вашей организации.

  • Простой URL-адрес Admin предназначен только для внутреннего использования и требует запись A DNS, которая разрешает этот URL-адрес в IP-адрес директора (если вы его развернули). В противном случае он должен разрешаться в IP-адрес подсистемы балансировки нагрузки интерфейсного пула. Если вы еще не развернули пул и используете развертывание сервера Standard Edition, запись A DNS должна разрешаться в IP-адрес одного сервера Standard Edition в вашей организации.

В варианте 2 все простые URL-адреса Meet, Dial-in и Admin имеют общий базовый URL-адрес, например lync.contoso.com. Таким образом, для этих простых URL-адресов вам требуется только одна запись A DNS, которая разрешает lync.contoso.com в IP-адрес пула директоров или интерфейсный пул. Если вы еще не развернули пул и используете развертывание сервера Standard Edition, запись A DNS должна разрешаться в IP-адрес одного сервера Standard Edition в вашей организации.

Если в вашей организации более одного домена SIP, вам все равно следует создать простые URL-адреса Meet для каждого домена SIP и использовать по записи A DNS на каждый простой URL-адрес Meet. Хотя все три простых URL-адреса в данном примере основаны на lync.contoso.com, дополнительный простой URL-адрес Meet для fabrikam.com настраивается с использованием другого базового URL-адреса. В этом примере вам следует создать записи A DNS для https://lync.contoso.com и https://lync.fabrikam.com. В вариант 3 простого URL-адреса показан другой способ именования и обработки записей A DNS при наличии нескольких доменов SIP.

Вариант 2 простого URL-адреса

Простой URL-адрес

Пример

Meet

https://lync.contoso.com/Meet, https://lync.fabrikam.com/Meet и т. п. (по одному на каждый домен SIP в вашей организации)

Dial-in

https://lync.contoso.com/Dialin

Admin

https://lync.contoso.com/Admin

Вариант 3 наиболее удобен в том случае, если у вас имеется несколько доменов SIP и вы хотите минимизировать потребности в записях DNS и сертификатах для этих простых URL-адресов. В данном примере вам требуется только одна запись A DNS, которая разрешает lync.contoso.com в IP-адрес пула директоров или интерфейсный пул.

Вариант 3 простого URL-адреса

Простой URL-адрес

Пример

Meet

https://lync.contoso.com/contosoSIPdomain/Meet

https://lync.contoso.com/fabrikamSIPdomain/Meet

Dial-in

https://lync.contoso.com/contosoSIPdomain/Dialin

Admin

https://lync.contoso.com/contosoSIPdomain/Admin

При наличии нескольких сайтов, содержащих пулы переднего плана, и поддержке поставщика услуг DNS технологии GeoDNS, можно настроить свои DNS-записи для простых URL-адресов, чтобы они поддерживали аварийное восстановление, так что функциональные возможности простых URL-адресов не прерываются, даже если выключается весь пул переднего плана. Этот компонент аварийного восстановления поддерживает простые URL-адреса Meet и Dial-In.

Для выполнения этой настройки создайте два адреса GeoDNS. Каждый адрес содержит две записи DNS A или CNAME, которые разрешаются в два пула, спаренных в целях аварийного восстановления. Один адрес GeoDNS используется для внутреннего доступа и разрешается в полное доменное имя внутренней веб-службы или IP-адрес балансировщика нагрузки для двух пулов. Другой адрес GeoDNS используется для внешнего доступа и разрешается в полное доменное имя внешней веб-службы или IP-адрес балансировщика нагрузки для двух пулов. Ниже приведен пример простого URL-адреса Meet для полных имен доменов этих пулов.

Meet-int.geolb.contoso.com
     Pool1InternalWebFQDN.contoso.com
     Pool2InternalWebFQDN.contoso.com
Meet-ext.geolb.contoso.com
     Pool1ExternalWebFQDN.contoso.com
     Pool2ExternalWebFQDN.contoso.com

Затем создайте записи CNAME, которые разрешают простой URL-адрес Meet (например, meet.contoso.com) в два адреса GeoDNS.

noteПримечание.
Если сеть поддерживает разворот пакетов (маршрутизация всего трафика простых URL-адресов через внешнюю ссылку, включая трафик из организации), можно просто настроить внешний адрес GeoDNS и разрешать простой URL-адрес Meet только во внешний адрес.

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

Можно задать ту же конфигурацию для простого URL-адреса Dial-In. Для этого создайте дополнительные записи, аналогичные приведенным в предыдущем примере, заменяя в этих DNS-записях dialin на meet. Для простого URL-адреса Admin используйте один из трех вариантов, приведенных выше в этом разделе.

После настройки этой конфигурации необходимо использовать приложение мониторинга для настройки мониторинга HTTP на предмет сбоев. Для внешнего доступа следует отслеживать успешное выполнение запросов автоматического обнаружения HTTPS GET lyncdiscover.<имя_домена_sip>, предназначенных для полного доменного имени внешней веб-службы или IP-адреса подсистемы балансировки нагрузки применительно к двум пулам. Например, следующие запросы не должны содержать какие-либо заголовки ACCEPT и должны возвращать 200 OK .

HTTPS GET Pool1ExternalWebFQDN.contoso.com/autodiscover/autodiscoverservice.svc/root
HTTPS GET Pool2ExternalWebFQDN.contoso.com/autodiscover/autodiscoverservice.svc/root

Для внутреннего доступа следует отслеживать порт 5061 на полном доменном имени внутреннего интерфейса или IP-адресе балансировщика нагрузки применительно к двум пулам. Если обнаруживаются какие-либо проблемы с подключением, на виртуальном IP-адресе этих пулов должны быть закрыты порты 80, 443 и 4443.

В данном разделе описываются записи службы доменных имен (DNS), необходимые для автоматического входа клиентов. При развертывании серверов Standard Edition или интерфейсных пулов вы можете настроить клиентов на использование автоматического обнаружения для входа на соответствующий сервер Standard Edition или в интерфейсный пул. Использование ручного подключения клиентов к Skype для бизнеса Server не рекомендуется.

Чтобы обеспечить поддержку автоматического входа клиентов, вам следует выполнить следующие действия:

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

  • Создать внутреннюю DNS-запись SRV, чтобы обеспечить поддержку автоматического входа клиентов для этого сервера или пула.

    noteПримечание.
    В приведенных ниже требованиях к записи домен SIP относится к той части кодов URI SIP, назначенных пользователям, которая обозначает узел. Например, если коды URI SIP имеют форму *@contoso.com, то contoso.com — это домен SIP. Этот домен SIP часто отличается от внутреннего домена Active Directory. Кроме того, организация может поддерживать несколько доменов SIP.

Чтобы разрешить автоматическую настройку для клиентов, вам следует создать внутреннюю DNS-запись SRV, которая сопоставляет одну из следующих записей с полным доменным именем интерфейсного пула или сервера Standard Edition, распространяющего запросы на вход от клиентов Skype для бизнеса:

  • _sipinternaltls._tcp. <domain> — для внутренних подключений TLS

Вам требуется создать только одну запись SRV на домен для интерфейсного пула или сервера Standard Edition, который будет распространять запросы на вход.

В следующей таблице приведено несколько примеров записей, требуемых для вымышленной компании Contoso, осуществляющей поддержку доменов SIP contoso.com и retail.contoso.com.

Пример DNS-записей, необходимых для автоматического входа клиентов с несколькими доменами SIP

Полное доменное имя интерфейсного пула, используемого для распространения запросов на вход Домен SIP SRV-запись DNS

pool01.contoso.com

contoso.com

Запись SRV для домена _sipinternaltls._tcp.contoso.com через порт 5061, которая сопоставлена с pool01.contoso.com

pool01.contoso.com

retail.contoso.com

Запись SRV для домена _sipinternaltls._tcp.retail.contoso.com через порт 5061, которая сопоставлена с pool01.contoso.com

noteПримечание.
По умолчанию запросы для DNS-записей придерживаются строгого совпадения имен доменов между доменом в имени пользователя и в записи SRV. Если вы предпочитаете, чтобы DNS-запросы клиентов вместо этого использовали совпадение суффиксов, то можете настроить групповую политику DisableStrictDNSNaming. Дополнительные сведения см. в разделе Планирование клиентов и устройств в Lync Server 2013 документации по планированию.

В данном примере используются образцы имен из предыдущей таблицы. Организация Contoso поддерживает домены SIP contoso.com и retail.contoso.com, и все ее пользователи имеют код URI SIP в одной из следующих форм:

  • <user> @retail.contoso.com

  • <user> @contoso.com

Когда вы развертываете компонент мобильности системы Skype для бизнеса Server, вы можете использовать новые URL-адреса, предоставляемые службой автообнаружения системы Skype для бизнеса Server Microsoft, или свои существующие URL-адреса веб-служб. Если вы используете существующие URL-адреса, пользователям необходимо вручную вводить эти URL-адреса в параметрах мобильного устройства. Данный вариант обычно используется для поиска и устранения неполадок. Когда вы используете новые URL-адреса, мобильные клиенты могут автоматически обнаруживать ресурсы системы Skype для бизнеса Server. В случае обеспечения поддержки автоматического обнаружения вам требуется добавить новые DNS-записи. В этом разделе описаны те DNS-записи, которые требуются для автоматического обнаружения.

Чтобы обеспечить поддержку автоматического обнаружения, вам необходимо создать следующие DNS-записи для каждого домена SIP:

  • Внутренняя DNS-запись для поддержки мобильных пользователей, которые подключаются изнутри сети организации

  • Внешняя (или общая) DNS-запись для поддержки мобильных пользователей, которые подключаются из Интернета

Внутренний URL-адрес автообнаружения не должен поддерживать обращение извне сети. Внешний URL-адрес автообнаружения не должен поддерживать обращение из вашей сети. Однако если вы не можете выполнить данное условие для внешнего URL-адреса, это не окажет негативного влияния на функциональные возможности мобильного клиента.

DNS-записи могут быть либо записями CNAME, либо записями A (узла).

Внутренние DNS-записи

Вам необходимо создать одну из следующих внутренних DNS-записей:

 

Тип записи Имя узла или определение SRV Разрешается в

CNAME

lyncdiscoverinternal. <sipdomain>

Полное доменное имя внутренних веб-служб для пула директоров (при его наличии) или для пула переднего плана, если у вас нет Директор

A (узел)

lyncdiscoverinternal. <sipdomain>

IP-адрес внутренних веб-служб (виртуальный IP-адрес, если вы используете подсистему балансировки нагрузки) для пула директоров (при его наличии) или для пула переднего плана, если у вас нет Директор

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

Вам необходимо создать одну из следующих внешних DNS-записей:

 

Тип записи Имя узла Разрешается в

CNAME

lyncdiscover. <sipdomain>

Полное доменное имя внешних веб-служб для пула директоров (при его наличии) или для пула переднего плана, если у вас нет Директор

A (узел)

lyncdiscover. <sipdomain>

Внешний или общий IP-адрес (виртуальный IP-адрес, если вы используете подсистему балансировки нагрузки) обратного прокси-сервера

SRV

_sipfederationtls._tcp. <sipdomain>

Разрешается в запись узла (A или AAAA) для доступа

Для поддержки служба push-уведомлений и Apple Push Notification Service вы создаете одну запись SRV для каждого домена SIP с клиентами Microsoft Lync Mobile.

importantВажно!
Это требование применяется только к клиентам Microsoft Lync Mobile на мобильных устройствах Apple и Майкрософт. Устройства Android и Nokia Symbian не используют push-уведомления.
noteПримечание.
Трафик автообнаружения передается через обратный прокси-сервер. Запись SRV указывает на запись, которая разрешается посредством доступа.

В Skype для бизнеса Server предусмотрена балансировка нагрузки на DNS, программное решение, которое может значительно уменьшить нагрузку администраторов по балансировке нагрузки в сети. Балансировка нагрузки на DNS балансирует сетевой трафик, присущий только Skype для бизнеса Server, такой как трафик SIP и трафик мультимедиа.

Если вы разворачиваете балансировку нагрузки на DNS, то нагрузка, связанная с администрированием аппаратных балансировщиков нагрузки в вашей организации, будет максимально сокращена. Кроме того, будет исключена комплексная диагностика проблем, связанных с неправильной конфигурацией аппаратных балансировщиков нагрузки для трафика SIP. Можно также запрещать серверные подключения, чтобы можно было переводить серверы в автономный режим. Балансировка нагрузки на DNS также гарантирует, что проблемы аппаратных балансировщиков нагрузки не будут оказывать влияние на элементы трафика SIP, такие как базовая маршрутизация вызовов.

При использовании балансировки нагрузки на DNS может также появиться возможность приобретения аппаратных балансировщиков нагрузки меньшей стоимости, чем при использовании аппаратных балансировщиков нагрузки для всех типов трафика. Следует использовать балансировщики нагрузки, прошедшие квалификационное тестирование взаимодействия с Skype для бизнеса Server. Сведения о квалификационном тестировании балансировщиков нагрузки см. в статье "Lync Server 2010 Load Balancer Partners" по адресу http://go.microsoft.com/fwlink/?linkid=202452. Содержимое применимо к Skype для бизнеса Server.

Балансировка нагрузки на DNS поддерживается для интерфейсных пулов, пулов пограничных серверов, пулов директоров и пулов изолированных серверов-посредников.

Балансировку нагрузки на DNS можно использовать для трафика SIP в интерфейсных пулах и в пулах директоров. Если развернута балансировка нагрузки на DNS, то все еще требуется использовать в этих пулах аппаратные балансировщики нагрузки, но только для HTTPS-трафика с клиента на сервер. Аппаратный балансировщик нагрузки используется для HTTPS-трафика от клиентов через порты 443 и 80.

Хотя для этих пулов еще нужны аппаратные балансировщики нагрузки, их настройка и администрирование будет в основном выполняться для HTTPS-трафика, который привычен для администраторов аппаратных балансировщиков нагрузки.

Балансировка нагрузки на DNS поддерживает автоматическую отработку отказа только для серверов, на которых работает сервер Skype для бизнеса Server или Lync Server 2010, и для клиентов Lync 2013 и Skype для бизнеса. Предыдущие версии клиентов и серверов Office Communications Server еще могут подключаться к пулам, в которых работает балансировка нагрузки на DNS, но если они не могут подключиться к первому серверу, на который направляет их балансировка нагрузки на DNS, то невозможно переключение и на другой сервер в пуле.

Кроме того, если используется единая система обмена сообщениями Exchange, то необходимо использовать как минимум Exchange 2010 с пакетом обновления 1 (SP1) для поддержки балансировки нагрузки на DNS Skype для бизнеса Server. Если используется более ранняя версия Exchange, пользователи не будут иметь возможности отработки отказа в следующих сценариях единой системы обмена сообщениями Exchange.

  • Воспроизведение корпоративной голосовой почты на своем телефоне

  • Передача вызовов из автосекретаря единой системы обмена сообщениями Exchange.

Все остальные сценарии единой системы обмена сообщениями Exchange будут работать должным образом.

Для развертывания балансировки нагрузки на DNS в интерфейсных пулах и в пулах директоров потребуется выполнить пару дополнительных действий с полными доменными именами и записями DNS.

  • Пул, который использует балансировку нагрузки на DNS, должен иметь два полных доменных имени: обычное полное доменное имя пула, которое используется балансировкой нагрузки на DNS (такое как pool01.contoso.com) и разрешается до физических IP-адресов серверов в пуле, и другое полное доменное имя для веб-служб пула (такое как web01.contoso.com), которое разрешается до виртуальных IP-адресов пула.

    Если требуется развернуть балансировку нагрузки для DNS, то в построителе топологий для создания дополнительного полного доменного имени для веб-служб пула необходимо установить флажок Override internal Web Services pool FQDN (Переопределить внутреннее полное доменное имя пула веб-служб) и ввести это полное доменное имя на странице Specify the Web Services URLs for this Pool (Укажите URL-адреса веб-служб для этого пула).

  • Для поддержки полного доменного имени, используемого балансировкой нагрузки на DNS, необходимо подготовить DNS, чтобы полное доменное имя пула (такое как pool01.contoso.com) разрешалось в IP-адрес всех серверов в пуле (например, 192.168.1.1, 192.168.1.2 и т.д.). Следует включать IP-адреса только тех серверов которые развернуты в текущий момент.

    warningПредупреждение.
    Если имеется несколько пулов переднего плана или ролей переднего плана, полное имя домена внешних веб-служб должно быть уникальным. Например, если определить полное имя домена веб-служб для некоторой роли переднего плана как pool01.contoso.com , имя pool01.contoso.com не удастся использовать для другого пула переднего плана или иной роли переднего плана. Если выполняется также развертывание Директоры, полное имя домена внешних веб-служб, определенное для любой роли Директор или любого директоров, должно отличаться от полного имени домена для любого другого объекта Директор и директоров, также как и от полного имени домена для любого объекта переднего плана и переднего плана. Если решено переопределить внутренние веб-службы с самоопределяемым полным именем домена, каждое полное имя домена должно отличаться от полного имени домена для любого другого объекта переднего плана, Директор и директоров.

Балансировку нагрузки на DNS можно разворачивать в пулах пограничных серверов. Для этого необходимо быть в курсе некоторых обстоятельств.

При использовании балансировки нагрузки на DNS на пограничных серверах будет потеряна возможность отработки отказа в следующих сценариях.

  • Федерация с организациями, которые используют версии Skype для бизнеса Server, выпущенные до Lync Server 2010.

  • Обмен мгновенными сообщениями с пользователями, которые используют общедоступные службы обмена мгновенными сообщениями, такие как AOL и Yahoo!, в дополнение к поставщикам и серверам на базе XMPP, таким как Google Talk, который в настоящее время является единственным поддерживаемым XMPP-партнером.

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

При использовании единой системы обмена сообщениями Exchange необходимо использовать как минимум Exchange 2013 для поддержки балансировки нагрузки на DNS сервера Skype для бизнеса Server для пограничного сервера. Если используется более ранняя версия Exchange, удаленные пользователи не будут иметь возможности отработки отказа в следующих сценариях единой системы обмена сообщениями Exchange.

  • Воспроизведение корпоративной голосовой почты на своем телефоне

  • Передача вызовов из автосекретаря единой системы обмена сообщениями Exchange.

Все остальные сценарии единой системы обмена сообщениями Exchange будут работать должным образом.

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

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

  • Для пограничной службы доступа потребуется по одной записи на каждый сервер в пуле. Каждая запись должна разрешать полное доменное имя пограничной службы доступа (например, sip.contoso.com) в IP-адрес пограничной службы доступа на одном из пограничных серверов в пуле.

  • Для пограничной службы веб-конференций потребуется по одной записи на каждый сервер в пуле. Каждая запись должна разрешать полное доменное имя пограничной службы веб-конференций (например, webconf.contoso.com) в IP-адрес пограничной службы веб-конференций на одном из пограничных серверов в пуле.

  • Для пограничной службы обработки аудио- и видеоданных потребуется по одной записи на каждый сервер в пуле. Каждая запись должна разрешать полное доменное имя пограничной службы обработки аудио- и видеоданных (например, av.contoso.com) в IP-адрес пограничной службы обработки аудио- и видеоданных на одном из пограничных серверов в пуле.

Для развертывания балансировки нагрузки DNS во внутреннем интерфейсе пула пограничных серверов необходимо добавить одну запись A DNS, которая разрешает внутреннее полное доменное имя пула пограничных серверов в IP-адрес каждого сервера в пуле.

Балансировку нагрузки на DNS можно использовать в пулах изолированных серверов-посредников. Весь трафик SIP и мультимедиа балансируется с помощью балансировки нагрузки на DNS.

Чтобы развернуть балансировку нагрузки на DNS в пуле серверов-посредников, необходимо подготовить DNS, чтобы полное доменное имя пула (например, mediationpool1.contoso.com) разрешалось в IP-адрес всех серверов в пуле (например, 192.168.1.1, 192.168.1.2 и т.п.).

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

Учтите, что для трафика между серверами Skype для бизнеса Server использует балансировку нагрузки с учетом топологии. Серверы читают опубликованную топологию в управления, чтобы получить полные доменные имена серверов в топологии, и автоматически распределяют трафик среди серверов. Чтобы запретить серверу принимать трафик между серверами, следует удалить сервер из топологии.

В этом разделе перечисляются записи DNS, которые требуются для развертывания сохраняемого чата.

В следующей таблице приводятся требования к DNS для развертывания Сервер сохраняемого чата.

Требования DNS для серверов сохраняемых чатов

Сценарий развертывания Требование DNS

Один сервер сохраняемого чата

Внутренняя запись A, разрешающая полное доменное имя сервера в IP-адрес.

Пул сохраняемого чата

Внутренняя запись A, разрешающая полное доменное имя сервера в IP-адрес.

Пример

PersistentChatServer01.contoso.com     10.10.10.1

PersistentChatServer02.contoso.com     10.10.10.2

Внутренняя запись A, разрешающая полное доменное имя сервера в IP-адрес.

Пример

PersistentChatPool.contoso.com    10.10.10.1

PersistentChatPool.contoso.com    10.10.10.2

 
Показ: