Estoy buscando una manera de configurar Apache como de alta disponibilidad. La idea es tener un grupo de más de 2 servidores Apache que sirvan a los mismos sitios web. Puedo configurar la dirección IP de cada servidor con DNS de operación por turnos para que cada solicitud se envíe aleatoriamente a uno de los servidores en el clúster (todavía no estoy demasiado preocupado por el equilibrio de carga, aunque eso puede entrar en juego). jugar más adelante).
Ya lo tengo configurado y trabajando con múltiples servidores Apache VM (repartidos en múltiples servidores físicos) que sirven sitios web y DNS por turnos, y esto funciona bien. La base de datos SQL se configura utilizando MariaDB en un clúster de alta disponibilidad, los datos web (HTML, JS, scripts PHP, imágenes, otros activos) se almacenan dentro de LizardFS y las sesiones también se almacenan en una ubicación compartida. Todo esto funciona bien hasta que uno de los servidores del clúster se vuelve inaccesible por cualquier motivo. Luego, un porcentaje de las solicitudes (aproximadamente el número de servidores caídos dividido por el número total de servidores en el clúster) quedan sin respuesta. Estas son las opciones que he considerado:
Actualizaciones automáticas de DNS
Tenga algún proceso que supervise la funcionalidad de los servidores web y elimine los servidores caídos del DNS. Esto tiene dos problemas:
Primero, aunque podemos configurar nuestro TTL en un número muy bajo (como 5 segundos), he oído que un puñado de servidores DNS aplicarán un TTL mínimo superior al nuestro. Y algunos navegadores (concretamente Chrome) almacenarán en caché el DNS durante no menos de 60 segundos, independientemente de la configuración de TTL. Entonces, aunque somos buenos por nuestra parte, es posible que algunos clientes no puedan acceder a los sitios durante algún tiempo en caso de una actualización de DNS.
En segundo lugar, el programa que monitorea la funcionalidad del clúster
y actualiza los registros DNS se convierte en un nuevo punto único de falla. Es posible que podamos
solucionar este problema si tenemos más de un monitor distribuido en varios
sistemas, porque si ambos detectan un problema y ambos realizan los mismos cambios de DNS, eso no debería causar ningún problema.
uCarpa/latido del corazón
Haga que las direcciones IP a las que se accede y en el DNS por turnos sean virtuales, y reasignelas a servidores activos desde servidores inactivos en caso de que un servidor falle. Por ejemplo, el VIP del servidor1 es 192.168.0.101 y el VIP del servidor2 es 192.168.0.102. Si el servidor1 deja de funcionar, entonces 192.168.1.102 se convierte en una IP adicional en el servidor2. Esto tiene dos problemas:
Primero, que yo sepa, uCarp/Heartbeat monitorea a sus pares específicamente en busca de inaccesibilidad, por ejemplo, si no se puede hacer ping al par. Cuando eso sucede, se hace cargo de la IP del par caído. Esto es un problema porque hay más razones por las que un servidor web puede no poder atender solicitudes además de ser inaccesible en la red. Es posible que Apache se haya bloqueado, que exista un error de configuración o alguna otra razón. Me gustaría que el criterio fuera "el servidor no sirve las páginas según se requiere" en lugar de "no se puede hacer ping al servidor". No creo que pueda definir eso en uCarp/Heartbeat.
En segundo lugar, esto no funciona en todos los centros de datos, porque cada conjunto de servidores en los centros de datos tiene diferentes bloques de direcciones IP. No puedo tener una IP virtual flotando entre centros de datos. El requisito de funcionar en todos los centros de datos (sí, mi sistema de archivos distribuido y mi clúster de base de datos están disponibles en todos los centros de datos) no es obligatorio, pero sería una buena ventaja.
Pregunta
Entonces, ¿alguna idea sobre cómo lidiar con esto? Básicamente, el santo grial de la alta disponibilidad: no hay puntos únicos de falla (ya sea en el servidor, el balanceador de carga o el centro de datos) y prácticamente no hay tiempo de inactividad en caso de un cambio.
Respuesta1
Cuando quiero HA y compartir carga, uso keepalived y lo configuro con dos VIP. De forma predeterminada, VIP1 se asigna al servidor1 y VIP2 se asigna al servidor2. Cuando un servidor no funciona, el otro servidor acepta ambos VIP.
Keepalived se encargará de HA observando el otro servidor. Si no se puede acceder a un servidor o alguna interfaz no funciona, cambia de FAULTestado. VIP será tomado por otro servidor. Para monitorear su servicio, puede usar track_scriptla opción.
Si desea agregar otro clúster en otro centro de datos, puede agregar dos servidores más y realizar la misma configuración. Ahora, puede cargar y compartir el tráfico entre centros de datos mediante el sistema round-robin de DNS. En este caso, no se requiere ninguna actualización de DNS.