Balanceadores y comprobaciones de salud

Hay comprobaciones de distinto nivel. La más simple prueba que un puerto abre: confirma que algo escucha, no que responda bien. Otra pide una dirección de la aplicación y espera un código de éxito, por ejemplo una página de salud que consulte sus dependencias. Una tercera revisa el contenido de la respuesta.

Entre más cerca esté la comprobación de lo que el usuario hace, menos probable es que mantenga en servicio a un miembro que ya no funciona. Una aplicación puede tener el puerto abierto y devolver error en cada petición.

Cruza dos columnas de miembros: el resultado de la comprobación y los errores de servidor (5xx) de los últimos cinco minutos. Un miembro con comprobación en «pasa» y una cifra de errores muy distinta a la de sus pares es el síntoma de una comprobación que no ve el fallo.

Con reparto por peso, cada miembro recibe una parte igual a su peso dividido entre la suma de los pesos de los miembros que siguen en el grupo. Cuando uno sale, su parte se redistribuye entre los demás en proporción a sus pesos, y es útil calcularla porque un miembro puede quedar sobrecargado.

Mira los pesos de GRP-51.

Los parámetros fallos_para_sacar y aciertos_para_volver evitan que un miembro entre y salga del grupo a cada comprobación. Sacar a uno tras varios fallos seguidos evita reacciones a un fallo aislado. Reincorporarlo tras varios aciertos seguidos evita devolverle todo el tráfico cuando solo acertó una vez por casualidad.

Un grupo sin comprobación de salud envía tráfico a todos sus miembros, estén como estén: si uno cae, el balanceador sigue repartiéndole conexiones hasta que alguien nota las quejas. Es el hallazgo más sencillo de la revisión y uno de los que más duele. Busca en grupos la comprobación.