L'adresse IP virtuelle est une adresse IP qui ne correspond pas à une interface réseau physique réelle. Il flotte entre plusieurs interfaces réseau et une seule interface active contiendra l'adresse IP pour la tolérance aux pannes et la mobilité. ClusterControl utilise Keepalived pour fournir une intégration d'adresse IP virtuelle avec des équilibreurs de charge de base de données afin d'éliminer tout point de défaillance unique (SPOF) au niveau de l'équilibreur de charge.
Dans cet article de blog, nous vous montrerons comment ClusterControl configure l'adresse IP virtuelle et ce à quoi vous pouvez vous attendre en cas de basculement ou de restauration automatique. La compréhension de ce comportement est primordiale afin de minimiser toute interruption de service, et de fluidifier les opérations de maintenance qui doivent être réalisées ponctuellement.
Exigences
Certaines conditions sont requises pour exécuter Keepalived sur votre réseau :
- Le protocole IP 112 (Virtual Router Redundancy Protocol - VRRP) doit être pris en charge dans le réseau. Certains réseaux désactivent la prise en charge de VRRP, en particulier les communications inter-VLAN. Veuillez vérifier cela auprès de l'administrateur réseau.
- Si vous utilisez la multidiffusion, le réseau doit prendre en charge la demande de multidiffusion (utilisez ip a | grep -i multicast). Sinon, vous pouvez utiliser l'unicast via unicast_src_ip et unicast_peer options. L'utilisation de la multidiffusion est utile lorsque vous disposez d'un environnement dynamique tel qu'un environnement cloud ou lorsque l'attribution d'adresses IP est effectuée via DHCP.
- Un ensemble d'instances VRRP doit utiliser un virtual_router_id unique valeur, qui ne peut pas être partagée entre d'autres instances. Sinon, vous verrez de faux paquets et casserez probablement le commutateur maître-sauvegarde.
- Si vous utilisez un environnement cloud comme AWS, vous devrez probablement utiliser un script externe (astuce :utilisez l'option "notify") pour dissocier et associer l'adresse IP virtuelle (Elastic IP) afin qu'elle soit reconnue et routable par le routeur.
Déployer Keepalived
Pour installer Keepalived via ClusterControl, vous avez besoin de deux équilibreurs de charge ou plus installés par ou importés dans ClusterControl. Pour une utilisation en production, nous recommandons fortement que le logiciel d'équilibrage de charge soit exécuté sur un hôte autonome et non colocalisé avec vos nœuds de base de données.
Une fois que vous avez au moins deux équilibreurs de charge gérés par ClusterControl, pour installer Keepalived et activer l'adresse IP virtuelle, allez simplement dans ClusterControl -> choisissez le cluster -> Gérer -> Load Balancer -> Keepalived :
La plupart des champs sont explicites. Vous pouvez déployer un nouvel ensemble d'instances Keepalived ou importer des instances Keepalived existantes. Les champs importants incluent l'adresse IP virtuelle réelle et l'interface réseau où l'adresse IP virtuelle existera. Si les hôtes utilisent deux noms d'interface différents, spécifiez le nom d'interface de l'hôte Keepalived 1, puis modifiez manuellement le fichier de configuration sur Keepalived 2 avec un nom d'interface correct ultérieurement.
Instance VRRP
Au moment de la rédaction de cet article, ClusterControl v1.5.1 installe Keepalived v1.3.5 (selon le système d'exploitation hôte) et voici ce qui est configuré pour l'instance VRRP :
vrrp_instance VI_PROXYSQL {
interface eth0 # interface to monitor
state MASTER
virtual_router_id 51 # Assign one ID for this route
priority 100
unicast_src_ip 10.0.0.246
unicast_peer {
10.0.0.204
}
virtual_ipaddress {
10.0.0.100 # the virtual IP
}
track_script {
chk_proxysql
}
# notify /usr/local/bin/notify_keepalived.sh
}ClusterControl configure l'instance VRRP pour communiquer via la monodiffusion. Avec unicast, nous devons définir tous les pairs unicast des autres nœuds Keepalived. Il est moins dynamique mais fonctionne la plupart du temps. Avec la multidiffusion, vous pouvez supprimer ces lignes (unicast_*) et compter sur l'adresse IP de multidiffusion pour la découverte d'hôte et l'appairage. C'est plus simple mais il est souvent bloqué par les administrateurs réseau.
La partie suivante est l'adresse IP virtuelle. Vous pouvez spécifier plusieurs adresses IP virtuelles par instance VRRP, séparées par une nouvelle ligne. L'équilibrage de charge dans HAProxy/ProxySQL et Keepalived en même temps nécessite également la possibilité de se lier à une adresse IP qui n'est pas locale, ce qui signifie qu'elle n'est pas attribuée à un appareil sur le système local. Cela permet à une instance d'équilibreur de charge en cours d'exécution de se lier à une adresse IP qui n'est pas locale pour le basculement. Ainsi ClusterControl configure également net.ipv4.ip_nonlocal_bind=1 dans /etc/sysctl.conf.
La directive suivante est le track_script , où vous pouvez spécifier le script pour le processus de vérification de l'état qui est expliqué dans la section suivante.
Vérifications de santé
ClusterControl configure Keepalived pour effectuer des vérifications de l'état en examinant le code d'erreur renvoyé par le track_script. Dans le fichier de configuration de Keepalived, qui se trouve par défaut dans /etc/keepalived/keepalived.conf, vous devriez voir quelque chose comme ceci :
track_script {
chk_proxysql
}Où il appelle chk_proxysql qui contient :
vrrp_script chk_proxysql {
script "killall -0 proxysql" # verify the pid existence
interval 2 # check every 2 seconds
weight 2 # add 2 points of prio if OK
}La commande "killall -0" renvoie le code de sortie 0 si un processus appelé "proxysql" est en cours d'exécution sur l'hôte. Sinon, l'instance devrait se rétrograder et commencer à lancer le basculement, comme expliqué dans la section suivante. Notez que Keepalived prend également en charge les composants Linux Virtual Server (LVS) pour effectuer des vérifications de l'état, où il est également capable d'équilibrer la charge des connexions TCP/IP, comme HAProxy, mais cela sort du cadre de cet article de blog.
Simulation du basculement
Pour les composants VRRP, Keepalived utilise le protocole VRRP (protocole IP 112) pour communiquer entre les instances VRRP. La valeur de priorité plus élevée d'un MASTER signifie que le maître aura toujours le privilège le plus élevé pour détenir l'adresse IP virtuelle, sauf si vous configurez l'instance avec "nopreempt". Prenons un exemple pour mieux expliquer le flux de basculement et de rétablissement. Considérez le schéma suivant :
Il y a trois instances ProxySQL devant trois nœuds MySQL Galera. Chaque hôte ProxySQL est configuré avec Keepalived en tant que MASTER avec le numéro de priorité suivant :
- ProxySQL1 - priorité 101
- ProxySQL2 - priorité 100
- ProxySQL3 - priorité 99
Lorsque Keepalived est démarré en tant que MASTER, il annoncera d'abord le numéro de priorité aux membres, puis s'associera à l'adresse IP virtuelle. Contrairement à l'instance BACKUP, elle observera uniquement l'annonce et n'attribuera l'adresse IP virtuelle qu'une fois qu'elle aura confirmé qu'elle peut s'élever au rang de MASTER.
Notez que si vous tuez manuellement le processus "proxysql" ou "haproxy" via la commande kill, le gestionnaire de processus systemd tentera par défaut de récupérer le processus qui est arrêté sans grâce. De plus, si la récupération automatique de ClusterControl est activée, ClusterControl tentera toujours de démarrer le processus même si vous effectuez un arrêt propre via systemd (systemctl stop proxysql). Pour simuler au mieux l'échec, nous suggérons à l'utilisateur de désactiver la fonction de récupération automatique de ClusterControl ou simplement d'arrêter le serveur ProxySQL pour interrompre la communication.
Si nous arrêtons ProxySQL1, l'adresse IP virtuelle sera basculée vers le prochain hôte qui détient une priorité plus élevée à ce moment particulier (qui est ProxySQL2) :
Vous verriez ce qui suit dans le journal système du nœud défaillant :
Feb 27 05:21:59 proxysql1 systemd: Unit proxysql.service entered failed state.
Feb 27 05:21:59 proxysql1 Keepalived_vrrp[12589]: /usr/bin/killall -0 proxysql exited with status 1
Feb 27 05:21:59 proxysql1 Keepalived_vrrp[12589]: VRRP_Script(chk_proxysql) failed
Feb 27 05:21:59 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Changing effective priority from 103 to 101
Feb 27 05:22:00 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Received advert with higher priority 102, ours 101
Feb 27 05:22:00 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Entering BACKUP STATE
Feb 27 05:22:00 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) removing protocol VIPs.Sur le nœud secondaire, ce qui suit s'est produit :
Feb 27 05:22:00 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) forcing a new MASTER election
Feb 27 05:22:01 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Transition to MASTER STATE
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Entering MASTER STATE
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) setting protocol VIPs.
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: Sending gratuitous ARP on eth0 for 10.0.0.100
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Sending/queueing gratuitous ARPs on eth0 for 10.0.0.100
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: Sending gratuitous ARP on eth0 for 10.0.0.100
Feb 27 05:22:02 proxysql2 avahi-daemon[346]: Registering new address record for 10.0.0.100 on eth0.IPv4.Dans ce cas, le basculement a pris environ 3 secondes, avec un temps de basculement maximal de intervalle + advert_int . Dans les coulisses, le point de terminaison de la base de données a changé et le trafic de la base de données est acheminé via ProxySQL2 sans que les applications ne s'en aperçoivent.
Lorsque ProxySQL1 reviendra en ligne, il forcera une nouvelle élection de MASTER et reprendra l'adresse IP en raison d'une priorité plus élevée :
Feb 27 05:38:34 proxysql1 Keepalived_vrrp[12589]: VRRP_Script(chk_proxysql) succeeded
Feb 27 05:38:35 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Changing effective priority from 101 to 103
Feb 27 05:38:36 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) forcing a new MASTER election
Feb 27 05:38:37 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Transition to MASTER STATE
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Entering MASTER STATE
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) setting protocol VIPs.
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: Sending gratuitous ARP on eth0 for 10.0.0.100
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Sending/queueing gratuitous ARPs on eth0 for 10.0.0.100
Feb 27 05:38:38 proxysql1 avahi-daemon[343]: Registering new address record for 10.0.0.100 on eth0.IPv4.Dans le même temps, ProxySQL2 passe à l'état BACKUP et supprime l'adresse IP virtuelle de l'interface réseau :
Feb 27 05:38:36 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Received advert with higher priority 103, ours 102
Feb 27 05:38:36 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Entering BACKUP STATE
Feb 27 05:38:36 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) removing protocol VIPs.
Feb 27 05:38:36 proxysql2 avahi-daemon[346]: Withdrawing address record for 10.0.0.100 on eth0.À ce stade, ProxySQL1 est de nouveau en ligne et devient l'équilibreur de charge actif qui dessert les connexions des applications et des clients. VRRP préemptera normalement un serveur de priorité inférieure lorsqu'un serveur de priorité supérieure est en ligne. Si vous souhaitez que l'adresse IP reste sur ProxySQL2 après le retour en ligne de ProxySQL1, utilisez l'option "nopreempt". Cela permet à la machine de priorité inférieure de conserver le rôle de maître, même lorsqu'une machine de priorité supérieure revient en ligne. Cependant, pour que cela fonctionne, l'état initial de cette entrée doit être BACKUP. Sinon, vous remarquerez la ligne suivante :
Feb 27 05:50:33 proxysql2 Keepalived_vrrp[6298]: (VI_PROXYSQL): Warning - nopreempt will not work with initial state MASTERÉtant donné que par défaut, ClusterControl configure tous les nœuds en tant que MASTER, vous devez configurer l'option de configuration suivante pour l'instance VRRP respective en conséquence :
vrrp_instance VI_PROXYSQL {
...
state BACKUP
nopreempt
...
}Redémarrez le processus Keepalived pour charger ces modifications. L'adresse IP virtuelle ne basculera vers ProxySQL1 ou ProxySQL3 (selon la priorité et le nœud disponible à ce moment-là) que si la vérification de l'état échoue sur ProxySQL2. Dans de nombreux cas, exécuter Keepalived sur deux hôtes suffira.
