Aperçu général de la Cluster Suite

Figure 1.22, « LVS Implemented with NAT Routing », illustrates LVS using NAT routing to move requests between the Internet and a private network.

Dans cet exemple, il y a deux NIC dans le routeur LVS actif. La NIC pour Internet a une adresse IP réelle sur eth0 et une adresse IP flottante possédant un alias sur eth0:1. La NIC pour l'interface réseau privée a une adresse IP réelle sur eth1 et une adresse IP flottante possédant un alias sur eth1:1. En cas de failover, l'interface virtuelle exposée à Internet et celle privée exposée à l'interface virtuelle sont récupérées simultanément par le routeur LVS de sauvegarde. Tous les serveurs réels sur le réseau privé utilisent l'adresse IP flottante pour le routeur NAT comme leur route par défaut afin de communiquer avec le routeur LVS actif pour que leurs capacités à répondre aux requêtes Internet ne soit pas détériorées.

In the example, the LVS router's public LVS floating IP address and private NAT floating IP address are aliased to two physical NICs. While it is possible to associate each floating IP address to its physical device on the LVS router nodes, having more than two NICs is not a requirement.

En utilisant cette topologie, le routeur LVS actif reçoit la requête et la redirige vers le serveur approprié. Le serveur réel traite ensuite la requête et retourne les paquets au routeur LVS. Le routeur LVS utilise la traduction d'adresses réseau pour remplacer l'adresse du serveur réel dans les paquets avec l'adresse VIP publique des routeurs LVS. Ce processus est appelé IP masquerading car les adresses IP courantes des serveurs réels sont cachées des clients effectuant la requête.

En utilisant le routage NAT, un serveur réel peut être n'importe quel type d'ordinateur exécutant une variété de systèmes d'exploitation. Le principal inconvénient du routage NAT est que le routeur LVS peut devenir un goulet d'étranglement dans les grands déploiements car il doit traiter les requêtes entrantes et sortantes.

Le routage direct offre des performances supérieures par rapport au routage NAT. Le routage direct permet aux serveurs réels de traiter et router les paquets directement vers un utilisateur les demandant plutôt que de passer les paquets sortants à travers le routeur LVS. Le routage direct réduit les risques de problèmes de performance réseau en reléguant le travail du routeur LVS pour ne traiter que les paquets entrants.

Dans une configuration LVS classique de routage direct, un routeur LVS reçoit des requêtes serveur entrantes par l'intermédiaire d'une adresse IP virtuelle (VIP) et utilise un algorithme de programmation pour diriger les requêtes vers les serveurs réels. Chaque serveur réel traite les requêtes et envoie les réponses directement aux clients sans passer par les routeurs LVS. Le routage direct permet une plus grande évolutivité car les serveurs réels peuvent être ajoutés sans charge supplémentaire sur le routeur LVS pour router les paquets sortants du serveur réel vers le client.

S'il existe de nombreux avantages à l'utilisation du routage direct dans LVS, il existe aussi des limitations. Le problème le plus courant avec le routage direct et LVS est le Protocole de résolution d'adresses (ARP de l'anglais Address Resolution Protocol).

In typical situations, a client on the Internet sends a request to an IP address. Network routers typically send requests to their destination by relating IP addresses to a machine's MAC address with ARP. ARP requests are broadcast to all connected machines on a network, and the machine with the correct IP/MAC address combination receives the packet. The IP/MAC associations are stored in an ARP cache, which is cleared periodically (usually every 15 minutes) and refilled with IP/MAC associations.

Le problème avec les requêtes ARP dans une configuration LVS de routage direct est que dans la mesure où l'adresse IP d'une requête client doit être associée à une adresse MAC pour être traitée, l'adresse virtuelle du routeur LVS doit également être associée à une adresse MAC. Cependant, parce que le routeur LVS et les serveurs réels ont la même adresse VIP, la requête ARP est diffusée à tous les noeuds associés à l'adresse VIP. Cela peut causer plusieurs problèmes, tels que l'adresse VIP associée directement à un des serveurs réels et traitant les requêtes directement, sans passer par le routeur LVS et ainsi allant à l'encontre du but de la configuration LVS. L'utilisation d'un routeur LVS avec un CPU puissant qui répond rapidement aux requêtes clients ne résout pas forcément ce problème. Si le routeur LVS est sous une charge élevée, il peut répondre à la requête ARP plus lentement qu'un serveur réel sous-utilisé répondant plus rapidement et qui se fait attribuer l'adresse VIP dans le cache ARP du client effectuant la requête.

