TOC

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

introduction

Ce tutoriel vous montrera comment créer une configuration d’équilibreur de charge HAProxy à haute disponibilité sur DigitalOcean, avec prise en charge d’une adresse IP flottante et de la pile de cluster Corosync / Pacemaker. Les équilibreurs de charge HAProxy seront chacun configurés pour répartir le trafic entre deux serveurs d’applications principaux. Si l’équilibreur de charge principal tombe en panne, l’adresse IP flottante sera automatiquement déplacée vers le deuxième équilibreur de charge, permettant ainsi au service de reprendre.

image: https: //assets.digitalocean.com/articles/high_availability/ha-diagram-animated.gif [Configuration HAProxy à haute disponibilité]

Conditions préalables

Afin de compléter ce guide, vous devrez avoir complété les https://www.digitalocean.com/community/tutorials/how-to-create-a-high-available-setup-with-corosync-pacemaker-and- floating-ips-on-ubuntu-14-04 [Comment créer une installation de haute disponibilité avec Corosync, un pacemaker et des adresses IP flottantes sur Ubuntu 14.04] (vous devez ignorer la section facultative * Ajouter des ressources Nginx *). Cela vous laissera deux gouttelettes, que nous appellerons * primaire * et * secondaire *, avec une adresse IP flottante qui peut faire la transition entre elles. Ensemble, nous ferons référence à ces serveurs en tant que * équilibreurs de charge *. Ce sont les Droplets sur lesquels nous allons installer un équilibreur de charge, HAProxy.

Vous devrez également être en mesure de créer deux droplets Ubuntu 14.04 supplémentaires dans le même centre de données, avec la mise en réseau privée activée, pour démontrer que la configuration de l’équilibreur de charge haute disponibilité fonctionne. Ce sont les serveurs qui seront équilibrés par HAProxy. Nous appellerons ces serveurs d’applications, sur lesquels nous installerons Nginx, les noms * app-1 * et * app-2 *. Si vous avez déjà des serveurs d’applications que vous souhaitez équilibrer, n’hésitez pas à les utiliser.

Sur chacun de ces serveurs, vous aurez besoin d’un utilisateur non-root configuré avec un accès + sudo +. Vous pouvez suivre notre Ubuntu 14.04 guide de configuration du serveur pour apprendre à configurer ces utilisateurs.

Créer des gouttelettes d’applications

La première étape consiste à créer deux gabarits Ubuntu, avec la mise en réseau privée activée, dans le même centre de données que vos équilibreurs de charge, qui serviront de serveurs * app-1 * et * app-2 * décrits ci-dessus. 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 l’équilibreur de charge HA fonctionne. Si vous avez déjà des serveurs d’applications que vous souhaitez équilibrer, n’hésitez pas à adapter les parties appropriées de ce didacticiel pour que cela fonctionne (et ignorer toutes les parties non pertinentes pour votre configuration).

Si vous souhaitez suivre l’exemple de configuration, créez deux droplets Ubuntu 14.04, * app-1 * et * app-2 *, et utilisez ce script bash comme 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 publique du droplet (en référençant le service de métadonnées). Accéder à l’un ou l’autre des sites Droplet affichera une page Web de base avec le nom d’hôte et l’adresse IP publique de Droplet, ce qui sera utile pour tester le serveur d’applications vers lequel les équilibreurs de charge dirigent le trafic.

Rassembler les informations réseau du serveur

Avant de commencer la configuration réelle de nos composants d’infrastructure, il est préférable de collecter des informations sur chacun de vos serveurs.

Pour compléter ce guide, vous devez disposer des informations suivantes sur vos serveurs:

  • * serveurs d’applications *: adresse IP privée

  • * équilibreurs de charge * adresses IP privées et d’ancrage

Rechercher des adresses IP privées

Le moyen le plus simple de trouver l’adresse IP privée de votre Droplet consiste à utiliser + curl + pour extraire l’adresse IP privée du service de métadonnées DigitalOcean. Cette commande doit être exécutée à partir de vos gouttelettes. Sur chaque gouttelette, tapez:

