Répartition de la Charge avec HAProxy
HAProxy est un outil logiciel gratuit qui fonctionne comme un relais de charge et un serveur proxy inverse pour les applications reposant sur TCP et HTTP. Cet outil distribue les requêtes de connexion entre plusieurs nœuds de serveur. Avec très peu de ressources, il permet de gérer d’énormes volumes de trafic HTTP et HTTPS. De plus, HAProxy effectue des vérifications de l’état des serveurs et redirige les utilisateurs vers un nœud fonctionnel si l’un des serveurs tombe en panne, ce qui en fait une solution de basculement utile.
En supposant les avantages mentionnés ci-dessus, nous avons configuré HAProxy pour distribuer les connexions pour MySQL RDBMS et notre interface utilisateur.
Dans cet article, nous examinerons les étapes pour effectuer la répartition de charge pour trois proxies DataSunrise en mode Haute Disponibilité aux adresses suivantes : 192.168.1.100, 192.168.1.101, 192.168.1.102.
Prérequis
Il y a plusieurs étapes à effectuer avant de commencer à travailler avec HAProxy.
Avant de configurer la répartition de charge, vous devez installer DataSunrise en mode haute disponibilité sur plusieurs serveurs. Pour mettre en œuvre le mode Haute Disponibilité sur DataSunrise, effectuez les opérations suivantes :
- L’assistant d’installation de DataSunrise vous permet de sélectionner l’emplacement local ou distant pour un onglet de configuration. Sélectionnez Distant.
- Dans l’onglet Détails du Serveur DataSunrise, spécifiez les détails de l’instance DataSunrise actuelle : nom du serveur, nom d’hôte où l’instance DataSunrise est installée, numéro de port de l’UI web de l’instance (11000, par défaut).
- Dans l’onglet Emplacement du Dictionnaire, spécifiez la base de données pour stocker la configuration DataSunrise (Dictionnaire). Tous les serveurs configurés pour utiliser cette base de données partageront des paramètres de configuration communs (y compris les identifiants communs pour accéder aux interfaces web).
Référez-vous au Guide d’Administration DataSunrise pour des instructions plus détaillées sur le mode haute disponibilité de DataSunrise. Assurez-vous également que la même version du produit est installée sur tous les serveurs.
Créer une Instance
Ensuite, nous devons créer une instance DataSunrise sur l’hôte virtuel où MySQL est installé et ouvrir des proxies sur les machines qui se connecteront à la base de données MySQL.
Pour créer une instance, effectuez les opérations suivantes sur la machine maître :
- Entrez dans l’interface graphique de DataSunrise et allez dans la sous-section Bases de Données de la section Configurations.
- Cliquez sur le bouton Database +.
- Entrez le nom d’hôte, le numéro de port et d’autres informations requises.
- Une fois l’instance créée, sélectionnez la nouvelle instance créée dans la liste et cliquez sur Modifier.
- Une fenêtre avec les configurations de l’instance s’ouvrira, cliquez sur le bouton Proxy +.
- Spécifiez le serveur, le nom d’hôte et le numéro de port (mysql0, 192.168.1.100, 3306 respectivement) et cliquez sur Sauvegarder.
- Ouvrez les proxies sur les machines de l’esclave avec la même instance en spécifiant le nom du serveur correspondant et le nom d’hôte pour chaque proxy.
À la fin, la configuration de l’instance ressemblera à ceci :
Configurer HAProxy pour MySQL
Configurer HAProxy pour les systèmes de gestion de bases de données est assez simple. Nous allons configurer HAProxy pour qu’il fonctionne comme distributeur de connexion pour les proxies DataSunrise (192.168.1.100:3306, 192.101.1.101:3306, 192.168.1.102:3306).
Après avoir installé HAProxy, ouvrez le fichier mentionné /etc/haproxy/haproxy.cfg et éditez le bloc de configuration ‘listen’ comme suit :
listen af_mysql_balancer
mode tcp
bind *:3306
balance leastconn
server mysql0 192.168.1.100:3306 check
server mysql1 192.168.1.101:3306 check
server mysql2 192.168.1.102:3306 check HAProxy effectuera des vérifications de l’état et distribuera les connexions en fonction du nombre de connexions sur le nœud du serveur, redirigeant l’utilisateur vers le serveur avec le moins de connexions.
balance <algorithm> est pour sélectionner les algorithmes d’équilibrage.
| roundrobin | Round Robin est l’algorithme par défaut, il sélectionne les serveurs à tour de rôle. |
| leastconn | Avec cet algorithme, HAProxy dirige chaque nouvel utilisateur vers le serveur avec le plus petit nombre de connexions. |
| source | L’algorithme pour diriger les utilisateurs vers les serveurs en fonction du hachage de l’adresse IP de l’utilisateur. |
Pour la liste complète des algorithmes d’équilibrage, référez-vous au Manuel de Configuration HAProxy.
En cas de panne du serveur actuellement utilisé par un utilisateur, la connexion sera fermée. L’utilisateur devra se reconnecter et HAProxy ouvrira une nouvelle connexion de base de données au serveur qui est en marche et a le moins de connexions.
Tous les autres systèmes de gestion de bases de données peuvent être configurés de la même manière, seuls les ports doivent être modifiés.
Configurer HAProxy comme répartition de charge pour le service backend DataSunrise (UI)
Dans cette section, nous examinerons les étapes pour effectuer la répartition de charge pour trois proxies DataSunrise en mode Haute Disponibilité aux adresses suivantes : 192.168.1.100, 192.168.1.101, 192.168.1.102.
Installez HAProxy sur un serveur séparé et ouvrez /etc/haproxy/haproxy.cfg avec n’importe quel éditeur de texte. Spécifiez la configuration du listener comme suit :
listen af_gui_balancer
timeout client 50000
timeout server 50000
mode http
bind *:11000 ssl crt /home/anon/proxy.pem
redirect scheme https if !{ ssl_fc }
cookie HA_BACKEND_ID insert
balance leastconn
server node0 192.168.1.100:11000 ssl verify none check cookie 0
server node1 192.168.1.101:11000 ssl verify none check cookie 1
server node2 192.168.1.102:11000 ssl verify none check cookie 2 Explication de la Configuration
Temps d’Inactivité de l’Utilisateur
timeout client <timeout> – définit la durée maximale d’inactivité de l’utilisateur après laquelle la connexion sera fermée (en millisecondes).
timeout server <timeout> – définit la durée maximale d’inactivité du serveur après laquelle la connexion sera fermée (en millisecondes).
Protocole d’Instance
mode { tcp|http } – définit le protocole de l’instance. Dans notre cas, l’équilibrage sera effectué au niveau du protocole HTTP. La requête client sera analysée en profondeur avant de se connecter à un serveur. Toute requête qui n’est pas conforme à la RFC sera rejetée. Le filtrage, le traitement et la commutation de la couche 7 seront possibles.
HAProxy peut également équilibrer au niveau TCP, mais les spécificités des applications Web ayant une condition de session utilisateur rendent difficile l’exécution d’un équilibrage de charge correct sans possibilité d’analyser ou de modifier certaines parties des requêtes HTTP. Nous utilisons le mode http car nous avons besoin que HAProxy assigne et lise un cookie de persistance qui permettra à HAProxy de déterminer le serveur vers lequel l’utilisateur doit être dirigé. Ainsi, le serveur Web fonctionnera correctement avec la session utilisateur.
Adresse et Port d’Écoute
bind [<address>]:<port_range> – l’option bind définit une ou plusieurs adresses d’écoute et ports dans un frontend. <address> peut être un nom d’hôte, une adresse IPv4, une adresse IPv6 ou ‘*’. ‘*’ signifie que le port sera ouvert sur toutes les adresses IP disponibles.
ssl crt /home/anon/proxy.pem – L’option ssl active le déchiffrement SSL qui nécessite des certificats. Les certificats et les clés seront pris à partir du fichier /home/anon/proxy.pem. Les utilisateurs système doivent avoir un accès en lecture au fichier.
Le contenu du fichier pem doit être au format suivant :
-----BEGIN CERTIFICATE----- HLDXjCDSAkY... -----END CERTIFICATE----- -----BEGIN RSA PRIVATE KEY----- HLDEpgIBDSKC.... -----END RSA PRIVATE KEY-----
Redirection
redirect scheme https if !{ ssl_fc } la configuration suivante redirige toutes les connexions HTTP en texte clair sur le port 11000 vers le schéma HTTPS. Ainsi, les utilisateurs ne pourront pas utiliser le service d’administration sans cryptage.
Cookie Persistant
cookie HA_BACKEND_ID insert. L’option donnée définit le cookie persistant. Après la première requête, HAProxy envoie un cookie à l’utilisateur. Selon la valeur du cookie, HAProxy déterminera quel nœud de serveur doit être utilisé pour les requêtes ultérieures de l’utilisateur.
HA_BACKEND_ID est le nom du cookie.
L’option insert définit que HAProxy attribuera ces valeurs de cookie après la première requête. La valeur du cookie persistant est utilisée jusqu’à ce que l’utilisateur efface les cookies de son navigateur ou termine la session.
Les trois dernières lignes définissent les instances.
node0 est un nom arbitraire de l’instance utilisé uniquement pour l’identification en termes de HAProxy.
192.168.1.100:11000 – l’adresse et le port de l’instance.
ssl – définit que l’instance accepte les connexions https.
verify [none | optional | required]. Par défaut, le réglage est défini sur none, ce qui signifie que le certificat SSL envoyé par le serveur ne sera pas vérifié, c’est-à-dire que HAProxy fera confiance au certificat du service backend DataSunrise.
L’option check active le mécanisme de vérification de l’état. Avant de rediriger la requête client vers le nœud, HAProxy vérifie si le nœud est disponible.
cookie <value> – le paramètre définit la valeur du cookie attribuée au serveur.
Sauvegardez les modifications de configuration et relancez HAProxy.
Conclusion
En conséquence, nous aurons la configuration permettant à HAProxy de fonctionner comme suit :
- Un utilisateur se connecte à HAProxy.
- HAProxy effectue des vérifications de l’état des serveurs.
- HAProxy redirige l’utilisateur vers le nœud de serveur avec la plus faible charge, ce qui équilibre réellement la charge.
HAProxy fonctionne sous Linux et Solaris. Pour le système d’exploitation Windows, essayez la solution plus avancée Nginx.
Si vous avez besoin d’aide pour configurer HAProxy ou DataSunrise en mode haute disponibilité, n’hésitez pas à nous contacter. Nos ingénieurs support vous aideront.
