Haute disponibilité PostgreSQL avec SafeKit : installez le module postgresql.safe pour le basculement

Guide d’installation rapide haute disponibilité pour PostgreSQL

Ce guide explique comment configurer un cluster miroir pour PostgreSQL à l’aide de SafeKit, garantissant un basculement automatique et une réplication synchrone sans avoir besoin de stockage partagé.

Pour obtenir de l’aide, vous pouvez utiliser SafeKit IA 🤖.

1. Aperçu

• Architecture : Utilise un système à deux nœuds (Primaire/Secondaire).
• Protection des données : Implémente une réplication synchrone en temps réel pour zéro perte de données (RPO=0).

2.Installation

• Logiciel : Installez le moteur SafeKit sur les deux serveurs.
• Module : Téléchargez le préconfiguré postgresql.safe.safe module applicatif.

3.Configuration

• Console Web : Configurez les dossiers spécifiques contenant les fichiers PostgreSQL.
• Surveillance : Commencez à surveiller et à protéger l’application PostgreSQL.

Limites de la haute disponibilité SafeKit

Présentation de la solution SafeKit / PostgreSQL

La solution est décrite ici : 💡La haute disponibilité PostgreSQL la plus simple : réplication synchrone à 2 nœuds et basculement.

Installation de la solution SafeKit / PostgreSQL sous Windows et Linux (postgresql.safe)

Conditions préalables

• Vous avez besoin de PostgreSQL installé sur 2 nœuds (machines virtuelles ou serveurs physiques).

Installation du package sur Windows

• Téléchargez et installez la version gratuite de SafeKit sur 2 nœuds Windows.
  Remarque : la version gratuite inclut toutes les fonctionnalités de SafeKit. À la fin de la période d’essai, vous pouvez activer les clés de licence permanentes sans désinstaller le package.
• Une fois l’installation du package terminée, sélectionnez Set console credentials and firewall rules now et configurez un mot de passe pour le admin utilisateur de la console SafeKit.
  Définissez le même mot de passe sur tous les nœuds.
• Exclure des analyses antivirus C:/safekit/ (le répertoire d’installation par défaut) et tous les dossiers répliqués que vous allez définir.
  Les antivirus peuvent être confrontés à des problèmes de détection avec SafeKit en raison de son intégration étroite avec le système d’exploitation, de ses mécanismes IP virtuels, de sa réplication en temps réel et du redémarrage des services critiques.

Télécharger SafeKit (Windows) >

Installation des modules sur Windows

• Téléchargez le module postgresql.safe. Le module est gratuit. Il contient les fichiers userconfig.xml et les scripts de redémarrage.
• Mettre postgresql.safe sous C:/safekit/Application_Modules/generic.

Télécharger postgresql.safe (Windows) >

Installation du package sur Linux

• Installez la version gratuite de SafeKit sur 2 nœuds Linux. Remarque : l’essai gratuit inclut toutes les fonctionnalités de SafeKit. À la fin de la période d’essai, vous pouvez activer les clés de licence permanentes sans désinstaller le package.
• Après le téléchargement du package safekit_xx.bin, exécutez-le pour extraire le script rpm et safekitinstall, puis exécutez le safekitinstall scénario
• Réponse oui à la configuration automatique du pare-feu
• Définir le mot de passe pour la console Web et l’utilisateur par défaut admin. Définissez le même mot de passe sur tous les nœuds.

Télécharger SafeKit (Linux) >

Installation des modules sur Linux

• Téléchargez le module postgresql.safe.
  Le module est gratuit. Il contient les fichiers userconfig.xml et les scripts de redémarrage.
• Mettre postgresql.safe sous /opt/safekit/Application_Modules/generic/.

Télécharger postgresql.safe (Linux) >

Configuration pas à pas de la solution SafeKit / PostgreSQL

Conditions préalables

