introduction

Il y a quelque temps, on m'a confié la tâche de développer un cluster de basculement pour PostgreSQL, opérant dans plusieurs centres de données connectés par fibre optique au sein d'une même ville, et capable de résister à une panne (par exemple, panne de courant) d'un centre de données. En tant que logiciel responsable de la tolérance aux pannes, j'ai choisi Pacemakercar c'est la solution officielle de RedHat pour créer des clusters de basculement. C'est bien car RedHat le supporte et parce que cette solution est universelle (modulaire). Avec son aide, il sera possible d'assurer la tolérance aux pannes non seulement de PostgreSQL, mais aussi d'autres services, soit en utilisant des modules standards, soit en les créant pour des besoins spécifiques.

Cette décision a soulevé une question raisonnable : dans quelle mesure un cluster de basculement sera-t-il tolérant aux pannes ? Pour étudier cela, j'ai développé un banc de test qui simule diverses pannes sur les nœuds du cluster, attend la restauration du service, récupère le nœud défaillant et continue les tests en boucle. Ce projet s'appelait à l'origine hapgsql, mais avec le temps, je me suis lassé de ce nom, qui n'avait qu'une seule voyelle. Par conséquent, j'ai commencé à appeler des bases de données tolérantes aux pannes (et une IP flottante pointant vers elles) krogane (un personnage d'un jeu informatique dans lequel tous les organes importants sont dupliqués), et les nœuds, les clusters et le projet lui-même sont tuchanka (la planète où vivent les Krogans).

Maintenant, la direction a autorisé ouvrir le projet à la communauté open source sous licence MIT. Le README sera bientôt traduit en anglais (car on s'attend à ce que les principaux consommateurs soient les développeurs Pacemaker et PostgreSQL), et j'ai décidé de présenter l'ancienne version russe du README (partiellement) sous la forme de cet article.

Les clusters sont déployés sur des machines virtuelles VirtualBox. Au total, 12 machines virtuelles (36 Go au total) seront déployées, qui forment 4 clusters tolérants aux pannes (différentes options). Les deux premiers clusters sont constitués de deux serveurs PostgreSQL situés dans des centres de données différents et d'un serveur commun. témoin c périphérique de quorum (hébergé sur une machine virtuelle bon marché dans un troisième centre de données), qui résout l'incertitude 50% / 50%, en donnant votre vote à l'un des partis. Troisième cluster dans trois centres de données : un maître, deux esclaves, non périphérique de quorum. Le quatrième cluster se compose de quatre serveurs PostgreSQL, deux par centre de données : un maître, le reste des répliques, et utilise également témoin c périphérique de quorum. Le quatrième peut résister à la panne de deux serveurs ou d'un centre de données. Cette solution peut être étendue à un plus grand nombre de répliques si nécessaire.

Service horaire précis ntpd également reconfiguré pour la tolérance aux pannes, mais il utilise la méthode elle-même ntpd (mode orphelin). Serveur partagé témoin agit comme un serveur NTP central, distribuant son temps à tous les clusters, synchronisant ainsi tous les serveurs entre eux. Si témoin échoue ou devient isolé, alors l'un des serveurs du cluster (au sein du cluster) commencera à distribuer son temps. Mise en cache auxiliaire Proxy HTTP également élevé à témoin, avec son aide, d'autres machines virtuelles ont accès aux référentiels Yum. En réalité, les services tels que l'heure précise et les proxys seront très probablement hébergés sur des serveurs dédiés, mais dans le stand, ils sont hébergés sur témoin uniquement pour économiser le nombre de machines virtuelles et l’espace.

Versions

v0. Fonctionne avec CentOS 7 et PostgreSQL 11 sur VirtualBox 6.1.

Structure des clusters

Tous les clusters sont conçus pour être situés dans plusieurs centres de données, combinés en un seul réseau plat et doivent résister aux pannes ou à l'isolement du réseau d'un seul centre de données. C'est pourquoi impossible utiliser pour se protéger contre cerveau divisé technologie Pacemaker standard appelée STONITH (Tirez sur l'autre nœud dans la tête) ou escrime. Son essence : si les nœuds du cluster commencent à soupçonner que quelque chose ne va pas avec un nœud, qu'il ne répond pas ou ne se comporte pas correctement, ils l'éteignent de force via des périphériques « externes », par exemple une carte de contrôle IPMI ou UPS. . Mais cela ne fonctionnera que dans les cas où, en cas de panne unique, le serveur IPMI ou UPS continue de fonctionner. Ici, nous prévoyons de nous protéger contre une panne beaucoup plus catastrophique, lorsque l'ensemble du centre de données tombe en panne (par exemple, perd de l'alimentation). Et avec un tel refus, tout pierre-les appareils (IPMI, UPS, etc.) ne fonctionneront pas non plus.

