Requisitos de balanceamento de carga para o Skype for Business

Resumo: Examine as considerações de balanceamento de carga antes de implementar Skype for Business Server.

O balanceamento de carga distribui o tráfego entre os servidores em um pool. Se você tiver pools do Front-End, pools do Servidor de Mediação ou pools do Edge Server, precisará implantar o balanceamento de carga para esses pools.

Skype for Business Server dá suporte a dois tipos de soluções de balanceamento de carga para tráfego cliente-servidor: balanceamento de carga DNS (Sistema de Nomes de Domínio) e balanceamento de carga de hardware (geralmente abreviado como HLB). O balanceamento de carga DNS oferece várias vantagens, incluindo administração mais simples, solução de problemas mais eficiente e a capacidade de isolar grande parte do tráfego Skype for Business Server de possíveis problemas de balanceador de carga de hardware.

Decida por si mesmo qual solução de balanceamento de carga é apropriada para cada pool em sua implantação, mas tenha em mente as seguintes restrições:

  • As interfaces de Borda interna e externa precisam usar o mesmo tipo de balanceamento de carga. Não é possível usar o balanceamento de carga DNS em uma interface e o balanceamento de carga de hardware em outra.

  • Alguns tipos de tráfego exigem um balanceador de carga de hardware. Por exemplo, o tráfego HTTP requer um balanceador de carga de hardware em vez do balanceamento de carga DNS. O balanceamento de carga DNS não funciona com o tráfego web de cliente-servidor.

Se optar por usar o balanceamento de carga DNS para um pool, mas ainda for necessário implementar balanceadores de carga de hardware para o tráfego, como o tráfego HTTP, a administração dos balanceadores de carga de hardware é bastante simplificada. Por exemplo, a configuração do balanceador de carga de hardware será mais simples, pois gerenciará somente os tráfegos HTTP e HTTPS, enquanto os demais protocolos serão gerenciados pelo balanceamento de carga DNS. Para obter detalhes, consulte DNS Load Balancing.

Para o tráfego servidor a servidor, Skype for Business Server usa o balanceamento de carga com reconhecimento de topologia. Os servidores leem a topologia publicada no repositório gerenciamento central para obter os FQDNs dos servidores na topologia e distribuir automaticamente o tráfego entre os servidores. Os administradores não precisam configurar nem gerenciar esse tipo de balanceamento de carga.

Se você usar um balanceamento de carga DNS e precisar bloquear o tráfego para um computador específico, não é suficiente apenas remover as entradas do endereço IP do Pool FQDN. Você deve remover a entrada DNS do computador.

Requisitos do balanceador de carga do hardware

A topologia do Edge consolidada Skype for Business Server é otimizada para o balanceamento de carga DNS para novas implantações federadas principalmente com outras organizações usando Skype for Business Server ou Lync Server. Se a alta disponibilidade for necessária para qualquer um dos seguintes cenários, um balanceador de carga de hardware deve ser usado em pools do Edge Server para o seguinte:

  • Federação com organizações usando o Office Communications Server 2007 R2 ou Office Communications Server 2007

  • Trocar UM por usuários remotos usando o Exchange UM antes do Exchange 2010 com o SP1

  • Conectividade para usuários públicos de mensagens instantâneas

Importante

O uso do balanceamento de carga de DNS em uma interface e do balanceamento de carga de hardware na outra não é suportado. É preciso usar o balanceamento de carga de hardware ou de DNS nas duas interfaces.

Nota

Se estiver usando um balanceador de carga de hardware, o balanceador de carga implantado para conexões com a rede interna deverá ser configurado para balancear apenas cargas do tráfego de servidores que executam o serviço de Borda de Acesso e o serviço de Borda A/V. Ele não poderá balancear a carga do tráfego do serviço interno de Borda de Webconferência ou do serviço interno de Proxy XMPP.

Nota

O NAT de retorno do servidor direto (DSR) não tem suporte com Skype for Business Server.