• Application PostgreSQL installée sur 2 nœuds.
• Total des données répliquées limité à quelques téraoctets ; au-delà, le temps de resynchronisation devient important.
• Interconnexion minimale de 1 Gbit/s entre les nœuds (10 Gbit/s recommandés pour une resynchronisation plus rapide).
• Le basculement IP nécessite les deux nœuds sur le même LAN ou le même LAN étendu (L2) — les réseaux L3 routés ne sont pas pris en charge (sauf avec les équilibreurs de charge cloud 🛠️ ).

1. Lancez la console SafeKit

• Lancez la console Web dans un navigateur sur un nœud de cluster en vous connectant à http://localhost:9010.
• Saisissez admin comme nom d’utilisateur et le mot de passe défini lors de l’installation.

Vous pouvez également exécuter la console dans un navigateur sur un poste de travail externe au cluster.

⚠️ La configuration de SafeKit se fait sur les deux nœuds depuis un seul navigateur.

ℹ️ Pour sécuriser la console web, voir 🛠️ 11. Sécurisation du service Web SafeKit dans le Guide de l’utilisateur.

2. Configurer les adresses des nœuds

• Entrez les adresses des nœuds IP, appuyez sur Tab key pour vérifier la connectivité et remplir les noms des nœuds. Si node1 ou node2 a une couleur rouge, vérifiez la connectivité du navigateur aux deux nœuds et vérifiez le pare-feu sur les deux nœuds pour 🛠️ troubleshooting.
• Cliquez ensuite sur Save and apply pour enregistrer la configuration.
• Vérifiez le message Success ✅ sur les deux nœuds.
• Si la configuration Failure ❌ se produit sur un nœud, ouvrez l’accordéon ▼ pour ce nœud et consultez les messages. Notez que vous pouvez utiliser le SafeKit AI 🤖 pour obtenir de l’aide.

ℹ️ Si vous le souhaitez, vous pouvez ajouter un nouveau LAN and nodes (premier ➕) pour créer un deuxième heartbeat et un réseau de réplication dédié.

ℹ️ Si vous cliquez sur Advanced configuration, le fichier cluster.xml s’affiche. Ce fichier est automatiquement renseigné par la console et déployé sur les nœuds.

3. Sélectionnez un module

• Dans New module, cliquez sur le module postgresql.safe.

ℹ️ Dans le bandeau bleu en haut, 🛜 node1 représente le nœud de connexion de la console. Ce nœud relaie les requêtes vers node2 lorsque cela est nécessaire.

ℹ️ La console recherche xxx.safe dans le répertoire Application_Modules/generic/ sur le nœud de connexion (node1) si vous y avez placé un module lors de l’installation.

4. Configurez le module

• Dans Module startup at boot, choisissez un démarrage automatique du module au démarrage sans délai.
• Dans Macros / SERVICES, saisissez les noms de services de votre application, dans l’ordre de démarrage, séparés par des virgules. Voir cette capture d’écran pour un exemple visuel des services Milestone XProtect 🖼️.
• Dans Heartbeat networks, vous devez disposer d’un réseau à pulsation unique sur lequel la réplication est effectuée. Si vous avez ajouté un LAN privé à l’étape 2, vous pouvez configurer deux pulsations avec le flux de réplication sur le LAN privé.
• Dans Virtual IP addresses, entrez une adresse virtuelle IP. Une adresse virtuelle IP est une adresse IP standard dans le même réseau IP (même sous-réseau) que les adresses IP des deux nœuds.
  Les clients d’application doivent être configurés avec l’adresse virtuelle IP (ou le nom DNS associé à l’adresse virtuelle IP).
  L’adresse virtuelle IP est automatiquement commutée en cas de panne.
• Dans Replicated directories, définissez les chemins des répertoires à répliquer. Vérifiez qu’ils existent sur les deux nœuds et contiennent les données de l’application.
  La réplication des données et des journaux est essentielle pour une base de données.
  Vous pouvez créer des répertoires répliqués supplémentaires selon vos besoins.
  Voir cette capture d’écran pour un exemple visuel de réplication Milestone XProtect SQL 🖼️.
