Lorsque vous entendez le terme « haute disponibilité », vous pensez peut-être à de grands environnements complexes avec des technologies obscures qui sont hors de portée de l'administrateur système moyen. Mais la haute disponibilité de base n'a pas besoin d'être compliquée :dans cette série, vous apprendrez à mettre en œuvre des services de base hautement disponibles à l'aide de Keepalived . Je vais vous présenter des situations de basculement simples, ainsi qu'une configuration plus complexe utilisée pour répondre à des événements externes et déclencher des basculements. Tout d'abord, nous allons commencer par les principes de base de Keepalived et le Virtual Router Redundancy Protocol (VRRP).
Cet article est le premier d'une série de trois articles couvrant tout, de la configuration de base aux concepts avancés de Linux HA.
Les bases de Keepalived et VRRP
Symboles de réseau dans les schémas disponibles via VRT Network Equipment Extension, CC BY-SA 3.0.
Si vous avez lu certains des articles sur la mise en réseau Enable Sysadmin, vous savez que tous les administrateurs système peuvent bénéficier d'une solide compréhension des principes fondamentaux du réseau. Connaissance de Keepalived n'est pas différent. Le protocole qui sous-tend le basculement HA est le Virtual Router Redundancy Protocol (VRRP) et Keepalived fournit à la fois une version 2 et une version 3 de l'implémentation de ce protocole.
Cela peut sembler étrange que nous utilisions un protocole conçu pour les routeurs sur nos serveurs. Il s'avère que la même technologie de mise en réseau utilisée pour assurer la redondance des équipements réseau peut également fournir une redondance dans les environnements de serveur. Les routeurs sont souvent déployés par paires, où un routeur est actif et un autre en veille, prêt à fonctionner en cas de défaillance du routeur actif. Ces mêmes concepts peuvent être appliqués aux serveurs.
VRRP utilise le concept d'adresse IP virtuelle (VIP). Un ou plusieurs hôtes (routeurs, serveurs, etc.) participent à une élection pour déterminer l'hôte qui contrôlera ce VIP. Un seul hôte (le maître) contrôle le VIP à la fois. Si le maître échoue, VRRP fournit des mécanismes pour détecter cette défaillance et basculer rapidement vers un hôte de secours. Dans la topologie ci-dessus, server1 est le maître et est responsable de l'adresse IP 192.168.122.200. Si le serveur1 échoue, le serveur2 prend le relais de cette IP.
Il convient également de savoir que Keepalived fournit plus qu'un simple VRRP la mise en oeuvre. Keepalived a également la possibilité de configurer des serveurs virtuels IP Linux pour l'équilibrage de charge. La configuration d'IPVS sort du cadre de cette série, mais il est bon de savoir que vous pouvez utiliser Keepalived pour configurer un équilibreur de charge redondant tout-en-un pour votre environnement.
Fonctionnement du protocole VRRP
VRRP Le comportement de est spécifié par RFC 3768 (version 2) et RFC 5798 (version 3). J'utiliserai la version 2 dans cette série d'articles. Bien que l'examen de la RFC soit le meilleur moyen de bien comprendre le comportement du protocole, vous n'avez pas besoin d'être un expert pour commencer à utiliser Keepalived dans votre environnement. Cependant, une connaissance de base de VRRP Le comportement de vous permettra de mieux vous positionner pour l'utiliser et le dépanner dans votre environnement.
La première étape de VRRP est l'élection d'un maître pour déterminer quel serveur (ou routeur, dans la spécification du protocole) détiendra l'adresse IP partagée. VRRP les serveurs sont configurés avec une valeur de priorité, qui peut être considérée comme un poids. Le serveur avec la priorité la plus élevée sera le propriétaire d'un VRRP adresse. La spécification indique que la priorité du maître doit être 255 , avec tous les serveurs de sauvegarde ayant une valeur inférieure à 255 . En pratique, une priorité de 255 n'est pas strictement nécessaire car le protocole sélectionnera le serveur avec la priorité la plus élevée, même si ce n'est pas 255.
Une fois qu'un maître est établi, tous les autres serveurs écoutent les messages périodiques envoyés par le maître pour indiquer qu'il est toujours actif. Le maître envoie ces annonces à intervalles réguliers. Tant que le maître est en vie, il desservira le trafic pour le VIP et enverra des publicités. Si le maître se déconnecte pour une raison quelconque, le serveur de sauvegarde avec la priorité la plus élevée prendra le relais. De même, une fonctionnalité appelée préemption peut permettre à tout serveur ayant une priorité plus élevée de devenir automatiquement maître lorsqu'il est en ligne.
Lorsqu'un maître se connecte pour la première fois et prend le contrôle d'une adresse IP, il diffuse un ARP gratuit. Ce message informe les autres serveurs du réseau de l'adresse MAC associée au VIP afin qu'ils puissent adresser correctement leur trafic au niveau de la couche 2. Il accélère également le basculement du VIP :les hôtes n'ont pas à attendre que leurs temporisateurs ARP expirent et peuvent mettez simplement à jour leurs tables ARP avec l'adresse MAC correcte pour l'hôte qui possède le VIP.
Format du paquet
Creuser dans les aspects théoriques du fonctionnement d'un protocole peut être un peu ennuyeux, mais c'est essentiel pour comprendre le fonctionnement d'une technologie (et pour la dépanner lorsqu'elle tombe en panne). Si vous regardez la structure de paquet d'un VRRP publicité utilisant Wireshark, certaines choses deviennent plus claires.
Tout d'abord, vous remarquerez que les adresses de destination Ethernet et IP sont multicast adresses. Le trafic de multidiffusion, comme son nom l'indique, est envoyé à plusieurs hôtes sur un réseau qui "écoutent" cette adresse de multidiffusion. La plupart des réseaux évitent une configuration multidiffusion complexe, de sorte que le trafic multidiffusion pour VRRP deviendra le trafic de diffusion sur le segment de réseau local et ira à tous les hôtes.
Vous pouvez également voir que VRRP n'est ni TCP ni UDP. VRRP utilise le numéro de protocole IP 112 pour son fonctionnement. Connaître ce numéro de protocole peut être important, car vous devrez peut-être configurer le pare-feu de votre hôte pour autoriser ce trafic depuis le VRRP serveurs dans votre environnement.
Une fois que vous commencez à regarder le VRRP section du paquet, vous remarquerez qu'il contient toutes les informations nécessaires pour élire un maître et informer les autres serveurs du maître actuel :
- L'ID de routeur virtuel (VRID) est un identifiant unique pour un
VRRPinstance et ses adresses IP (il peut y en avoir plusieurs) sur un réseau. Vous devez éviter de réutiliser des VRID sur le même réseau local, mais ils peuvent être réutilisés en toute sécurité sur différents réseaux de couche 2. - La priorité est la priorité de l'hôte qui envoie la publicité. Une fois qu'un maître est élu, c'est quelle que soit la priorité définie du maître. Le strict respect de la spécification doit utiliser
255pour la priorité du maître, mais de nombreuses configurations choisissent une valeur différente. - Le type d'authentification et la chaîne d'authentification contiennent un simple mot de passe texte pour authentifier les membres du
VRRPgroupe les uns avec les autres. - L'intervalle de publicité indique la fréquence à laquelle les publicités seront envoyées par le maître. Dans ce cas, le maître enverra une publicité toutes les secondes.
- L'adresse IP contient une ou plusieurs adresses IP dont le maître est responsable. Bien que cette série ne couvre que le basculement d'une seule adresse IP, il est possible d'avoir
VRRPgérer plusieurs adresses IP.
Conclusion
Cet article vous a présenté le protocole de base qui sous-tend Keepalived , une implémentation logicielle de VRRP sur Linux. Bien que l'examen des spécificités des protocoles puisse sembler ennuyeux, il est essentiel de comprendre les protocoles réseau fonctionnant dans votre environnement afin de pouvoir les configurer et les dépanner efficacement. Dans le prochain article, vous apprendrez comment installer et configurer Keepalived .
[ Besoin d'en savoir plus sur l'administration système Linux ? Envisagez de suivre un cours d'administration système Red Hat. ]