Comment créer une configuration haute disponibilité avec Corosync, pacemaker et adresses IP flottantes sous Ubuntu 14.04

introduction

Ce didacticiel explique comment utiliser Corosync et Pacemaker avec une adresse IP flottante pour créer une infrastructure de serveur haute disponibilité sur DigitalOcean.

Corosync est un programme open source qui fournit aux serveurs clients des fonctionnalités d’appartenance à un cluster et de messagerie, souvent appelées la couche * messagerie *. Pacemaker est un gestionnaire de ressources en cluster open source (CRM), un système qui coordonne les ressources et les services gérés et rendus hautement disponibles par un cluster. Corosync permet essentiellement aux serveurs de communiquer en tant que cluster, tandis que Pacemaker offre la possibilité de contrôler le comportement du cluster.

Goal

Une fois l’opération terminée, la configuration HA comprendra deux serveurs Ubuntu 14.04 dans une configuration active / passive. Pour ce faire, il vous suffit de pointer une adresse IP flottante (par laquelle les utilisateurs accéderont à votre service Web), puis de pointer vers le serveur principal (actif) à moins qu’une défaillance ne soit détectée. Si Pacemaker détecte que le serveur principal est indisponible, le serveur secondaire (passif) exécute automatiquement un script qui réaffectera l’IP flottante à lui-même via l’API DigitalOcean. Ainsi, le trafic réseau ultérieur vers l’IP flottante sera dirigé vers votre serveur secondaire, qui agira en tant que serveur actif et traitera le trafic entrant.

Ce diagramme illustre le concept de la configuration décrite:

image: https: //assets.digitalocean.com/articles/high_availability/ha-diagram-animated.gif [Diagramme actif / passif]

Pour atteindre cet objectif, nous allons suivre les étapes suivantes:

  • Créez 2 gouttelettes qui recevront du trafic

  • Créer une adresse IP flottante et l’assigner à l’une des gouttelettes

  • Installer et configurer Corosync

  • Installer et configurer Pacemaker

  • Configurer une ressource de cluster de réaffectation d’adresse IP flottante

  • Tester le basculement

  • Configurer la ressource de cluster Nginx

Conditions préalables

Pour automatiser la réaffectation d’adresses IP flottantes, nous devons utiliser l’API DigitalOcean. Cela signifie que vous devez générer un jeton d’accès personnel (PAT), qui est un jeton d’API pouvant être utilisé pour s’authentifier sur votre compte DigitalOcean, avec read et write access en suivant les instructions https://www.digitalocean.com/community. / tutorials / comment-utiliser-le-digitalocean-api-v2 # comment générer un jeton d’accès personnel [Comment générer un jeton d’accès personnel] du didacticiel de l’API. Votre PAT sera utilisé dans un script qui sera ajouté aux deux serveurs de votre cluster. Veillez donc à le conserver dans un endroit sûr, car il permet un accès complet à votre compte DigitalOcean, à des fins de référence.

En plus de l’API, ce didacticiel utilise les fonctionnalités DigitalOcean suivantes:

Veuillez lire les tutoriels liés si vous voulez en savoir plus à leur sujet.

Créer des gouttelettes

La première étape consiste à créer deux droplets Ubuntu, avec mise en réseau privée activée, dans le même centre de données, qui serviront de serveurs primaire et secondaire décrits ci-dessus. Dans notre exemple de configuration, nous les nommerons «primaire» et «secondaire» pour faciliter les recherches. Nous allons installer Nginx sur les deux gouttelettes et remplacer leurs pages d’index par des informations les identifiant de manière unique. Cela nous permettra de démontrer simplement que la configuration de la haute disponibilité fonctionne. Pour une configuration réelle, vos serveurs doivent exécuter le serveur Web ou l’équilibreur de charge de votre choix, tel que Nginx ou HAProxy.

Créez deux gouttelettes Ubuntu 14.04, * primaire * et * secondaire *. Si vous souhaitez suivre l’exemple de configuration, utilisez ce script bash en tant que données utilisateur:

Exemple de données utilisateur

#!/bin/bash

