As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Padrão de IP flutuante para HA entre servidores ativos e em espera
O padrão de design de IP flutuante é um mecanismo bem conhecido para obter failover automático entre um par de nós de hardware ativos e em espera (servidores de mídia). Um endereço IP virtual secundário estático é atribuído ao nó ativo. O monitoramento contínuo entre os nós ativo e em espera detecta falhas. Se o nó ativo falhar, o script de monitoramento atribuirá o IP virtual ao nó em espera pronto e o nó em espera assumirá a função ativa primária. Dessa forma, o IP virtual flutua entre o nó ativo e o em espera.
Aplicabilidade em soluções RTC
Nem sempre é possível ter várias instâncias ativas do mesmo componente em serviço, como um cluster ativo-ativo de N nós. Uma configuração ativa em espera fornece o melhor mecanismo para HA. Por exemplo, os componentes com estado em uma solução RTC, como o servidor de mídia ou de conferência, ou até mesmo um servidor SBC ou de banco de dados, são adequados para uma configuração ativa e em espera. Um servidor SBC ou de mídia tem várias sessões ou canais de longa execução ativos em um determinado momento e, no caso de falha da instância ativa do SBC, os endpoints podem se reconectar ao nó em espera sem nenhuma configuração do lado do cliente devido ao IP flutuante.
Implementação em AWS
Você pode implementar esse padrão na AWS usando os principais recursos da Amazon Elastic Compute Cloud (Amazon EC2), Amazon EC2 API, endereços IP elásticos e suporte na Amazon EC2 para endereços IP privados secundários.
Para implementar o padrão de IP flutuante em AWS:
-
Inicie duas EC2 instâncias para assumir as funções dos nós primário e secundário, em que se presume que o primário esteja no estado ativo por padrão.
-
Atribua um endereço IP privado secundário adicional à EC2 instância primária.
-
Um endereço IP elástico, que é semelhante a um IP virtual (VIP), está associado ao endereço privado secundário. Esse endereço privado secundário é o endereço usado pelos endpoints externos para acessar o aplicativo.
-
Algumas configurações do sistema operacional (SO) são necessárias para que o endereço IP secundário seja adicionado como um alias à interface de rede primária.
-
O aplicativo deve se vincular a esse endereço IP elástico. No caso do software Asterisk, você pode configurar a vinculação por meio de configurações avançadas do Asterisk SIP.
-
Execute um script de monitoramento — personalizado, KeepAlive em Linux, Corosync e assim por diante — em cada nó para monitorar o estado do nó de mesmo nível. Caso o nó ativo atual falhe, o par detecta essa falha e invoca a API da EC2 Amazon para reatribuir o endereço IP privado secundário a si mesmo.
Portanto, o aplicativo que estava escutando o VIP associado ao endereço IP privado secundário fica disponível para os endpoints por meio do nó em espera.
Failover entre EC2 instâncias com estado usando um endereço IP elástico
Benefícios
Essa abordagem é uma solução confiável de baixo orçamento que protege contra falhas no nível da EC2 instância, da infraestrutura ou do aplicativo.
Limitações e extensibilidade
Esse padrão de design geralmente é limitado a uma única zona de disponibilidade. Ele pode ser implementado em duas zonas de disponibilidade, mas com uma variação. Nesse caso, o endereço IP elástico flutuante é reassociado entre o nó ativo e o nó em espera em diferentes zonas de disponibilidade por meio da API de reassociação de endereços IP elásticos disponível. Na implementação de failover mostrada na figura anterior, as chamadas em andamento são descartadas e os endpoints devem se reconectar. É possível estender essa implementação com a replicação dos dados subjacentes da sessão para fornecer um failover contínuo das sessões ou também a continuidade da mídia.
Balanceamento de carga para escalabilidade e HA com WebRTC e SIP
O balanceamento de carga de um cluster de instâncias ativas com base em regras predefinidas, como round robin, afinidade ou latência, etc., é um padrão de design amplamente popularizado pela natureza sem estado das solicitações HTTP. Na verdade, o balanceamento de carga é uma opção viável no caso de muitos componentes do aplicativo RTC.
O balanceador de carga atua como proxy reverso ou ponto de entrada para solicitações ao aplicativo desejado, que por sua vez está configurado para ser executado em vários nós ativos simultaneamente. Em qualquer momento, o balanceador de carga direciona uma solicitação do usuário para um dos nós ativos no cluster definido. Os balanceadores de carga realizam uma verificação de integridade nos nós em seu cluster de destino e não enviam uma solicitação de entrada para um nó que falhe na verificação de integridade. Portanto, um grau fundamental de alta disponibilidade é alcançado pelo balanceamento de carga. Além disso, como um balanceador de carga realiza verificações de integridade ativas e passivas em todos os nós do cluster em intervalos de menos de um segundo, o tempo de failover é quase instantâneo.
A decisão sobre qual nó direcionar é baseada nas regras do sistema definidas no balanceador de carga, incluindo:
-
Ida e volta
-
Afinidade de sessão ou IP, que garante que várias solicitações em uma sessão ou do mesmo IP sejam enviadas para o mesmo nó no cluster
-
Baseado em latência
-
Baseado na carga
Aplicabilidade em arquiteturas RTC
O protocolo WebRTC possibilita que os WebRTC Gateways sejam facilmente balanceados por meio de um balanceador de carga baseado em HTTP, como Elastic Load Balancing (ELB), Application Load Balancer (ALB) ou Network Load Balancer (NLB)
Balanceamento de carga ativado AWS para WebRTC usando Application Load Balancer e Auto Scaling
No caso de comunicações baseadas em WebRTC, o Elastic Load Balancing fornece um balanceador de carga totalmente gerenciado, altamente disponível e escalável para servir como ponto de entrada para solicitações, que são então direcionadas para um cluster de instâncias de destino associado ao Elastic Load Balancing. EC2 Como as solicitações do WebRTC não têm estado, você pode usar o Amazon EC2 Auto Scaling para fornecer escalabilidade, elasticidade e alta disponibilidade totalmente automatizadas e controláveis.
O Application Load Balancer fornece um serviço de balanceamento de carga totalmente gerenciado, altamente disponível usando várias zonas de disponibilidade e escalável. Isso suporta o balanceamento de carga de WebSocket solicitações que manipulam a sinalização para aplicativos WebRTC e a comunicação bidirecional entre o cliente e o servidor usando uma conexão TCP de longa duração. O Application Load Balancer também suporta roteamento baseado em conteúdo e sessões fixas, roteando solicitações do mesmo cliente para o mesmo destino usando cookies gerados pelo balanceador de carga. Se você ativar sessões fixas, o mesmo destino receberá a solicitação e poderá usar o cookie para recuperar o contexto da sessão.
A figura a seguir mostra a topologia de destino.
Escalabilidade e arquitetura de alta disponibilidade do WebRTC
Implementação para SIP usando o Network Load Balancer ou um produto AWS Marketplace
No caso de comunicações baseadas em SIP, as conexões são feitas por TCP ou UDP, com a maioria dos aplicativos RTC usando UDP. Se o SIP/TCP for o protocolo de sinal preferido, é possível usar o Network Load Balancer para balanceamento de carga totalmente gerenciado, altamente disponível, escalável e de desempenho.
Um Network Load Balancer opera no nível da conexão (camada quatro), roteando conexões para destinos como EC2 instâncias, contêineres e endereços IP da Amazon com base nos dados do protocolo IP. Ideal para balanceamento de carga de tráfego TCP ou UDP, o balanceamento de carga de rede é capaz de lidar com milhões de solicitações por segundo, mantendo latências ultrabaixas. Ele é integrado a outros serviços populares da AWS, como Amazon EC2 Auto Scaling, Amazon Elastic Container Service
Se as conexões SIP forem iniciadas, outra opção é usar off-the-shelf software AWS Marketplace
Escalabilidade de RTC baseada em SIP com o produto AWS Marketplace
