Simple failover pour site web (surveillance + DNS dynamique)

Dans cet article, je souhaite montrer comment il est facile et gratuit de mettre en place un schéma de basculement pour un site web (ou tout autre service Internet) en combinant la surveillance okerr et un service DNS dynamique. En d'autres termes, en cas de problème avec le site principal (que ce soit une erreur « PHP », un manque d'espace ou simplement un nombre de commandes suspectement bas dans le cas d'un e-commerce), les nouveaux visiteurs seront redirigés vers un serveur secondaire (tertiaire, etc.) qui fonctionne déjà, ou vers une page « Désolé », où il leur sera poliment expliqué qu'« il y a un problème, nous en sommes informés et nous le réparons, cela sera corrigé sous peu » (et dans ce cas, vous serez déjà au courant et pourrez effectuer la réparation).

Vivre avec ou sans basculement ?

Tant qu'il n'y a pas de problème, cela ne fait pas vraiment de différence. Mais quand il y a un problème, sans basculement, il se passe souvent ceci : vous essayez de comprendre rapidement la source du problème, sans succès (les sauvegardes ne se déploient pas, le logiciel ne fonctionne pas comme il devrait selon la documentation, etc.), et le temps presse, les serveurs/sites sont en panne, les clients appellent, tout le monde est nerveux, vous tentez de réparer de manière approximative et chaotique, puis ça redémarre plus ou moins avec des rustines et ça continue. Vous pensez qu'il faudra un jour approfondir le sujet et tout refaire correctement, mais rien n'est plus permanent qu'un temporaire.

Maintenant, voyons comment cela se passe dans une version optimale avec un basculement :

• L'erreur se produit
• L'erreur est détectée automatiquement
• Une notification est envoyée
• La bascule vers un des serveurs de secours est effectuée
• On gère le problème tranquillement et sans panique, on corrige l'erreur et le serveur est à nouveau opérationnel.

Dans ce schéma, il peut également y avoir des soucis, mais en fin de compte, le processus est linéaire, chaque étape est simple et surtout — elle peut être testée séparément, donc le risque d'échec de ce schéma est bien plus faible, et toutes les actions peuvent être automatisées et exécutées rapidement (contrairement à la tâche de trouver et de corriger une erreur épique inexplicable). Votre avion a atterri dans un pays lointain, vous allumez votre téléphone et voyez dans Telegram qu'une notification indique que le serveur est tombé, mais tout va bien, le serveur de secours a été activé, vous pouvez continuer votre voyage, vous n'avez pas besoin de retourner ou de réparer par SSH depuis le café le plus proche avec WiFi. Vous vous occuperez de cela quand cela vous conviendra mieux.

Le futur est déjà là !

Auparavant, le principal problème qui rendait le failover souvent inacceptable était le coût élevé associé. Il fallait soit acheter du matériel coûteux (et faire appel à des spécialistes encore plus onéreux), soit bricoler quelque chose de complexe en suivant des guides (je suis même tombé sur un exemple où deux serveurs étaient reliés par un câble null modem, échangeant des signaux heartbeat pour que le serveur secondaire sache à quel moment prendre le relais). Aujourd'hui, il existe des solutions plus simples et gratuites. Si vous avez un site de chats, il n’y a aucune excuse pour ne pas avoir mis en place le failover !

En outre, un serveur (ou peut-être plusieurs) est nécessaire pour le schéma de failover, et cela engendrait des coûts importants par le passé. Maintenant, vous pouvez obtenir un VDS pour une bouchée de pain.

Le site le plus fiable sur les chats

Pour illustrer pratiquement la solution avec okerr + dns dynamique, nous avons lancé notre propre site de chats cat.okerr.com. Nous détestons les chats, donc il y en aura presque pas. Il y a au total trois sites, chacun ressemblant à peu près à l'autre (tous sur le même modèle), mais avec différents chatons pour faciliter la distinction, et chacun fournit des informations techniques pour observer le fonctionnement du failover. La page se met à jour automatiquement toutes les minutes, mais vous pouvez toujours cliquer sur recharger dans votre navigateur.

Dans les informations techniques, il y a une ligne « status=OK ». De temps en temps, les serveurs simulent des problèmes et indiquent status=ERR. Le serveur principal « tombe » à 20 minutes de chaque heure (0:20, 1:20, 2:20, …). Le serveur de secours (backup) le fait à 40 minutes. Le dernier serveur (« sorry »-server) fonctionne toujours. À 0 minute de chaque heure, le serveur principal et le serveur de secours « redémarrent ».

Si vous ouvrez le site et le laissez dans un onglet, vous constaterez qu'il ne tombe jamais (bien que chaque serveur individuel simule périodiquement un problème), et en cas de problème avec un serveur, il « court » simplement entre les serveurs actifs. L'image, le nom et l'adresse du serveur ainsi que son rôle changeront. Parfois, vous pouvez attraper le moment où status=ERR (le problème est déjà là, mais tout le schéma de failover n'a pas encore réagi), mais la mise à jour suivante vous montrera la page d'un serveur actif.

Failover sur okerr + DNS dynamique

Voyons comment cela fonctionne en coulisses. La tâche du failover est de garantir que l'adresse cat.okerr.com pointe toujours vers l'adresse IP du serveur actif.
Pour chacun des serveurs qui maintiennent notre site de chats à okerr, il y a un indicateur qui vérifie son état une fois par minute.

