Conmutación por fallo simple para o sitio web (monitorización + DNS dinámico)

Neste artigo quero mostrar o sinxelo e gratuíto que pode facer un esquema de conmutación por fallo para un sitio web (ou calquera outro servizo de Internet) usando unha combinación de monitorización okerr e servizo DNS dinámico. É dicir, en caso de problemas co sitio principal (desde un problema cun "Erro PHP" na páxina, ata falta de espazo ou simplemente un número sospeitosamente pequeno de pedidos no caso dunha tenda en liña), os novos visitantes ser dirixido ao segundo (terceiro, etc.) máis adiante) un servidor coñecido que funciona, ou á páxina "Sentímolo", onde explicarán educadamente que "hai un problema, xa estamos conscientes e xa o estamos solucionando, solucionarao en breve” (e neste caso xa estarás informado e poderás reparalo).

Vivir con failover ou sen?

Ata que non ocorre algún problema, non hai moita diferenza. Pero cando ocorre, sen conmutación por falla adoita ocorrer o seguinte: tentas descubrir rapidamente cal é o problema, non funciona (as copias de seguridade non se implementan, o software por algún motivo non funciona como debería da documentación). , etc.), pero non hai tempo nin servidor: os sitios están por aí, os clientes están a chamar, todo o mundo está ao límite, estás tentando arranxalo de algunha maneira e ensucia "con cinta", entón parece que se inicia. con muletas e vidas. Pensas que no teu tempo libre terás que descubrilo con máis detalle e refacelo todo moi ben, pero non hai nada máis permanente que o temporal.

Agora, como ocorre isto nunha fermosa versión cun ficheiro:

  • Ocorre un erro
  • O erro detéctase automaticamente
  • Envíase a alerta
  • O cambio a un dos servidores de copia de seguranza transfírese
  • Con calma e sen pánico, o problema é resolto, corrixido e o servidor volve poñerse en funcionamento.

Este esquema, por suposto, tamén pode ter os seus propios problemas, pero aínda así, o esquema é lineal, cada etapa é sinxela e o principal é que se pode depurar por separado, polo que a probabilidade de falla deste esquema é moito menor e todas as accións poden ser automatizadas e realizadas rapidamente (a diferenza da tarefa de atopar e corrixir unha merda épica descoñecida). O teu avión aterrou nun país afastado, acendes o teu teléfono e ves unha notificación nun telegrama de que o servidor fallou, pero todo está ben, o servidor de copia de seguridade activouse, podes continuar a túa viaxe, non necesitas para voar de volta ou reparalo a través de SSH desde o café máis próximo con WiFi. Descubrirás cando sexa máis conveniente.

O futuro xa está aquí!

Anteriormente, o principal problema que convertía a failover nunha solución a miúdo inaceptable era o custo que custa. Ou era necesario comprar hardware caro (e invitar a especialistas aínda máis caros). Ou granxa colectiva algo complicado segundo as guías (ata me atopei cunha opción onde dous servidores están conectados adicionalmente cun cable de módem nulo, e mandan un latexo a través del, para que no momento oportuno o servidor de copia de seguridade o recoñeza e tome o relevo). control). Agora hai formas máis sinxelas e gratuítas. Se tes un sitio web con gatos, non hai escusa para non implementar a conmutación por falla aínda!

Ben, ademais, para un esquema de failover necesitas outro servidor (e quizais máis dun) e antes isto era un gran gasto, agora podes conseguir un VDS por céntimos.

O sitio máis fiable con gatos

Para ilustrar practicamente a solución con okerr + dynamic dns, lanzamos a nosa web con cats cat.okerr.com. Odiamos os gatos, polo que non haberá moitos alí. Hai tres sitios en total, cada un ten un aspecto máis ou menos igual (todos no mesmo modelo), pero con gatiños diferentes para que sexa fácil de distinguir, e cada un escribe información técnica para ver como funciona o failover. A páxina actualízase unha vez cada minuto, pero sempre podes facer clic en Recargar no navegador.

Na información técnica hai unha liña "estado=OK". Ás veces, os servidores simulan problemas e escriben status=ERR. O servidor principal "parece fallar" aos 20 minutos de cada hora (0:20, 1:20, 2:20, ...). Copia de seguranza do servidor en 40 minutos. O último servidor (servidor "perdón") está sempre en execución. Aos 0 minutos de cada hora, "restauráronse" os servidores principal e de reserva.

Conmutación por fallo simple para o sitio web (monitorización + DNS dinámico)

Se abres o sitio e o deixas na pestana, verás que nunca falla (aínda que cada servidor individual simula periódicamente un problema) e, en caso de producirse un problema co servidor, simplemente "execútase" entre servidores en directo. A imaxe, o nome e o enderezo do servidor e a súa función cambiarán. Ás veces podes captar o momento no que status = ERR (o problema xa existe, pero todo o esquema de conmutación por fallo aínda non funcionou), pero a próxima actualización amosarache unha páxina do sitio de traballo.

Failover en okerr + DNS dinámico

A ver como funciona baixo o capó. A tarefa do ficheiro é asegurarse de que o enderezo cat.okerr.com apunte sempre ao enderezo IP do servidor en funcionamento.
Detrás de cada un dos servidores que aloxan o noso sitio de gatos en okerr hai un indicador que verifica o seu estado unha vez por minuto.

Conmutación por fallo simple para o sitio web (monitorización + DNS dinámico)