Para determinar se o balanceador de carga de hardware dá suporte aos recursos necessários exigidos pelo Skype for Business Server, consulte Infraestrutura para Skype for Business.

Requisitos do balanceador de carga de hardware para servidores de borda que executam o serviço de Borda A/V

A seguir estão os requisitos do balanceador de carga de hardware para Servidores de Borda que executam o serviço A/V Edge:

  • Desative o nagling de TCP para as portas interna e externa 443. Nagling é o processo de combinação de diversos pacotes pequenos em um único pacote maior para uma transmissão mais eficiente.

  • Desative a soneca TCP para o intervalo de portas externas de 50.000 a 59.999.

  • Não use NAT no firewall interno ou externo.

  • A interface interna de borda deve estar em uma rede diferente da interface externa do Edge Server e o roteamento entre eles deve ser desabilitado.

  • A interface externa do Edge Server que executa o Serviço de Borda A/V deve usar endereços IP roteáveis publicamente e nenhuma tradução nat ou porta em qualquer um dos endereços IP externos de borda.

  • O balanceador de carga não pode trocar o endereço da fonte do cliente.

Outros requisitos de Load Balancer de hardware

Os requisitos de afinidade baseados em cookie são muito reduzidos em Skype for Business Server para serviços Web. Se você estiver implantando Skype for Business Server e não manter nenhum Servidor de Front-End do Lync Server 2010 ou pools front-end, não precisará de persistência baseada em cookie. No entanto, se você manter temporariamente ou permanentemente todos os servidores front-end do Lync Server 2010 ou pools front-end, você ainda usará a persistência baseada em cookie à medida que ela é implantada e configurada para o Lync Server 2010.

Nota

Se decidir usar afinidade baseada em cookie mesmo que sua implantação não exija, isso não causará um impacto negativo.

Para implantações que não usarão afinidade baseada em cookie:

  • No proxy reverso que publica a regra da porta 4443, defina Encaminhar cabeçalho de host como Verdadeiro. Isso garantirá que a URL original seja encaminhada.

Para implantações que usarão afinidade baseada em cookie:

  • No proxy reverso que publica a regra da porta 4443, defina Encaminhar cabeçalho de host como Verdadeiro. Isso garantirá que a URL original seja encaminhada.

  • O cookie do balanceador de carga de hardware NÃO DEVE ser marcado como httpOnly

  • O cookie do balanceador de carga de hardware NÃO DEVE conter uma data de vencimento

  • O cookie do balanceador de carga de hardware DEVE ser nomeado como MS-WSMAN (esse é o valor que o serviço Web espera e não pode ser alterado)

  • O cookie do balanceador de carga de hardware DEVE ser definido em todas as respostas HTTP para as quais a solicitação HTTP recebida não contém um cookie, independentemente de uma resposta HTTP anterior na mesma conexão TCP já ter obtido um cookie. Se o balanceador de carga otimiza a inserção de cookie para apenas uma ocorrência por conexão TCP, essa otimização NÃO DEVE ser usada

Nota

As configurações típicas do balanceador de carga de hardware usam afinidade de endereço-origem e 20 minutos. Tempo de vida da sessão TCP, o que é bom para clientes do Lync Server e do Lync 2013 porque o estado da sessão é mantido por meio do uso do cliente e/ou interação do aplicativo.

Se estiver implantando dispositivos móveis, o balanceador de carga de hardware deverá ser capaz de balancear a carga da solicitação individual em uma sessão TCP (na verdade, você deve poder balancear a carga de uma solicitação individual com base no endereço IP de destino).

Cuidado

Se você estiver implantando dispositivos móveis, o balanceador de carga de hardware deve ser capaz de balancear individualmente cada solicitação dentro de uma conexão TCP. Os aplicativos móveis mais recentes do Apple iOS exigem a versão 1.2 do protocolo TLS.

Cuidado

Para obter detalhes sobre balanceadores de carga de hardware de terceiros, consulte Infraestrutura para Skype for Business.