• Dans Checkers, vous pourrez configurer des vérificateurs si nécessaire, tels que la surveillance des processus, des vérificateurs personnalisés, TCP, un ping ou des vérificateurs split-brain.
  Par exemple, si un nom de processus est affiché dans Monitored processes/services, il sera surveillé avec une action de redémarrage en cas d’échec. La configuration d’un mauvais nom de processus entraînera l’arrêt du module juste après son démarrage.

ℹ️ Si vous cliquez sur Advanced configuration, le fichier userconfig.xml s’affiche. Ce fichier est automatiquement renseigné par la console et déployé sur les nœuds avec les scripts de redémarrage.

ℹ️ Dans un déploiement cloud, vous n’avez pas besoin de configurer une adresse virtuelle IP dans SafeKit. Le IP virtuel est géré au niveau de l’équilibreur de charge cloud 🛠️ .

ℹ️ Lorsque vous appliquez la configuration SafeKit, le startup type des services est automatiquement défini sur Manual dans les services Windows. Cela garantit que les services ne démarrent pas automatiquement au démarrage du système, mais uniquement au démarrage du module lui-même (il en va de même sur Linux).

5. Modifier les scripts (facultatif)

• Cette étape est facultative et peut être ignorée dans la plupart des cas, car les scripts de redémarrage sont déjà préconfigurés pour redémarrer les services définis à l’étape précédente.
• Alors, cliquez directement sur Next step.
• start_prim.ps1 démarre tous les services dans l’ordre spécifié dans la liste SERVICES, tandis que stop_prim.ps1 arrête tous les services dans l’ordre inverse.
• De plus, start_prim.ps1 vérifie le démarrage de chaque service et arrête le module si un service ne démarre pas correctement.

6. Cryptage des communications (facultatif)

• Conservez le cryptage des communications entre les nœuds.

7. Enregistrez et postulez

• Save and apply la configuration et les scripts sur les deux nœuds.

8. Vérifiez la configuration réussie

• Vérifiez le message Success ✅ sur les deux nœuds et cliquez sur Monitor modules.
• Si la configuration Failure ❌ se produit sur un nœud, ouvrez l’accordéon ▼ pour ce nœud et consultez les messages. Notez que vous pouvez utiliser le SafeKit AI 🤖 pour obtenir de l’aide.

⚠️ Sur Linux, vous pouvez obtenir une erreur à cette étape si les répertoires répliqués sont des points de montage.🛠️ Voir SK-0030 pour résoudre le problème.

9. Démarrez le nœud avec des données à jour

• Si le nœud 1 possède les répertoires répliqués à jour, sélectionnez-le et ⋯ Force start ▶ As primary.

Lorsque le nœud 2 sera démarré, toutes les données seront copiées du nœud 1 vers le nœud 2.

⚠️ Si vous faites le mauvais choix, vous courez le risque de synchroniser des données obsolètes sur les deux nœuds.

⚠️ Il est également supposé que l’application PostgreSQL est arrêtée sur le nœud 1 afin que SafeKit installe les mécanismes de réplication puis démarre l’application dans le script start_prim.

⚠️ Utilisez Start pour les démarrages ultérieurs : SafeKit conserve le serveur le plus à jour. Le démarrage du As primary est un démarrage particulier dès la première fois ou lors d’opérations exceptionnelles.

10. Attendez la transition vers ALONE (vert)

• Le nœud 1 doit atteindre l’état ALONE (vert), ce qui signifie que le IP virtuel est défini et que le script start_prim a été exécuté sur le nœud 1.

⚠️ Si ALONE (vert) n’est pas atteint ou si l’application n’est pas démarrée, analysez pourquoi avec le log du module 🖼️ du nœud 1.

• Cliquez sur l’icône 🔍 log de node1 pour ouvrir le journal du module et rechercher des messages d’erreur tels qu’un vérificateur détectant une erreur et arrêtant le module.
• Cliquez sur start_prim dans le log : les messages de sortie du script s’affichent à droite et des erreurs peuvent être détectées comme par exemple un service mal démarré.
• Utilisez le SafeKit AI 🤖 pour obtenir de l’aide concernant les messages de journal.

