Recuperação de desastres do servidor de borda no Lync Server 2013

 

Tópico última modificação: 12/03/2014

Assim como ocorre com outras funções de servidor, a melhor maneira de fornecer alta disponibilidade para seus Servidores de Borda é implantar vários servidores de borda em pools em cada site. Se um Servidor de Borda ficar inativo, os outros servidores no pool continuarão a fornecer serviços do Edge.

Para habilitar procedimentos de recuperação de desastre, você deve ter pools de Servidor de Borda separados implantados em sites separados. Você não precisa emparelhar explicitamente pools de borda como faz com pools de Front-End, mas ter vários pools de Borda ainda fornece a disponibilidade para continuar se um pool inteiro do Edge ficar inativo. As seções a seguir fornecem detalhes sobre a recuperação de desastre para as várias funções dos Servidores de Borda.

Acesso Remoto

Se você tiver vários sites, cada um com um pool de servidores de Borda e um pool inteiro do Edge falhar, os serviços de acesso remoto continuarão a funcionar sem a necessidade de ação de administrador. Ao criar pools de Borda em sites diferentes, você não pode usar o mesmo FQDN. Cada pool de borda deve ter FQDNs exclusivos (internos e externos). Os pools de Borda não usam regras de publicação de proxy reverso para se comunicar com os servidores Front-End. O failover automático ocorre quando o cliente consulta novamente os registros de serviço DNS de acesso remoto e os usuários remotos são roteados para os servidores de Borda em outro site. O cliente tenta cada FQDN de Borda externo de acordo com a prioridade dos registros SRV dns.

Nota

Para que o failover funcione sem problemas, verifique se o firewall permite que os servidores Front-End de cada pool se comuniquem com todos os servidores de Borda.

Federação

Para relações de federação com outras organizações que executam o Lync Server, as solicitações de federação de entrada continuarão a funcionar, desde que você tenha soluções como o GEO-DNS GTM. É importante entender que o failover de federação não fornece failover com prioridade nos registros SRV. Uma solução fornecida anteriormente pode ajudá-lo a fornecer recursos de recuperação de desastre para federação de entrada.

A federação de saída é sempre configurada por meio de um pool de Borda publicado ou do Servidor de Borda na organização. Se esse pool de Borda tiver sido inativo, você deverá usar o Construtor de Topologias para alterar a rota de federação de saída para usar um pool de Borda que ainda está em execução. Para obter detalhes, consulte Failover do pool de borda usado para federação do Lync Server no Lync Server 2013

Federação XMPP

Para a federação XMPP, o tráfego de saída e de entrada falhará se o pool de borda designado como o gateway de federação XMPP ficar inativo. Para fazer com que a federação XMPP funcione novamente, você deve alterar a federação XMPP para usar um pool de Borda diferente. Para obter detalhes, consulte Failover do pool de borda usado para federação XMPP no Lync Server 2013.

O pool de borda falha, mas o pool de front-end ainda está em execução

Se um pool de Borda falhar em um site, mas o pool de Front-Ends nesse site ainda estiver em execução, você precisará alterar o pool de Front-Ends para usar um pool de Borda diferente em um site diferente enquanto o primeiro pool de Borda estiver inativo. Para obter mais informações, consulte Alterando o pool de borda associado a um pool de Front-Ends no Lync Server 2013.