Algumas palavras sobre o que fazemos. A DINS está envolvida no desenvolvimento e suporte do serviço UCaaS no mercado internacional para clientes corporativos. O serviço é usado por pequenas empresas e startups e grandes empresas. Os clientes se conectam pela Internet via protocolo SIP por TCP, TLS ou WSS. Isso cria uma carga bastante grande: quase 1,5 milhão de conexões de dispositivos finais - telefones Polycom / Cisco / Yealink e clientes de software para PC / Mac / IOS / Android.
Neste artigo, falo sobre como os pontos de entrada de VoIP são organizados.
Antecedentes
No perímetro do sistema (entre os dispositivos terminais e o kernel), há SBC comercial (Session Border Controller).
Desde 2012, usamos soluções da Acme Packet, posteriormente adquiridas pela Oracle. Antes disso, usamos o NatPASS.
Liste brevemente a funcionalidade que usamos:
• passagem NAT;
• B2BUA;
Normalização do SIP (cabeçalhos permitidos / não permitidos, regras de manipulação de cabeçalhos, etc.)
• Descarregamento de TLS e SRTP;
• Conversão de transporte (dentro do sistema usamos SIP sobre UDP);
• monitoramento MOS (via RTCP-XR);
• ACLs, detecção de Bruteforce;
• Tráfego de registro reduzido devido ao aumento da expiração de contatos (baixa expira no lado do acesso, alta no lado do núcleo);
• Controle de mensagens SIP por método.
Os sistemas comerciais têm suas vantagens óbvias (funcionalidade pronta para uso, suporte comercial) e desvantagens (preço, prazo de entrega, falta de oportunidade ou prazos muito longos para a implementação de novos recursos que precisamos, prazos para solução de problemas etc.). Gradualmente, as falhas começaram a ser superadas, e ficou claro que era necessária a necessidade de desenvolver nossas próprias soluções.
O desenvolvimento foi lançado há um ano e meio. No subsistema de fronteira, tradicionalmente distinguíamos dois componentes principais: servidores SIP e Mídia; balanceadores de carga acima de cada componente. Estou trabalhando nos pontos de entrada / balanceadores aqui, então vou tentar falar sobre eles.
Exigências
- Tolerância a falhas: o sistema deve fornecer um serviço em caso de falha de uma ou mais instâncias no data center ou em todo o data center
- Facilidade de manutenção: queremos poder alternar cargas de um data center para outro
- Escalabilidade: quero aumentar a capacidade de forma rápida e barata
Balanceamento
Selecionamos o IPVS (aka LVS) no modo IPIP (tunelamento de tráfego). Não entrarei em uma análise comparativa de NAT / DR / TUN / L3DSR (você pode ler sobre os modos, por exemplo, aqui ), mencionarei apenas os motivos:
- Não queremos impor um requisito para que os back-ends estejam na mesma sub-rede do LVS (os pools contêm back-ends de nossos próprios datacenters e remotos);
- O back-end deve receber o IP de origem original do cliente (ou seu NAT), ou seja, o NAT de origem não é adequado;
- O back-end deve oferecer suporte ao trabalho simultâneo com vários VIPs.
Como estamos balanceando o tráfego de mídia (acabou sendo muito difícil, vamos recusar), o esquema de implantação atual no data center é o seguinte:
A atual estratégia de balanceamento IPVS é "sed" (atraso mais curto esperado), mais sobre isso. Diferentemente do Robin Redondo Ponderado / Menor Conexão Ponderada, ele permite que você não transfira tráfego para back-end com pesos mais baixos até que um determinado limite seja atingido. O menor atraso esperado é calculado usando a fórmula (Ci + 1) / Ui, em que Ci é o número de conexões no back-end i, Ui é o peso do back-end. Por exemplo, se houver back-end no pool com pesos de 50.000 e 2, novas conexões serão distribuídas pelos primeiros até que cada servidor atinja 25.000 conexões ou até que o limite seja alcançado - um limite para o número total de conexões.
Leia mais sobre estratégias de balanceamento no man ipvsadm .
O pool de IPVS tem esta aparência (aqui e abaixo, os endereços IP fictícios estão listados):
# ipvsadm -ln Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 1.1.1.1:5060 sed -> 10.11.100.181:5060 Tunnel 50000 5903 4 -> 10.11.100.192:5060 Tunnel 50000 5905 1 -> 10.12.100.137:5060 Tunnel 2 0 0 -> 10.12.100.144:5060 Tunnel 2 0 0
A carga no VIP é distribuída para servidores com um peso de 50.000 (eles são implantados no mesmo datacenter que uma instância específica do LVS). Se eles estiverem sobrecarregados ou entrarem em uma lista negra, a carga irá para a parte de backup do pool - servidores com um peso de 2, localizados em data center vizinho.
O mesmo pool exato, mas com escalas, pelo contrário, é configurado no data center vizinho (no sistema de produção, é claro que o número de back-end é muito maior).
A sincronização de conexões via ipvs sync permite que o LVS de backup conheça todas as conexões atuais.
Para sincronização entre data centers, foi aplicada uma técnica "suja", que, no entanto, funciona bem. A sincronização IPVS funciona apenas por multicast, o que foi difícil para nós entregar corretamente ao controlador de domínio vizinho. Em vez do multicast, duplicamos o tráfego de sincronização via IPTables target TEE do ipvs master para o ip-ip tunnel para o servidor no DC vizinho e pode haver vários hosts / data centers de destino:
#### start ipvs sync master role: ipvsadm --start-daemon master --syncid 10 --sync-maxlen 1460 --mcast-interface sync01 --mcast-group 224.0.0.81 --mcast-port 8848 --mcast-ttl 1 #### duplicate all sync packets to remote LVS servers using iptables TEE target: iptables -t mangle -A POSTROUTING -d 224.0.0.81/32 -o sync01 -j TEE --gateway 172.20.21.10 # ip-ip remote lvs server 1 iptables -t mangle -A POSTROUTING -d 224.0.0.81/32 -o sync01 -j TEE --gateway 172.20.21.14 # ip-ip remote lvs server 2 #### start ipvs sync backup role: ipvsadm --start-daemon backup --syncid 10 --sync-maxlen 1460 --mcast-interface sync01 --mcast-group 224.0.0.81 --mcast-port 8848 --mcast-ttl 1 #### be ready to receive sync sync packets from remote LVS servers: iptables -t mangle -A PREROUTING -d 224.0.0.81/32 -i loc02_srv01 -j TEE --gateway 127.0.0.1 iptables -t mangle -A PREROUTING -d 224.0.0.81/32 -i loc02_srv02 -j TEE --gateway 127.0.0.1
De fato, cada um de nossos servidores LVS desempenha as duas funções ao mesmo tempo (mestre e backup), por um lado, é apenas conveniente, pois elimina a alteração de função ao alternar tráfego, por outro é necessário, pois cada controlador de domínio processa o tráfego do grupo por padrão. VIPs públicos.
Troca de carga entre data centers
Em operação normal, cada endereço IP público é anunciado na Internet de qualquer lugar (neste diagrama, de dois data centers). O tráfego que chega ao VIP é roteado para o DC necessário no momento, usando o atributo BGP MED (Discriminador de múltiplas saídas) com valores diferentes para DC ativo e DC de backup. Ao mesmo tempo, o Backup DC está sempre pronto para aceitar o tráfego se algo acontecer com o ativo:
Alterando os valores dos BGP MEDs e usando o IPVS-sync entre locais, temos a oportunidade de transferir tráfego sem problemas dos back-ends de um data center para outro, sem afetar as chamadas telefônicas estabelecidas, que mais cedo ou mais tarde terminarão naturalmente. O processo é totalmente automatizado (para cada VIP, temos um botão no console de gerenciamento) e fica assim:
O SIP-VIP está ativo no DC1 (à esquerda), o cluster no DC2 (à direita) é redundante. Graças à sincronização de ipvs, ele possui informações sobre conexões estabelecidas em sua memória. À esquerda, os VIPs ativos são anunciados com um valor de MED 100, à direita - com um valor de 500:
O botão do interruptor causa uma mudança no chamado “Target_state” (um conceito interno que declara os valores dos BGP MEDs em um determinado momento). Aqui, não esperamos que o DC1 esteja em ordem e pronto para processar o tráfego; portanto, o LVS no DC2 entra no estado de "força ativa", diminuindo o valor de MEDs para 50 e arrastando o tráfego para si mesmo. Se os back-end no DC1 estiverem ativos e disponíveis, as chamadas não serão interrompidas. Todas as novas conexões TCP (registros) serão enviadas para back-end no DC2:
O DC1 recebeu uma nova replicação target_state e defina o valor de backup MEDs (500). Quando o DC2 descobre isso, ele normaliza seu valor (50 => 100). Resta aguardar a conclusão de todas as chamadas ativas no DC1 e interromper as conexões TCP estabelecidas. As instâncias SBC no DC1 introduzem os serviços necessários no chamado Estado de “desligamento normal”: “503” responde às próximas solicitações SIP e desconecta, mas não aceita novas conexões. Além disso, essas instâncias entram na lista negra do LVS. Ao interromper, o cliente estabelece um novo registro / conexão, que já vem no DC2:
O processo termina quando todo o tráfego no DC2.
Funções comutadas DC1 e DC2.
Em condições de carga alta constante nos pontos de entrada, tornou-se muito conveniente poder trocar de tráfego a qualquer momento. O mesmo mecanismo inicia automaticamente se o controlador de domínio de backup repentinamente começar a receber tráfego. Ao mesmo tempo, para proteger contra batidas, a comutação é acionada apenas uma vez em uma direção e a trava é ajustada para comutação automática.
O que há dentro
Cluster VRRP e gerenciador IPVS: Keepalived. O Keepalived é responsável pela troca de VIPs dentro do cluster, bem como pela verificação de integridade / lista negra de back-end.
Pilha BGP: ExaBGP. Ele é responsável por anúncios de rotas para endereços VIP e aposição dos BGP MEDs correspondentes. Totalmente controlado pelo servidor de gerenciamento. Um daemon BGP confiável, escrito em Python, está se desenvolvendo ativamente; ele executa sua tarefa 100%.
Servidor de gerenciamento (API / Monitoramento / gerenciamento de subcomponentes): Pyro4 + Flask. É um servidor de provisionamento para Keepalived e ExaBGP, gerencia todas as outras configurações do sistema (sysctl / iptables / ipset / etc), fornece monitoramento (gnlpy), adiciona e remove back-ends a pedido (eles se comunicam com sua API).
Figuras
Uma máquina virtual com CPU Intel Xeon Gold 6140 de quatro núcleos a 2,30 GHz atende a um fluxo de tráfego de 300 Mbps / 210 Kpps (tráfego de mídia, são processados por meio de tráfego de mídia, cerca de 3 mil chamadas simultâneas no horário de pico). Utilização da CPU ao mesmo tempo - 60%.
Agora, isso é suficiente para atender o tráfego de até 100 mil dispositivos terminais (telefones de mesa). Para atender todo o tráfego (mais de 1 milhão de dispositivos de terminal), estamos construindo cerca de 10 pares desses clusters em vários data centers.