Au lieu de cela, le système repose sur l’idée de quorum. Tous les nœuds ont une voix, et seuls ceux qui peuvent voir plus de la moitié de tous les nœuds peuvent fonctionner. Cette quantité de « moitié + 1 » est appelée quorum. Si le quorum n'est pas atteint, alors le nœud décide qu'il est isolé du réseau et doit désactiver ses ressources, c'est-à-dire c'est ce que c'est protection du cerveau divisé. Si le logiciel responsable de ce comportement ne fonctionne pas, un chien de garde, par exemple basé sur IPMI, devra fonctionner.

Si le nombre de nœuds est pair (un cluster dans deux centres de données), une incertitude peut survenir. 50% / 50% (moitié-moitié) lorsque l'isolation du réseau divise le cluster exactement en deux. Ainsi, pour un nombre pair de nœuds, on ajoute périphérique de quorum est un démon peu exigeant qui peut être lancé sur la machine virtuelle la moins chère d'un troisième centre de données. Il donne son vote à l'un des segments (qu'il voit) et résout ainsi l'incertitude 50 %/50 %. J'ai nommé le serveur sur lequel le périphérique quorum sera lancé témoin (terminologie de repmgr, j'ai bien aimé).

Les ressources peuvent être déplacées d'un endroit à l'autre, par exemple, depuis des serveurs défectueux vers des serveurs sains, ou sur commande des administrateurs système. Pour que les clients sachent où se trouvent les ressources dont ils ont besoin (où se connecter ?), IP flottante (IP flottante). Ce sont des adresses IP que Pacemaker peut déplacer autour des nœuds (tout est sur un réseau plat). Chacun d'eux symbolise une ressource (service) et se situera à l'endroit où vous devrez vous connecter pour accéder à ce service (dans notre cas, une base de données).

Tuchanka1 (circuit avec compactage)

structure

L'idée était que nous disposions de nombreuses petites bases de données à faible charge, pour lesquelles il n'est pas rentable de maintenir un serveur esclave dédié en mode veille chaude pour les transactions en lecture seule (un tel gaspillage de ressources n'est pas nécessaire).

Chaque centre de données dispose d'un serveur. Chaque serveur dispose de deux instances PostgreSQL (dans la terminologie PostgreSQL on les appelle clusters, mais pour éviter toute confusion je les appellerai instances (par analogie avec d'autres bases de données), et j'appellerai uniquement clusters Pacemaker clusters). Une instance fonctionne en mode maître, et elle seule fournit des services (seule l'IP flottante y mène). La deuxième instance fonctionne comme esclave pour le deuxième centre de données et fournira des services uniquement en cas de panne de son maître. Comme la plupart du temps seule une instance sur deux (le maître) va fournir des services (effectuer des requêtes), toutes les ressources du serveur sont optimisées pour le maître (la mémoire est allouée au cache shared_buffers, etc.), mais pour que la deuxième instance dispose également de suffisamment de ressources (bien que pour un fonctionnement sous-optimal via le cache du système de fichiers) en cas de panne de l'un des centres de données. L'esclave ne fournit pas de services (n'effectue pas de requêtes en lecture seule) pendant le fonctionnement normal du cluster, de sorte qu'il n'y a pas de guerre pour les ressources avec le maître sur la même machine.

Dans le cas de deux nœuds, la tolérance aux pannes n'est possible qu'avec la réplication asynchrone, car avec la réplication synchrone, la panne d'un esclave entraînera l'arrêt du maître.

Défaut de témoigner

Défaut de témoigner (périphérique de quorum) Je ne considérerai que pour le cluster Tuchanka1, avec tous les autres ce sera la même histoire. Si le témoin échoue, rien ne changera dans la structure du cluster, tout continuera à fonctionner de la même manière. Mais le quorum passera à 2 sur 3, et donc tout échec ultérieur sera fatal pour le cluster. Il faudra encore y remédier de toute urgence.

Tuchanka1 refus

Panne de l'un des centres de données de Tuchanka1. Dans ce cas témoin vote sur un deuxième nœud dans un deuxième centre de données. Là, l'ancien esclave se transforme en maître, en conséquence, les deux maîtres travaillent sur le même serveur et leurs deux adresses IP flottantes pointent vers eux.

Tuchanka2 (classique)

structure

Schéma classique de deux nœuds. Le maître travaille sur l'un, l'esclave sur le second. Les deux peuvent exécuter des requêtes (l'esclave est en lecture seule), donc les deux sont pointés par une IP flottante : krogan2 est le maître, krogan2s1 est l'esclave. Le maître et l'esclave auront une tolérance aux pannes.

Dans le cas de deux nœuds, la tolérance aux pannes n'est possible qu'avec la réplication asynchrone, car avec la réplication synchrone, la défaillance de l'esclave entraînera l'arrêt du maître.

Tuchanka2 refus

Si l'un des centres de données tombe en panne témoin vote pour le deuxième. Sur le seul centre de données fonctionnel, le maître sera élevé et les deux adresses IP flottantes pointeront vers lui : le maître et l'esclave. Bien entendu, l'instance doit être configurée de manière à disposer de suffisamment de ressources (limites de connexion, etc.) pour accepter simultanément toutes les connexions et requêtes de l'IP flottante maître et esclave. C'est-à-dire qu'en fonctionnement normal, il doit disposer d'un nombre suffisant de limites.

Tuchanka4 (beaucoup d'esclaves)

structure

Déjà un autre extrême. Il existe des bases de données qui reçoivent beaucoup de requêtes en lecture seule (cas typique d'un site très chargé). Tuchanka4 est une situation où il peut y avoir trois esclaves ou plus pour traiter de telles demandes, mais toujours pas trop. Avec un très grand nombre d'esclaves, il faudra inventer un système de réplication hiérarchique. Dans le cas minimum (dans l'image), chacun des deux centres de données dispose de deux serveurs, chacun avec une instance PostgreSQL.

Une autre caractéristique de ce schéma est qu'il est déjà possible d'organiser une réplication synchrone. Il est configuré pour répliquer, si possible, vers un autre centre de données, plutôt que vers une réplique située dans le même centre de données que le maître. Le maître et chaque esclave sont pointés par une IP flottante. Heureusement, entre esclaves il faudra équilibrer les demandes tant bien que mal proxy SQL, par exemple, côté client. Différents types de clients peuvent nécessiter différents types proxy SQL, et seuls les développeurs clients savent qui a besoin de quoi. Cette fonctionnalité peut être implémentée soit par un démon externe, soit par une bibliothèque cliente (pool de connexions), etc. Tout cela va au-delà du sujet d'un cluster de bases de données de basculement (failover proxy SQL peut être mis en œuvre indépendamment, avec la tolérance aux pannes du client).

Tuchanka4 refus

Si un centre de données (c'est-à-dire deux serveurs) tombe en panne, le témoin vote pour le second. En conséquence, deux serveurs fonctionnent dans le deuxième centre de données : l'un exécute un maître et l'adresse IP flottante du maître pointe vers lui (pour recevoir les requêtes de lecture-écriture) ; et sur le deuxième serveur, il y a un esclave exécuté avec une réplication synchrone, et l'une des adresses IP flottantes de l'esclave pointe vers lui (pour les requêtes en lecture seule).

La première chose à noter est que toutes les adresses IP flottantes esclaves ne seront pas des travailleurs, mais une seule. Et pour travailler correctement avec cela, il faudra que proxy SQL redirigé toutes les requêtes vers la seule adresse IP flottante restante ; et si proxy SQL non, alors vous pouvez lister tous les esclaves IP flottants séparés par des virgules dans l'URL de connexion. Dans ce cas, avec libpq la connexion se fera à la première IP active, cela se fait dans le système de test automatique. Peut-être que dans d'autres bibliothèques, par exemple JDBC, cela ne fonctionnera pas et est nécessaire proxy SQL. Ceci est dû au fait qu'il est interdit d'augmenter simultanément les adresses IP flottantes des esclaves sur un serveur, de sorte qu'elles soient réparties uniformément entre les serveurs esclaves s'il y en a plusieurs en cours d'exécution.

Deuxièmement : même en cas de panne du centre de données, la réplication synchrone sera maintenue. Et même si une panne secondaire survient, c'est-à-dire si l'un des deux serveurs du centre de données restant tombe en panne, le cluster, même s'il cesse de fournir des services, conservera toujours les informations sur toutes les transactions validées pour lesquelles il a donné confirmation de la validation. (il n'y aura aucune information de perte en cas de panne secondaire).

Tuchanka3 (3 centres de données)

structure

Il s'agit d'un cluster pour une situation dans laquelle il existe trois centres de données entièrement fonctionnels, chacun disposant d'un serveur de base de données entièrement fonctionnel. Dans ce cas périphérique de quorum pas besoin. Un centre de données est géré par un maître, les deux autres sont gérés par des esclaves. La réplication est synchrone, tapez ANY (slave1, slave2), c'est-à-dire que le client recevra une confirmation de validation lorsque l'un des esclaves sera le premier à répondre qu'il a accepté la validation. Les ressources sont indiquées par une IP flottante pour le maître et deux pour les esclaves. Contrairement à Tuchanka4, les trois IP flottantes sont tolérantes aux pannes. Pour équilibrer les requêtes SQL en lecture seule, vous pouvez utiliser proxy SQL (avec tolérance de panne séparée), ou attribuez une adresse IP flottante esclave à la moitié des clients et l'autre moitié à la seconde.

Tuchanka3 refus

Si l'un des centres de données tombe en panne, il en reste deux. Dans l'un, l'IP maître et l'IP flottante du maître sont levées, dans le second - l'IP esclave et les deux IP flottantes esclaves (l'instance doit avoir une double réserve de ressources afin d'accepter toutes les connexions des deux IP flottantes esclaves). Réplication synchrone entre maîtres et esclaves. De plus, le cluster enregistrera les informations sur les transactions validées et confirmées (il n'y aura aucune perte d'informations) en cas de destruction de deux centres de données (s'ils ne sont pas détruits simultanément).

J'ai décidé de ne pas inclure de description détaillée de la structure des fichiers et de leur déploiement. Quiconque veut jouer peut tout lire dans le README. Je ne fais que fournir une description des tests automatisés.

Système de test automatique

Pour tester la tolérance aux pannes des clusters en simulant diverses pannes, un système de tests automatiques a été créé. Lancé par script test/failure. Le script peut prendre en paramètres le nombre de clusters que vous souhaitez tester. Par exemple cette commande :

test/failure 2 3

ne testera que les deuxième et troisième clusters. Si les paramètres ne sont pas spécifiés, tous les clusters seront testés. Tous les clusters sont testés en parallèle et le résultat est affiché dans le panneau tmux. Tmux utilise un serveur tmux dédié, de sorte que le script peut être exécuté sous tmux par défaut, ce qui donne lieu à un tmux imbriqué. Je recommande d'utiliser le terminal dans une grande fenêtre et avec une petite police. Avant le début des tests, toutes les machines virtuelles sont restaurées vers un instantané au moment où le script se termine setup.

Le terminal est divisé en colonnes selon le nombre de clusters testés ; par défaut (dans la capture d'écran) il y en a quatre. Je décrirai le contenu des colonnes en utilisant l'exemple de Tuchanka2. Les panneaux de la capture d'écran sont numérotés :

1. Les statistiques des tests sont affichées ici. Colonnes:
   • échec — le nom du test (fonction dans le script) qui émule la panne.
   • réaction — temps moyen arithmétique en secondes pendant lequel le cluster a récupéré sa fonctionnalité. Elle est mesurée depuis le début du script émulant une panne jusqu'au moment où le cluster rétablit ses fonctionnalités et est capable de continuer à fournir des services. Si le temps est très court, par exemple six secondes (cela se produit dans les clusters avec plusieurs esclaves (Tuchanka3 et Tuchanka4)), cela signifie que le défaut provenait de l'esclave asynchrone et n'a en aucun cas affecté les performances ; il n'y a eu aucun commutateurs d’état du cluster.
   • déviation — montre la répartition (précision) de la valeur réaction en utilisant la méthode de l’écart type.
   • compter — combien de fois ce test a été effectué.
2. Un court journal vous permet d'évaluer ce que fait actuellement le cluster. Le numéro d'itération (test), l'horodatage et le nom de l'opération sont affichés. Une exécution trop longue (> 5 minutes) indique un problème.
3. Cœur (cœur) - heure actuelle. Pour une évaluation visuelle des performances maîtres L'heure actuelle est constamment écrite dans sa table à l'aide du maître IP float. En cas de succès, le résultat est affiché dans ce panneau.
4. battre (impulsion) - "heure actuelle", qui a été précédemment enregistrée par le script Cœur à maîtriser, lisez maintenant à partir de esclave via son IP flottante. Vous permet d'évaluer visuellement les performances de l'esclave et de la réplication. Dans Tuchanka1, il n'y a pas d'esclaves avec une IP flottante (aucun esclave fournissant des services), mais il y a deux instances (DB), donc cela ne sera pas affiché ici battreEt Cœur deuxième instance.
5. Surveillance de la santé du cluster à l'aide de l'utilitaire pcs mon. Affiche la structure, la répartition des ressources entre les nœuds et d'autres informations utiles.
6. La surveillance du système de chaque machine virtuelle du cluster est affichée ici. Il peut y avoir davantage de panneaux de ce type en fonction du nombre de machines virtuelles dont dispose le cluster. Deux graphiques Charge du processeur (les machines virtuelles ont deux processeurs), nom de la machine virtuelle, Charge du système (appelé Load Average car il est moyenné sur 5, 10 et 15 minutes), traite les données et l'allocation de mémoire.
7. Trace du script effectuant les tests. En cas de dysfonctionnement - une interruption soudaine du fonctionnement ou un cycle d'attente sans fin - vous pouvez voir ici la raison de ce comportement.

Les tests sont effectués en deux étapes. Tout d'abord, le script effectue tous les types de tests, sélectionnant au hasard une machine virtuelle à laquelle appliquer ce test. Ensuite, un cycle sans fin de tests est effectué, les machines virtuelles et le défaut sont sélectionnés aléatoirement à chaque fois. L'arrêt soudain du script de test (panneau inférieur) ou une boucle sans fin d'attente de quelque chose (> 5 minutes de temps d'exécution pour une opération, cela peut être vu dans la trace) indique que certains des tests sur ce cluster ont échoué.

Chaque test comprend les opérations suivantes :

1. Lancez une fonction qui émule un défaut.
2. Prêt(e) ? — en attente de la restauration du cluster (lorsque tous les services sont fournis).
3. Affiche le délai d'expiration de la récupération du cluster (réaction).
4. Fixer — le cluster est en cours de « réparation ». Après quoi, il devrait revenir à un état pleinement opérationnel et être prêt pour le prochain dysfonctionnement.

Voici une liste de tests avec une description de ce qu'ils font :

• Fourchette: Crée "Mémoire insuffisante" à l'aide d'une bombe fork.
• En dehors de l'espace: Le disque dur est plein. Mais le test est plutôt symbolique : avec la charge insignifiante créée lors du test, PostgreSQL n'échoue généralement pas lorsque le disque dur est plein.
• Postgres-KILL: tue PostgreSQL avec la commande killall -KILL postgres.
• Postgres-STOP: bloque la commande PostgreSQL killall -STOP postgres.
• Poweroff: « met hors tension » la machine virtuelle avec la commande VBoxManage controlvm "виртуалка" poweroff.
• Réinitialiser: surcharge la machine virtuelle avec la commande VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: suspend le démon SBD avec la commande killall -STOP sbd.
• Arrêt: envoie une commande à la machine virtuelle via SSH systemctl poweroff, le système s'arrête normalement.
• séparer: isolation réseau, commande VBoxManage controlvm "виртуалка" setlinkstate1 off.

Terminer les tests en utilisant la commande tmux standard "kill-window" Ctrl-b &, ou la commande "detach-client" Ctrl-bd: à ce stade, les tests se terminent, tmux se ferme, les machines virtuelles sont désactivées.

Problèmes identifiés lors des tests

• Actuellement chien de garde démon sbd travaille à arrêter les démons observés, mais pas à les geler. Et, par conséquent, des défauts qui conduisent uniquement au gel Corosynchrone и Pacemaker, mais pas suspendu sbd... Pour chèque Corosynchrone déjà PR # 83 (sur GitHub à sbd), accepté dans le fil de discussion maître. Ils ont promis (dans le PR#83) qu'il y aurait quelque chose de similaire pour Pacemaker, j'espère que d'ici RedHat 8 ça ira. Mais de tels « dysfonctionnements » sont spéculatifs et peuvent être facilement simulés artificiellement en utilisant, par exemple, killall -STOP corosync, mais ne se rencontrent jamais dans la vraie vie.

• У Pacemaker en version pour 7 CentOS mal réglé sync_timeout у périphérique de quorum, par conséquent si un nœud tombe en panne, avec une certaine probabilité, le deuxième nœud redémarre également, vers lequel le maître était censé se déplacer. Guéri par l'élargissement sync_timeout у périphérique de quorum pendant le déploiement (dans le script setup/setup1). Cet amendement n'a pas été accepté par les développeurs Pacemaker, au lieu de cela, ils ont promis de repenser l'infrastructure de telle manière (dans un avenir indéterminé) que ce délai d'attente serait calculé automatiquement.

• Si la configuration de la base de données spécifie que LC_MESSAGES (messages texte) Unicode peut être utilisé, par ex. ru_RU.UTF-8, puis au démarrage postgres dans un environnement où les paramètres régionaux ne sont pas UTF-8, disons dans un environnement vide (ici stimulateur cardiaque+pgsqlms(paf) court postgres) puis le journal contiendra des points d'interrogation au lieu de lettres UTF-8. Les développeurs de PostgreSQL ne se sont pas mis d'accord sur la marche à suivre dans ce cas. Ça coûte, il faut installer LC_MESSAGES=en_US.UTF-8 lors de la configuration (création) d’une instance de base de données.

• Si wal_receiver_timeout est défini (par défaut il est de 60 s), alors pendant le test PostgreSQL-STOP sur le maître dans les clusters tuchanka3 et tuchanka4 la réplication ne se reconnecte pas au nouveau maître. La réplication y est synchrone, donc non seulement l'esclave s'arrête, mais aussi le nouveau maître. Contourne le problème en définissant wal_receiver_timeout=0 lors de la configuration de PostgreSQL.

• Parfois, j'ai observé des blocages de réplication dans PostgreSQL lors du test ForkBomb (débordement de mémoire). Après ForkBomb, il arrive parfois que les esclaves ne se reconnectent pas au nouveau maître. Je n'ai rencontré cela que dans les clusters tuchanka3 et tuchanka4, où le maître s'est figé en raison d'une réplication synchrone. Le problème a disparu tout seul après un certain temps (environ deux heures). Des recherches supplémentaires sont nécessaires pour corriger cela. Les symptômes sont similaires à ceux du bug précédent, provoqué par une raison différente, mais avec les mêmes conséquences.

Photo de Krogan prise depuis Deviant Art avec l'autorisation de l'auteur :

Source: habr.com