Planear a implementação do Servidor Edge Avançado para Skype for Business Server
Resumo: Reveja os cenários para Skype for Business Server opções de implementação. Quer pretenda um único servidor ou prefira um conjunto de servidores com DNS ou HLB, este tópico deve ajudar.
No que diz respeito ao planeamento do Sistema de Nomes de Domínio (DNS) para Skype for Business Server, muitos fatores podem ser reproduzidos na 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 acedem a 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 registo SRV para ligações TLS internas.
_sip._tls.<domínio>
Este é um registo SRV para ligações TLS externas.
sipinternal.<domínio>
Este é um registo de anfitrião A para o conjunto de Front-End ou o Director, resolvível apenas na rede interna.
sip.<domínio>
Este é um registo de anfitrião A para o conjunto de Front-End ou o Director, resolvível apenas na rede interna.
sipexternal.<domínio>
Este é um registo de anfitrião 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ê quiser, é possível definir 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 solucionando problemas ou fazendo testes, as configurações manuais podem ser muito ú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.
Isso apresenta alguns desafios. O mais importante é que o DNS split-brain não é suportado para a 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).
Vamos listar os registos DNS das zonas internas e externas aqui, mas pode encontrar exemplos detalhados na secçã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:
Registos DNS A e AAAA (se estiver a utilizar endereçamento IPv6) para o conjunto de Front-End, o Conjunto de diretórios ou o Nome do conjunto de diretórios e todos os servidores internos em execução Skype for Business Server na rede da sua organização.
Registos DNS A e AAAA (se estiver a utilizar endereçamento IPv6) para a interface interna do Edge para cada Skype for Business Server Edge Server na sua rede de perímetro.
DNS A e AAAA (se estiver a utilizar o endereçamento IPv6) para a interface interna de cada servidor proxy inverso na sua rede de perímetro (o que é opcional para a gestão de um proxy inverso).
DNS A e AAAA (se estiver a utilizar endereçamento IPv6) e registos SRV para configuração automática interna Skype for Business Server cliente (o que é opcional).
DNS A e AAAA (se estiver a utilizar endereços IPv6) ou registos CNAME para deteção automática de Skype for Business Server Serviços Web (o que é opcional).
Todas as suas Skype for Business Server interfaces edge internas na sua rede de perímetro utilizam esta zona DNS interna para resolver consultas para contoso.com.
Todos os servidores com Skype for Business Server e clientes com Skype for Business Server na rede empresarial apontam para servidores DNS internos para resolver consultas para contoso.com ou utilizam o ficheiro Anfitrião em cada Servidor Edge e listam os registos A e AAAA (se estiver a utilizar o endereçamento IPv6) para o servidor de salto seguinte (especificamente para o conjunto de Diretórios ou Diretores) VIP, VIP do conjunto de Front-end ou servidor do 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 estiver a utilizar endereçamento IPv6) ou registos CNAME, para deteção automática de Skype for Business Server serviços Web. Isto é para utilização com mobilidade.
DNS A e AAAA (se estiver a utilizar o endereçamento IPv6) e os registos SRV para a interface externa do Edge de cada VIP do Skype for Business Server Edge Server ou com balanceamento de carga de hardware (HLB) na rede de perímetro.
DNS A e AAAA (se estiver a utilizar endereços IPv6) e registos SRV para a interface externa do servidor proxy inverso ou (VIP para um conjunto de servidores proxy inversos) na rede de perímetro.
DNS A e AAAA (se estiver a utilizar o endereçamento IPv6) e os registos SRV para Skype for Business Server configuração automática do cliente ( opcional ).
Configuração automática sem DNS de dupla personalidade
Se não utilizar dNS de cérebro dividido, a configuração automática interna de clientes com Skype for Business não funcionará, a menos que esteja a utilizar uma das soluções que temos aqui. Por que não? Uma vez que Skype for Business Server requer que o URI do SIP do utilizador corresponda ao domínio do conjunto de Front-End designado para configuração automática. Isto não foi alterado em 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 utilizador iniciar sessão como bob@contoso.com, este registo funcionará para a configuração automática, uma vez que o domínio SIP do utilizador corresponde ao domínio do conjunto de Front-End (contoso.com).
_sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
Se um utilizador iniciar sessão como alice@fabrikam.com, este registo funcionará para a configuração automática do segundo domínio, novamente porque o domínio SIP corresponde ao conjunto de 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
Um utilizador que inicie sessão como tim@litwareinc.com não funcionará para a configuração automática, porque o seu domínio SIP (litwareinc.com) não corresponde ao domínio no conjunto (fabrikam.com).
Agora que sabemos tudo isso, se precisar de requisitos automáticos para os seus clientes Skype for Business sem DNS dividido, tem 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
Terá de criar uma zona no seu DNS interno que corresponda à zona DNS externa (por exemplo, contoso.com) e, em seguida, criar registos DNS A (e AAAA se estiver a utilizar endereçamento IPv6) que correspondam ao conjunto de Skype for Business Server utilizado para a configuração automática.
Por exemplo, se tiver um utilizador alojada no pool01.contoso.net, mas iniciar sessão no Skype for Business como bob@contoso.com, crie uma zona DNS interna denominada contoso.com e, dentro dela, terá de criar um registo DNS A (e AAAA se o endereçamento IPv6 estiver a ser utilizado) 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 seu domínio SIP estiver contoso.com e tiver um conjunto de Front-End chamado pool01 que contenha dois Servidores front-end, precisará das seguintes zonas de pin-point e registos A no 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
Verá que o FQDN do conjunto de Front-End é apresentado duas vezes, mas com dois endereços IP diferentes. Isso ocorre porque o balanceamento de carga DNS é usado. Se o HLB for utilizado, existirá apenas uma única entrada de conjunto de Front-End.
Nota
Além disso, os valores do FQDN do conjunto de Front-End mudam entre os exemplos contoso.com e fabrikam.com, mas os endereços IP permanecem os mesmos. Isto deve-se ao facto de os utilizadores que estão a iniciar sessão a partir de qualquer um dos domínios SIP utilizarem o mesmo conjunto de Front-End para configuração automática.
DNS disaster recovery
Para configurar o DNS para redirecionar Skype for Business Server tráfego da Web para os sites de recuperação após desastre (DR) e de ativação pós-falha, tem de utilizar um fornecedor de DNS que suporte GeoDNS. Pode configurar os seus registos DNS para suportar a recuperação após desastre, para que as funcionalidades que utilizam serviços Web continuem mesmo que um conjunto de Front End inteiro fique inativo. Esse recurso de DR suporta URLs simples de Descoberta Automática, de reunião e discado.
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. Os detalhes seguintes partem do princípio de que os conjuntos emparelhados, dispersos geograficamente e que o GeoDNS suportado pelo seu fornecedor tem DNS round robin ou está configurado para utilizar o Pool1 como primário e efetua a ativação pós-falha para o Pool2 se houver alguma 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 |
Meet.contoso.com a Meet-int.geolb.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 |
Meet.contoso.com para Meet-ext.geolb.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 |
Meet.contoso.com a Meet-int.geolb.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 |
Meet.contoso.com para Meet-ext.geolb.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 |
Meet.contoso.com a Meet-int.geolb.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 |
Meet.contoso.com para Meet-ext.geolb.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 |
Meet.contoso.com a Meet-int.geolb.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 |
Meet.contoso.com para Meet-ext.geolb.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. A aplicação (por exemplo, um cliente com Skype for Business), tenta ligar-se a um servidor num conjunto ao ligar a um dos endereços IP devolvidos pelo DNS A e AAAA (se for utilizado o endereçamento IPv6) para o FQDN do conjunto.
Por exemplo, se existirem três Servidores Front-End num conjunto com o nome pool01.contoso.com, ocorrerá o seguinte:
Clientes com Skype for Business consulta DNS 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. Se isso falhar, tentará o endereço IP seguinte que é colocado em cache a partir dessa lista.
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 em cache sem uma ligação com êxito, o utilizador recebe uma notificação a indicar que não existem servidores a executar Skype for Business Server estão disponíveis neste 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:
Balancear a carga do SIP de servidor para servidor para os Servidores Edge.
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 a carga de todo o tráfego cliente a servidor entre clientes e Servidores Edge.
O balanceamento de carga DNS não pode ser usado para:
- Tráfego Web cliente a servidor para os Servidores front-end ou um Diretor.
Para obter um pouco mais de profundidade sobre a forma como um registo SRV DNS é selecionado quando vários registos DNS são devolvidos por uma consulta, o serviço Access Edge escolhe sempre o registo com a prioridade numérica mais baixa e, se for necessário um disjuntor, a maior ponderação numérica. Isto é consistente com a documentação do Task Force 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 registos com pesos superiores a 0, os registos com peso 0 têm uma pequena hipótese de trazer selecionados.
Então, o que acontece se vários registros SRV de DNS com prioridade e peso iguais forem retornados? Nesta situação, o serviço Access Edge escolherá primeiro o registo SRV que obteve do servidor DNS.