Suporte de gateway múltiplo
Tópico modificado em: 2012-01-25
Uma novidade para o Servidor de Mediação no Lync Server 2010 é a habilidade de um único Servidor de Mediação de controlar vários gateways. Nas versões anteriores, havia uma proporção de 1:1 de Servidor de Mediação para gateways. Um determinado gateway pode ser atribuído a múltiplas rotas de chamada e associado a um Servidor de Mediação ou a um pool de Servidor de Mediação. Múltiplos gateways podem ser associados a um único Servidor de Mediação ou a um pool de Servidor de Mediação. Nesta versão, o número de gateways com os quais um determinado Servidor de Mediação pode lidar depende da capacidade de processamento do servidor durante os horários de pico. Se você implantar um Servidor de Mediação no hardware que excede os requisitos mínimos de hardware para Lync Server 2010, conforme descrito em “Hardware suportado” na documentação Suporte, a estimativa de quantas chamadas ativas um Servidor de Mediação autônomo pode lidar é de aproximadamente 1000 chamadas. Quando implantado em um hardware que atende a essas especificações, espera-se que o Servidor de Mediação execute a transcodificação, mas ainda roteie chamadas para vários gateways, mesmo se os gateways não suportarem o bypass de mídia.
Ao definir uma rota de chamada, você especifica os gateways associados à essa rota, mas não especifica quais Servidor de Mediação estão associados a essa rota. Em vez disso, você usa o Construtor de Topologias para associar gateways e, portanto, rotas, ao Servidor de Mediação. Em outras palavras, o roteamento determina qual gateway usar para uma chamada e o Servidor de Mediação associado a esse gateway lida com a chamada.
Outra novidade para o Lync Server 2010 é a capacidade de um Servidor de Mediação de ser implantado como um pool; esse pool pode ser colocado com um Pool de Front-Ends ou pode ser implantado como um pool autônomo. Quando um Servidor de Mediação é colocado com um Pool de Front-Ends, o tamanho do pool pode ser no máximo 10 (o limite do tamanho do pool do registrador). Reunidos, esses novos recursos aumentam a confiabilidade e a flexibilidade de implantação para o Servidor de Mediação, mas exigem recursos associados nas seguintes entidades pares:
Gateway PSTN. Um gateway qualificado do Lync Server 2010 precisa implementar o balanceamento de carga DNS, que permite a um gateway PSTN qualificado agir como um balanceador de carga para um pool de Servidor de Mediação e, dessa forma, balancear a carga de chamadas no pool.
Session Border Controller. Para um tronco SIP, a entidade par é um SBC (Session Border Controller) em um provedor de serviço de telefonia da Internet. Na direção do pool do Servidor de Mediação para o SBC, o SBC pode receber conexões de qualquer Servidor de Mediação no pool. Na direção do SBC para o pool, o tráfego pode ser enviado a qualquer Servidor de Mediação no pool. Um método para conseguir isso é por meio do balanceamento de carga DNS, se for suportado pelo provedor de serviço e pelo SBC. Uma alternativa é fornecer ao provedor de serviço os endereços IP de todos os Servidor de Mediação no pool, e o provedor de serviço fornecerá isso em seu SBC como um tronco SIP separado para cada Servidor de Mediação. Em seguida, o provedor de serviço lidará com o balanceamento de carga para seus próprios servidores. Nem todos os provedores de serviço ou SBCs podem suportar esses recursos. Além disso, o provedor de serviço pode cobrar mais por esse recurso. Normalmente, cada tronco SIP para o SBC incorre uma taxa mensal.
Como alternativa, o provedor de serviço pode configurar um único tronco SIP para seu site e você pode implantar um balanceador de carga de hardware entre o SBC e o Pool do servidor de mediação (ou o Servidor de Mediação colocado no Pool de Front-Ends). Com essa configuração, se você adicionar um novo Servidor de Mediação, a configuração do provedor de serviço não precisará mudar. A redundância de SBC pode ser alcançada se o IP do SBC for um IP virtual (VIP) que pode terminar em SBCs físicos diferentes. Nesse caso, se um SBC ficar indisponível, haverá um mecanismo de recuperação.
IP-PBX. Na direção do Pool do servidor de mediação para a terminação SIP IP-PBX, o IP-PBX pode receber conexões de qualquer Servidor de Mediação no pool. Na direção do IP-PBX para o pool, o tráfego pode ser enviado a qualquer Servidor de Mediação no pool. Como a maioria dos IP-PBXs não suporta balanceamento de carga DNS, recomendamos que as conexões SIP diretas individuais sejam definidas a partir do IP-PBX para cada Servidor de Mediação no pool. Em seguida, o IP-PBX lidará com seu próprio balanceamento de carga por meio da distribuição do tráfego sobre o grupo de troncos. A suposição é que o grupo de troncos tenha um conjunto consistente de regras de roteamento no IP-PBX. É necessário determinar se um IP-PBX específico suporta esse conceito de grupo de troncos e como ele interage com a arquitetura de redundância/clustering do próprio IP-PBX antes de você poder decidir se um cluster do Servidor de Mediação pode interagir corretamente com um IP-PBX.
Um Pool do servidor de mediação precisa ter uma visualização uniforme do gateway par com o qual ele interage. Isso significa que todos os membros do pool acessam a mesma definição do gateway par a partir do repositório de configurações e têm a mesma probabilidade de interagir com ele para chamadas de saída. Dessa forma, não é possível segmentar o pool de modo que alguns Servidor de Mediação se comuniquem com apenas alguns gateway pares para chamadas de saída. Se essa segmentação for necessária, um pool separado de Servidor de Mediação deverá ser usado. Isso seria o caso, por exemplo, se os recursos associados nos gateways PSTN, troncos SIP ou IP-PBXs para interação com um pool, conforme detalhado anteriormente neste tópico, não estivessem presentes.
Uma implantação do Lync Server 2010 assume que um gateway PSTN específico, IP-PBX ou tronco SIP par depende somente de um único Pool do servidor de mediação; as chamadas são roteadas para esse pool pelo Lync Server 2010Pool de Front-Ends de modo que eles possam acessar esse gateway par.
Para troncos SIP, IP-PBXs e gateways PSTN onde um pool separado de Servidor de Mediação precisa ser usado, o esquema a seguir pode ser usado para conseguir a redundância:
Para resolver múltiplos Servidor de Mediação interagindo com a mesma entidade par do gateway, é necessário configurar diversos gateways virtuais. Cada gateway seria associado a um FQDN diferente, que o DNS resolveria para o mesmo endereço IP.
Servidor de Mediação autônomo individual (por exemplo, um pool de um Servidor de Mediação) seria usado e um tronco seria definido a partir de um Servidor de Mediação para um gateway virtual; cada Servidor de Mediação redundante seria responsável por uma conexão de tronco com um gateway virtual diferente.
Para que esse esquema funcione para gateway pares que suportam TLS, o FQDN de cada gateway virtual precisa estar na parte do nome de entidade ou do nome de entidade alternativo do certificado fornecido pelo gateway par.
A política aplicada para interação com gateway par será a política associada ao primeiro objeto de gateway no repositório de configurações que mostre uma correspondência. Isso não deve ser um problema, pois a mesma política deve ser associada a todos os gateways virtuais. (Todos os gateways virtuais correspondem ao mesmo hardware físico.)
As rotas do Lync Server 2010 usarão gateways virtuais diferentes. Cada gateway virtual dependerá de um Servidor de Mediação diferente.
O número de gateways que um pool específico do Servidor de Mediação pode controlar depende do número de chamadas que usam bypass de mídia. Se uma grande quantidade de chamadas usar bypass de mídia, um Servidor de Mediação no pool poderá lidar com mais chamadas, pois apenas o processamento da camada de sinalização é necessário.