Répartition de Charge avec HAProxy
HAProxy est un logiciel gratuit qui fonctionne comme un répartiteur de charge et un serveur proxy inverse pour les applications basées sur TCP et HTTP. Cet outil distribue les demandes de connexion entre plusieurs nœuds de serveur. Avec très peu de ressources, il permet de gérer de grands volumes de trafic HTTP et HTTPS. De plus, HAProxy effectue des contrôles de santé du serveur et redirige les utilisateurs vers un nœud en état de marche en cas de panne d’un des serveurs, ce qui en fait une solution de basculement utile.
Compte tenu des avantages précédemment mentionnés, nous avons configuré HAProxy pour distribuer les connexions pour MySQL RDBMS et notre interface utilisateur.
Dans cet article, nous allons examiner les étapes à suivre pour effectuer la répartition de charge pour trois proxys 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 à suivre 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 implémenter le mode Haute Disponibilité sur DataSunrise, effectuez les étapes 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 actuelle de DataSunrise : nom du serveur, nom d’hôte où l’instance DataSunrise est installée, numéro de port de l’interface 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 de DataSunrise (Dictionnaire). Tous les serveurs configurés pour utiliser cette base de données partageront des paramètres de configuration communs (y compris des 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éation d’Instance
Ensuite, nous devons créer une instance DataSunrise sur l’hôte virtuel où MySQL est installé et ouvrir des proxys sur des machines qui se connecteront à la base de données MySQL.
Pour créer une instance, effectuez les opérations suivantes sur la machine principale :
- 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 Base de Données +.
- Saisissez le nom d’hôte, le numéro de port et les autres informations requises.
- Une fois l’instance créée, sélectionnez la nouvelle instance créée dans la liste et cliquez sur Éditer.
- 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 Enregistrer.
- Ouvrez les proxys sur les machines secondaires de la même instance en précisant le nom du serveur correspondant et le nom d’hôte pour chaque proxy.
À la fin, la configuration de l’instance ressemblera à ceci :
Configuration de HAProxy pour MySQL
Configurer HAProxy pour les systèmes de gestion de bases de données est assez simple. Ci-dessous, nous allons configurer HAProxy pour fonctionner comme un distributeur de connexion pour les proxys 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é ci-dessus /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 contrôles de santé et distribuera les connexions en fonction du nombre de connexions sur le nœud de serveur, redirigeant l’utilisateur vers le serveur avec le moins de connexions.
balance <algorithme> est utilisé pour sélectionner les algorithmes de répartition.
| 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 ayant le moins de connexions. |
| source | L’algorithme dirige les utilisateurs vers les serveurs en fonction d’un hachage de l’adresse IP de l’utilisateur. |
Si le serveur actuellement utilisé par un utilisateur est en panne, la connexion sera fermée. L’utilisateur devra se reconnecter et HAProxy ouvrira une nouvelle connexion à la base de données sur le serveur disponible avec 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.
Configuration de HAProxy comme répartiteur de charge pour le service backend de DataSunrise (GUI)
Dans cette section, nous considérerons les étapes à suivre pour effectuer la répartition de charge pour trois proxys 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 de l’écouteur 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 Répartition de la Configuration
Temps d’Inactivité des Utilisateurs
timeout client <timeout> – définit la période d’inactivité maximale de l’utilisateur après laquelle la connexion sera fermée (millisecondes).timeout server <timeout> – définit la période d’inactivité maximale du serveur après laquelle la connexion sera fermée (millisecondes).
Protocole d’Instance
mode { tcp|http } – définit le protocole de l’instance. Dans notre cas, la répartition sera effectuée au niveau du protocole HTTP. La requête client sera analysée en profondeur avant de se connecter à un serveur. Toute requête non conforme au RFC sera rejetée. Le filtrage, le traitement et le basculement de niveau 7 seront possibles. HAProxy peut également effectuer la répartition au niveau TCP, mais les spécificités des applications web avec une session utilisateur rendent difficile la répartition correcte sans opportunité d’analyser ou de modifier certaines parties des requêtes HTTP. Nous utilisons le mode http car nous avons besoin que HAProxy attribue 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 [<adresse>]:<port_range> – l’option bind définit une ou plusieurs adresses et ports d’écoute dans un frontend. <adresse> 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 permet le déchiffrement SSL ce qui nécessite des certificats. Les certificats et les clés seront tirés du fichier /home/anon/proxy.pem. Les utilisateurs du 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 brut sur le port 11000 vers le schéma HTTPS. Ainsi, les utilisateurs ne pourront pas utiliser le service d’administration sans chiffrement.
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 serveur doit être utilisé pour les requêtes suivantes 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 du 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 paramètre est réglé 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 permet le mécanisme de vérification de l’état de santé. Avant de rediriger la requête du client vers le nœud, HAProxy vérifie si le nœud est disponible. cookie <valeur> – le paramètre définit la valeur du cookie attribué au serveur.
Enregistrez 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 vérifie l’état des serveurs.
- HAProxy redirige l’utilisateur vers le nœud serveur avec la charge la plus faible, ce qui équilibre effectivement 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 de support vous aideront.
