Desbalance del balanceador de carga y health checks erróneos LB imbalance, bad health checks
ID de la causa dc-lb-imbalance · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Las conexiones se concentran en un solo servidor, o se sigue enviando gente a un servidor que ya está caído.
Por qué La regla de reparto no encaja o el health check no ve el estado real → Efecto Un solo servidor sobrecargado, o intentos de conexión a un servidor caído → En pantalla Cámara lenta, o el juego no conecta o se queda en carga infinita, solo en algunos canales o para algunos jugadores
Al conectar o tras un mantenimiento, Cuando se junta mucha gente
Responsable
Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Implementar un health check que responda a las comprobaciones del balanceador de carga según el estado real del juego (avance del tick, conexiones a la BD), informar también de la carga del servidor.
Tareas (Equipo de infraestructura)
Cambiar a health checks que verifiquen respuestas reales del juego, repartir según la carga de los servidores, monitorear las diferencias en el número de conexiones entre servidores.
En el gráfico
Alto solo en algunos · Conexiones/utilización de CPU por servidor
Dónde mirar
Superponer en un gráfico el número de conexiones (ss -s) y la utilización de CPU de cada servidor detrás del balanceador de carga, y comparar el estado de salud de los destinos en el balanceador (en AWS, HealthyHostCount y UnHealthyHostCount de CloudWatch) con el estado real de los servidores del juego
Se confirma si
Solo uno o dos servidores tienen muchas más conexiones y CPU que los demás, o un servidor con el tick detenido sigue marcado “en buen estado” y recibiendo conexiones nuevas
Se descarta si
Si el número de conexiones es parejo entre servidores y solo va lento un canal, apunta a la carga dentro de ese canal (“Sobrecarga de una zona de un solo hilo (hotspot)”)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Load Balancing in the DatacenterGoogle Con un round robin simple, el uso de CPU entre tareas llega a diferir hasta 2 veces; reparto ponderado en el que los backends informan de su carga en las respuestas y en los health checks; estado lame duck, en el que un backend pide que no le envíen más solicitudes
Health checks for Network Load Balancer target groupsAWS Health check cada 30 s por defecto y exclusión tras 2 fallos; los servicios UDP se comprueban con health checks TCP o HTTP, así que se recomienda configurarlos para que reflejen el estado real del servicio