Quelques mots sur ce que nous faisons. DINS est impliqué dans le développement et le support du service UCaaS sur le marché international pour les entreprises clientes. Le service est utilisé à la fois par les petites entreprises et les startups, ainsi que par les grandes entreprises. Les clients se connectent via Internet via le protocole SIP via TCP, TLS ou WSS. Cela crée une charge assez importante: près de 1,5 million de connexions depuis les terminaux - téléphones Polycom / Cisco / Yealink et clients logiciels pour PC / Mac / IOS / Android.
Dans cet article, je parle de la façon dont les points d'entrée VoIP sont organisés.
Contexte
Sur le périmètre du système (entre les terminaux et le noyau) se trouvent SBC (Session Border Controller) commercial.
Depuis 2012, nous utilisons des solutions d'Acme Packet, acquises plus tard par Oracle. Avant cela, nous utilisions NatPASS.
Énumérez brièvement les fonctionnalités que nous utilisons:
• Traversée NAT;
• B2BUA;
• Normalisation SIP (en-têtes autorisés / interdits, règles de manipulation d'en-tête, etc.)
• déchargement TLS et SRTP;
• Conversion de transport (à l'intérieur du système, nous utilisons SIP sur UDP);
• Surveillance MOS (via RTCP-XR);
• ACL, détection de Bruteforce;
• Réduction du trafic d'enregistrement en raison de l'expiration accrue des contacts (faible expiration côté accès, haut côté cœur);
• Limitation des messages SIP par méthode.
Les systèmes commerciaux ont leurs avantages évidents (fonctionnalité prête à l'emploi, support commercial) et leurs inconvénients (prix, délai de livraison, manque d'opportunité ou délais trop longs pour mettre en œuvre les nouvelles fonctionnalités dont nous avons besoin, délais pour résoudre les problèmes, etc.). Peu à peu, les défauts ont commencé à être dépassés et il est devenu clair que le besoin était venu de développer nos propres solutions.
Le développement a été lancé il y a un an et demi. Dans le sous-système frontalier, nous distinguions traditionnellement 2 composants principaux: les serveurs SIP et Media; équilibreurs de charge au-dessus de chaque composant. Je travaille sur les points d'entrée / équilibreurs ici, donc j'essaierai d'en parler.
Prérequis
- Tolérance aux pannes: le système doit fournir un service en cas de défaillance d'une ou plusieurs instances dans le centre de données ou l'ensemble du centre de données
- Facilité de maintenance: nous voulons pouvoir basculer les charges d'un centre de données à un autre
- Évolutivité: je veux augmenter la capacité rapidement et à peu de frais
Équilibrage
Nous avons sélectionné IPVS (alias LVS) en mode IPIP (tunnel de trafic). Je ne vais pas entrer dans une analyse comparative de NAT / DR / TUN / L3DSR, (vous pouvez lire sur les modes, par exemple, ici ), je mentionnerai seulement les raisons:
- Nous ne voulons pas imposer aux backends l'exigence d'être sur le même sous-réseau que LVS (les pools contiennent des backends à la fois de nos propres centres de données et des centres de données distants);
- Le backend doit recevoir l'IP source d'origine du client (ou son NAT), en d'autres termes, le NAT source ne convient pas;
- Le backend doit prendre en charge le travail simultané avec plusieurs VIP.
Nous équilibrons le trafic multimédia (il s'est avéré très difficile, nous allons refuser), donc le schéma de déploiement actuel dans le centre de données est le suivant:
La stratégie d'équilibrage IPVS actuelle est «sed» (le délai le plus court attendu), plus à ce sujet. Contrairement à Weighted Round Robin / Weighted Least-Connection, il vous permet de ne pas transférer le trafic vers des backends avec des poids inférieurs jusqu'à ce qu'un certain seuil soit atteint. Le délai le plus court attendu est calculé par la formule (Ci + 1) / Ui, où Ci est le nombre de connexions sur le backend i, Ui est le poids du backend. Par exemple, s'il y a des backends dans le pool avec des poids de 50 000 et 2, les nouvelles connexions seront distribuées par les premiers jusqu'à ce que chaque serveur atteigne 25 000 connexions ou jusqu'à ce que uthreshold soit atteint - une limite sur le nombre total de connexions.
En savoir plus sur les stratégies d'équilibrage dans man ipvsadm .
Le pool IPVS ressemble à ceci (ici et ci-dessous, les adresses IP fictives sont répertoriées):
# 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
La charge sur le VIP est répartie sur des serveurs avec un poids de 50 000 (ils sont déployés dans le même centre de données qu'une instance LVS spécifique), s'ils sont surchargés ou entrent dans une liste noire, la charge ira à la partie de sauvegarde du pool - serveurs avec un poids de 2, qui sont situés dans centre de données voisin.
Exactement le même pool, mais avec des balances, au contraire, est configuré dans le centre de données voisin (sur le système de production, le nombre de backends, bien sûr, est beaucoup plus important).
La synchronisation des connexions via la synchronisation ipvs permet au LVS de sauvegarde de connaître toutes les connexions actuelles.
Pour la synchronisation entre les centres de données, une technique «sale» a été appliquée, qui fonctionne néanmoins très bien. La synchronisation IPVS ne fonctionne que par multidiffusion, ce qui nous a été difficile à livrer correctement au contrôleur de domaine voisin. Au lieu de la multidiffusion, nous dupliquons le trafic de synchronisation via TEE cible iptables du maître ipvs vers le tunnel ip-ip vers le serveur dans le DC voisin, et il peut y avoir plusieurs hôtes / centres de données cibles:
#### 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
En fait, chacun de nos serveurs LVS joue les deux rôles à la fois (maître et sauvegarde), d'une part, c'est juste pratique, car il élimine le changement de rôle lors du changement de trafic, de l'autre il est nécessaire, car chaque DC traite son trafic de groupe par défaut VIP publics.
Commutation de charge entre les centres de données
En fonctionnement normal, chaque adresse IP publique est annoncée sur Internet depuis n'importe où (dans ce diagramme, à partir de deux centres de données). Le trafic entrant vers le VIP est acheminé vers le contrôleur de domaine dont nous avons besoin pour le moment en utilisant l'attribut BGP MED (Discriminateur de sortie multiple) avec différentes valeurs pour Active DC et Backup DC. Dans le même temps, Backup DC est toujours prêt à accepter du trafic si quelque chose arrive à l'actif:
En modifiant les valeurs des BGP MED et en utilisant la synchronisation IPVS inter-emplacements, nous avons la possibilité de transférer en toute transparence le trafic des backends d'un centre de données à un autre, sans affecter les appels téléphoniques établis, qui se termineront tôt ou tard naturellement. Le processus est entièrement automatisé (pour chaque VIP, nous avons un bouton dans la console de gestion), et ressemble à ceci:
SIP-VIP est actif dans DC1 (à gauche), le cluster dans DC2 (à droite) est redondant, grâce à la synchronisation ipvs, il a des informations sur les connexions établies dans sa mémoire. A gauche, les VIP actifs sont annoncés avec une valeur de MED 100, à droite - avec une valeur de 500:
Le bouton de commutation provoque une modification de la soi-disant "Target_state" (un concept interne déclarant les valeurs des BGP MED à un moment donné). Ici, nous n'espérons pas que DC1 est en ordre et prêt à traiter le trafic, donc LVS dans DC2 entre dans l'état «force active», abaissant la valeur MED à 50, et entraîne ainsi le trafic sur lui-même. Si les backends de DC1 sont actifs et disponibles, les appels ne seront pas interrompus. Toutes les nouvelles connexions TCP (enregistrements) seront envoyées aux backends dans DC2:
DC1 a reçu une nouvelle réplication target_state et a défini la valeur de sauvegarde MEDs (500). Lorsque DC2 s'en rend compte, il normalise sa valeur (50 => 100). Il reste à attendre la fin de tous les appels actifs dans DC1 et à rompre les connexions TCP établies. Les instances SBC dans DC1 introduisent les services nécessaires dans ce que l'on appelle État «arrêt progressif»: «503» répond aux prochaines demandes SIP et se déconnecte, mais n'accepte pas les nouvelles connexions. De plus, ces instances entrent dans la liste noire de LVS. Lors de la rupture, le client établit une nouvelle inscription / connexion, qui vient déjà dans DC2:
Le processus se termine lorsque tout le trafic dans DC2.
DC1 et DC2 ont changé de rôle.
Dans des conditions de charge élevée constante sur les points d'entrée, il s'est avéré très pratique de pouvoir changer de trafic à tout moment. Le même mécanisme démarre automatiquement si le DC de sauvegarde commence soudainement à recevoir du trafic. Dans le même temps, pour se protéger contre les battements, la commutation n'est déclenchée qu'une seule fois dans une direction et la serrure est réglée sur la commutation automatique, pour l'enlever, une intervention humaine est requise.
À l'intérieur
Cluster VRRP et gestionnaire IPVS: Keepalived. Keepalived est responsable du changement de VIP au sein du cluster, ainsi que du contrôle de santé / liste noire des backends.
Pile BGP: ExaBGP. Il est responsable de l'annonce des itinéraires vers les adresses VIP et de l'apposition des BGP MED correspondants. Entièrement contrôlé par le serveur de gestion. Un démon BGP fiable écrit en Python se développe activement, il effectue sa tâche à 100%.
Serveur de gestion (API / Monitoring / gestion des sous-composants): Pyro4 + Flask. Il s'agit d'un serveur de provisionnement pour Keepalived et ExaBGP, gère tous les autres paramètres système (sysctl / iptables / ipset / etc), fournit une surveillance (gnlpy), ajoute et supprime des backends à la demande (ils communiquent avec son API).
Les chiffres
Une machine virtuelle à quatre cœurs Intel Xeon Gold 6140 CPU à 2,30 GHz sert un flux de trafic de 300 Mbps / 210 Kpps (trafic multimédia, environ 3 000 appels simultanés en heure de pointe sont traités par leur intermédiaire). Utilisation du CPU en même temps - 60%.
Maintenant, cela suffit pour desservir le trafic de jusqu'à 100 000 terminaux (téléphones de bureau). Pour desservir tout le trafic (plus d'un million de terminaux), nous construisons environ 10 paires de tels clusters dans plusieurs centres de données.