Algunas palabras sobre lo que hacemos. DINS está involucrado en el desarrollo y soporte del servicio UCaaS en el mercado internacional para clientes corporativos. El servicio lo utilizan tanto pequeñas empresas como nuevas empresas, y grandes empresas. Los clientes se conectan a través de Internet a través del protocolo SIP a través de TCP, TLS o WSS. Esto crea una carga bastante grande: casi 1,5 millones de conexiones desde dispositivos finales: teléfonos Polycom / Cisco / Yealink y clientes de software para PC / Mac / IOS / Android.
En este artículo, hablo sobre cómo se organizan los puntos de entrada VoIP.
Antecedentes
En el perímetro del sistema (entre los dispositivos terminales y el núcleo) se encuentran los SBC comerciales (Controlador de borde de sesión).
Desde 2012, hemos estado utilizando soluciones de Acme Packet, que luego adquirió Oracle. Antes de eso, usamos NatPASS.
Enumere brevemente la funcionalidad que utilizamos:
• transversal NAT;
• B2BUA;
• Normalización SIP (encabezados permitidos / no permitidos, reglas de manipulación de encabezados, etc.)
• Descarga de TLS y SRTP;
• Conversión de transporte (dentro del sistema usamos SIP sobre UDP);
• Monitoreo MOS (a través de RTCP-XR);
• ACL, detección de fuerza bruta;
• Tráfico de registro reducido debido al aumento de la caducidad del contacto (bajo vencimiento en el lado de acceso, alto en el lado central);
• Aceleración de mensajes SIP por método.
Los sistemas comerciales tienen sus ventajas obvias (funcionalidad lista para usar, soporte comercial) y desventajas (precio, tiempo de entrega, falta de oportunidades o plazos demasiado largos para implementar las nuevas funciones que necesitamos, plazos para resolver problemas, etc.). Poco a poco, los defectos comenzaron a ser superados, y se hizo evidente que era necesario desarrollar nuestras propias soluciones.
El desarrollo se lanzó hace un año y medio. En el subsistema de frontera, tradicionalmente distinguimos 2 componentes principales: SIP y servidores de medios; equilibradores de carga sobre cada componente. Estoy trabajando en puntos de entrada / equilibradores aquí, así que intentaré hablar sobre ellos.
Requisitos
- Tolerancia a fallas: el sistema debe proporcionar un servicio en caso de falla de una o más instancias en el centro de datos o en todo el centro de datos
- Facilidad de servicio: queremos poder cambiar cargas de un centro de datos a otro
- Escalabilidad: quiero aumentar la capacidad de forma rápida y económica
Equilibrio
Seleccionamos IPVS (también conocido como LVS) en modo IPIP (túnel de tráfico). No entraré en un análisis comparativo de NAT / DR / TUN / L3DSR, (puede leer sobre los modos, por ejemplo, aquí ), solo mencionaré las razones:
- No queremos imponer a los backends el requisito de estar en la misma subred que LVS (los pools contienen backends de nuestros propios y remotos centros de datos);
- El servidor debe recibir la IP de origen original del cliente (o su NAT), en otras palabras, la fuente de NAT no es adecuada;
- El backend debe admitir el trabajo simultáneo con varios VIP.
Estamos equilibrando el tráfico de medios (resultó ser muy difícil, lo vamos a rechazar), por lo que el esquema de implementación actual en el centro de datos es el siguiente:
La estrategia actual de equilibrio de IPVS es "sed" (retraso más corto esperado), más sobre eso. A diferencia de Weighted Round Robin / Weighted Least-Connection, le permite no transferir tráfico a backends con pesos más bajos hasta que se alcanza un cierto umbral. El retraso esperado más corto se calcula utilizando la fórmula (Ci + 1) / Ui, donde Ci es el número de conexiones en el backend i, Ui es el peso del backend. Por ejemplo, si hay backends en el grupo con pesos de 50,000 y 2, las conexiones nuevas serán distribuidas por los primeros hasta que cada servidor alcance las 25,000 conexiones o hasta que se alcance el umbral, un límite en el número total de conexiones.
Lea más sobre estrategias de equilibrio en man ipvsadm .
El conjunto de IPVS tiene este aspecto (aquí y a continuación, se enumeran las direcciones IP ficticias):
# 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 carga en el VIP se distribuye a servidores con un peso de 50,000 (se implementan en el mismo centro de datos que una instancia específica de LVS), si se sobrecargan o entran en una lista negra, la carga irá a la parte de respaldo del grupo: servidores con un peso de 2, que se encuentran en centro de datos vecino.
Exactamente el mismo grupo, pero con escalas, por el contrario, está configurado en el centro de datos vecino (en el sistema de producción, el número de backends, por supuesto, es mucho mayor).
La sincronización de conexiones a través de la sincronización de ipvs permite que el LVS de respaldo conozca todas las conexiones actuales.
Para la sincronización entre centros de datos, se aplicó una técnica "sucia", que sin embargo funciona bien. La sincronización IPVS funciona solo a través de multidifusión, lo que nos resultó difícil entregar correctamente a la DC vecina. En lugar de multidifusión, duplicamos el tráfico de sincronización a través del TEE objetivo de iptables desde el maestro ipvs al túnel ip-ip al servidor en el DC vecino, y puede haber varios hosts / centros de datos objetivo:
#### 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 hecho, cada uno de nuestros servidores LVS desempeña ambos roles a la vez (maestro y respaldo), por un lado, es conveniente, ya que elimina el cambio de rol al cambiar el tráfico, por el otro es necesario, ya que cada DC procesa su tráfico grupal de manera predeterminada VIP públicos.
Cambio de carga entre centros de datos
En funcionamiento normal, cada dirección IP pública se anuncia en Internet desde cualquier lugar (en este diagrama, desde dos centros de datos). El tráfico entrante al VIP se enruta al DC que necesitamos en este momento utilizando el atributo BGP MED (Discriminador de salida múltiple) con diferentes valores para DC activo y DC de respaldo. Al mismo tiempo, Backup DC siempre está listo para aceptar tráfico si algo le sucede al activo:
Al cambiar los valores de los BGP MED y usar la sincronización IPVS entre ubicaciones, tenemos la oportunidad de transferir sin problemas el tráfico de los servidores de un centro de datos a otro, sin afectar las llamadas telefónicas establecidas, que tarde o temprano terminarán naturalmente. El proceso está completamente automatizado (para cada VIP tenemos un botón en la consola de administración), y se ve así:
SIP-VIP está activo en DC1 (izquierda), el clúster en DC2 (derecha) es redundante, gracias a la sincronización ipvs, tiene información sobre las conexiones establecidas en su memoria. A la izquierda, los VIP activos se anuncian con un valor de MED 100, a la derecha, con un valor de 500:
El botón de cambio provoca un cambio en el llamado "Target_state" (un concepto interno que declara los valores de BGP MED en un momento dado). Aquí no esperamos que DC1 esté en orden y listo para procesar el tráfico, por lo tanto, LVS en DC2 entra en el estado de "fuerza activa", lo que reduce el valor de MED a 50 y arrastra el tráfico sobre sí mismo. Si los backends en DC1 están activos y disponibles, las llamadas no se interrumpirán. Todas las nuevas conexiones TCP (registros) se enviarán a backends en DC2:
DC1 recibió una nueva replicación target_state y estableció el valor de respaldo MEDs (500). Cuando DC2 se entera de esto, normaliza su valor (50 => 100). Queda por esperar la finalización de todas las llamadas activas en DC1 y romper las conexiones tcp establecidas. Las instancias de SBC en DC1 introducen los servicios necesarios en el llamado Estado de "apagado correcto": "503" responde a las siguientes solicitudes SIP y se desconecta, pero no acepta nuevas conexiones. Además, estas instancias entran en la lista negra en LVS. Cuando se rompe, el cliente establece un nuevo registro / conexión, que ya viene en DC2:
El proceso finaliza cuando todo el tráfico en DC2.
DC1 y DC2 cambiaron roles.
En condiciones de alta carga constante en los puntos de entrada, resultó ser muy conveniente poder cambiar el tráfico en cualquier momento. El mismo mecanismo se inicia automáticamente si la copia de seguridad DC de repente comienza a recibir tráfico. Al mismo tiempo, para proteger contra el aleteo, la conmutación se activa solo una vez en una dirección y el bloqueo se establece en conmutación automática, para eliminarlo, se requiere intervención humana.
Que hay dentro
Clúster VRRP y administrador de IPVS: Keepalived. Keepalived es responsable de cambiar los VIP dentro del clúster, así como también de la revisión / lista negra del estado del backends.
Pila BGP: ExaBGP. Es responsable de los anuncios de rutas a direcciones VIP y de la colocación de los correspondientes BGP MED. Totalmente controlado por el servidor de gestión. Un demonio BGP confiable escrito en Python se está desarrollando activamente; realiza su tarea al 100%.
Servidor de gestión (API / Monitoreo / gestión de subcomponentes): Pyro4 + Flask. Es un servidor de aprovisionamiento para Keepalived y ExaBGP, administra todas las demás configuraciones del sistema (sysctl / iptables / ipset / etc), proporciona monitoreo (gnlpy), agrega y elimina backends a pedido (se comunican con su API).
Figuras
Una máquina virtual con cuatro núcleos Intel Xeon Gold 6140 CPU @ 2.30GHz sirve un flujo de tráfico de 300Mbps / 210Kpps (a través de ellos se procesan aproximadamente 3 mil llamadas simultáneas en hora pico). Utilización de la CPU al mismo tiempo: 60%.
Ahora esto es suficiente para atender el tráfico de hasta 100 mil dispositivos terminales (teléfonos de escritorio). Para atender todo el tráfico (más de 1 millón de dispositivos terminales), estamos construyendo alrededor de 10 pares de dichos grupos en varios centros de datos.