Nesta captura de pantalla vemos como se comproba o sitio cat.okerr.com desde o servidor alpha.okerr.com. A páxina debe conter status=OK e, como vemos arriba, o noso indicador está agora OK. Cando o servidor "rompe", haberá un ERR. (Este é só un exemplo dun indicador, okerr é un seguimento, polo que podes anexar calquera tipo de indicador, por exemplo, comprobar o espazo libre no disco, o número de pedidos novos na base de datos e mesmo indicadores lóxicos, por exemplo , pola noite haberá uns criterios de erro, e polo día outros) .

Na configuración do proxecto creamos un esquema de failover con estes indicadores:

Conmutación por fallo simple para o sitio web (monitorización + DNS dinámico)

O esquema ten tres indicadores (tres servidores), diferentes en prioridade. O servidor principal do sitio é Charlie, se non funciona (non terá "estado = OK" ou simplemente non está dispoñible), entón bravo e, neste último caso, alfa. O lado dereito da páxina mostra o estado do rexistro DNS en diferentes servidores.

Para aqueles que notaron que se usa o nome cat.he.okerr.com: Usamos un esquema un pouco máis complexo. En lugar de simplemente cambiar o rexistro DNS de cat.okerr.com, cambiamos cat.he.okerr.com (no provedor de DNS dinámico Furacán eléctrico), e cat.okerr.com é un CNAME (alias), que non cambia, sempre apunta a cat.he.okerr.com. Gústanos máis Hurricane como DNS dinámico e ten claves para xestionar unha única entrada (en lugar de unha zona enteira), pensamos que é máis seguro. Tampouco tes que especificar contrasinais clave en okerr para xestionar todo o dominio, pero só para un subdominio ou rexistro.

De baixar a subir

Como funciona este esquema paso a paso:

  1. Prodúcese un problema (simulado) no servidor
  2. O sensor okerr comproba o estado de cada servidor unha vez por minuto e informa ao servidor do proxecto principal en okerr
  3. O indicador do servidor correspondente cambia de OK a ERR
  4. Cando o estado do indicador cambia, recalcúlase a conmutación por fallo e calcúlase cal é o enderezo que se debe establecer (se é necesario. Por exemplo, se o servidor principal está funcionando e, ao mesmo tempo, o servidor de copia de seguranza morreu, non se producirán cambios). feita)
  5. Este enderezo infórmase ao servizo de DNS dinámico. Ao rematar esta etapa, verá o estado "sincronizado" á dereita.
  6. Moi pronto (segundos) o rexistro chegará aos servidores DNS do teu dominio (para o sitio cat é ns1-ns5.he.net).
  7. A partir deste momento, algúns usuarios xa estarán no novo servidor en directo. Pero aínda non todos os servidores DNS do mundo actualizaron os rexistros e é posible que o rexistro antigo aínda estea almacenado na memoria caché nalgún lugar. Podes ver como os datos dos servidores DNS públicos "bailan", mostrando un valor novo ou antigo. Se actualiza a páxina de configuración de failover, o propio operador solicitará novos datos aos servidores DNS.
  8. Despois de que os datos se estabilizaron, o antigo rexistro en caché está podre en todas partes: o 100 % das solicitudes van ao novo servidor.

Para acelerar a etapa 7 (a miúdo a máis longa), o TTL do rexistro DNS dinámico debe establecerse o máis baixo posible. Normalmente os servizos permiten intervalos de 90-120 segundos. Este é un compromiso completamente razoable.

adicionalmente

Todo isto pódese configurar nunha noite (se xa tes un servidor de copia de seguridade). Tanto okerr como os servizos DNS dinámicos son gratuítos. Para obter máis comprobacións en okerr e un período de verificación máis curto, debes completar a formación (desde a túa páxina de perfil). Ao rematar, o nivel aumenta inmediatamente (20 indicadores por hora + 1 rápido, 10 minutos). E se son poucos, escribe a [protexido por correo electrónico], moi probablemente será posible aumentar (ata agora sempre houbo unha oportunidade, nunca me neguei, pola contra, ofrecinllo eu). É que nun principio non quero prometer todo a todos, non estou seguro de ter capacidade suficiente para cumprir a miña palabra. Pero ata agora hai poucos usuarios, polo que non hai problemas para aumentar os límites.

O que pode facer okerr en xeral: mira o sitio web presentación. En xeral, trátase dun seguimento (zabbix desde a nube) e o ficheiro é unha función adicional agradable. Tamén podes acceder á demostración desde o sitio sen rexistrarte.

Cando o estado do indicador cambia, envíase unha notificación por correo electrónico ou Telegram. (Miramos o que estaba a suceder e decatámonos de que Telegram parece ser o mensaxeiro máis fiable. Grazas a RKN pola proba de esforzo!) Con okerr configurado correctamente, calquera notificación é un sinal de "deixa todo, necesitamos solucionalo!" , ou "apaga as luces!" Non debería haber alertas adicionais da okerra (se as hai, deben configurarse dun xeito diferente). Por exemplo, para o noso sitio de gatos, o servidor alfa é o último e nunca finxe un erro. Se se deita, hai que sabelo. Pero outros servidores fingen erros constantemente, polo tanto, para non recibir alertas varias veces por hora, eses indicadores teñen un estado "silencioso".

Tamén ten sentido crear un servidor de desculpas (en calquera hospedaxe máis barata), que terá a túa páxina de desculpas (no caso de que todos os servidores principais e de copia de seguridade estean inactivos) ou que te redirija á páxina de estado de okerr (por exemplo, o noso). cp.okerr.com/status/okerr) ou statuspage.io.

Fonte: www.habr.com

Engadir un comentario