Sur cette capture d'écran, nous voyons comment le site cat.okerr.com est vérifié depuis le serveur alpha.okerr.com. La page doit contenir status=OK, et comme nous pouvons le voir en haut, l'état de l'indicateur est actuellement OK. Lorsque le serveur tombe en panne, l'indicateur affichera ERR. (Ceci n'est qu'un exemple d'indicateur, okerr est un service de surveillance, donc nous pouvons attacher n'importe quel type d'indicateur, par exemple, vérifier l'espace disque libre, le nombre de nouvelles commandes dans la base, et même des indicateurs logiques, par exemple, la nuit, il y aura des critères d'erreur différents que le jour).

Dans les paramètres du projet, nous avons créé un schéma de basculement avec ces indicateurs :

Le schéma comporte trois indicateurs (trois serveurs), de différentes priorités. Le serveur principal pour le site est charlie, s'il ne fonctionne pas (ne sera pas 'status=OK' ou est simplement inaccessible), alors bravo et dans le dernier cas — alpha. Dans la partie droite de la page, l'état de l'enregistrement DNS sur différents serveurs est affiché.

Pour ceux qui ont remarqué l'utilisation du nom cat.he.okerr.com : Nous utilisons un schéma un peu plus complexe. Au lieu de simplement modifier l'enregistrement DNS de cat.okerr.com, nous modifions cat.he.okerr.com (sur le fournisseur de DNS dynamique Hurricane Electric), et cat.okerr.com est un CNAME (alias), qui ne change pas, indiquant toujours vers cat.he.okerr.com. Nous préférons Hurricane comme DNS dynamique, et il dispose de clés pour gérer un enregistrement spécifique (et non toute la zone), ce qui nous semble plus sûr. Vous pouvez également ne pas spécifier de mots de passe-clés dans okerr pour gérer tout le domaine, mais seulement pour le sous-domaine ou l'enregistrement.

De la chute à la remontée

Étape par étape, voici comment fonctionne ce schéma :

1. Un problème se produit (simulé) sur le serveur
2. Le capteur okerr vérifie l'état de chaque serveur chaque minute et informe le serveur principal du projet à okerr
3. L'indicateur du serveur concerné change d'état de OK à ERR
4. Lors du changement de statut de l'indicateur, le basculement est recalculé, et l'adresse à définir est déterminée (si besoin. Par exemple, si le serveur principal fonctionne, mais que le secours est tombé en panne — il n'y aura aucun changement)
5. Cette adresse est communiquée au service DNS dynamique. Une fois cette étape terminée, à droite, vous verrez le statut 'synced'
6. Bientôt (en quelques secondes), l'enregistrement atteindra les serveurs DNS de votre domaine (pour le site de chat, il s'agit de ns1-ns5.he.net).
7. À partir de maintenant, certains utilisateurs commenceront à accéder au nouveau serveur en direct. Cependant, tous les serveurs DNS dans le monde n'ont pas encore mis à jour leurs enregistrements, et il se peut que l'ancien enregistrement soit encore mis en cache quelque part. On peut voir comment les données sur les serveurs DNS publics "dansent", montrant tantôt la nouvelle, tantôt l'ancienne valeur. Si vous actualisez la page de configuration du failover, okerr demandera lui-même de nouvelles données aux serveurs DNS.
8. Une fois que les données se stabilisent, l'ancien enregistrement mis en cache a disparu de partout — 100 % des requêtes vont au nouveau serveur.

Pour accélérer la 7e étape (souvent la plus longue), il faut définir le TTL de l'enregistrement DNS dynamique aussi bas que possible. En général, les services autorisent des intervalles de 90 à 120 secondes. C'est un compromis tout à fait raisonnable.

Supplémentaire

Tout cela peut être configuré en une soirée (si vous avez déjà un serveur de secours). Et okerr ainsi que les services DNS dynamiques sont gratuits. Pour obtenir davantage de vérifications dans okerr et un délai de vérification plus court, il faut suivre une formation (sur la page du profil). Après cela, le niveau augmente immédiatement (20 indicateurs par heure + 1 rapide, de 10 minutes). Et s'il y en a peu — écrivez à support@okerr.com, il y a de fortes chances qu'on puisse augmenter (jusqu'à présent, il y a toujours eu une possibilité, je n'ai jamais été refusé, au contraire, j'ai moi-même proposé). Je ne veux juste pas promettre à tout le monde tout, car je ne suis pas sûr d'avoir assez de ressources pour tenir ma parole. Mais pour l'instant, il y a peu d'utilisateurs, donc il n'y a pas de problème pour augmenter les limites.

Que peut faire okerr en général — consultez le site la présentation. En fait, il s'agit de surveillance (Zabbix dans le cloud), et le fichierur est une fonction supplémentaire agréable. De plus, on peut accéder à une démo sans inscription depuis le site.

Lors de la modification de l'état de l'indicateur, une notification est envoyée par e-mail ou sur Telegram. (Nous avons observé ce qui se passe et réalisé que, apparemment, Telegram est le messager le plus fiable. Merci au RKN pour le test de stress !) Avec un réglage correct de okerr, toute notification est soit un signal "laissez tout tomber, il faut réparer !", soit "tout va bien !". Il ne devrait pas y avoir d'alertes superflues de la part d'okerr (s'il y en a, il faut configurer différemment). Par exemple, pour notre site dédié aux chats, le serveur alpha est le dernier et n'imite jamais une erreur. S'il s'écroule — nous devons le savoir. En revanche, les autres serveurs simulent constamment des erreurs, donc, pour ne pas recevoir d'alertes plusieurs fois par heure, ces indicateurs ont le statut "silencieux".

Il est également judicieux de créer un serveur de secours (sur n'importe quel hébergement bon marché) qui aura soit votre page d'excuses (au cas où tous les serveurs principaux et de secours seraient hors ligne), soit un redirection vers la page d'état sur okerr (comme notre cp.okerr.com/status/okerr) ou statuspage.io.

Source : habr.com