Suite de cluster de Red Hat: Configuration et gestion d'un cluster | ||
---|---|---|
Précédent | Chapitre 12. Configuration des routeurs LVS avec l'Outil de configuration de Piranha | Suivant |
Le panneau VIRTUAL SERVERS affiche des informations sur chaque serveur virtuel actuellement configuré. Chaque entrée du tableau montre le statut du serveur virtuel, le nom du serveur, l'adresse IP virtuelle vers le serveur, le masque réseau de l'adresse IP virtuelle, le numéro du port de communication du service, le protocole utilisé et l'interface virtuelle du périphérique.
Chaque serveur affiché dans le panneau VIRTUAL SERVERS peut être configuré dans des panneaux suivants ou dans des sous-sections suivantes.
Pour ajouter un service, cliquez sur le bouton ADD. Pour supprimer un service, choisissez ce dernier en cliquant sur le bouton radio à côté du serveur virtuel et cliquez ensuite sur bouton DELETE.
Pour activer ou désactiver un serveur virtuel dans le tableau, cliquez sur le bouton radio qui lui est associé puis cliquez sur le bouton (DÉ)ACTIVATE.
Après l'ajout d'un serveur virtuel, vous pouvez le configurer en cliquant sur le bouton radio qui se trouve à gauche de ce service, puis sur le bouton EDIT pour afficher la sous-section VIRTUAL SERVER.
Le panneau de la sous-section VIRTUAL SERVER reproduit en Figure 12-6 vous permet de configurer un serveur virtuel individuel. Des liens vers des sous-sections concernant spécifiquement ce serveur virtuel se trouvent en haut de la page. Mais avant de configurer toute sous-section concernant de serveur virtuel, remplissez cette page et cliquez sur le bouton ACCEPT.
Entrez un nom descriptif permettant d'identifier le serveur virtuel. Ce nom n'est pas le nom d'hôte de la machine. Choisissez donc un mon descriptif et facilement identifiable. Vous pouvez même donner la référence du protocole utilisé par le serveur virtuel, comme HTTP.
Entrez le numéro de port au moyen duquel l'application de service communiquera. Cet exemple étant relatif aux services HTTP, le port 80 est utilisé.
Choisissez entre UDP et TCP dans le menu déroulant. Comme les serveurs Web communiquent généralement via le protocole TCP, ce dernier a été choisi pour l'exemple précédent.
Entrez l'adresse IP flottante du serveur virtuel dans ce champ texte.
À l'aide du menu déroulant, déterminez le masque réseau pour ce serveur virtuel.
N'entrez pas dans ce champ une valeur entière pour la balise pare-feu à moins que vous ne groupiez des protocoles multi-ports ou ne créiez un serveur virtuel multi-ports pour des protocoles séparés mais néanmoins apparentés. Dans cet exemple, le serveur virtuel ci-dessus a une balise pare-feu (ou Firewall Mark) de 80 parce que nous regroupons des connexions vers HTTP sur le port 80 et des connexions vers HTTPS sur le port 443 en utilisant pour la balise pare-feu une valeur de 80. La combinaison de la balise pare-feu avec la persistance garantira que des utilisateurs accédant à des pages Web sûres ou non, seront routés vers le même serveur réel, préservant ainsi l'état.
![]() | Attention |
---|---|
L'entrée d'une balise pare-feu dans ce champ permet à IPVS de préciser que des paquets portant cette balise pare-feu doivent être traités de la même manière. Ceci étant, vous devez effectuer des tâches de configuration supplémentaires en dehors de l'Outil de configuration de Piranha pour vraiment assigner des balises pare-feu. Pour des instructions sur la création de services multi-ports, consultez la Section 11.3. Pour des informations sur la création d'un serveur virtuel FTP haute disponibilité, consultez la Section 11.4. |
Entrez le nom du périphérique réseau auquel vous voulez lier l'adresse IP flottante définie dans le champ Virtual IP Address.
Vous devriez créer un alias pour l'adresse IP flottante vers l'interface Ethernet connectée au réseau public. Dans cet exemple, comme le réseau public est sur l'interface eth0, eth0:1 devrait être entré pour le nom de périphérique.
Entrez une valeur entière qui définit la durée, en secondes, devant s'écouler avant que le routeur LVS actif n'essaie de réintégrer un serveur réel dans le cluster après une défaillance.
Entrez une valeur entière qui définit la durée, en secondes, devant s'écouler avant qu'un serveur réel ne soit considéré comme mort et ne soit retiré du cluster.
En cliquant sur le bouton radio de Quiesce server, chaque fois que le noeud d'un nouveau serveur réel établit une connexion, la table de connexions moindres (least-connections) est réinitialisée à zéro afin que le routeur LVS actif achemine les requêtes comme si tous les serveurs réels venaient juste d'être ajoutés au cluster. Cette option évite qu'un nouveau serveur ne s'enlise dans un grand nombre de connexions lors de son entrée dans le cluster.
Le routeur LVS peut surveiller la charge sur les différents serveurs réels en utilisant soit rup soit ruptime. Si vous choisissez rup dans le menu déroulant, chaque serveur réel doit faire tourner le service rstatd. Si vous choisissez ruptime, chaque serveur réel doit faire tourner le service rwhod.
![]() | Attention |
---|---|
Contrôle de charge ne signifie pas répartition de charge. Le contrôle de charge associé aux algorithmes d'ordonnancement pondéré, peut entraîner un comportement d'ordonnancement difficile à prédire. En outre, si vous utilisez le contrôle de charge, les serveurs réels du cluster doivent être des machines Linux. |
Choisissez l'algorithme d'ordonnancement que vous préférez à partir du menu déroulant. La sélection par défaut est Weighted least-connection. Pour obtenir de plus amples informations sur les algorithmes d'ordonnancement (scheduling), consultez la Section 9.3.1.
Si un administrateur a besoin de connexions persistantes vers le serveur virtuel lors des transactions clientes, entrez dans le champ texte le nombre de secondes d'inactivité qui pourront s'écouler avant que le délai d'attente de la connexion ne soit dépassé.
![]() | Important |
---|---|
Si vous avez entré une valeur dans le champ Firewall Mark ci-dessus, vous devriez entrer également une valeur pour la persistance. En outre, si vous utilisez des balises pare-feu et la persistance en même temps, assurez-vous que la valeur de la persistance est bien la même pour chaque serveur virtuel avec la balise pare-feu. Pour obtenir de plus amples informations sur la persistance et sur les balises pare-feu, consultez la Section 9.5. |
Pour limiter la persistance à un sous-réseau particulier, choisissez le masque réseau approprié à partir du menu déroulant.
![]() | Remarque |
---|---|
Avant l'apparition des balises pare-feu, la persistance limitée par un sous-réseau était un moyen rudimentaire de grouper des connexions. Maintenant, il est préférable d'utiliser la persistance en association avec les balises pare-feu pour obtenir le même résultat. |
![]() | Attention |
---|---|
N'oubliez pas de cliquer sur le bouton ACCEPT après toute modification apportée à ce panneau, afin de garantir que, lors du choix d'un autre panneau, aucun changement ne soit perdu. |
En cliquant sur le lien de la sous-section REAL SERVER (serveur réel)qui se trouve en haut du panneau, la sous-section EDIT REAL SERVER (modifier serveur réel) s'affichera. Cette dernière affiche le statut du serveur hôte physique pour un service virtuel spécifique.
Cliquez sur le bouton ADD pour ajouter un nouveau serveur. Pour supprimer un serveur existant, choisissez le bouton radio à côté de ce service et cliquez sur le bouton DELETE. Cliquez sur le bouton EDIT pour charger le panneau EDIT REAL SERVER (modifier serveur réel) identique à celui reproduit dans la Figure 12-8.
Ce panneau comprend trois champs d'entrées :
Un nom descriptif pour le serveur réel.
![]() | Astuce |
---|---|
Ce nom n'est pas le nom d'hôte de la machine. Ainsi, choisissez un nom descriptif et facile à identifier. |
L'adresse IP du serveur réel. Comme le port de réception est déjà spécifié pour le serveur virtuel associé, n'ajoutez pas de numéro de port.
Une valeur entière indiquant la capacité de cet hôte par rapport à celle des autres hôtes du parc. La valeur peut être arbitraire, mais considérez-la comme un rapport entre les différents serveurs réels dans le cluster. Pour obtenir de plus amples informations sur le poids associé aux serveurs, consultez la Section 9.3.2.
![]() | Attention |
---|---|
N'oubliez pas de cliquer sur le bouton ACCEPT après toute modification apportée à ce panneau, afin de garantir que, lors du choix d'un autre panneau, aucun changement ne soit perdu. |
Cliquez sur le lien MONITORING SCRIPTS en haut de la page. La sous-section EDIT MONITORING SCRIPTS permet à l'administrateur de spécifier une séquence de chaînes envoyer/attendre (send/expect) pour vérifier que le service du serveur virtuel est bien opérationnel sur chaque serveur réel. C'est aussi l'endroit où l'administrateur peut spécifier des scripts personnalisés pour vérifier des services nécessitant des données dynamiques changeantes.
Pour une vérification plus avancée, vous pouvez utiliser ce champ pour spécifier le chemin d'accès à un script de vérification de services. Cette fonctionnalité est particulièrement utile pour des services ayant besoin de données dynamiques changeantes, comme HTTPS ou SSL.
Afin de pouvoir utiliser cette fonctionnalité, vous devez écrire un script qui renvoie une réponse textuelle : établissez-le en tant qu'exécutable et insérez son chemin d'accès dans le champ Sending Program (Programme envoyeur).
![]() | Astuce |
---|---|
Pour garantir la vérification de chaque serveur appartenant au parc de serveurs réels, utilisez l'indicateur spécifique %h après le chemin d'accès au script dans le champ Sending Program. Cet indicateur est remplacé par l'adresse IP de chaque serveur réel lorsque le script est appelé par le démon nanny. |
Ci-après figure un exemple de script que vous pouvez utiliser comme guide lors de la rédaction d'un script de vérification de service externe.
#!/bin/sh TEST=`dig -t soa example.com @$1 | grep -c dns.example.com if [ $TEST != "1" ]; then echo "OK else echo "FAIL" fi |
![]() | Remarque |
---|---|
Si un programme externe est spécifié dans le champ Sending Program, le champ Send n'est pas pris en compte. |
Entrez une chaîne que le démon nanny enverra à chaque serveur réel mentionné dans ce champ. Par défaut, le champ Send contient HTTP. Vous pouvez néanmoins modifier cette valeur selon vos besoins. Si vous laissez ce champ vierge, le démon nanny essaie d'ouvrir le port et, s'il réussit, suppose que le service est en cours d'exécution.
Une seule séquence Send est permise dans ce champ, et elle ne peut contenir que des caractères ASCII imprimables et les caractères d'échappement suivants :
\n pour une nouvelle ligne.
\r pour un retour automatique de chariot.
\t pour tabulation.
\ pour sauter le caractère suivant cette barre oblique.
Entrez la réponse textuelle que le serveur devrait renvoyer s'il fonctionne correctement. Si vous rédigez votre propre programme envoyeur (sending program), entrez la réponse que vous lui avez demandé d'envoyer en cas de bon fonctionnement.
![]() | Astuce |
---|---|
Pour déterminer ce que vous devez envoyer pour un service donné, vous pouvez ouvrir une connexion telnet vers le port sur le serveur réel et voir le résultat obtenu. Par exemple, si FTP indiquait 220 lors de la connexion, vous pourriez entrer quit dans le champ Send et 220 dans le champ Expect. |
![]() | Attention |
---|---|
N'oubliez pas de cliquer sur le bouton ACCEPT après toute modification apportée à ce panneau, afin de garantir que, lors du choix d'un autre panneau, aucun changement ne soit perdu. |
Une fois les serveurs virtuels configurés à l'aide de l'Outil de configuration de Piranha, vous devez copier les fichiers de configuration spécifiques sur le serveur LVS de secours. Pour obtenir de plus amples informations, consultez la Section 12.7.
Précédent | Sommaire | Suivant |
Redondance (REDUNDANCY) | Niveau supérieur | Synchronisation des fichiers de configuration |