Planejamento de DNS do Advanced Edge Server para Skype for Business Server
Resumo: Examine cenários para Skype for Business Server opções de implantação. Se você deseja um único servidor ou prefere um pool de servidores com DNS ou HLB, este tópico deve ajudar.
Quando se trata do planejamento do DNS (Sistema de Nomes de Domínio) para Skype for Business Server, muitos fatores podem jogar em sua decisão. Se a estrutura de domínio de sua organização já estiver em vigor, pode ser só uma questão de analisar como continuar. Começaremos com os tópicos abaixo:
Walkthrough of Skype for Business clients locating services
Skype for Business clientes são semelhantes às versões anteriores dos clientes do Lync na forma como encontram e acessam serviços no Skype for Business Server. Esta seção detalha o processo de local do servidor.
lyncdiscoverinternal.<Domínio>
Um registro de host do serviço de Descoberta Automática nos serviços Web internos.
lyncdiscover.<Domínio>
Um registro de host do serviço de Descoberta Automática nos serviços Web externos.
_sipinternaltls._tcp.<Domínio>
Este é um registro SRV para conexões TLS internas.
_sip._tls.<Domínio>
Este é um registro SRV para conexões TLS externas.
sipinternal.<Domínio>
Este é um registro de host A para o pool de Front-End ou Diretor, resolvível somente na rede interna.
Sip.<Domínio>
Este é um registro de host A para o pool de Front-End ou Diretor, resolvível somente na rede interna.
sipexternal.<Domínio>
Este é um registro de host A para o serviço Access Edge, quando o cliente é externo.
O serviço de Descoberta Automática é sempre considerado o método preferencial para local do serviço, e os outros estão métodos de fallback.
Nota
Ao criar registros SRV, é importante lembrar que eles devem apontar para um DNS A (e AAAA, se você estiver usando endereçamento IPv6) no mesmo domínio em que o registro SRV do DNS for criado. Por exemplo, se o registro SRV estiver em contoso.com, o registro A (e AAAA) para o qual aponta não poderá estar em fabrikam.com.
Se você estiver inclinado a fazê-lo, poderá configurar seu dispositivo móvel para descoberta manual de serviços. Se for isso que você desejar fazer, cada usuário precisa definir as configurações de seus dispositivos móveis com os URIs completos, internos e externos, do serviço de Descoberta Automática, incluindo o protocolo e o caminho, da seguinte forma:
Para acesso externo: https://< ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root
Para acesso interno: https://< IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root
Recomendamos que você use a descoberta automática em oposição à descoberta manual. Mas se você estiver fazendo alguma solução de problemas ou teste, as configurações manuais podem ser úteis.
DNS de dupla personalidade
Esta é uma configuração de DNS na qual você tem duas zonas DNS com o mesmo namespace. A primeira zona DNS lida com os pedidos internos, enquanto a segunda zona DNS lida com os pedidos externos.
Por que uma empresa faria isso? Pode haver a necessidade de usar o mesmo namespace internamente e externamente, mas isso levaria a muitos SRV e registros A de DNS exclusivos para uma ou outra zona e, onde houver duplicação, os endereços IP associados a esses registros seriam exclusivo.
Essa situação apresenta alguns desafios. O mais importante é que o DNS de cérebro dividido não tem suporte para Mobilidade. Isso ocorre por causa dos registros de DNS LyncDiscover e LyncDiscoverInternal (LyncDiscover deve ser definido no servidor DNS externo, enquanto que LyncDiscoverInternal deve ser definido em seu servidor DNS interno).
Listaremos os registros DNS para as zonas internas e externas aqui, mas você pode encontrar exemplos detalhados na seção requisitos ambientais do Edge Server.
DNS Interno
Contém uma zona DNS chamada (por exemplo) contoso.com, para a qual é autoritativo.
Essa zona interna contoso.com contém:
DNS A e AAAA (se você estiver usando registros de endereçamento IPv6) para o pool do Front End, o pool de diretores ou o nome do pool de diretores e todos os servidores internos que executam Skype for Business Server na rede da sua organização.
DNS A e AAAA (se você estiver usando registros de endereçamento IPv6) para sua interface interna do Edge para cada Skype for Business Server Edge Server em sua rede de perímetro.
DNS A e AAAA (se você estiver usando registros de endereçamento IPv6) para a interface interna de cada servidor proxy reverso em sua rede de perímetro (o que é opcional para o gerenciamento de um proxy reverso).
DNS A e AAAA (se você estiver usando o endereçamento IPv6) e registros SRV para configuração automática interna Skype for Business Server cliente (que é opcional ).
DNS A e AAAA (se você estiver usando o endereçamento IPv6) ou registros CNAME para descoberta automática de Skype for Business Server Web Services (o que é opcional ).
Todas as suas Skype for Business Server interfaces internas do Edge em sua rede de perímetro usam essa zona DNS interna para resolver consultas para contoso.com.
Todos os servidores que executam Skype for Business Server e clientes que executam Skype for Business Server na rede corporativa, apontam para servidores DNS internos para resolver consultas para contoso.com ou usam o arquivo Host em cada Servidor de Borda e listam registros A e AAAA (se você estiver usando o endereçamento IPv6) para o servidor de próximo salto (especificamente para o pool de diretores ou diretores VIP, VIP do pool front-end ou servidor Standard Edition).
DNS Externo
Contém uma zona DNS chamada (por exemplo) contoso.com, para a qual é autoritativo
Essa zona externa contoso.com contém:
DNS A e AAAA (se você estiver usando o endereçamento IPv6) ou registros CNAME, para descoberta automática de Skype for Business Server serviços Web. Isso é para uso com mobilidade.
DNS A e AAAA (se você estiver usando o endereçamento IPv6) e registros SRV para a interface externa do Edge de cada vip do Skype for Business Server Edge Server ou HLB (hardware load balanceado) na rede de perímetro.
DNS A e AAAA (se você estiver usando o endereçamento IPv6) e registros SRV para a interface externa do servidor proxy reverso ou (VIP para um pool de servidores proxy reverso), na rede de perímetro.
DNS A e AAAA (se você estiver usando o endereçamento IPv6) e registros SRV para Skype for Business Server autoconfiguração do cliente (opcional ).
Configuração automática sem DNS de dupla personalidade
Se você não usar dNS de cérebro dividido, a configuração automática interna de clientes que executam Skype for Business não funcionará a menos que você esteja usando uma das soluções alternativas que temos aqui. Por que não? Como Skype for Business Server requer que o URI SIP do usuário corresponda ao domínio do pool front-end designado para configuração automática. Isso não foi alterado em relação às versões anteriores do Lync Server.
Portanto, se você tiver dois domínios SIP em uso, você precisará desses registros SRV de DNS:
_sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com
Se um usuário entrar como bob@contoso.com, esse registro funcionará para configuração automática, pois o domínio SIP do usuário corresponderá ao domínio do pool front-end (contoso.com).
_sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
Se um usuário entrar como alice@fabrikam.com, esse registro funcionará para a configuração automática do segundo domínio, novamente porque o domínio SIP corresponde ao pool front-end desse domínio.
Para aprofundar mais o exemplo, isso não funcionaria:
_sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
Uma entrada do usuário como tim@litwareinc.com não funcionará para configuração automática, pois seu domínio SIP (litwareinc.com) não corresponde ao domínio no pool (fabrikam.com).
Portanto, agora que sabemos tudo isso, se você precisar de requisitos automáticos para seus clientes Skype for Business sem DNS de cérebro dividido, você terá estas opções:
Objetos de Política de Grupo
Você pode usar Objetos de Política de Grupo (GPOs) para popular os valores de servidor corretos.
Nota
Essa opção não habilita a configuração automática, mas automatiza a configuração manual. Se essa abordagem for utilizada, os registros SRV associados à configuração automática não serão necessários.
Zona interna correspondente
Você precisará criar uma zona em seu DNS interno que corresponda à zona DNS externa (por exemplo, contoso.com) e criar registros DNS A (e AAAA se estiver usando o endereçamento IPv6) que correspondam ao pool de Skype for Business Server usado para configuração automática.
Por exemplo, se você tiver um usuário hospedado em pool01.contoso.net, mas entrar em Skype for Business como bob@contoso.com, crie uma zona DNS interna chamada contoso.com e, dentro dela, você precisará criar um registro DNS A (e AAAA se o endereçamento IPv6 estiver sendo usado) para pool01.contoso.com.
Zona interna exata
Se criar uma zona inteira no DNS interno não for uma opção, você poderá criar zonas exatas (dedicadas) que correspondam aos registros SRV necessários para a configuração automática e popular estas zonas usando o dnscmd.exe. O dnscmd.exe é necessário porque a interface do usuário do DNS não é compatível com a criação de zonas exatas.
Por exemplo, se o domínio SIP estiver contoso.com e você tiver um pool do Front End chamado pool01 que contém dois Servidores front-end, você precisará das seguintes zonas de ponto de fixação e um registro em seu DNS interno:
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>Você pode ter um segundo domínio SIP em seu ambiente. Nesse caso, você precisará das seguintes zonas exatas e registros A em seu DNS interno:
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>
Nota
Você verá o FQDN do pool front-end aparecer duas vezes, mas com dois endereços IP diferentes. Isso ocorre porque o balanceamento de carga DNS é usado. Se o HLB for usado, haverá apenas uma única entrada de pool do Front End.
Nota
Além disso, os valores FQDN do pool de Front-End são alterados entre os exemplos de contoso.com e fabrikam.com, mas os endereços IP permanecem os mesmos. Isso ocorre porque os usuários que estão entrando em qualquer domínio SIP usarão o mesmo pool de Front-End para configuração automática.
DNS disaster recovery
Para configurar o DNS para redirecionar Skype for Business Server tráfego Web para seus sites de recuperação de desastre (DR) e failover, você precisa usar um provedor DNS que dê suporte ao GeoDNS. Você pode configurar seus registros DNS para dar suporte à recuperação de desastres, de modo que os recursos que usam serviços Web continuem mesmo que um pool de Front-End inteiro seja reduzido. Esse recurso de DR dá suporte às URLs simples Autodiscover, Meet e Dial-in.
Você define e configura registros adicionais de host de DNS A (AAAA, se estiver usando IPv6) para resolução de serviços da Web internos e externos em seu provedor GeoDNS. As informações a seguir supõem pools emparelhados e geograficamente dispersos, GeoDNS suportado por seu provedor com DNS round robin ou configurado para usar o Pool1 como primário e failover para o Pool2, em caso de perda de comunicações ou falha de energia.
Todos os registros DNS nesta tabela são exemplos.
| Registro GeoDNS | Registros de Pool | Registros CNAME | Registros DNS (selecione uma opção) |
|---|---|---|---|
| Meet-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Alias Meet.contoso.com para Pool1InternalWebFQDN.contoso.com Alias Meet.contoso.com para Pool2InternalWebFQDN.contoso.com |
Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha |
| Meet-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Alias Meet.contoso.com para Pool1ExternalWebFQDN.contoso.com Alias Meet.contoso.com para Pool2ExternalWebFQDN.contoso.com |
Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha |
| Dialin-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Alias Dialin.contoso.com para Pool1InternalWebFQDN.contoso.com Alias Dialin.contoso.com para Pool2InternalWebFQDN.contoso.com |
Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha |
| Dialin-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Alias Dialin.contoso.com para Pool1ExternalWebFQDN.contoso.com Alias Dialin.contoso.com para Pool2ExternalWebFQDN.contoso.com |
Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha |
| Lyncdiscoverint-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Alias Lyncdiscoverinternal.contoso.com para Pool1InternalWebFQDN.contoso.com Alias Lyncdiscoverinternal.contoso.com para Pool2InternalWebFQDN.contoso.com |
Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha |
| Lyncdiscover-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Alias Lyncdiscover.contoso.com para Pool1ExternalWebFQDN.contoso.com Alias Lyncdiscover.contoso.com para Pool2ExternalWebFQDN.contoso.com |
Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha |
| Scheduler-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Alias Scheduler.contoso.com para Pool1InternalWebFQDN.contoso.com Alias Scheduler.contoso.com para Pool2InternalWebFQDN.contoso.com |
Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha |
| Scheduler-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Alias Scheduler.contoso.com para Pool1ExternalWebFQDN.contoso.com Alias Scheduler.contoso.com para Pool2ExternalWebFQDN.contoso.com |
Round Robin entre pools OU Use o primário, conecte-se ao secundário em caso de falha |
Balanceamento de carga DNS
O balanceamento de carga do DNS normalmente é implantado no nível dos aplicativos. O aplicativo (por exemplo, um cliente que executa Skype for Business), tenta se conectar a um servidor em um pool conectando-se a um dos endereços IP retornados da consulta de registro DNS A e AAAA (se o endereçamento IPv6 for usado) para o pool FQDN.
Por exemplo, se houver três Servidores front-end em um pool chamado pool01.contoso.com, o seguinte aconteceria:
Clientes que executam Skype for Business DNS de consulta para pool01.contoso.com. A consulta retorna três endereços de IP e os armazena em cache da seguinte maneira (em qualquer ordem):
pool01.contoso.com 192.168.10.90 pool01.contoso.com 192.168.10.91 pool01.contoso.com 192.168.10.92 O cliente tenta estabelecer uma conexão TCP com um dos endereços IP. Em caso de falha, o cliente tenta o próximo endereço IP em cache.
Se a conexão TCP for bem -sucedida, o cliente negocia o TLS para se conectar ao Registrador Avançado primário em pool01.contoso.com.
Se o cliente tentar todas as entradas armazenadas em cache sem uma conexão bem-sucedida, o usuário receberá uma notificação de que nenhum servidor em execução Skype for Business Server estará disponível no momento.
Nota
O balanceamento de carga com base em DNS é diferente do round robin de DNS (DNS RR), que normalmente faz referência ao balanceamento de carga confiando no DNS para fornecer uma ordem diferente de endereços IP dos servidores de seu pool. Normalmente, o DNS RR habilita a distribuição de carga, mas não habilita o failover. Por exemplo, se a conexão com um endereço IP retornado pela consulta DNS A (ou AAAA, se estiver usando o endereçamento IPv6) falhar, a conexão falha. Portanto, o round robin de DNS é menos confiável do que o balanceamento de carga com base em DNS. O round robin de DNS ainda pode ser usado em conjunto com o balanceamento de carga DNS.
O balanceamento de carga DNS é usado para:
Balanceamento de carga SIP servidor a servidor para os Servidores de Borda.
Balanceamento de carga de aplicativos de Serviços de Aplicativos de Comunicações Unificadas (UCAS), como o Atendedor Automático de Conferências, Grupo de Resposta e Estacionamento de Chamada.
Evitar novas conexões a aplicativos UCAS (também conhecido como drenagem).
Balancear o carregamento de todo o tráfego cliente a servidor entre clientes e servidores do Edge.
O balanceamento de carga DNS não pode ser usado para:
- Tráfego Web cliente a servidor para seus Servidores front-end ou um diretor.
Para detalhar um pouco mais sobre como um registro DNS SRV é selecionado quando vários registros DNS são retornados por uma consulta, o serviço access Edge sempre escolhe o registro com a menor prioridade numérica e, se um desempate for necessário, o maior peso numérico. Isso é consistente com a documentação da Força-Tarefa de Engenharia da Internet.
Assim, por exemplo, se seu primeiro registro SRV de DNS tem um peso 20 e uma prioridade 40 e seu segundo registro SRV de DNS tem um peso 10 e uma prioridade 50, o primeiro registro vai ser escolhido, pois tem a prioridade menor de 40. A Prioridade é sempre considerada primeiro, e esse é o primeiro host de destino de um cliente. E se dois destinos tiverem a mesma prioridade?
Nesse caso, o peso é considerado. Pesos maiores devem ter maior probabilidade, nessas circunstâncias, de serem escolhidos. Os administradores DNS devem usar peso 0 quando não houver nenhuma seleção de servidor para fazer. Na presença de registros contendo pesos maiores que 0, os registros com peso 0 devem ter uma chance muito pequena de serem selecionados.
Então, o que acontece se vários registros SRV de DNS com prioridade e peso iguais forem retornados? Nessa situação, o serviço do Access Edge escolherá primeiro o registro SRV que obteve do servidor DNS.