Requisitos de balanceamento de carga para o Skype for Business
Resumo: Reveja 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 num conjunto. Se tiver conjuntos de Front-End, conjuntos de Servidores de Mediação ou conjuntos do Edge Server, terá de implementar o balanceamento de carga para estes conjuntos.
Skype for Business Server suporta dois tipos de soluções de balanceamento de carga para o tráfego cliente para servidor: balanceamento de carga do Sistema de Nomes de Domínio (DNS) e balanceamento de carga de hardware (muitas vezes abreviado como HLB). O balanceamento de carga DNS oferece várias vantagens, incluindo uma administração mais simples, uma resolução de problemas mais eficiente e a capacidade de isolar grande parte do tráfego Skype for Business Server de quaisquer potenciais problemas do balanceador de carga de hardware.
Decida por si qual a solução de balanceamento de carga adequada para cada conjunto na sua implementação, mas tenha em atenção 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 utiliza balanceamento de carga com suporte para topologia. Os servidores leem a topologia publicada no arquivo de Gestão 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
O Skype for Business Server topologia do Edge consolidada dimensionada está otimizada para balanceamento de carga DNS para novas implementações federadas principalmente com outras organizações que utilizam o Skype for Business Server ou o Lync Server. Se for necessária elevada disponibilidade para qualquer um dos seguintes cenários, tem de ser utilizado um balanceador de carga de hardware nos conjuntos do Edge Server para o seguinte:
Federação com organizações que utilizam o Office Communications Server 2007 R2 ou o Office Communications Server 2007
Exchange UM para utilizadores remotos que utilizam o Exchange UM antes do Exchange 2010 com 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 devolução direta do servidor (DSR) não é suportado com Skype for Business Server.
Para determinar se o balanceador de carga de hardware suporta as funcionalidades necessárias para Skype for Business Server, veja 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
Seguem-se os requisitos do balanceador de carga de hardware para Servidores Edge 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 navegação TCP para o intervalo de portas externas 50 000 - 59.999.
Não use NAT no firewall interno ou externo.
A interface interna do edge tem de estar numa rede diferente da interface externa do Edge Server e o encaminhamento entre eles tem de ser desativado.
A interface externa do Servidor Edge que executa o Serviço Edge A/V tem de utilizar endereços IP encaminháveis publicamente e nenhuma tradução de NAT ou porta em nenhum dos endereços IP externos edge.
O balanceador de carga não pode trocar o endereço da fonte do cliente.
Outros requisitos de hardware Load Balancer
Os requisitos de afinidade baseados em cookies são significativamente reduzidos em Skype for Business Server para serviços Web. Se estiver a implementar Skype for Business Server e não irá reter quaisquer Servidores front-end ou conjuntos front-end do Lync Server 2010, não precisa de persistência baseada em cookies. No entanto, se manter temporariamente ou permanentemente quaisquer Servidores front-end ou conjuntos front-end do Lync Server 2010, continuará a utilizar a persistência baseada em cookies à medida que é implementado e configurado 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 utilizam afinidade de endereço de origem e 20 min. Duração da sessão TCP, o que é bom para clientes do Lync Server e do Lync 2013 porque o estado da sessão é mantido através da utilização do cliente e/ou da interação da aplicação.
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).
Atenção
Se estiver a implementar dispositivos móveis, o balanceador de carga de hardware tem de conseguir fazer o balanceamento de carga individualmente em cada pedido numa ligação TCP. Os aplicativos móveis mais recentes do Apple iOS exigem a versão 1.2 do protocolo TLS.
Atenção
Para obter detalhes sobre balanceadores de carga de hardware de terceiros, veja 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. Por Skype for Business Server, Source_addr persistência significa que várias ligaçõ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.
Na firewall entre o proxy inverso e o balanceador de carga de hardware do conjunto de salto seguinte, crie uma regra para permitir https: tráfego na porta 4443, desde o proxy inverso 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 (utilizadores internos e externos) Dispositivo móvel (usuários internos e externos) |
Sem afinidade |
Afinidade do endereço de origem |
Lync Web App (apenas utilizadores externos) Dispositivo móvel (usuários internos e externos) |
Sem afinidade |
Afinidade do endereço de origem |
Lync Web App (apenas utilizadores 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 Front End Server (RTCSRV) parar porque o Servidor front-end ou o conjunto de Front-End falham, a monitorização do HLB também deverá deixar de receber tráfego nos Serviços Web. Implante o monitoramento de portas no HLB para monitorar o seguinte:
Conjunto de Utilizadores 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 |
---|---|---|---|---|
<
>conjunto de int_mco_443_vs Web 443 |
443 |
Front-End 5061 |
Origem |
HTTPS |
<
>conjunto de int_mco_80_vs Web 80 |
80 |
Front-End 5061 |
Origem |
HTTP |
Conjunto de Utilizadores 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 |
---|---|---|---|---|
<web_mco_443_vs do conjunto> 443 |
4443 |
Front-End 5061 |
Nenhum |
HTTPS |
<web_mco_80_vs do conjunto> 80 |
8080 |
Front-End 5061 |
Nenhum |
HTTP |
DNS Load Balancing
Skype for Business Server permite o balanceamento de carga DNS, uma solução de software que pode reduzir consideravelmente a sobrecarga de administração para balanceamento de carga na sua rede. O balanceamento de carga DNS equilibra o tráfego de rede exclusivo para Skype for Business Server, como o tráfego SIP e o tráfego de multimédia.
Se implementar 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 resolução complexa de problemas relacionados com a configuração incorreta dos balanceadores de carga para o tráfego SIP será eliminada. Também pode impedir ligações de servidor para que possa colocar os servidores offline. O balanceamento de carga DNS também garante que os problemas do balanceador de carga de hardware não afetam os elementos do tráfego SIP, como o encaminhamento básico de chamadas.
O diagrama seguinte mostra um exemplo que inclui o balanceamento de carga de DNS interno e externo:
Diagrama da rede de borda que usa endereços IPv4 públicos
Se utilizar o balanceamento de carga DNS, também poderá comprar balanceadores de carga de hardware de baixo custo do que se utilizasse os balanceadores de carga de hardware para todos os tipos de tráfego. Deve utilizar balanceadores de carga que passaram em testes de qualificação de interoperabilidade com Skype for Business Server. Para obter detalhes sobre os testes de interoperabilidade do balanceador de carga, veja Lync Server 2010 Load Balancer Partners . Os conteúdos aí presentes aplicam-se a Skype for Business Server.
O balanceamento de carga DNS é suportado para conjuntos de Front-End, conjuntos do Edge Server, Conjuntos de diretórios e conjuntos de Servidores de Mediação autónomos.
O balanceamento de carga DNS é normalmente implementado ao nível da aplicação. A aplicação (por exemplo, um cliente a executar Skype for Business), tenta ligar-se a um servidor num conjunto ao ligar a um dos endereços IP devolvidos a partir da consulta de registo DNS A e AAAA (se for utilizado o endereçamento IPv6) para o nome de domínio completamente qualificado (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 devolve três endereços IP e coloca-os em cache da seguinte forma (não necessariamente por esta 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 ligação TCP (Transmission Control Protocol) a um dos endereços IP. Se isso falhar, o cliente tentará o endereço IP seguinte na 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 em cache sem uma ligação bem-sucedida, o utilizador será notificado de que não existem servidores com Skype for Business Server disponíveis neste momento.
Nota
O balanceamento de carga baseado em DNS é diferente do round robin de DNS (RR de DNS), que normalmente se refere ao balanceamento de carga ao depender do DNS para fornecer uma ordem diferente de endereços IP correspondentes aos servidores num conjunto. Normalmente, o RR de DNS só permite a distribuição de carga, mas não ativa a ativação pós-falha. Por exemplo, se a ligação ao endereço IP devolvido pela consulta DNS A e AAAA (se estiver a utilizar o endereçamento IPv6) falhar, a ligação falhará. Por conseguinte, o round robin de DNS por si só é menos fiável do que o balanceamento de carga baseado em DNS. Pode utilizar o round robin de DNS em conjunto com o balanceamento de carga DNS.
O balanceamento de carga DNS é utilizado para o seguinte:
Balanceamento de carga de servidor para servidor SIP para os Servidores Edge
Balanceamento de carga de aplicações do Unified Communications Application Services (UCAS), tais como Atendedor Automático de Conferências, Grupo de Resposta e Call Park
Impedir novas ligações a aplicações UCAS (também conhecidas como "drenagem")
Balanceamento de carga de todo o tráfego cliente a servidor entre clientes e Servidores Edge
O balanceamento de carga DNS não pode ser utilizado para o seguinte:
- Tráfego Web cliente a servidor para Servidores de Diretório ou Front-end
Balanceamento de carga DNS e tráfego federado:
Se forem devolvidos vários registos DNS por uma consulta SRV DNS, o serviço Access Edge escolhe sempre o registo SRV DNS com a prioridade numérica mais baixa e o peso numérico mais elevado. O documento "A DNS RR for specifying the location of services (DNS SRV)" RFC 2782, DNS SRV RR especifica que, se existirem vários registos SRV DNS definidos, a prioridade é utilizada primeiro e, em seguida, a ponderação. Por exemplo, o registo SRV DNS A tem um peso de 20 e uma prioridade de 40 e o registo SRV DNS B tem um peso de 10 e uma prioridade de 50. Será selecionado o registo DNS SRV A com prioridade 40. As seguintes regras aplicam-se à seleção de registos SRV DNS:
A prioridade é considerada em primeiro lugar. Um cliente TEM de tentar contactar o anfitrião de destino definido pelo registo SRV de DNS com a prioridade numerada mais baixa que pode alcançar. Os destinos com a mesma prioridade DEVEM ser experimentados numa ordem definida pelo campo de ponderação.
O campo de peso especifica um peso relativo para entradas com a mesma prioridade. Os pesos maiores DEVEM ter uma probabilidade proporcionalmente maior de serem selecionados. Os administradores de DNS DEVEM utilizar a ponderação 0 quando não existe nenhuma seleção de servidor para fazer. Na presença de registos que contenham pesos superiores a 0, os registos com peso 0 devem ter uma hipótese muito pequena de serem selecionados.
Se forem devolvidos vários registos SRV DNS com igual prioridade e ponderação, o serviço Access Edge irá selecionar o registo SRV que foi recebido primeiro a partir do servidor DNS.
Balanceamento de Carga DNS em Conjuntos de Front-end e Conjuntos de Diretórios
Pode utilizar o balanceamento de carga DNS para o tráfego SIP em conjuntos de Front-End e Conjuntos de diretórios. Com o balanceamento de carga DNS implementado, ainda precisa de utilizar balanceadores de carga de hardware para estes conjuntos, mas apenas para tráfego HTTPS cliente a servidor. O balanceador de carga de hardware é utilizado para o tráfego HTTPS de clientes através das portas 443 e 80.
Embora ainda precise de balanceadores de carga de hardware para estes conjuntos, a respetiva configuração e administração será principalmente para o tráfego HTTPS, ao qual os administradores dos balanceadores de carga de hardware estão habituados.
Balanceamento de Carga DNS e Suporte a Clientes e Servidores Mais Antigos
O balanceamento de carga DNS suporta a ativação pós-falha automática apenas para servidores com Skype for Business Server ou Lync Server 2010 e para clientes do Lync 2013 e Skype for Business. As versões anteriores dos clientes e do Office Communications Server ainda podem ligar-se a conjuntos com balanceamento de carga DNS, mas se não conseguirem estabelecer uma ligação ao primeiro servidor ao qual o balanceamento de carga DNS os encaminha, não poderão efetuar a ativação pós-falha para outro servidor no conjunto.
Além disso, se estiver a utilizar o Exchange UM, tem de utilizar um mínimo de Exchange 2010 SP1 para obter suporte para Skype for Business Server balanceamento de carga DNS. Se utilizar uma versão anterior do Exchange, os seus utilizadores não terão capacidades de ativação pós-falha para estes cenários do Exchange UM:
A reproduzir o voicemail enterprise no telemóvel
Transferir chamadas de um Atendedor Automático do Exchange UM
Todos os outros cenários do Exchange UM funcionarão corretamente.
Implementar o Balanceamento de Carga DNS em Conjuntos de Front-end e Conjuntos de Diretórios
A implementação do balanceamento de carga de DNS em conjuntos de Front-End e conjuntos de Diretórios requer que execute alguns passos adicionais com FQDNs e registos DNS.
Um conjunto que utilize balanceamento de carga DNS tem de ter dois FQDNs: o FQDN do conjunto normal que é utilizado pelo balanceamento de carga de DNS (como pool01.contoso.com) e resolve para os IPs físicos dos servidores no conjunto e outro FQDN para os serviços Web do conjunto (como web01.contoso.com), que resolve para o endereço IP virtual do conjunto.
No Topology Builder, se quiser implementar o balanceamento de carga de DNS para um conjunto, para criar este FQDN adicional para os serviços Web do conjunto, tem de selecionar a caixa de marcar substituir o FQDN do conjunto de Serviços Web internos e escrever o FQDN, na página Especificar os URLs dos Serviços Web para este Conjunto.
Para suportar o FQDN utilizado pelo balanceamento de carga DNS, tem de aprovisionar o DNS para resolve o FQDN do conjunto (por exemplo, pool01.contoso.com) para os endereços IP de todos os servidores no conjunto (por exemplo, 192.168.1.1, 192.168.1.2, etc.). Deve incluir apenas os endereços IP dos servidores atualmente implementados.
Atenção
Se tiver mais do que um conjunto de Front-End ou Servidor front-end, o FQDN de serviços Web externos tem de ser exclusivo. Por exemplo, se definir o FQDN de serviços Web externos de um Servidor front-end como pool01.contoso.com, não pode utilizar pool01.contoso.com para outro conjunto de Front-End ou Servidor front-end. Se também estiver a implementar Directores, o FQDN de serviços Web externos definido para qualquer Conjunto de Diretórios ou Diretores tem de ser exclusivo de qualquer outro Conjunto de Diretórios ou Diretórios, bem como de qualquer conjunto de Front-End ou Servidor front-end. Se optar por substituir os Serviços Web internos por um FQDN autodefinido, cada FQDN tem de ser exclusivo de qualquer outro conjunto de Front-End, Diretor ou conjunto de Diretórios.
Balanceamento de Carga DNS em Conjuntos de Servidores do Edge
Pode implementar o balanceamento de carga DNS em conjuntos do Edge Server. Se o fizer, tem de estar ciente de algumas considerações.
A utilização do balanceamento de carga DNS nos Servidores Edge causa uma perda de capacidade de ativação pós-falha nos seguintes cenários:
Federação com organizações com versões de Skype for Business Server lançadas antes do Lync Server 2010.
Troca de mensagens instantâneas com utilizadores de serviços de mensagens instantâneas públicas (MI) AOL e Yahoo!, além de fornecedores e servidores baseados em XMPP, como o Google Talk, atualmente o único parceiro XMPP suportado.
Estes cenários funcionarão desde que todos os Servidores Edge no conjunto estejam em execução, mas se um Servidor Edge estiver indisponível, todos os pedidos para estes cenários enviados para o mesmo falharão, em vez de serem encaminhados para outro Servidor Edge.
Se estiver a utilizar o Exchange UM, tem de utilizar um mínimo de Exchange 2013 para obter suporte para Skype for Business Server balanceamento de carga DNS no Edge. Se utilizar uma versão anterior do Exchange, os utilizadores remotos não terão capacidades de ativação pós-falha para estes cenários do Exchange UM:
A reproduzir o voicemail enterprise no telemóvel
Transferir chamadas de um Atendedor 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.
Implementar o Balanceamento de Carga DNS nos Conjuntos de Servidores do Edge
Para implementar o balanceamento de carga DNS na interface externa do conjunto do Edge Server, precisa das seguintes entradas DNS:
Para o serviço Access Edge, precisa de uma entrada para cada servidor no conjunto. Cada entrada tem de resolve o FQDN do serviço Access Edge (por exemplo, sip.contoso.com) para o endereço IP do serviço Access Edge num dos Servidores Edge no conjunto.
Para o serviço Web Conferencing Edge, precisa de uma entrada para cada servidor no conjunto. Cada entrada tem de resolve o FQDN do serviço Web Conferencing Edge (por exemplo, webconf.contoso.com) para o endereço IP do serviço Web Conferencing Edge num dos Servidores Edge no conjunto.
Para o serviço Audio/Video Edge, precisa de uma entrada para cada servidor no conjunto. Cada entrada tem de resolve o FQDN do serviço Audio/Video Edge (por exemplo, av.contoso.com) para o endereço IP do serviço A/V Edge num dos Servidores Edge no conjunto.
Para implementar o balanceamento de carga DNS na interface interna do conjunto do Edge Server, tem de adicionar um registo DNS A, o que resolve o FQDN interno do conjunto do Servidor Edge para o endereço IP de cada servidor no conjunto.
Utilizar o Balanceamento de Carga DNS em Conjuntos de Servidores de Mediação
Pode utilizar o balanceamento de carga DNS em conjuntos autónomos do Servidor de Mediação. Todo o tráfego de SIP e multimédia é equilibrado pelo balanceamento de carga DNS.
Para implementar o balanceamento de carga DNS num conjunto de Servidores de Mediação, tem de aprovisionar o DNS para resolve o FQDN do conjunto (por exemplo, mediationpool1.contoso.com) para os endereços IP de todos os servidores no conjunto (por exemplo, 192.168.1.1, 192.168.1.2 e assim sucessivamente).
Bloquear o Tráfego para 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.
Tenha em atenção que, para o tráfego servidor a servidor, Skype for Business Server utiliza o balanceamento de carga com suporte para topologia. Os servidores leem a topologia publicada no arquivo de Gestão 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 servidor a servidor, tem de remover o servidor da topologia.