⚠️ Si le cluster est dans l’état WAIT (red) not uptodate, STOP (red) not uptodate, arrêtez le nœud WAIT et forcez son démarrage en tant que principal 🖼️.

11. Démarrer le nœud 2

• ⋯ Start nœud 2 avec son menu contextuel.
• Attendez l’état SECOND (vert).

ℹ️ Le nœud 2 reste dans l’état SECOND (orange) lors de la resynchronisation des répertoires répliqués (copie du nœud 1 vers le nœud 2).

• Cela peut prendre un certain temps en fonction de la taille des fichiers à resynchroniser dans les répertoires répliqués et de la bande passante du réseau.
• Pour voir la progression de la copie, consultez le journal du module 🖼️ et les ressources de réplication 🖼️ du nœud 2. Utilisez le SafeKit AI 🤖 pour obtenir de l’aide sur les messages du journal.

12. Vérifiez que le cluster est opérationnel

• Vérifiez que le cluster est vert/vert avec les services PostgreSQL exécutés sur le nœud PRIM et non exécutés sur le nœud SECOND.

Seules les modifications contenues dans les fichiers sont répliquées en temps réel dans cet état.

⚠️ Les composants clients des services PostgreSQL doivent être configurés avec l’adresse virtuelle IP. La configuration peut se faire avec un nom DNS (si un nom DNS a été créé et associé à l’adresse virtuelle IP).

13. Tests

• Arrêtez le nœud PRIM en faisant défiler son menu contextuel et en cliquant sur Stop.
• Vérifiez qu’il existe un basculement sur le nœud SECOND qui doit devenir ALONE (vert).
• Et avec Microsoft Management Console (MMC) sur Windows ou avec des lignes de commande sur Linux, vérifiez le basculement des services PostgreSQL (arrêtés sur le nœud 1 dans le script stop_prim et démarrés sur le nœud 2 dans le script start_prim).

⚠️ Si ALONE (vert) n’est pas atteint sur node2 ou si l’application n’est pas démarrée, analysez pourquoi avec le log du module 🖼️ du nœud 2.

• Cliquez sur l’icône 🔍 log de node2 pour ouvrir le journal du module et rechercher des messages d’erreur tels qu’un vérificateur détectant une erreur et arrêtant le module.
• Cliquez sur start_prim dans le log : les messages de sortie du script s’affichent à droite et des erreurs peuvent être détectées comme par exemple un service mal démarré.
• Utilisez le SafeKit AI 🤖 pour obtenir de l’aide concernant les messages de journal.

⚠️

• Si tout va bien, lancez un démarrage sur node1, qui resynchronisera les répertoires répliqués depuis node2.
• Si les choses tournent mal, arrêtez node2 et forcez le démarrage en tant que principal 🖼️ de node1, qui redémarrera avec ses données localement saines au moment de l’arrêt.

ℹ️ Trouvez plus de détails, ainsi que des vidéos, dans la formation en ligne SafeKit.

14. Assistance

• Pour obtenir de l’aide, prenez 2 SafeKit Snapshots (2 fichiers .zip), un pour chaque nœud.

ℹ️ Plus d’informations sur le support ici.

Démonstration de la solution miroir SafeKit

Vidéo SafeKit : Clustering au niveau applicatif (8:47)

Dans cette vidéo, découvrez comment SafeKit implémente un cluster HA miroir sans la complexité d’un SAN. Bien que cette démonstration utilise Microsoft SQL Server, la solution fonctionne de manière identique pour d’autres bases de données et applications.

Chapitres

1. 🎬 2 nœuds avec SQL Server (0:32)
2. 🎬 Configurer le cluster et le module mirror.safe (3:58)
3. 🎬 Démarrer et tester la réplication SQL, la migration, le basculement sur panne (4:17)

Mise en œuvre étape par étape

• 🛠️ Lire le guide de configuration d’un cluster miroir sur Windows
• 🛠️ Lire le guide de configuration d’un cluster miroir sur Linux

🔍 Hub de navigation SafeKit Haute Disponibilité

Explorez SafeKit : fonctionnalités, vidéos techniques, documentation et essai gratuit