curl 169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address && echo

L’adresse IP correcte doit être imprimée dans la fenêtre du terminal:

Private IP address:10.132.20.236

Effectuez cette étape sur les quatre gouttelettes et copiez les adresses IP privées dans un endroit facilement référencé.

Trouver des adresses IP d’ancrage

  • L’ancre IP * est l’adresse IP privée locale à laquelle l’IP flottante se liera lorsqu’elle sera attachée à un serveur DigitalOcean. C’est simplement un alias pour l’adresse + eth0 + régulière, implémentée au niveau de l’hyperviseur.

Le moyen le plus simple et le moins sujet aux erreurs de saisir cette valeur est directement issu du service de métadonnées DigitalOcean. Avec + curl +, vous pouvez atteindre ce noeud final sur chacun de vos serveurs en tapant:

curl 169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address && echo

L’ancre IP sera imprimée sur sa propre ligne:

Output10.17.1.18

Effectuez cette étape sur vos deux Droplets d’équilibrage de charge et copiez les adresses IP d’ancrage à un endroit facilement référencé.

Configurer les serveurs d’applications

Après avoir rassemblé les données ci-dessus, nous pouvons passer à la configuration de nos services.

Note

Nous allons commencer par configurer nos serveurs d’applications d’arrière-plan. Ces deux serveurs serviront simplement leur nom et leur adresse IP publique; dans une configuration réelle, ces serveurs serviraient un contenu identique. Ils n’accepteront que les connexions Web sur leurs adresses IP privées. Cela vous aidera à vous assurer que le trafic est exclusivement dirigé vers l’un des deux serveurs HAProxy que nous configurerons plus tard.

La configuration de serveurs d’applications derrière un équilibreur de charge nous permet de répartir la charge des demandes entre plusieurs serveurs d’applications identiques. À mesure que nos besoins en trafic évoluent, nous pouvons facilement nous adapter aux nouvelles exigences en ajoutant ou en supprimant des serveurs d’applications de ce niveau.

Configurer Nginx pour n’autoriser que les demandes des équilibreurs de charge

Si vous suivez cet exemple et que vous avez utilisé les * données utilisateur * fournies lors de la création de vos serveurs d’applications, Nginx sera déjà installé sur vos serveurs. La prochaine étape consiste à apporter quelques modifications à la configuration.

Nous voulons configurer Nginx pour n’écouter que les demandes sur l’adresse IP privée du serveur. De plus, nous ne servirons que les demandes provenant des adresses IP privées de nos deux équilibreurs de charge. Cela forcera les utilisateurs à accéder à vos serveurs d’applications via vos équilibreurs de charge (que nous configurerons pour être accessibles uniquement via l’adresse IP flottante).

Pour apporter ces modifications, ouvrez le fichier de blocage du serveur Nginx par défaut sur chacun de vos serveurs d’applications:

sudo vi /etc/nginx/sites-available/default

Pour commencer, nous allons modifier les directives + listen +. Modifiez la directive + listen + pour écouter l’adresse IP privée * du serveur d’applications actuel * sur le port 80. Supprimez la ligne supplémentaire + listen +. Ça devrait ressembler a quelque chose comme ca:

/ etc / nginx / sites-available / default (1 sur 2)

