En este artículo quiero mostrar cómo es fácil y gratuito crear un esquema de failover para un sitio web (o cualquier otro servicio en Internet) usando una combinación de monitoreo y un servicio de DNS dinámico. Es decir, en caso de cualquier problema con el sitio principal (desde un problema de «Error PHP» en la página, hasta falta de espacio o simplemente un número sospechosamente bajo de pedidos en el caso de una tienda en línea), los nuevos visitantes serán dirigidos a un segundo (tercero, y así sucesivamente) servidor que esté funcionando, o a una página de «Lo siento», donde se les explicará amablemente que «hay un problema, ya estamos al tanto y lo estamos arreglando, pronto estará solucionado» (y en este caso usted de hecho ya estará al tanto y podrá arreglarlo).
¿Vivir con failover o sin él?
Hasta que ocurra algún problema, realmente no hay mucha diferencia. Pero cuando sucede, sin failover a menudo ocurre lo siguiente: usted intenta averiguar rápidamente cuál es el problema, no lo logra (las copias de seguridad no se restauran, el software no funciona como se supone que debe según la documentación, etc.), y no hay tiempo, los servidores y sitios están caídos, los clientes llaman, todos están nerviosos, intenta arreglarlo de manera improvisada y desordenada «con cinta», luego algo parece funcionar con parches y sigue adelante. Usted piensa que en su tiempo libre necesitará revisar todo más a fondo y hacerlo bien, pero no hay nada más permanente que lo temporal.
Ahora, ¿cómo ocurre esto en una variante elegante con failover:
- Ocurre un error
- El error se detecta automáticamente
- Se envía una notificación
- Se realiza la transición a uno de los servidores de respaldo
- Se resuelve el problema con calma y sin pánico, se corrige y el servidor se vuelve a activar.
En este esquema, por supuesto, pueden surgir sus complicaciones, pero aun así, el esquema es lineal, cada etapa aquí es simple y lo principal es que se puede depurar por separado, por lo que la probabilidad de fallos en este esquema es mucho menor, y todas las acciones pueden ser automatizadas y ejecutadas rápidamente (a diferencia de la tarea de encontrar y corregir alguna falla épica desconocida). Su avión ha aterrizado en un país lejano, enciende el teléfono y ve en Telegram una notificación de que el servidor ha caído, pero todo está bien, se ha activado el servidor de respaldo, puede continuar su viaje, no necesita volar de regreso ni reparar por SSH desde el café más cercano con WiFi. Lo resolverá cuando sea más conveniente.
¡El futuro ya está aquí!
Antes, el principal problema que hacía que la conmutación por falla fuera a menudo una solución inaceptable era el costo asociado. O se necesitaban comprar costosos equipos (y contratar a especialistas aún más costosos). O se improvisaban soluciones complejas según guías (incluso vi una opción donde dos servidores se conectaban con un cable null-modem y enviaban un latido por él, para que en el momento adecuado el servidor de respaldo supiera y tomara el control). Ahora hay maneras más simples y gratuitas. Si tiene un sitio de gatos, no tiene excusa si aún no ha implementado la conmutación por falla para él.
Además, para el esquema de conmutación por falla se necesita también un servidor (o tal vez más de uno) y antes esto representaba un gran gasto, ahora se puede obtener un VDS por unas pocas monedas.
El sitio más confiable de gatos
Para ilustrar prácticamente la solución con okerr + DNS dinámico, hemos lanzado nuestro sitio de gatos . Odiamos a los gatos, por lo que allí casi no habrá ninguno. Hay un total de tres sitios, cada uno se parece aproximadamente al mismo (todos en una misma plantilla), pero con diferentes gatitos para que sea fácil diferenciarlos, y cada uno proporciona información técnica para ver cómo funciona la conmutación por falla. La página se actualiza sola cada minuto, pero siempre se puede presionar recargar en el navegador.
En la información técnica hay una línea 'status=OK'. A veces, los servidores simulan problemas y escriben status=ERR. El servidor principal 'cae' a los 20 minutos de cada hora (0:20, 1:20, 2:20, ...). El servidor secundario (backup) a los 40 minutos. El último servidor (servidor 'sorry') siempre está operativo. A los 0 minutos de cada hora, el servidor principal y el secundario 'se restauran'.
Si abres el sitio web y lo dejas en la pestaña, verás que nunca se cae (aunque cada servidor por separado simula problemas periódicamente), y en caso de un problema con el servidor, simplemente "salta" entre servidores en vivo. La imagen, el nombre y la dirección del servidor y su función cambiarán. A veces puedes captar el momento en que status=ERR (ya hay un problema, pero todo el esquema de failover aún no se ha activado), pero la siguiente actualización te mostrará la página del servidor activo.
Failover en okerr + DNS dinámico
Veamos cómo está organizado esto por dentro. La tarea del failover es que la dirección cat.okerr.com siempre apunte a la dirección IP del servidor activo.
Detrás de cada uno de los servidores que mantiene nuestro sitio de gato en okerr hay un indicador que verifica su estado cada minuto.
En esta captura vemos cómo se verifica el sitio cat.okerr.com desde el servidor alpha.okerr.com. La página debe contener status=OK, y como podemos ver arriba, el estado del indicador actualmente es OK. Cuando el servidor "se rompe", aparecerá ERR. (Este es solo un ejemplo de indicador, okerr es un servicio de monitoreo, por lo que se puede adjuntar cualquier tipo de indicador, como comprobar el espacio libre en disco, la cantidad de nuevos pedidos en la base de datos e incluso indicadores lógicos, por ejemplo, de noche habrá un conjunto de criterios de error, y durante el día otro).
En la configuración del proyecto, hemos creado un esquema de failover con estos indicadores:
En el esquema hay tres indicadores (tres servidores), diferentes en prioridad. El servidor principal para el sitio es charlie, si no está funcionando (no habrá "status=OK" o simplemente está inaccesible), entonces bravo y, en último caso, alpha. En la parte derecha de la página se muestra el estado del registro DNS en diferentes servidores.
Para aquellos que notaron que se utiliza el nombre cat.he.okerr.com: utilizamos un esquema un poco más complicado. En lugar de simplemente cambiar el registro DNS cat.okerr.com, cambiamos cat.he.okerr.com (en el proveedor de DNS dinámico ), y cat.okerr.com es un CNAME (alias) que no cambia, siempre apunta a cat.he.okerr.com. Simplemente preferimos Hurricane como DNS dinámico, y tiene claves para gestionar un registro específico (y no toda la zona), eso nos parece más seguro. También puedes no especificar en okerr las contraseñas-clave para gestionar todo el dominio, sino solo para un subdominio o registro.
De caída a subida
Pasos sobre cómo funciona este esquema:
- Suele ocurrir (simular) un problema en el servidor
- El sensor okerr verifica el estado de cada servidor cada minuto y reporta al servidor principal del proyecto en okerr.
- El indicador del servidor correspondiente cambia su estado de OK a ERR.
- Al cambiar el estado del indicador, se recalcula el failover y se determina qué dirección debe establecerse (si es necesario. Por ejemplo, si el servidor principal está funcionando y en ese momento el secundario ha fallado, no habrá cambios).
- Esta dirección se comunica al servicio de DNS dinámico. Al finalizar esta etapa, a la derecha verás el estado “sincronizado”.
- Muy pronto (en segundos) el registro llegará a los servidores DNS de tu dominio (en el sitio son ns1-ns5.he.net).
- A partir de este momento, algunos usuarios ya estarán accediendo al nuevo servidor en vivo. Pero aún no todos los servidores DNS en el mundo han actualizado los registros, y en algunos lugares puede que aún esté almacenado en caché el registro anterior. Se puede observar cómo los datos en los servidores DNS públicos “bailan”, mostrando a veces el nuevo y a veces el viejo valor. Si actualizas la página de configuración del failover, okerr solicitará nuevos datos de los servidores DNS.
- Una vez que los datos se estabilizan y el antiguo registro en caché ya ha expirado, el 100% de las consultas irán al nuevo servidor.
Para acelerar la etapa 7 (a menudo la más larga), el TTL del registro DNS dinámico debe establecerse lo más bajo posible. Por lo general, los servicios permiten intervalos de 90-120 segundos. Es un compromiso razonable.
Adicionalmente
Todo esto se puede configurar en una tarde (si ya tienes un servidor duplicado). Tanto okerr como los servicios de DNS dinámico son gratuitos. Para obtener más verificaciones en okerr y un periodo de verificación más corto, necesitas pasar una capacitación (desde la página de perfil). Al completar, se aumenta inmediatamente el nivel (20 indicadores por hora + 1 rápido, de 10 minutos). Y si son pocos, escribe a support@okerr.com, probablemente se podrá aumentar (hasta ahora siempre ha habido posibilidad, nunca he dicho que no, al contrario, me he ofrecido). Simplemente al principio no quiero prometerles todo a todos, no estoy seguro de tener capacidad para cumplir. Pero por ahora hay pocos usuarios, así que no hay problemas con el aumento de límites.
¿Qué puede hacer okerr? Míralo en el sitio. . En general, esto es monitoreo (zabbix desde la nube), y el failover es una función adicional agradable. También puedes acceder a la demostración desde el sitio sin necesidad de registrarte.
Al cambiar el estado del indicador, se envía una notificación por correo electrónico o Telegram. (Observamos lo que sucede y entendimos que, parece, Telegram es el mensajero más confiable. ¡Gracias, RKN, por la prueba de estrés!) Con la configuración correcta de okerr, cualquier notificación es una señal de "¡dejen todo, hay que reparar!", o "¡falso alarma!". No debería haber alertas innecesarias de okerr (si las hay, hay que configurarlo de otra manera). Por ejemplo, para nuestro sitio de gatos, el servidor alpha nunca simula un error. Si se cae, debemos saberlo. Pero los demás servidores simulan errores constantemente, por lo que, para no recibir alertas varias veces por hora, esos indicadores tienen un estado de "silencio".
También tiene sentido crear un servidor de disculpas (en cualquier hosting muy barato), que tenga ya sea su página de disculpas (en caso de que todos los servidores principales y de respaldo estén caídos) o redirija a la página de estado en okerr (por ejemplo, nuestra ) o statuspage.io.
Fuente: habr.com