A seguir, são apresentados os requisitos do balanceador de carga de hardware para serviços Web do pool de diretores e de front-end:

  • Para VIPs de serviços Web internos, defina a persistência Source_addr (porta interna 80, 443) no balanceador de carga de hardware. Para Skype for Business Server, Source_addr persistência significa que várias conexões provenientes de um único endereço IP são sempre enviadas para um servidor para manter o estado da sessão.

  • Use um tempo de ociosidade de TCP de 1.800 segundos.

  • No firewall entre o proxy reverso e o balanceador de carga de hardware do pool de salto seguinte, crie uma regra para permitir https: tráfego na porta 4443, do proxy reverso ao balanceador de carga de hardware. O balanceador de carga de hardware deve ser configurado para ouvir as portas 80, 443 e 4443.

Resumo dos requisitos de afinidade do balanceador de carga de hardware

Local do cliente/usuário Requisitos de afinidade de FQDN de serviços Web externos Requisitos de afinidade de FQDN de serviços Web internos
Lync Web App (usuários internos e externos)
Dispositivo móvel (usuários internos e externos)
Sem afinidade
Afinidade do endereço de origem
Lync Web App (somente usuários externos)
Dispositivo móvel (usuários internos e externos)
Sem afinidade
Afinidade do endereço de origem
Lync Web App (somente usuários internos)
Dispositivo móvel (não implantado)
Sem afinidade
Afinidade do endereço de origem

Monitoramento de portas dos balanceadores de carga de hardware

Defina o monitoramento de portas nos balanceadores de carga de hardware para determinar quando serviços específicos não estão mais disponíveis devido a uma falha de hardware ou comunicação. Por exemplo, se o SERVIÇO do Servidor front-end (RTCSRV) for interrompido porque o pool do Front End Server ou front-end falhar, o monitoramento do HLB também deverá parar de receber tráfego nos Serviços Web. Implante o monitoramento de portas no HLB para monitorar o seguinte:

Pool de Usuários do Servidor Front-End – Interface Interna do HLB

IP/porta virtual Porta do nó Máquina/monitor do nó Perfil de persistência Anotações
<pool>web-int_mco_443_vs
443
443
Front-End
5061
Origem
HTTPS
<pool>web-int_mco_80_vs
80
80
Front-End
5061
Origem
HTTP

Pool de Usuários do Servidor Front-End – Interface Externa do HLB

IP/porta virtual Porta do nó Máquina/monitor do nó Perfil de persistência Anotações
<pool>web_mco_443_vs
443
4443
Front-End
5061
Nenhum
HTTPS
<pool>web_mco_80_vs
80
8080
Front-End
5061
Nenhum
HTTP

DNS Load Balancing

Skype for Business Server habilita o balanceamento de carga DNS, uma solução de software que pode reduzir consideravelmente a sobrecarga de administração para o balanceamento de carga em sua rede. O balanceamento de carga DNS equilibra o tráfego de rede exclusivo para Skype for Business Server, como tráfego SIP e tráfego de mídia.

Se você implantar o balanceamento de carga DNS, a sobrecarga de administração da sua organização para balanceadores de carga de hardware será minimizada. Além disso, a solução de problemas complexos de problemas relacionados à configuração incorreta de balanceadores de carga para tráfego SIP será eliminada. Você também pode impedir conexões de servidor para que você possa tirar servidores offline. O balanceamento de carga DNS também garante que os problemas do balanceador de carga de hardware não afetem elementos do tráfego SIP, como o roteamento básico de chamadas.

O diagrama a seguir mostra um exemplo que inclui o balanceamento de carga DNS interno e externo:

Diagrama da rede de borda que usa endereços IPv4 públicos

exemplo de diagrama de rede DNS.

Se você usar o balanceamento de carga DNS, também poderá comprar balanceadores de carga de hardware de menor custo do que se você usou os balanceadores de carga de hardware para todos os tipos de tráfego. Você deve usar balanceadores de carga que passaram pelo teste de qualificação de interoperabilidade com Skype for Business Server. Para obter detalhes sobre o teste de interoperabilidade do balanceador de carga, consulte Lync Server 2010 Load Balancer Partners. O conteúdo lá se aplica a Skype for Business Server.

