Partage de technologie

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

L'architecture haute disponibilité du cluster lvs est uniquement destinée à la haute disponibilité du planificateur.

Implémenter les planificateurs principaux et de sauvegarde basés sur vrrp

Architecture haute disponibilité haute disponibilité

Planificateur principal et planificateur de sauvegarde (il peut y avoir plusieurs planificateurs de sauvegarde)

Lorsque le planificateur fonctionne normalement, l'équipement est complètement redondant (veille). Il ne participe pas au fonctionnement du cluster. Ce n'est qu'en cas de panne du planificateur principal que la sauvegarde prendra en charge le travail du planificateur principal. Une fois que le planificateur principal aura récupéré sa fonction, le maître continuera à servir d'entrée au cluster. , et la sauvegarde continuera à être dans un état redondant (en fonction de la priorité).

Keepalive est basé sur le protocole vrrp pour implémenter la solution haute disponibilité LVS.

1. Adresse de multidiffusion :

224.0.0.18 communique en fonction de l'adresse de multidiffusion. Les appareils principal et secondaire envoient des messages pour déterminer si l'autre partie est en vie.

2. Déterminez les positions principale et secondaire en fonction de la priorité.

3. Basculement : si la machine principale raccroche, la machine de sauvegarde continuera à fonctionner. Lorsque la machine principale sera restaurée, la machine de sauvegarde continuera d'attendre.

4. La commutation entre primaire et secondaire est la commutation d'adresse VIP.

Keepalive apparaît spécifiquement pour LVS, mais il n'est pas exclusif à LVS.

module principal : le module principal de keepalive, responsable du démarrage et de la maintenance du processus principal ainsi que du chargement des fichiers de configuration globaux

module vrrp : le module qui implémente le protocole vrrp, qui est le module de fonction principal

module de vérification : responsable du contrôle de santé et peut également vérifier l'état du serveur réel en arrière-plan.

Sur la base de l'expérience du mode DR dans le chapitre précédent, nous ajoutons quelques configurations. Cette fois, deux planificateurs sont utilisés, un principal et un de secours.

Installez d’abord keepalive sur le planificateur

yum -y install keepalived

Une fois l'installation terminée

Modifions le fichier keepalived.conf

[root@test1 ~]# vim /etc/keepalived/keepalived.conf
   notification_email_from [email protected]
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_01
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
   vrrp_iptables
}
 
vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 120
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.124.100
    }
}
 
virtual_server 192.168.124.100 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR
    persistence_timeout 50
    protocol TCP
 
    real_server 192.168.124.40 80 {
        weight 1
            TCP_CHECK {
            connect_port 80
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
 
    real_server 192.168.124.50 80 {
                                                                     9,1           36%

Copiez le fichier de configuration du premier planificateur vers le deuxième planificateur

scp root@192.168.233.10:/etc/keepallved/keepallved.conf
/etc/keepallved

Puis changez la configuration

Priorité au primaire et au secondaire

Ajouter une option iptables

De cette façon, l'accès aux règles keepalive ne sera pas arrêté dans la table des règles ipetables.

[root@localhost ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.124.100:80 rr persistent 50
  -> 192.168.124.40:80            Route   1      0          0
  -> 192.168.124.50:80            Route   1      0          0

Vérifiez-le

Puis redémarrez tout

Jetez un oeil aux résultats des clients

Arrêtons d'abord le planificateur principal

stsemctl stop keepalived.servers

Le planificateur de sauvegarde prend en charge le travail du maître et continue de fonctionner.

Il s'agit de l'adresse VIP qui a été téléchargée sur le planificateur préparé. Le client y accède.

Peut toujours accéder

---

Résumer

Keepalived comprend principalement trois modules : core (module principal, responsable du démarrage du processus principal, de la maintenance et du chargement et de l'analyse des fichiers de configuration globale), check (module de vérification de l'état) et vrrp (implémentation du protocole vrrp).

Le principe de fonctionnement de Keepalived est basé sur le protocole VRRP. Plusieurs serveurs fournissant les mêmes fonctions sont constitués en un groupe de serveurs doté d'un maître et de plusieurs sauvegardes. Il y a un VIP sur le maître qui fournit des services au monde extérieur (la route par défaut des autres machines du LAN où se trouve le serveur est ce VIP. Le maître enverra la multidiffusion lorsque la sauvegarde ne peut pas recevoir le paquet VRRP). pensera que le maître est en panne, puis, selon la priorité du niveau VRRP, élire une sauvegarde pour devenir le nouveau maître.

Lors de la configuration de LVS + Keepalived, vous devez généralement installer les logiciels associés (tels que ipvsadm, keepalived) sur les nœuds maître et de sauvegarde, et configurer le fichier keepalived.conf. Par exemple, dans le fichier de configuration du nœud maître, vous devez spécifier l'état (state) comme maître, l'interface réseau (interface), l'ID de route virtuelle (virtual_router_id), la priorité (priority), l'intervalle de publication (advert_int), les informations d'authentification. (authentification) Et l'adresse IP virtuelle (virtual_ipaddress), etc. ; la configuration du nœud de sauvegarde est similaire, mais le statut est de sauvegarde et la priorité est généralement inférieure à celle du maître.

Une fois la configuration terminée, redémarrez le service keepalived pour obtenir un équilibrage de charge haute disponibilité. Lorsque le nœud maître tombe en panne, VIP basculera automatiquement vers le nœud de sauvegarde pour garantir un accès normal au service ; une fois le maître récupéré, il servira à nouveau de nœud de chargement principal. De plus, le serveur réel (rs) peut également être configuré en conséquence. Par exemple, lors de l'utilisation du modèle DR pour la communication, lo doit être configuré en tant que VIP sur la carte réseau de rs.

De cette manière, la combinaison LVS + Keepalived peut atteindre les objectifs suivants : le client accède au service via VIP, et la demande sera distribuée selon les règles de configuration lorsque le nœud d'équilibrage de charge du maître échoue, il peut automatiquement passer à la sauvegarde ; nœud pour garantir que le service est normal ; lorsqu'un certain rs Lorsqu'un nœud tombe en panne, le nœud peut être automatiquement supprimé et peut être à nouveau ajouté au cluster après la récupération.

Dans les applications réelles, il faut prêter attention aux éléments pertinents, tels que l'adresse IP configurée par virtual_ipaddress dans le fichier de configuration Keepalived doit se trouver dans le même segment de réseau ; plus la valeur de priorité est élevée, plus la probabilité que le nœud devienne le maître est grande ; node ; plus la valeur de advert_int est petite, plus la probabilité que le nœud envoie des messages VRRP est élevée. Dans le même temps, des facteurs tels que l'environnement réseau et les performances du serveur doivent également être pris en compte pour garantir la stabilité et le fonctionnement efficace de l'ensemble du système.