En este artículo quiero mostrar lo fácil y gratuito que puedes crear un esquema de conmutación por error para un sitio web (o cualquier otro servicio de Internet) utilizando una combinación de monitoreo. y servicio DNS dinámico. Es decir, en caso de cualquier problema con el sitio principal (desde un problema con un “Error de PHP” en la página, hasta falta de espacio o simplemente un número sospechosamente pequeño de pedidos en el caso de una tienda online), nuevos visitantes aparecerán ser dirigido al segundo (tercero, y así sucesivamente) un servidor en funcionamiento conocido, o a la página "Lo siento", donde le explicarán cortésmente que "hay un problema, ya lo sabemos y ya lo estamos solucionando, Lo solucionará pronto” (y en este caso ya estará informado y podrá repararlo).
¿Vivir con conmutación por error o sin ella?
Hasta que no ocurra algún problema, no hay mucha diferencia. Pero cuando esto sucede, sin conmutación por error, a menudo sucede lo siguiente: intentas descubrir rápidamente cuál es el problema, no funciona (las copias de seguridad no se implementan, el software por alguna razón no funciona como debería, según la documentación). , etc.), pero no hay tiempo, no hay servidor: los sitios están por ahí, los clientes llaman, todos están nerviosos, estás tratando de arreglarlo de alguna manera de manera tosca y sucia "con cinta adhesiva", luego de alguna manera parece que se inicia con muletas y vidas. Piensas que en tu tiempo libre tendrás que resolverlo con más detalle y rehacer todo maravillosamente, pero no hay nada más permanente que temporal.
Ahora, cómo sucede esto en una hermosa versión con un archivador:
- sucede un error
- El error se detecta automáticamente.
- Se envía alerta
- Se transfiere el cambio a uno de los servidores de respaldo
- Con calma y sin pánico, el problema se soluciona, se corrige y el servidor se vuelve a poner en funcionamiento.
Este esquema, por supuesto, también puede tener sus propios problemas, pero aún así, el esquema es lineal, cada etapa es simple y lo principal es que se puede depurar por separado, por lo que la probabilidad de falla de este esquema es mucho menor, y todas las acciones se pueden automatizar y realizar rápidamente (a diferencia de la tarea de encontrar y arreglar basura épica desconocida). Tu avión ha aterrizado en un país lejano, enciendes tu teléfono y ves una notificación en un telegrama de que el servidor ha fallado, pero todo está bien, el servidor de respaldo se ha activado, puedes continuar tu viaje, no necesitas para volar de regreso o repararlo vía SSH desde la cafetería más cercana con WiFi. Lo descubrirás cuando sea más conveniente.
¡El futuro ya está aquí!
Anteriormente, el principal problema que hacía que la conmutación por error fuera a menudo una solución inaceptable era el coste que implicaba. O fue necesario comprar hardware caro (e invitar a especialistas aún más caros). O cultivar algo complicado según las guías (incluso me encontré con una opción en la que además se conectan dos servidores con un cable de módem nulo y envían un latido a través de él, de modo que en el momento adecuado el servidor de respaldo lo reconoce y se hace cargo control). Ahora hay formas más fáciles y gratuitas. Si tienes un sitio web con gatos, ¡no hay excusa para no implementar la conmutación por error todavía!
Bueno, además, para un esquema de conmutación por error necesitas otro servidor (y tal vez más de uno) y antes esto era un gran gasto, ahora puedes conseguir un VDS por unos centavos.
El sitio más confiable con gatos.
Para ilustrar prácticamente la solución con okerr + dns dinámico, lanzamos nuestro sitio web con gatos . Odiamos a los gatos, así que no habrá muchos allí. Hay tres sitios en total, cada uno se ve más o menos igual (todos en la misma plantilla), pero con diferentes gatitos para que sea fácil de distinguir, y cada uno escribe información técnica para ver cómo funciona la conmutación por error. La página se actualiza sola una vez cada minuto, pero siempre puedes hacer clic en recargar en el navegador.
En la información técnica hay una línea "status=OK". A veces los servidores fingen problemas y escriben status=ERR. El servidor principal “parece fallar” a los 20 minutos de cada hora (0:20, 1:20, 2:20,…). Servidor de respaldo en 40 minutos. El último servidor (servidor "lo siento") siempre está ejecutándose. A los 0 minutos de cada hora, los servidores principal y de respaldo se "restauran".
Si abre el sitio y lo deja en la pestaña, verá que nunca falla (aunque cada servidor individual simula periódicamente un problema) y, en caso de un problema con el servidor, simplemente "se ejecuta" entre servidores activos. 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 (el problema ya existe, pero todo el esquema de conmutación por error aún no ha funcionado), pero la próxima actualización te mostrará una página del sitio de trabajo.
Conmutación por error en okerr + DNS dinámico
Veamos cómo funciona debajo del capó. La tarea del declarante es garantizar que la dirección cat.okerr.com siempre apunte a la dirección IP del servidor en funcionamiento.
Detrás de cada uno de los servidores que alojan nuestro sitio de gatos en okerr hay un indicador que comprueba su estado una vez por minuto.
En esta captura de pantalla 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 vemos arriba, el estado de nuestro indicador es OK ahora. Cuando el servidor "se rompe", habrá un ERR. (Este es solo un ejemplo de un indicador, okerr está monitoreando, por lo que puede adjuntar cualquier tipo de indicador, por ejemplo, verificar el espacio libre en el disco, la cantidad de nuevos pedidos en la base de datos e incluso indicadores lógicos, por ejemplo , de noche habrá algunos criterios de error, y de día otros).
En la configuración del proyecto creamos un esquema de conmutación por error con estos indicadores:
El esquema tiene tres indicadores (tres servidores), de diferente prioridad. El servidor principal del sitio es charlie, si no funciona (no tendrá “estado=OK” o simplemente no está disponible), entonces bravo y en el último caso - alpha. El lado derecho de la página muestra el estado del registro DNS en diferentes servidores.
Para aquellos que notaron que se usa el nombre cat.he.okerr.com: utilizamos un esquema un poco más complejo. En lugar de simplemente cambiar el registro DNS de 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 nos gusta más Hurricane como DNS dinámico y tiene claves para administrar una única entrada (en lugar de una zona completa), creemos que es más seguro. Tampoco es necesario especificar contraseñas clave en okerr para administrar todo el dominio, sino solo para un subdominio o registro.
De caer a subir
Paso a paso cómo funciona este esquema:
- Ocurre un problema (simulado) en el servidor
- El sensor okerr verifica el estado de cada servidor una vez por minuto y lo informa al servidor principal del proyecto en okerr.
- El indicador del servidor correspondiente cambia de OK a ERR
- Cuando el estado del indicador cambia, se vuelve a calcular la conmutación por error y se calcula qué dirección debe configurarse (si es necesario. Por ejemplo, si el servidor principal está funcionando y al mismo tiempo el servidor de respaldo falló, no se realizarán cambios hecho)
- Esta dirección se informa al servicio DNS dinámico. Al finalizar esta etapa, verá el estado "sincronizado" a la derecha.
- Muy pronto (segundos) el registro llegará a los servidores DNS de su dominio (para el sitio cat es ns1-ns5.he.net).
- A partir de este momento, algunos usuarios ya estarán en el nuevo servidor en vivo. Pero no todos los servidores DNS del mundo han actualizado los registros todavía, y es posible que el registro antiguo aún esté almacenado en caché en algún lugar. Puede ver cómo los datos de los servidores DNS públicos “bailan”, mostrando un valor nuevo o antiguo. Si actualiza la página de configuración de conmutación por error, el propio operador solicitará nuevos datos a los servidores DNS.
- Una vez que los datos se han estabilizado, el antiguo registro en caché está podrido en todas partes: el 100% de las solicitudes van 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. Normalmente los servicios permiten intervalos de 90 a 120 segundos. Este es un compromiso completamente razonable.
además
Todo esto se puede configurar en una noche (si ya tiene un servidor de respaldo). Tanto el servicio DNS dinámico como el okerr son gratuitos. Para obtener más controles en okerr y un período de verificación más corto, debe completar la capacitación (desde su página de perfil). Al finalizar, el nivel aumenta inmediatamente (20 indicadores por hora + 1 rápido, 10 minutos). Y si son pocos, escribe a [email protected], lo más probable es que sea posible aumentar (hasta ahora siempre ha habido una oportunidad, nunca la he rechazado, al contrario, la ofrecí yo mismo). Es solo que inicialmente no quiero prometerles todo a todos, no estoy seguro de tener la capacidad suficiente para cumplir mi palabra. Pero hasta ahora hay pocos usuarios, por lo que no hay problemas para aumentar los límites.
Qué puede hacer okerr en general: consulte el sitio web . En general, esto es monitoreo (zabbix desde la nube) y el archivador es una buena función adicional. También puede acceder a la demostración desde el sitio sin registrarse.
Cuando el estado del indicador cambia, se envía una notificación por correo electrónico o Telegram. (Observamos lo que estaba sucediendo y nos dimos cuenta de que Telegram parece ser el mensajero más confiable. ¡Gracias a RKN por la prueba de estrés!) Con okerr configurado correctamente, cualquier notificación es una señal de "¡deja todo, tenemos que arreglarlo!". , o "¡luces apagadas!" No debería haber alertas adicionales de okerra (si las hay, deben configurarse de alguna manera diferente). Por ejemplo, para nuestro sitio cat, el servidor alfa es el último y nunca finge un error. Si se acuesta, necesitamos saberlo. Pero otros servidores constantemente fingen errores, por lo que, para no recibir alertas varias veces por hora, esos indicadores tienen un estado “silencioso”.
También tiene sentido crear un servidor de disculpas (en cualquier hosting más barato), que tendrá su página de disculpas (en caso de que todos los servidores principal y de respaldo estén caídos) o lo redireccionará a la página de estado en okerr (por ejemplo, el nuestro). ) o statuspage.io.
Fuente: habr.com