Pour résoudre ce problème, les requêtes entrantes devraient uniquement associer l'adresse VIP au routeur LVS, qui traitera correctement les requêtes et les enverra au pool de serveurs réels. Ceci peut être fait en utilisant le pool de filtrage des paquets arptables.

Lorsqu'elle est activée, la persistance agit comme un minuteur. Lorsqu'un client se connecte à un service, LVS se souvient de sa dernière connexion pendant une période de temps spécifique. Si le client se connecte à nouveau avec la même adresse IP avant la fin de cette période, le client est envoyé vers le même serveur auquel il s'était connecté précédemment — sans passer par le mécanisme de répartition de charge. Lorsqu'une connexion est effectuée après cette période, elle est traitée en fonction des règles de programmation mises en place.

La persistance vous permet également de spécifier un masque de sous-réseau à appliquer sur l'adresse IP du client afin de contrôler les adresses qui ont un plus haut niveau de persistance et ainsi grouper les connexions vers ce sous-réseau.

Le groupement de connexions destinées à différents ports peut être important pour les protocoles qui utilisent plus d'un port pour communiquer, tels que FTP. Cependant, la persistance n'est pas la façon la plus efficace de gérer le problème de groupement de connexions destinées à différents ports. Dans de telles situations, il est préférable d'utiliser les marques de pare-feu.

Les marques de pare-feu sont un moyen simple et efficace pour grouper les ports utilisés par un protocole ou un groupe de protocoles connexes. Par exemple, si LVS est déployé pour exécuter un site de e-commerce, les marques de pare-feu peuvent être utilisées pour empaqueter les connexions HTTP sur le port 80 et sécuriser les connexions HTTPS sur le port 443. En assignant la même marque de pare-feu au serveur virtuel pour chaque protocole, les informations d'état de la transaction peuvent être préservées car le routeur LVS redirige toutes les requêtes vers le même serveur réel après qu'une connexion soit ouverte.

Parce qu'elles sont simples à utiliser et efficaces, les administrateurs LVS devraient utiliser, dès que possible, les marques de pare-feu afin de grouper les connexions. Toutefois, vous devriez toujours ajouter la persistance aux serveurs virtuels conjointement aux marques de pare-feu pour vous assurer que les clients soient reconnectés au même serveur pendant une période désirée.

You can access the Cluster Configuration Tool (Figure 1.27, « Cluster Configuration Tool ») through the Cluster Configuration tab in the Cluster Administration GUI.

L'Cluster Configuration Tool représente les composants de configuration du cluster au sein du fichier de configuration (/etc/cluster/cluster.conf) avec un affichage graphique hiérarchique dans le panneau de gauche. Un icône en forme de triangle à gauche du nom d'un composant indique que le composant possède un ou plusieurs composants de second niveau. En cliquant sur cet icône vous pouvez agrandir et réduire la partie de l'arborescence située sous le composant. Les composants affichés dans l'interface utilisateur graphique sont structurés de la manière suivante :

You can access the Cluster Status Tool (Figure 1.28, « Cluster Status Tool ») through the Cluster Management tab in Cluster Administration GUI.

Les noeuds et services affichés dans l'Cluster Status Tool sont déterminés par le fichier de configuration du cluster (/etc/cluster/cluster.conf). Vous pouvez utiliser l'Cluster Status Tool pour activer, désactiver, redémarrer ou déplacer un service à haute disponibilité.

The VIRTUAL SERVER subsection panel shown in Figure 1.34, « The VIRTUAL SERVERS Subsection » allows you to configure an individual virtual server. Links to subsections related specifically to this virtual server are located along the top of the page. But before configuring any of the subsections related to this virtual server, complete this page and click on the ACCEPT button.

Cliquez sur le lien de la sous-section REAL SERVER en haut du panneau pour afficher la sous-section EDIT REAL SERVER. Cette sous-section affiche le statut des hôtes du serveur physique pour un service virtuel particulier.

Click the ADD button to add a new server. To delete an existing server, select the radio button beside it and click the DELETE button. Click the EDIT button to load the EDIT REAL SERVER panel, as seen in Figure 1.36, « The REAL SERVER Configuration Panel ».

Ce panneau est composé de trois zones de texte :

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 caractères send/expect afin de vérifier que le service pour le serveur virtuel soit fonctionnel sur chaque serveur réel. C'est également ici que l'administrateur peut spécifier des scripts personnalisés pour vérifier les services nécessitant des données qui changent dynamiquement.