server {
   listen :80;

   . . .

Directement sous la directive + listen +, nous allons configurer deux directives + allow + pour autoriser le trafic provenant des adresses IP privées de nos deux équilibreurs de charge. Nous suivrons cela avec une règle + refuser tout + pour interdire tout autre trafic:

/ etc / nginx / sites-available / default (2 sur 2)

   allow ;
   allow ;
   deny all;

Enregistrez et fermez les fichiers lorsque vous avez terminé.

Vérifiez que les modifications que vous avez apportées représentent la syntaxe Nginx valide en tapant:

sudo nginx -t

Si aucun problème n’a été signalé, redémarrez le démon Nginx en tapant:

sudo service nginx restart

N’oubliez pas de suivre toutes ces étapes (avec les adresses IP privées du serveur d’applications appropriées) sur les deux serveurs d’applications.

Tester les changements

Pour vérifier que vos serveurs d’applications sont correctement limités, vous pouvez faire des demandes en utilisant + curl depuis différents emplacements.

Sur vos serveurs d’applications eux-mêmes, vous pouvez essayer une simple requête du contenu local en tapant:

curl 127.0.0.1

En raison des restrictions que nous avons définies dans nos fichiers de blocage de serveur Nginx, cette demande sera en réalité refusée:

Outputcurl: (7) Failed to connect to 127.0.0.1 port 80: Connection refused

Ceci est prévu et reflète le comportement que nous avons tenté d’implémenter.

Désormais, à partir de l’un des * équilibreurs de charge *, nous pouvons demander l’adresse IP publique de notre serveur d’application:

curl

Encore une fois, cela devrait échouer. Les serveurs d’applications n’écoutent pas sur l’interface publique. En outre, lors de l’utilisation de l’adresse IP publique, nos serveurs d’applications ne verraient pas les adresses IP privées autorisées dans la demande de nos équilibreurs de charge:

Outputcurl: (7) Failed to connect to  port 80: Connection refused

Toutefois, si nous modifions l’appel pour effectuer la requête à l’aide de l’adresse IP privée_ du serveur de l’application, il devrait fonctionner correctement:

curl

La page Nginx + index.html devrait être renvoyée. Si vous avez utilisé les exemples de données utilisateur, la page doit contenir le nom et l’adresse IP publique du serveur d’application auquel vous accédez:

app server index.htmlDroplet: app-1, IP Address: 159.203.130.34

Testez ceci des deux équilibreurs de charge vers les deux serveurs d’applications. Chaque demande d’adresse IP privée doit aboutir tandis que chaque demande adressée aux adresses publiques doit échouer.

Une fois que le comportement ci-dessus est démontré, nous pouvons passer à autre chose. La configuration de notre serveur d’applications principal est maintenant terminée.

Supprimer Nginx des équilibreurs de charge

En suivant le didacticiel * Configuration requise HA haute avec Corosync, Pacemaker et IP flottantes *, Nginx sera installé sur vos serveurs d’équilibreur de charge. Puisque nous allons utiliser HAProxy comme équilibreur de charge de proxy inverse, nous devons supprimer Nginx et toutes les ressources de cluster associées.

Supprimer les ressources du cluster Nginx

Si vous avez ajouté une ressource de cluster Nginx en suivant le didacticiel préalable, arrêtez et supprimez la ressource + Nginx + avec ces commandes sur * l’un de vos équilibreurs de charge *:

sudo crm resource stop Nginx
sudo crm configure delete Nginx

Cela devrait également supprimer tous les paramètres de cluster qui dépendent de la ressource + Nginx +. Par exemple, si vous avez créé un + clone + ou + + colocation + qui fait référence à la ressource + Nginx +, ils seront également supprimés.

Supprimer le package Nginx

Nous sommes maintenant prêts à désinstaller Nginx sur * les deux serveurs d’équilibreur de charge *.

Tout d’abord, arrêtez le service Nginx:

sudo service nginx stop

Puis purgez le paquet avec cette commande:

sudo apt-get purge nginx

Vous pouvez également vouloir supprimer les fichiers de configuration Nginx:

sudo rm -r /etc/nginx

Nous sommes maintenant prêts à installer et configurer HAProxy.

Installer et configurer HAProxy

Nous allons ensuite configurer les équilibreurs de charge HAProxy. Ceux-ci s’installent chacun devant nos serveurs Web et divisent les demandes entre les deux serveurs d’applications principaux. Ces équilibreurs de charge seront complètement redondants, dans une configuration active-passive; un seul recevra du trafic à un moment donné.

La configuration HAProxy transmet les requêtes aux deux serveurs Web. Les équilibreurs de charge écouteront les demandes sur leur adresse IP d’ancrage. Comme mentionné précédemment, il s’agit de l’adresse IP à laquelle l’adresse IP flottante se liera lorsqu’elle sera attachée au Droplet. Cela garantit que seul le trafic provenant de l’adresse IP flottante sera transféré.

Installer HAProxy

Cette section doit être effectuée sur * les deux serveurs d’équilibrage de charge *.

Nous allons installer HAProxy 1.6, qui ne se trouve pas dans les référentiels Ubuntu par défaut. Cependant, nous pouvons toujours utiliser un gestionnaire de paquets pour installer HAProxy 1.6 si nous utilisons un PPA, avec cette commande:

sudo add-apt-repository ppa:vbernat/haproxy-1.6

Mettez à jour l’index de paquetage local sur vos équilibreurs de charge et installez HAProxy en tapant:

sudo apt-get update
sudo apt-get install haproxy

HAProxy est maintenant installé, mais nous devons le configurer maintenant.

Configurer HAProxy

Ouvrez le fichier de configuration principal HAProxy:

sudo vi /etc/haproxy/haproxy.cfg

Recherchez la section + defaults + et ajoutez-y les deux lignes suivantes:

/etc/haproxy/haproxy.cfg (1 sur 3)

   option forwardfor
   option http-server-close

L’option forwardfor permet à HAProxy d’ajouter des en-têtes + X-Forwarded-For + à chaque requête, ce qui est utile si vous voulez que vos serveurs d’applications sachent quelle adresse IP a initialement envoyé une requête et l’option http-server-close réduit le temps d’attente HAProxy et vos utilisateurs en fermant les connexions tout en maintenant des connexions persistantes.

Ensuite, à la fin du fichier, nous devons définir notre configuration frontale. Cela dictera comment HAProxy écoute les connexions entrantes. Nous allons lier HAProxy à l’adresse IP d’ancrage de l’équilibreur de charge. Cela lui permettra d’écouter le trafic provenant de l’adresse IP flottante. Nous appellerons notre interface "http" pour plus de simplicité. Nous allons également spécifier un backend par défaut, + app_pool +, pour transférer le trafic (que nous allons configurer dans un instant):

/etc/haproxy/haproxy.cfg (2 sur 3)

frontend http
   bind    :80
   default_backend app_pool

Ensuite, nous pouvons définir la configuration du backend. Cela spécifiera les emplacements en aval où HAProxy transmettra le trafic reçu. Dans notre cas, il s’agira des adresses IP privées des deux serveurs d’applications Nginx que nous avons configurés:

/etc/haproxy/haproxy.cfg (3 sur 3)

backend app_pool
   server app-1 :80 check
   server app-2 :80 check

Lorsque vous avez terminé les modifications ci-dessus, enregistrez et quittez le fichier.

Vérifiez que les modifications de configuration que nous avons apportées représentent la syntaxe HAProxy valide en tapant:

sudo haproxy -f /etc/haproxy/haproxy.cfg -c

Si aucune erreur n’a été signalée, redémarrez votre service en tapant:

sudo service haproxy restart

Encore une fois, veillez à exécuter toutes les étapes décrites dans cette section sur les deux serveurs d’équilibrage de charge.

Tester les changements

Nous pouvons nous assurer que votre configuration est valide en testant à nouveau avec + curl.

À partir des serveurs de l’équilibreur de charge, essayez de demander à l’hôte local, à sa propre adresse IP publique ou à l’adresse IP privée du serveur:

curl 127.0.0.1
curl
curl

Ceux-ci devraient tous échouer avec des messages qui ressemblent à ceci:

Outputcurl: (7) Failed to connect to  port 80: Connection refused

Cependant, si vous faites une demande à l’adresse IP_anchor_ de l’équilibreur de charge, celle-ci doit aboutir:

curl

Vous devriez voir la page Nginx + index.html de l’un des serveurs de l’application:

app server index.htmlDroplet: app-1, IP Address: app1_IP_address

Effectuez à nouveau la même requête curl:

curl

Vous devriez voir la page + index.html + de l’autre serveur d’applications, car HAProxy utilise l’équilibrage de charge round-robin par défaut:

app server index.htmlDroplet: app-2, IP Address: app2_IP_address

Si ce comportement correspond à celui de votre système, vos équilibreurs de charge sont configurés correctement. vous avez testé avec succès que vos serveurs d’équilibrage de charge équilibraient le trafic entre les deux serveurs d’applications principaux. En outre, votre adresse IP flottante doit déjà être affectée à l’un des serveurs de l’équilibreur de charge, comme cela avait été configuré dans le didacticiel Prérequis * HA avec Corosync, Pacemaker et Floating IPs *.

Télécharger l’agent de ressources HAProxy OCF

À ce stade, vous avez un basculement de base au niveau de l’hôte, mais nous pouvons améliorer la configuration en ajoutant HAProxy en tant que ressource de cluster. Cela permettra à votre cluster de s’assurer que HAProxy est en cours d’exécution sur le serveur auquel votre adresse IP flottante est attribuée. Si Pacemaker détecte que HAProxy n’est pas en cours d’exécution, il peut redémarrer le service ou attribuer l’adresse IP flottante à l’autre nœud (qui doit exécuter HAProxy).

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

Sur * les deux serveurs d’équilibrage de charge *, téléchargez l’agent de ressource HAProxy OCF avec les commandes suivantes:

cd /usr/lib/ocf/resource.d/heartbeat
sudo curl -O https://raw.githubusercontent.com/thisismitch/cluster-agents/master/haproxy

Sur * les deux serveurs d’équilibrage de charge *, rendez-le exécutable:

sudo chmod +x haproxy

N’hésitez pas à revoir le contenu de la ressource avant de continuer. C’est un script shell qui peut être utilisé pour gérer le service HAProxy.

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

Ajouter une ressource haproxy

Avec notre agent de ressources HAProxy OCF installé, nous pouvons maintenant configurer une ressource + haproxy + qui permettra au cluster de gérer HAProxy.

Sur * le serveur d’équilibrage de charge *, créez la ressource primitive + haproxy + avec cette commande:

sudo crm configure primitive haproxy ocf:heartbeat:haproxy op monitor interval=15s

La ressource spécifiée indique au cluster de surveiller HAProxy toutes les 15 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 pourrait décider de démarrer les ressources + haproxy + et + + FloatIP + `sur des nœuds distincts car nous n’avons défini aucune contrainte de ressource. Ceci est un problème car l’IP flottante peut pointer vers un Droplet alors que le service HAProxy est exécuté 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 un clone de la ressource + haproxy + appelé «haproxy-clone» avec cette commande:

sudo crm configure clone haproxy-clone haproxy

Le statut du cluster devrait maintenant ressembler à ceci:

crm_mon:Online: [ primary secondary ]

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

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

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

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

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

sudo crm configure show

HAProxy doit maintenant être exécuté sur vos deux serveurs, tandis que la ressource FloatIP est en cours d’exécution sur un seul d’entre eux.

Essayez d’arrêter le service HAProxy sur l’un des deux serveurs:

sudo service haproxy stop

Vous remarquerez qu’il redémarrera au cours des 15 prochaines secondes.

Nous allons ensuite tester votre configuration haute disponibilité en redémarrant votre serveur d’équilibreur de charge actif (celui sur lequel la ressource + FloatIP + est actuellement «démarrée»).

Testez la haute disponibilité des équilibreurs de charge

Avec votre nouvelle configuration HAProxy haute disponibilité, vous souhaitez vérifier que tout fonctionne comme prévu.

Afin de mieux visualiser la transition entre les équilibreurs de charge, nous pouvons surveiller les journaux Nginx du serveur d’applications pendant la transition.

Etant donné que les informations sur le serveur proxy utilisé ne sont pas renvoyées au client, le meilleur endroit pour afficher les journaux est celui des serveurs Web principaux. Chacun de ces serveurs doit conserver des journaux sur les clients qui demandent des actifs. Du point de vue du service Nginx, le client est l’équilibreur de charge qui effectue les demandes pour le compte du client réel.

Surveiller le statut du cluster

Lors des tests à venir, vous voudrez peut-être examiner le statut en temps réel des noeuds et des ressources du cluster. Vous pouvez le faire avec cette commande, sur l’un des deux serveurs d’équilibreur de charge (tant qu’il est en cours d’exécution):

sudo crm_mon

La sortie devrait ressembler à ceci:

crm_mon output:Last updated: Thu Nov  5 13:51:41 2015
Last change: Thu Nov  5 13:51:27 2015 via cibadmin on primary
Stack: corosync
Current DC: secondary (2) - partition with quorum
Version: 1.1.10-42f2063
2 Nodes configured
3 Resources configured

Online: [ primary secondary ]

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

Cela vous indiquera quels nœuds d’équilibreur de charge sont en ligne et quels nœuds sont démarrés sur les ressources + FloatIP + et + haproxy +.

Notez que le nœud sur lequel la ressource + FloatIP + est + Started +, * primaire * dans l’exemple ci-dessus, est le serveur d’équilibrage de charge auquel l’adresse IP flottante est actuellement attribuée. Nous ferons référence à ce serveur en tant que * serveur d’équilibreur de charge actif *.

Automatiser les requêtes sur l’IP flottant

Sur votre ordinateur local, nous demanderons le contenu Web à l’adresse IP flottante toutes les 2 secondes. Cela nous permettra de voir facilement comment l’équilibreur de charge actif traite le trafic entrant. Autrement dit, nous verrons à quels serveurs d’applications backend le trafic est destiné. Dans votre terminal local, entrez cette commande:

while true; do curl ; sleep 2; done

Toutes les deux secondes, vous devriez voir une réponse de l’un des serveurs d’applications principaux. Il alternera probablement entre * app-1 * et * app-2 * car l’algorithme de balance par défaut de HAProxy, que nous n’avons pas spécifié, est défini sur * round-robin *. Donc, votre terminal devrait afficher quelque chose comme ceci:

[secondary_label curl loop output:
Droplet: app-1, IP Address:
Droplet: app-2, IP Address:
...

Laissez cette fenêtre de terminal ouverte afin que les demandes soient continuellement envoyées à vos serveurs. Ils seront utiles lors de nos prochaines étapes de test.

Tail the Logs sur les serveurs Web

Sur chacun de nos serveurs d’applications d’arrière-plan, nous pouvons + tail + l’emplacement + / var / log / nginx / access.log +. Cela montrera chaque demande faite au serveur. Étant donné que nos équilibreurs de charge divisent le trafic de manière uniforme en utilisant une rotation alternée, chaque serveur d’applications principal devrait voir environ la moitié des demandes effectuées.

L’adresse du client est le tout premier champ du journal d’accès. Il sera donc facile à trouver. Exécutez les opérations suivantes sur * les deux * de vos serveurs d’applications Nginx (dans des fenêtres de terminal distinctes):

sudo tail -f /var/log/nginx/access.log

Le premier champ doit indiquer l’adresse IP privée de votre serveur d’équilibreur de charge actif, toutes les quatre secondes (nous supposerons qu’il s’agit de l’équilibreur de charge * primaire *, mais que ce pourrait être le * secondaire * dans votre cas):

Output. . .
- - [05/Nov/2015:14:26:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
- - [05/Nov/2015:14:26:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

Laissez la commande + tail + en cours d’exécution sur vos deux serveurs d’applications.

Interrompre le service HAProxy sur l’équilibreur de charge principal

Maintenant, redémarrons l’équilibreur de charge * primaire *, pour nous assurer que le basculement IP flottant fonctionne:

sudo reboot

Faites maintenant attention aux journaux d’accès Nginx sur vos deux serveurs d’applications. Vous remarquerez qu’après le basculement IP flottant, les journaux d’accès indiquent que les serveurs d’applications sont en cours d’accès via une adresse IP différente de celle utilisée auparavant. Les journaux doivent indiquer que le serveur d’équilibrage de charge * secondaire * envoie les demandes:

Output. . .
- - [05/Nov/2015:14:27:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
- - [05/Nov/2015:14:27:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

Cela montre que la défaillance de l’équilibreur de charge principal a été détectée et que l’adresse IP flottante a été réaffectée à l’équilibreur de charge secondaire.

Vous pouvez également vérifier la sortie de votre terminal local (qui accède à l’IP flottante toutes les deux secondes) pour vérifier que l’équilibreur de charge secondaire envoie des demandes aux deux serveurs d’applications principaux:

[secondary_label curl loop output:
Droplet: app-1, IP Address:
Droplet: app-2, IP Address:
...

Vous pouvez également essayer le basculement dans l’autre sens, une fois que l’autre équilibreur de charge est à nouveau en ligne.

Configurer Nginx pour consigner l’adresse IP réelle du client

Comme vous l’avez vu, les journaux d’accès Nginx indiquent que toutes les demandes client proviennent de l’adresse IP privée de l’équilibreur de charge actuel, et non de l’adresse IP réelle du client qui a initialement effectué la demande (c’est-à-dire. votre machine locale). Il est souvent utile de consigner l’adresse IP du demandeur d’origine à la place du serveur de l’équilibreur de charge. Ceci est facilement réalisé en apportant quelques modifications à la configuration de Nginx sur tous vos serveurs d’applications principaux.

Sur les deux * serveurs d’application *, ouvrez le fichier + nginx.conf + dans un éditeur:

sudo vi /etc/nginx/nginx.conf

Recherchez la section "Paramètres de journalisation" (dans le bloc + http +) et ajoutez la ligne suivante:

ajouter à /etc/nginx/nginx.conf

log_format haproxy_log 'ProxyIP: $remote_addr - ClientIP: $http_x_forwarded_for - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent "$http_referer" ' '"$http_user_agent"';

Sauvegarder et quitter. Ceci spécifie un nouveau format de journal appelé + haproxy_log +, qui ajoute le + $ http_x_forwarded_for + valeur - l’adresse IP du client qui a fait la demande d’origine - aux entrées du journal d’accès par défaut. Nous incluons également + $ remote_addr +, qui correspond à l’adresse IP de l’équilibreur de charge de proxy inverse (c’est-à-dire le serveur d’équilibrage de charge actif).

Ensuite, pour utiliser ce nouveau format de journal, nous devons ajouter une ligne à notre bloc de serveur par défaut.

Sur * les deux serveurs d’applications *, ouvrez la configuration du serveur + default +:

sudo vi /etc/nginx/sites-available/default

Dans le bloc + server (juste en dessous de la directive` + listen` est un bon endroit), ajoutez la ligne suivante:

ajouter à / etc / nginx / sites-available / default

       access_log /var/log/nginx/access.log haproxy_log;

Sauvegarder et quitter. Cela indique à Nginx d’écrire ses journaux d’accès en utilisant le format de journal + haproxy_log + que nous avons récemment créé.

Sur * les deux serveurs d’applications *, redémarrez Nginx pour appliquer les modifications:

sudo service nginx restart

Désormais, vos journaux d’accès Nginx doivent contenir les adresses IP réelles des clients qui font les demandes. Vérifiez cela en ajustant les journaux de vos serveurs d’applications, comme nous l’avons fait dans la section précédente. Les entrées du journal doivent ressembler à ceci:

New Nginx access logs:. . .
ProxyIP:  - ClientIP:  - - [05/Nov/2015:15:05:53 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

Si vos journaux sont corrects, vous êtes prêt!

Conclusion

Dans ce guide, nous avons expliqué le processus complet de mise en place d’une infrastructure hautement disponible et équilibrée. Cette configuration fonctionne bien car le serveur HAProxy actif peut répartir la charge sur le pool de serveurs d’applications du backend. Vous pouvez facilement adapter ce pool à mesure que votre demande augmente ou diminue.

La configuration IP flottante et Corosync / Pacemaker élimine le point de défaillance unique au niveau de la couche d’équilibrage de charge, permettant ainsi à votre service de continuer à fonctionner même en cas de défaillance complète de l’équilibreur de charge principal. Cette configuration est assez flexible et peut être adaptée à votre propre environnement d’application en configurant votre pile d’applications préférées derrière les serveurs HAProxy.

Related