apt-get -y update
apt-get -y install nginx
export HOSTNAME=$(curl -s http://169.254.169.254/metadata/v1/hostname)
export PUBLIC_IPV4=$(curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
echo Droplet: $HOSTNAME, IP Address: $PUBLIC_IPV4 > /usr/share/nginx/html/index.html

Ces données utilisateur installeront Nginx et remplaceront le contenu de + index.html + par le nom d’hôte et l’adresse IP du droplet (en référençant le service de métadonnées). Accéder à Droplet via son adresse IP publique affichera une page Web de base avec le nom d’hôte et l’adresse IP de Droplet, ce qui sera utile pour tester le point cible de Droplet à l’adresse IP flottante.

Créer une adresse IP flottante

Dans le Panneau de configuration DigitalOcean, cliquez sur * Réseau * dans le menu supérieur, puis sur * IP flottantes * dans le menu latéral.

image: https: //assets.digitalocean.com/site/ControlPanel/fip_no_floating_ips.png [Aucune adresse IP flottante]

Attribuez une adresse IP flottante à votre droplet * principal *, puis cliquez sur le bouton * Attribuer une adresse IP flottante *.

Une fois l’adresse IP flottante attribuée, notez son adresse IP. Vérifiez que vous pouvez atteindre le Droplet auquel il a été affecté en visitant l’adresse IP flottante dans un navigateur Web.

http://

Vous devriez voir la page d’index de votre Droplet principal.

Configurer DNS (facultatif)

Si vous souhaitez pouvoir accéder à votre configuration haute disponibilité via un nom de domaine, créez un enregistrement * A * dans votre DNS qui pointe votre domaine vers votre adresse IP flottante. Si votre domaine utilise les serveurs de noms de DigitalOcean, suivez https://www.digitalocean.com/community/tutorials/how-to-set-up-a-host-name-with-digitalocean#step-three%E2%80%94configure. -your-domain [étape trois] du tutoriel Comment configurer un nom d’hôte avec DigitalOcean. Une fois que cela se propage, vous pouvez accéder à votre serveur actif via le nom de domaine.

L’exemple de nom de domaine que nous allons utiliser est + exemple.com +. Si vous n’avez pas de nom de domaine à utiliser pour le moment, vous utiliserez plutôt l’adresse IP flottante pour accéder à votre configuration.

Configurer la synchronisation horaire

Chaque fois que plusieurs serveurs communiquent entre eux, en particulier avec le logiciel de mise en cluster, il est important de s’assurer que leurs horloges sont synchronisées. Nous utiliserons le protocole NTP (Network Time Protocol) pour synchroniser nos serveurs.

Sur * les deux serveurs *, utilisez cette commande pour ouvrir un sélecteur de fuseau horaire:

sudo dpkg-reconfigure tzdata

Sélectionnez votre fuseau horaire souhaité. Par exemple, nous choisirons + America / New_York +.

Ensuite, mettez à jour apt-get:

sudo apt-get update

Puis installez le paquetage + ntp + avec cette commande;

sudo apt-get -y install ntp

Vos horloges de serveur doivent maintenant être synchronisées via NTP. Pour en savoir plus sur le protocole NTP, consultez ce tutoriel: https://www.digitalocean.com/community/tutorials/additional-recommended-steps-for-new-ubuntu-14-04-servers#configure-timezones-and -network -time-protocole-synchronization [Configurer les fuseaux horaires et la synchronisation de protocole de temps réseau].

Configurer le pare-feu

Corosync utilise le transport UDP entre les ports + 5404 + et + 5406 +. Si vous utilisez un pare-feu, assurez-vous que la communication sur ces ports est autorisée entre les serveurs.

Par exemple, si vous utilisez + iptables +, vous pouvez autoriser le trafic sur ces ports et + eth1 + (l’interface de réseau privé) avec les commandes suivantes:

sudo iptables -A INPUT  -i eth1 -p udp -m multiport --dports 5404,5405,5406 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT  -o eth1 -p udp -m multiport --sports 5404,5405,5406 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Il est conseillé d’utiliser des règles de pare-feu plus restrictives que l’exemple fourni.

Installer Corosync et Pacemaker

Sur * les deux serveurs *, installez Corosync et Pacemaker à l’aide d’apt-get:

sudo apt-get install pacemaker

Notez que Corosync est installé en tant que dépendance du package Pacemaker.

Corosync et Pacemaker sont maintenant installés, mais ils doivent être configurés avant de pouvoir faire quoi que ce soit d’utile.

Configurer Corosync

Corosync doit être configuré pour que nos serveurs puissent communiquer en tant que cluster.

Créer une clé d’autorisation de cluster

Afin de permettre aux nœuds de rejoindre un cluster, Corosync exige que chaque nœud possède une clé d’autorisation de cluster identique.

Sur le serveur * primaire *, installez le paquetage + haveged +:

sudo apt-get install haveged

Ce progiciel nous permet d’augmenter facilement la quantité d’entropie sur notre serveur, qui est requise par le script + corosync-keygen +.

Sur le serveur * primaire *, exécutez le script + corosync-keygen +:

sudo corosync-keygen

Cela générera une clé d’autorisation de cluster de 128 octets et l’écrira dans + / etc / corosync / authkey +.

Maintenant que nous n’avons plus besoin du paquet + haveged +, supprimons-le du serveur * primaire *:

sudo apt-get remove --purge haveged
sudo apt-get clean

Sur le serveur * primaire *, copiez la clé + authkey + sur le serveur secondaire:

sudo scp /etc/corosync/authkey @:/tmp

Sur le serveur * secondaire *, déplacez le fichier + authkey + à l’emplacement approprié et limitez ses autorisations à la racine:

sudo mv /tmp/authkey /etc/corosync
sudo chown root: /etc/corosync/authkey
sudo chmod 400 /etc/corosync/authkey

Les deux serveurs doivent maintenant avoir une clé d’autorisation identique dans le fichier + / etc / corosync / authkey +.

Configurer le cluster Corosync

Pour que notre cluster souhaité soit opérationnel, nous devons configurer ces

Sur * les deux serveurs *, ouvrez le fichier + corosync.conf + à modifier dans votre éditeur favori (nous utiliserons + vi +):

sudo vi /etc/corosync/corosync.conf

Voici un fichier de configuration Corosync qui permettra à vos serveurs de communiquer en tant que cluster. Assurez-vous de remplacer les pièces surlignées par les valeurs appropriées. + bindnetaddr + doit être défini sur l’adresse IP privée du serveur sur lequel vous travaillez actuellement. Les deux autres éléments en surbrillance doivent correspondre à l’adresse IP privée du serveur indiqué. À l’exception de + bindnetaddr +, le fichier doit être identique sur les deux serveurs.

Remplacez le contenu de + corosync.conf + par cette configuration, avec les modifications spécifiques à votre environnement:

/etc/corosync/corosync.conf

totem {
 version: 2
 cluster_name: lbcluster
 transport: udpu
 interface {
   ringnumber: 0
   bindnetaddr:
   broadcast: yes
   mcastport: 5405
 }
}

quorum {
 provider: corosync_votequorum
 two_node: 1
}

nodelist {
 node {
   ring0_addr:
   name: primary
   nodeid: 1
 }
 node {
   ring0_addr:
   name: secondary
   nodeid: 2
 }
}

logging {
 to_logfile: yes
 logfile: /var/log/corosync/corosync.log
 to_syslog: yes
 timestamp: on
}

La section * totem * (lignes 1 à 11), qui fait référence au protocole Totem utilisé par Corosync pour l’appartenance à un cluster, spécifie comment les membres du cluster doivent communiquer entre eux. Dans notre configuration, les paramètres importants sont + transport: udpu + (spécifie le mode unicast) et + bindnetaddr + (spécifie l’adresse réseau à laquelle Corosync doit se lier).

La section * quorum * (lignes 13 à 16) spécifie qu’il s’agit d’un cluster à deux nœuds, de sorte qu’un seul nœud est requis pour le quorum (+ two_node: 1 +). Il s’agit d’une solution de contournement du fait que l’atteinte d’un quorum nécessite au moins trois nœuds dans un cluster. Ce paramètre permettra à notre cluster à deux nœuds d’élire un coordinateur (contrôleur de domaine), qui est le nœud qui contrôle le cluster à un moment donné.

La section * nodelist * (lignes 18 à 29) spécifie chaque nœud du cluster et indique comment atteindre chaque nœud. Ici, nous configurons nos nœuds principal et secondaire, et précisons qu’ils peuvent être atteints via leurs adresses IP privées respectives.

La section * logging * (lignes 31 à 36) spécifie que les journaux Corosync doivent être écrits dans + / var / log / corosync / corosync.log +. Si vous rencontrez des problèmes avec le reste de ce didacticiel, veillez à regarder ici pendant que vous dépannez.

Sauvegarder et quitter.

Ensuite, nous devons configurer Corosync pour autoriser le service Pacemaker.

Sur * les deux serveurs *, créez le fichier + pcmk + dans le répertoire du service Corosync avec un éditeur. Nous allons utiliser + vi +:

sudo vi /etc/corosync/service.d/pcmk

Ajoutez ensuite le service Pacemaker:

service {
 name: pacemaker
 ver: 1
}

Sauvegarder et quitter. Cela sera inclus dans la configuration de Corosync et permettra à Pacemaker d’utiliser Corosync pour communiquer avec nos serveurs.

Par défaut, le service Corosync est désactivé. Sur * les deux serveurs *, modifiez cela en éditant + / etc / default / corosync +:

sudo vi /etc/default/corosync

Changez la valeur de + START + en + + yes +:

/ etc / default / corosync

START=

Sauvegarder et quitter. Nous pouvons maintenant démarrer le service Corosync.

Sur les deux serveurs, démarrez Corosync avec cette commande:

sudo service corosync start

Une fois que Corosync est exécuté sur les deux serveurs, ils doivent être mis en cluster. Nous pouvons le vérifier en exécutant cette commande:

sudo corosync-cmapctl | grep members

La sortie devrait ressembler à ceci, ce qui indique que le primaire (noeud 1) et le secondaire (noeud 2) ont rejoint le cluster:

corosync-cmapctl output:runtime.totem.pg.mrp.srp.members.1.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.1.ip (str) = r(0) ip()
runtime.totem.pg.mrp.srp.members.1.join_count (u32) = 1
runtime.totem.pg.mrp.srp.members.1.status (str) = joined
runtime.totem.pg.mrp.srp.members.2.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.2.ip (str) = r(0) ip()
runtime.totem.pg.mrp.srp.members.2.join_count (u32) = 1
runtime.totem.pg.mrp.srp.members.2.status (str) = joined

Maintenant que Corosync est correctement configuré, passons maintenant à la configuration de Pacemaker.

Démarrer et configurer le pacemaker

Pacemaker, qui dépend des capacités de messagerie de Corosync, est maintenant prêt à être démarré et à avoir ses propriétés de base configurées.

Activer et démarrer pacemaker

Le service Pacemaker nécessite l’exécution de Corosync, il est donc désactivé par défaut.

Sur * les deux serveurs *, activez Pacemaker pour qu’il démarre au démarrage du système avec cette commande:

sudo update-rc.d pacemaker defaults 20 01

Avec la commande précédente, nous avons défini la priorité de démarrage de Pacemaker sur + 20 +. Il est important de spécifier une priorité de démarrage supérieure à celle de Corosync ("+ 19 +" par défaut) afin que Pacemaker démarre après Corosync.

Maintenant, commençons Pacemaker:

sudo service pacemaker start

Pour interagir avec Pacemaker, nous allons utiliser l’utilitaire + crm +.

Vérifiez le pacemaker avec + crm +:

sudo crm status

Cela devrait produire quelque chose comme ceci (sinon, attendez 30 secondes, puis relancez la commande):

crm status:Last updated: Fri Oct 16 14:38:36 2015
Last change: Fri Oct 16 14:36:01 2015 via crmd on primary
Stack: corosync
Current DC: primary (1) - partition with quorum
Version: 1.1.10-42f2063
2 Nodes configured
0 Resources configured


Online: [ primary secondary ]

Il y a quelques points à noter à propos de cette sortie. Tout d’abord, * le contrôleur de domaine actuel * (coordinateur désigné) doit être réglé sur + primaire (1) + ou + secondaire (2) +. Deuxièmement, il devrait y avoir * 2 nœuds configurés * et * 0 ressources configurées *. Troisièmement, les deux nœuds doivent être marqués comme * en ligne *. S’ils sont marqués comme * hors ligne *, essayez d’attendre 30 secondes et vérifiez à nouveau le statut pour voir s’il se corrige lui-même.

À partir de ce moment, vous pouvez exécuter le moniteur CRM interactif dans une autre fenêtre SSH (connectée à l’un des nœuds du cluster). Cela vous donnera des mises à jour en temps réel de l’état de chaque nœud et de l’emplacement de chaque ressource:

sudo crm_mon

La sortie de cette commande semble identique à celle de + crm status + sauf qu’elle est exécutée en continu. Si vous voulez quitter, appuyez sur + Ctrl-C +.

Configurer les propriétés du cluster

Nous sommes maintenant prêts à configurer les propriétés de base de Pacemaker. Notez que toutes les commandes Pacemaker (+ crm) peuvent être exécutées à partir de l’un ou l’autre serveur de nœud, car elles synchronisent automatiquement toutes les modifications liées au cluster sur tous les nœuds membres.

Pour notre configuration souhaitée, nous voulons désactiver STONITH, un mode utilisé par de nombreux clusters pour supprimer les nœuds défectueux, car nous configurons un cluster à deux nœuds. Pour ce faire, exécutez cette commande sur l’un des serveurs suivants:

sudo crm configure property stonith-enabled=false

Nous voulons également désactiver les messages liés au quorum dans les journaux:

sudo crm configure property no-quorum-policy=ignore

Encore une fois, ce paramètre ne s’applique qu’aux clusters à 2 nœuds.

Si vous souhaitez vérifier votre configuration de pacemaker, exécutez cette commande:

sudo crm configure show

Cela affichera tous vos paramètres de stimulateur cardiaque actifs. Actuellement, cela n’inclut que deux nœuds et les propriétés STONITH et quorum que vous venez de définir.

Créer un agent de ressources de réaffectation d’adresse IP flottant

Maintenant que Pacemaker est en cours d’exécution et configuré, nous devons ajouter des ressources pour le gérer. Comme indiqué dans l’introduction, les ressources sont des services que le cluster est chargé de rendre hautement disponibles. Dans Pacemaker, l’ajout d’une ressource nécessite l’utilisation d’un * agent de ressources *, qui sert d’interface avec le service qui sera géré. Le pacemaker est livré avec plusieurs agents de ressources pour des services communs et permet l’ajout d’agents de ressources personnalisés.

Dans notre configuration, nous voulons nous assurer que le service fourni par nos serveurs Web, * primaire * et * secondaire *, est hautement disponible dans une configuration active / passive, ce qui signifie que nous avons besoin d’un moyen de nous assurer que notre IP flottante est pointant toujours vers le serveur disponible. Pour l’activer, nous devons configurer un * agent de ressources * que chaque nœud peut exécuter pour déterminer s’il possède l’IP flottante et, si nécessaire, exécuter un script pour le faire pointer lui-même. Nous ferons référence à l’agent de ressources en tant que «FloatIP OCF» et au script de réaffectation d’adresse IP flottante en tant que + assign-ip +. Une fois que l’agent de ressources FloatIP OCF est installé, nous pouvons définir la ressource elle-même, que nous appellerons «+ FloatIP +».

Télécharger assign-ip Script

Comme nous venons de le mentionner, nous avons besoin d’un script capable de réaffecter l’aiguille vers laquelle Droplet notre adresse IP flottante pointe, au cas où la ressource + FloatIP + devrait être déplacée vers un autre noeud. Pour cela, nous allons télécharger un script Python de base qui attribue une adresse IP flottante à un ID de droplet donné, à l’aide de l’API DigitalOcean.

Sur * les deux serveurs *, téléchargez le script Python + assign-ip +:

sudo curl -L -o /usr/local/bin/assign-ip http://do.co/assign-ip

Sur * les deux serveurs *, rendez-le exécutable:

sudo chmod +x /usr/local/bin/assign-ip

L’utilisation du script + assign-ip + nécessite les informations suivantes:

  • * IP flottante: * Le premier argument du script, l’adresse IP flottante en cours d’attribution

  • * Droplet ID: * Le deuxième argument du script, l’identifiant de droplet auquel l’adresse IP flottante doit être attribuée

  • * DigitalOcean PAT (jeton d’API): * Transmis en tant que variable d’environnement + DO_TOKEN +, votre PAT en lecture / écriture DigitalOcean

N’hésitez pas à revoir le contenu du script avant de continuer.

Donc, si vous voulez exécuter manuellement ce script pour réaffecter une adresse IP flottante, vous pouvez l’exécuter comme suit: + DO_TOKEN = / usr / local / bin / assign-ip +. Cependant, ce script sera appelé à partir de l’agent de ressources FloatIP OCF dans le cas où la ressource + FloatIP + doit être déplacée vers un autre noeud.

Ensuite, installons l’agent de ressources IP Float.

Télécharger FloatIP OCF Resource Agent

Pacemaker permet l’ajout d’agents de ressources OCF en les plaçant dans un répertoire spécifique.

Sur * les deux serveurs *, créez le répertoire du fournisseur d’agents de ressources + digitalocean + avec cette commande:

sudo mkdir /usr/lib/ocf/resource.d/digitalocean

Sur * les deux serveurs *, téléchargez l’agent de ressources FloatIP OCF:

sudo curl -o /usr/lib/ocf/resource.d/digitalocean/floatip https://gist.githubusercontent.com/thisismitch/b4c91438e56bfe6b7bfb/raw/2dffe2ae52ba2df575baae46338c155adbaef678/floatip-ocf

Sur * les deux serveurs *, rendez-le exécutable:

sudo chmod +x /usr/lib/ocf/resource.d/digitalocean/floatip

N’hésitez pas à revoir le contenu de l’agent de ressources avant de continuer. C’est un script bash qui, s’il est appelé avec la commande + start +, va rechercher l’ID de droplet du nœud qui l’appelle (via des métadonnées) et affecter l’IP flottante à l’ID de droplet. De plus, il répond aux commandes + status et` + monitor of` en indiquant si une adresse IP flottante est attribuée au droplet appelant.

Il nécessite les paramètres OCF suivants:

  • * do_token: *: jeton de l’API DigitalOcean à utiliser pour les réaffectations d’adresses IP flottantes, c.-à-d. votre jeton d’accès personnel DigitalOcean

  • * floating_ip: *: votre adresse IP flottante, au cas où elle aurait besoin d’être réaffectée

Nous pouvons maintenant utiliser l’agent de ressources FloatIP OCF pour définir notre ressource + FloatIP +.

Ajouter une ressource FloatIP

Avec notre agent de ressources FloatIP OCF installé, nous pouvons maintenant configurer notre ressource + FloatIP +.

Sur l’un ou l’autre des serveurs, créez la ressource + FloatIP + avec cette commande (veillez à spécifier les deux paramètres en surbrillance avec vos propres informations):

sudo crm configure primitive FloatIP ocf:digitalocean:floatip \
 params do_token= \
 floating_ip=

Cela crée une ressource primitive, qui est un type générique de ressource de cluster, appelée «FloatIP», à l’aide de l’agent de ressources FloatIP OCF créé précédemment (+ ocf: digitalocean: floatip +). Notez que cela nécessite que les variables + do_token + et + floating_ip + soient passées en tant que paramètres. Ceux-ci seront utilisés si l’adresse IP flottante doit être réaffectée.

Si vous vérifiez l’état de votre cluster (+ sudo crm status + ou + + sudo crm_mon + ), vous devriez voir que la ressource + FloatIP + `est définie et démarrée sur l’un de vos nœuds:

crm_mon:...
2 Nodes configured
1 Resource configured

Online: [ primary secondary ]

FloatIP    (ocf::digitalocean:floatip):    Started

En supposant que tout a été configuré correctement, vous devriez maintenant avoir une configuration HA active / passive! Dans l’état actuel des choses, l’adresse IP flottante sera réaffectée à un serveur en ligne si le nœud sur lequel le + FloatIP + est démarré est déconnecté ou en mode + veille +. À l’heure actuelle, si le noeud actif - * primaire *, dans notre exemple, la sortie devient indisponible, le cluster demandera au noeud * secondaire * de démarrer la ressource + FloatIP + et de revendiquer l’adresse IP flottante. Une fois la réattribution effectuée, l’adresse IP flottante dirigera les utilisateurs vers le serveur * secondaire * nouvellement actif.

Actuellement, le basculement (réaffectation d’adresses IP flottantes) n’est déclenché que si l’hôte actif est déconnecté ou ne peut pas communiquer avec le cluster. Une meilleure version de cette configuration spécifierait des ressources supplémentaires devant être gérées par Pacemaker. Cela permettrait au cluster de détecter les défaillances de services spécifiques, tels que l’équilibreur de charge ou le logiciel de serveur Web. Avant de configurer cela, cependant, nous devons nous assurer que le basculement de base fonctionne.

Tester la haute disponibilité

Il est important de tester le bon fonctionnement de notre configuration de haute disponibilité. Faisons-le maintenant.

Actuellement, l’adresse IP flottante est attribuée à l’un de vos nœuds (supposons * primaire *). Accéder maintenant à l’adresse IP flottante, via l’adresse IP ou par le nom de domaine qui le désigne, affiche simplement la page d’index du serveur * primaire *. Si vous avez utilisé l’exemple de script de données utilisateur, cela ressemblera à ceci:

Floating IP is pointing to primary server:Droplet: , IP Address:

Cela indique que l’adresse IP flottante est en fait affectée au droplet principal.

Maintenant, ouvrons un nouveau terminal local et utilisons + curl + pour accéder à l’IP Floating en boucle d’une seconde. Utilisez cette commande pour le faire, mais veillez à remplacer l’URL par votre domaine ou votre adresse IP flottante:

while true; do curl ; sleep 1; done

Actuellement, cela produira le même nom et l’adresse IP de Droplet du serveur principal. Si nous provoquons l’échec du serveur principal, en le mettant hors tension ou en modifiant le statut du cluster du nœud principal en «+ standby +», nous verrons si l’adresse IP flottante est réaffectée au serveur secondaire.

Réinitialisons le serveur * primaire * maintenant. Faites-le via le Panneau de configuration DigitalOcean ou en exécutant cette commande sur le serveur principal:

sudo reboot

Après quelques instants, le serveur principal devrait devenir indisponible. Faites attention à la sortie de la boucle + curl + qui est exécutée dans le terminal. Vous devriez remarquer une sortie qui ressemble à ceci:

curl loop output:Droplet: , IP Address:
...
curl: (7) Failed to connect to  port 80: Connection refused
Droplet: , IP Address:
...

C’est-à-dire que l’adresse IP flottante doit être réaffectée pour pointer vers l’adresse IP du serveur * secondaire *. Cela signifie que votre configuration HA fonctionne, puisqu’un basculement automatique réussi a eu lieu.

Vous pouvez ou ne pas voir l’erreur + Connection denied +, qui peut se produire si vous essayez d’accéder à l’adresse IP flottante entre l’échec du serveur principal et la fin de la réaffectation d’adresse IP flottante.

Si vous vérifiez le statut de Pacemaker, vous devriez voir que la ressource + FloatIP + est démarrée sur le serveur * secondaire *. En outre, le serveur * primaire * doit être temporairement marqué comme + OFFLINE, mais rejoindra la liste` + Online` dès qu’il aura terminé son redémarrage et rejoint le cluster.

Dépannage du basculement (facultatif)

Ignorez cette section si votre configuration HA fonctionne comme prévu. Si le basculement n’a pas eu lieu comme prévu, vous devez vérifier votre configuration avant de poursuivre. En particulier, assurez-vous que toutes les références à votre propre configuration, telles que les adresses IP de nœud, votre adresse IP flottante et votre jeton d’API.

Commandes utiles pour le dépannage

Voici quelques commandes qui peuvent vous aider à dépanner votre configuration.

Comme mentionné précédemment, l’outil + crm_mon + peut être très utile pour afficher le statut en temps réel de vos noeuds et ressources:

sudo crm_mon

De plus, vous pouvez regarder votre configuration de cluster avec cette commande:

sudo crm configure show

Si les commandes + crm + ne fonctionnent pas, consultez les journaux Corosync pour obtenir des indices:

sudo tail -f /var/log/corosync/corosync.log

Commandes CRM diverses

Ces commandes peuvent être utiles lors de la configuration de votre cluster.

Vous pouvez définir un nœud sur le mode + veille +, qui peut être utilisé pour simuler l’indisponibilité d’un nœud, avec la commande suivante:

sudo crm node standby

Vous pouvez changer l’état d’un nœud de + standby en` + online` avec cette commande:

sudo crm node online

Vous pouvez éditer une ressource, ce qui vous permet de la reconfigurer, avec cette commande:

sudo crm configure edit

Vous pouvez supprimer une ressource, qui doit être arrêtée avant de la supprimer, avec la commande suivante:

sudo crm resource stop
sudo crm configure delete

Enfin, la commande + crm + peut être exécutée seule pour accéder à une invite interactive + crm +:

crm

Nous ne couvrirons pas l’utilisation de l’invite interactive + crm +, mais elle peut être utilisée pour effectuer toutes les configurations + crm + que nous avons effectuées jusqu’à présent.

Ajouter une ressource Nginx (facultatif)

Maintenant que vous êtes certain que votre basculement IP flottant fonctionne, voyons comment ajouter une nouvelle ressource à votre cluster. Dans notre exemple d’installation, Nginx est le service principal que nous rendons hautement disponible. Laissons donc l’ajouter à la liste des ressources gérées par notre cluster.

Pacemaker est livré avec un agent de ressources Nginx. Nous pouvons donc facilement ajouter Nginx en tant que ressource de cluster.

Utilisez cette commande pour créer une nouvelle ressource de cluster primitive appelée «Nginx»:

sudo crm configure primitive Nginx ocf:heartbeat:nginx \
 params httpd="/usr/sbin/nginx" \
 op start timeout="40s" interval="0" \
 op monitor timeout="30s" interval="10s" on-fail="restart" \
 op stop timeout="60s" interval="0"

La ressource spécifiée indique au cluster de surveiller Nginx toutes les 10 secondes et de le redémarrer s’il devient indisponible.

Vérifiez l’état de vos ressources de cluster en utilisant + sudo crm_mon ou` + sudo crm status`:

crm_mon:...
Online: [ primary secondary ]

FloatIP    (ocf::digitalocean:floatip):    Started
Nginx  (ocf::heartbeat:nginx): Started

Malheureusement, Pacemaker décidera de démarrer les ressources + Nginx + et + FloatIP + sur des nœuds distincts car nous n’avons défini aucune contrainte de ressource. Ceci est un problème car cela signifie que l’IP flottante pointera vers un Droplet, alors que le service Nginx ne s’exécutera que sur l’autre Droplet. L’accès à l’IP flottante vous dirigera vers un serveur qui n’exécute pas le service qui devrait être hautement disponible.

Pour résoudre ce problème, nous allons créer une ressource * clone *, qui spécifie qu’une ressource primitive existante doit être démarrée sur plusieurs nœuds.

Créez une ressource de clone de la ressource + Nginx + appelée «Nginx-clone» avec cette commande:

sudo crm configure clone Nginx-clone Nginx

Le statut du cluster devrait maintenant ressembler à ceci:

crm_mon:Online: [ primary secondary ]

FloatIP (ocf::digitalocean:floatip):    Started primary
Clone Set: Nginx-clone [Nginx]
    Started: [ primary secondary ]

Comme vous pouvez le constater, la ressource de clonage + Nginx-clone + est maintenant démarrée sur nos deux nœuds.

La dernière étape consiste à configurer une contrainte * colocation *, afin de spécifier que la ressource + FloatIP + doit être exécutée sur un nœud avec une ressource active + Nginx-clone +. Pour créer une contrainte de colocation appelée «FloatIP-Nginx», utilisez cette commande:

sudo crm configure colocation FloatIP-Nginx inf: FloatIP Nginx-clone

Vous ne verrez aucune différence dans la sortie + crm status +, mais vous pouvez voir que la ressource de colocation a été créée avec cette commande:

sudo crm configure show

Maintenant, Nginx devrait fonctionner sur vos deux serveurs, alors que l’un d’entre eux seulement a la ressource + FloatIP + en cours d’exécution. Le moment est venu de tester votre configuration haute disponibilité en arrêtant votre service Nginx et en redémarrant ou en mettant votre serveur * actif * hors tension.

Conclusion

Toutes nos félicitations! Vous disposez maintenant d’une configuration de serveur haute disponibilité de base utilisant Corosync, Pacemaker et une adresse IP flottante DigitalOcean.

L’étape suivante consiste à remplacer l’exemple de configuration Nginx par un équilibreur de charge par proxy inverse. Vous pouvez utiliser Nginx ou HAProxy à cette fin. N’oubliez pas que vous souhaiterez lier votre équilibreur de charge à * l’adresse IP d’ancrage *, afin que vos utilisateurs ne puissent accéder à vos serveurs que via l’adresse IP flottante (et non via l’adresse IP publique de chaque serveur). Ce processus est détaillé dans https://www.digitalocean.com/community/tutorials/how-to-create-a-high-availability-haproxy-setup-with-corosync-pacemaker-and-floating-ips-on- ubuntu-14-04 [Comment créer une configuration HAProxy à haute disponibilité avec Corosync, un pacemaker et des adresses IP flottantes sous Ubuntu 14.04].

Related