Há suporte para balanceamento de carga DNS para pools front-end, pools do Edge Server, pools de diretores e pools de servidores de mediação autônomos.

O balanceamento de carga DNS normalmente é implementado no nível do aplicativo. 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 nome de domínio totalmente qualificado do pool (FQDN).

Por exemplo, se houver três servidores front-end em um pool chamado pool01.contoso.com, o seguinte acontecerá:

  • Clientes que executam Skype for Business DNS de consulta para pool01.contoso.com. A consulta retorna três endereços IP e os armazena em cache da seguinte maneira (não necessariamente nesta 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 (Protocolo de Controle de Transmissão) com um dos endereços IP. Se isso falhar, o cliente tentará o próximo endereço IP no 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 será notificado de que nenhum servidor em execução Skype for Business Server estará disponível no momento.

Nota

O balanceamento de carga baseado em DNS é diferente do DNS (DNS RR), que normalmente se refere ao balanceamento de carga, dependendo do DNS para fornecer uma ordem diferente de endereços IP correspondentes aos servidores em um pool. Normalmente, o DNS RR só 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 e AAAA (se você estiver usando o endereçamento IPv6) falhar, a conexão falhará. Portanto, o round robin DNS por si só é menos confiável do que o balanceamento de carga baseado em DNS. Você pode usar o round robin DNS em conjunto com o balanceamento de carga DNS.

O balanceamento de carga DNS é usado para o seguinte:

  • Balanceamento de carga do SIP servidor a servidor para os Servidores de Borda

  • Aplicativos UCAS (Serviços de Aplicativo de Comunicações Unificadas) de balanceamento de carga, como Atendimento Automático de Conferência, Grupo de Resposta e Parque de Chamadas

  • Impedindo novas conexões com aplicativos UCAS (também conhecidos como "drenagem")

  • Balanceamento de carga de todo o tráfego cliente-servidor entre clientes e Servidores do Edge

O balanceamento de carga DNS não pode ser usado para o seguinte:

  • Tráfego Web cliente a servidor para Servidores de Direção ou Front-End

Balanceamento de carga DNS e tráfego federado:

Se vários registros DNS forem retornados por uma consulta DNS SRV, o serviço Access Edge sempre escolherá o registro DNS SRV com a menor prioridade numérica e o maior peso numérico. O documento da Força-Tarefa de Engenharia da Internet "A DNS RR para especificar o local dos serviços (DNS SRV)" RFC 2782, DNS SRV RR especifica que, se houver vários registros DNS SRV definidos, a prioridade será usada primeiro e, em seguida, o peso. Por exemplo, o registro DNS SRV A tem um peso de 20 e uma prioridade de 40 e o registro de SRV DNS B tem um peso de 10 e prioridade de 50. O registro DNS SRV A com prioridade 40 será selecionado. As seguintes regras se aplicam à seleção de registro do DNS SRV:

  • A prioridade é considerada primeiro. Um cliente DEVE tentar entrar em contato com o host de destino definido pelo registro DNS SRV com a menor prioridade numerada que pode alcançar. Destinos com a mesma prioridade DEVE ser tentado em uma ordem definida pelo campo de peso.

  • O campo de peso especifica um peso relativo para entradas com a mesma prioridade. Pesos maiores DEVEM receber uma probabilidade proporcionalmente maior de ser selecionado. Os administradores DNS devem usar o Peso 0 quando não houver nenhuma seleção de servidor para fazer. Na presença de registros que contêm pesos maiores que 0, os registros com peso 0 devem ter uma pequena chance de serem selecionados.

Se vários registros DNS SRV com igual prioridade e peso forem retornados, o serviço access Edge selecionará o registro SRV que foi recebido primeiro do servidor DNS.

Balanceamento de carga DNS em pools front-end e pools de diretores

Você pode usar o balanceamento de carga DNS para o tráfego SIP em pools front-end e pools de diretores. Com o balanceamento de carga DNS implantado, você ainda precisa usar balanceadores de carga de hardware para esses pools, mas apenas para tráfego HTTPS cliente a servidor. O balanceador de carga de hardware é usado para tráfego HTTPS de clientes nas portas 443 e 80.

Embora você ainda precise de balanceadores de carga de hardware para esses pools, sua configuração e administração serão principalmente para o tráfego HTTPS, ao qual os administradores dos balanceadores de carga de hardware estão acostumados.

Balanceamento de carga DNS e suporte a clientes e servidores mais antigos

O balanceamento de carga DNS dá suporte apenas ao failover automático para servidores que executam Skype for Business Server ou Lync Server 2010 e para clientes do Lync 2013 e Skype for Business. Versões anteriores de clientes e do Office Communications Server ainda podem se conectar a pools que executam o balanceamento de carga DNS, mas se eles não puderem fazer uma conexão com o primeiro servidor ao qual o balanceamento de carga DNS os encaminha, eles não poderão fazer failover para outro servidor no pool.

Além disso, se você estiver usando o Exchange UM, deverá usar um mínimo do Exchange 2010 SP1 para obter suporte para Skype for Business Server balanceamento de carga DNS. Se você usar uma versão anterior do Exchange, seus usuários não terão recursos de failover para esses cenários do Exchange UM:

  • Reproduzindo sua caixa postal enterprise em seu telefone

  • Transferir chamadas de um assistente automático do Exchange UM

Todos os outros cenários do Exchange UM funcionarão corretamente.

Implantando o balanceamento de carga DNS em pools front-end e pools de diretores

A implantação do balanceamento de carga DNS em pools front-end e pools de diretores exige que você execute algumas etapas extras com FQDNs e registros DNS.

  • Um pool que usa o balanceamento de carga DNS deve ter dois FQDNs: o FQDN de pool regular usado pelo balanceamento de carga DNS (como pool01.contoso.com) e resolve para os IPs físicos dos servidores no pool e outro FQDN para os serviços Web do pool (como web01.contoso.com), que resolve para o endereço IP virtual do pool.

    No Construtor de Topologia, se você quiser implantar o balanceamento de carga DNS para um pool, para criar esse FQDN extra para os serviços Web do pool, você deve selecionar a caixa FQDN marcar do pool de Serviços Web interno de substituição e digitar o FQDN, na página Especificar as URLs dos Serviços Web para esta página do Pool.

  • Para dar suporte ao FQDN usado pelo balanceamento de carga DNS, você deve provisionar o DNS para resolve o pool FQDN (como pool01.contoso.com) para os endereços IP de todos os servidores no pool (por exemplo, 192.168.1.1, 192.168.1.2 e assim por diante). Você deve incluir apenas os endereços IP de servidores que estão implantados no momento.

    Cuidado

    Se você tiver mais de um pool de Front-End ou o Front-End Server, o FQDN de serviços Web externos deverá ser exclusivo. Por exemplo, se você definir o FQDN de serviços Web externos de um Servidor front-end como pool01.contoso.com, não poderá usar pool01.contoso.com para outro pool de Front-End ou Servidor front-end. Se você também estiver implantando Diretores, o FQDN de serviços Web externos definido para qualquer pool de diretores ou diretores deve ser exclusivo de qualquer outro pool de diretores ou diretores, bem como qualquer pool de Front-End ou Servidor front-end. Se decidir substituir os serviços Web internos com um FQDN autodefinido, cada FQDN deverá ser exclusivo de qualquer outro pool front-end, diretor ou um pool de diretores.

Balanceamento de carga DNS em Pools do Servidor de Borda

Você pode implantar o balanceamento de carga DNS em pools do Edge Server. Se você fizer isso, você deve estar ciente de algumas considerações.

O uso do balanceamento de carga DNS em seus Servidores de Borda causa uma perda da capacidade de failover nos seguintes cenários:

  • Federação com organizações que estão executando versões de Skype for Business Server lançadas antes do Lync Server 2010.

  • Troca de mensagens instantâneas com usuários dos serviços públicos de mensagens instantâneas AOL e Yahoo!, além de provedores e servidores baseados em XMPP, como o Google Talk, atualmente o único parceiro XMPP com suporte.

Esses cenários funcionarão enquanto todos os Servidores do Edge no pool estiverem em execução, mas se um Servidor do Edge não estiver disponível, todas as solicitações para esses cenários enviados a ele falharão, em vez de rotear para outro Servidor de Borda.

Se você estiver usando o Exchange UM, deverá usar um mínimo do Exchange 2013 para obter suporte para Skype for Business Server balanceamento de carga DNS no Edge. Se você usar uma versão anterior do Exchange, seus usuários remotos não terão recursos de failover para esses cenários do Exchange UM:

  • Reproduzindo sua caixa postal enterprise em seu telefone

  • Transferir chamadas de um assistente automático do Exchange UM

Todos os outros cenários do Exchange UM funcionarão corretamente.

As interfaces de Borda interna e externa precisam usar o mesmo tipo de balanceamento de carga. Não é possível usar balanceamento de carga DNS em uma interface de Borda e balanceamento de carga de hardware na outra interface de Borda.

Implantando o Balanceamento de Carga DNS em Pools do Servidor de Borda

Para implantar o balanceamento de carga DNS na interface externa do pool do Edge Server, você precisa das seguintes entradas DNS:

  • Para o serviço Access Edge, você precisa de uma entrada para cada servidor no pool. Cada entrada deve resolve o FQDN do serviço Access Edge (por exemplo, sip.contoso.com) ao endereço IP do serviço Access Edge em um dos Servidores de Borda no pool.

  • Para o serviço Web Conferencing Edge, você precisa de uma entrada para cada servidor no pool. Cada entrada deve resolve o FQDN do serviço Web Conferencing Edge (por exemplo, webconf.contoso.com) ao endereço IP do serviço Web Conferencing Edge em um dos Servidores de Borda no pool.

  • Para o serviço Audio/Video Edge, você precisa de uma entrada para cada servidor no pool. Cada entrada deve resolve o FQDN do serviço de Áudio/Vídeo Edge (por exemplo, av.contoso.com) no endereço IP do serviço A/V Edge em um dos Servidores de Borda no pool.

Para implantar o balanceamento de carga DNS na interface interna do pool do Edge Server, você deve adicionar um registro DNS A, que resolve o FQDN interno do pool do Edge Server ao endereço IP de cada servidor no pool.

Usando o balanceamento de carga DNS em pools de servidores de mediação

Você pode usar o balanceamento de carga DNS em pools autônomos do Servidor de Mediação. Todo o tráfego de mídia e SIP é balanceado pelo balanceamento de carga DNS.

Para implantar o balanceamento de carga DNS em um pool do Servidor de Mediação, você deve provisionar o DNS para resolve o pool FQDN (por exemplo, mediationpool1.contoso.com) nos endereços IP de todos os servidores do pool (por exemplo, 192.168.1.1, 192.168.1.2 e assim por diante).

Bloquear o tráfego em um servidor com balanceamento de carga DNS

Se você usar um balanceamento de carga DNS e precisar bloquear o tráfego para um computador específico, não é suficiente apenas remover as entradas do endereço IP do Pool FQDN. Você deve remover a entrada DNS do computador.

Observe que, para o tráfego servidor a servidor, Skype for Business Server usa o balanceamento de carga com reconhecimento de topologia. Os servidores leem a topologia publicada no repositório gerenciamento central para obter os FQDNs dos servidores na topologia e distribuir automaticamente o tráfego entre os servidores. Para impedir que um servidor receba tráfego de servidor para servidor, você deve remover o servidor da topologia.