LVS-mini-HOWTO French Joseph Mack jmack (at) wm7d (dot) net v2003.07 Jul 2003, publié sous license GPL. 2001 2002 2003 Joseph Mack Convention pour la version française de ce document Dans la suite de ce document le serveur virtuel linux sera désigné par son nom anglais : Linux Virtual Server (LVS) car c'est le terme sous lequel il est le plus souvent référencé. Objectif de ce document Vous monter comment installer un Linux Virtual Server (LVS) et mettre en place quelques serveurs virtuels de démonstration. Aucune connaissance du fonctionnement de LVS n'est requise ni expliquée ici. Vous aurez besoin de quelques connaissance dans la configuration de linux. Une fois que vous aurez réussi à faire fonctionner LVS, vous devriez lire la documentation et le HOWTO (Version Anglaise) sur le site web de LVS, pour comprendre comment LVS fonctionne et pour l'installer exactement selon vos désirs.
Introduction Tout ce que vous voudriez savoir (code, documentation, liste de diffusion, archives de la liste de diffusion) peut être trouvé quelque part sur le site web LVS La nécessité de ce mini-HOWTO a été mise en relief par ratz ratz (at) tac (dot) ch qui a fait des suggestions sur son contenu et l'a relu. D'autres suggestions ont été données par John Cronin jsc3 (at) havoc (dot) gtf (dot) org. Ce document était à l'origine un ensemble d'instructions pour mettre en place rapidement un LVS sans avoir à comprendre comment un LVS marche. Cependant cela a ammené à une duplication des instructions entre le HOWTO et le mini-HOWTO. Par la suite, il est devenu plus facile de rassembler toutes les instructions au même endroit. Maintenant le mini-HOWTO contient un peu plus que le strict minimum nécessaire à la mise en place d'un LVS de démonstration fonctionnel. Ce document est (à l'origine) écrit en xml.
Emplacement de ce document Sur le site web LVS et aussi par la page de Documentation LVS (Anglais).
Ce que fait un LVS Un LVS est un groupe de serveurs avec un directeur qui apparait pour le monde extérieur (un client sur l'internet) comme un seul serveur. Le LVS peut proposer plus de services, ou des services avec une plus grande capacité/débit, ou des services redondants (ou des serveurs peuvent être éteints pour maintenance de manière individuelle) par rapport à ce qui est possible avec un seul serveur. Dans ce document, on appele service une connection à un port unique, par exemple telnet, http, https, nntp, nfs, ntp, ssh, smtp, pop, bases de données. Certains services à plusieurs ports (par exemple ftp pour LVS_NAT) sont aussi supportés comme des cas à part. D'autres services à plusieurs ports (par exemple ftp passif, http/https pour les site de e-commerce) sont supportés par la persistance LVS ou plus récement par fwmark comme décrit dans le HOWTO. Dans le bestiare des ordinateurs, LVS est un switch de couche (ISO) 4. La sémantique standard client-serveur est préservée. Chaque client pense être connecté directement au serveur réel. Chaque serveur réel pense être connecté direcement au client. Ni le client ni les serveurs réels n'ont quelque moyen que ce soit de dire qu'un directeur est intervenu dans la connection. Un LVS n'est pas un beowulf - un beowulf est un groupe de machines où chacune d'elles coopère pour le calcul d'une petite partie d'un problème plus important. Un LVS n'est pas un cluster - un cluster de machines est un groupe de machines qui se répartie la charge de manière coopérative. Les serveurs réels dans un LVS ne coopèrent pas - ils n'ont pas conscience de la présence d'autres serveurs réels dans le LVS. Tout ce qu'un serveur réel sait c'est qu'il reçoit des connections d'un client. Ce mini-HOWTO va expliquer la mise en place d'un LVS pour les services telnet et http.
Minimun requis pour le matériel et le réseau Voici une configuration LVS-NAT typique : Voici une configuration LVS-DR ou LVS-Tun typique : Pour la redondance du directeur (abordée dans le LVS-HOWTO (Anglais)), la VIP (IP Virtuelle) et la DIP (IP du directeur) seront déplacées sur un directeur de backup. Les deux IPs ne pourront donc pas être l'adresse primaire des cartes réseau du directeur donc elles doivent être des adresses secondaires (ou des alias comme on les appelait autrefois :). Les adresses primaires sur le directeur peuvent être n'importe quoi du moment qu'elles sont compatibles avec la topologie réseau déployée. Toutes les procédures de déployement (y compris le script de configuration) supposent que vous avez déjà configuré toutes les IPs et les connections réseau, sauf la (les) VIP(s) et la DIP : donc configurez les RIP1..n, l'adresse primaire du directeur, la passerelle du directeur (DIRECTOR_GW), la passerelle des serveur réels (SERVER_GW) et installez les connexions réseau entre tous ces éléments. Le script de configuration mettra en place la VIP et la DIP (la version 0.9.x les configurera en tant qu'alias, si tout va bien les versions postérieures les configureront en tant qu'adresses secondaires). Dans une configuration de test, avec toutes les machines dans la même pièce, un routeur (dans le diagram ascii) ne sera pas installé et la machine cliente aura les IPs de la passerelle du directeur (DIRECTOR_GW) ou de la passerelle des serveurs réels (SERVER_GW). Vous aurez besoin de 3 machines minimum (1 client, 1 directeur, 1 serveur réel). Si vous avez 4 machines (c'est à dire 2 serveurs réels), vous pourrez alors voir la répartition de charge (la connection depuis le client au LVS est alors envoyée à un serveur réel puis à l'autre). Vous pouvez configurer un LVS avec 2 machines (1 client, 1 directeur) en utilisant la fonctionnalité localnode de LVS (Anglais), avec le directeur fonctionnant aussi en tant que serveur réel, mais cela ne montre pas la façon de dimensionner une ferme de serveurs, et vous pourriez éprouver des difficultés à dire si cela marche correctement si vous êtes novice par rapport à LVS. Le directeur est connecté à toutes les machine. Si vous avez un seul clavier et un seul moniteur, vous pouvez tout configurer à partir du directeur. Vous avez besoin : Client : N'importe quelle machine, n'importe quel OS avec un client telnet et/ou un client http (c'est à dire netscape, lynx, IE). (J'ai utilisé un client Mac pour mon premier LVS). Directeur : Une machine tournant avec un noyau Linux 2.2.x (x>=14) ou 2.4.x patché avec ipvs. Si vous commencez à partir de zéro, utilisez un noyau 2.4.x, car le développement d'ipchains (pour les noyaux 2.2.x) a été arrété. Pour un test, cette machine n'a pas besoin d'être puissante - n'importe quel 486 avec de l'ethernet 10Mbps fera l'affaire. Dans la vrai vie, un Pentium I 75Mhz peut délivrer 50Mbps de packets sur de l'ethernet 100Mbps. Dans ce cas la couche réseau (bus à 33Mhz pour un port PCI) est la goulet d'étrangelement et le CPU travaille peu. Comparez ce débit avec la capacité d'un connexion T-1 (1.5Mbps) et vous pouvez voir que pour des réseaux à faible traffic, la fonction essentielle est la redondance. Ce n'est qu'avec une infrastructure réseau à 1Gbps que les ressources CPU deviennent limitantes avec un Pentium III à 300Mhz. Serveur(s) réel(s) : Ce sont ces machines qui offrent le service intéressant (ici telent et/ou http). Dans un environnement de production, ils peuvent être de n'importe quel OS mais par simplicité je ne parlerai que du cas où ils sont des linux avec un noyau >=2.2.14. (Le support de versions antérieures du noyau a été retiré du HOWTO). Le directeur peut transmettre les packets selon 3 methodes. L'OS des serveurs réels peut être : LVS-NAT - n'importe quelle machine, n'importe quel OS, avec des services interessants (par exemple httpd, ftpd, telnetd, smtp, nntp, dns, daytime ...). Le serveur réel doit juste avoie une pile TCP/IP - même une imprimante réseau fera l'affaire. LVS-DR - les OS connus poour fonctionner sont listés dans le HOWTO (Anglais) : pratiquement tous les unix et les OS Microsoft. LVS-Tun - les serveurs doivent avoir un OS capable de faire des tunnels (uniquement Linux jusqu'à présent). (only Linux so far).
Gotchas: vous avez besoin d'un client à l'extérieur Vous avez besoin d'un client à l'extérieur. Le VLs fonctionne comme une seule machine. Vous devez accéder au LVS depuis un client qui ne fait pas partie du LVS. Vous ne pouvez pas accéder à un service controllé par un LVS (par ex. http, telent) depuis n'importe laquelle des machines du LVS; un accès depuis le directeur plantera, un accès depuis un serveur réel se connectera au service local, bypassant le LVS. Avril 2003: Julian a trouvé comment avoir un serveur réel comme client d'un LVS-NAT (Anglais). Minimum 3 machines: client, directeur, serveur(s) réel(s)
Le service de départ pour les tests devrait être telent (ou netcat) Tous les test de votre LVS devraient être faits avec des service simples (telnet, http). Telnet a un client simple (disponilve avec tous les OSs) un protocole simple (un port) des échanges tous en ascii (et peuvent être observés avec tcpdump) des connections non persistantes (vous pouvez tester la planfication tourniquet (round robin)) telnetd ecoute d'habitude sur toutes les IP sur un serveur (c'est à dire sur 0.0.0.0) au moins avec inetd le plus important, quand une connection est faite vous verez une entrée dans la colonne ActConn de la sortie de ipvsadm. Pour des raisons de sécurité, vous éteindrez telnet plus tard, mais tant que vous êtes en train de tester votre LVS ou votre nouveau service, regardez toujours si telnet marche si vous avez des soucis. Si telnet n'est pas transmis par LVS vous devriez réparez cela en premier. Un autre client utile est : netcat ou son remplaçant, phatcat.
Tester sans règles de filtre (Firewall) Vous pouvez les ajouter après avoir fait fonctionner LVS.
Logiciels
Compilateur Wensong utilise egcs-2.91.66 sur RedHat 6.2 et gcc-2.96 sur RedHat 7.3. J'ai eu beaucoup de problèmes (Mai 2003) avec les nouveaux noyaux et gcc-3.x. Les noyeaux compilent mais ne fonctionnent pas correctement (sur une de mes machines, la scsi, et le réseau ne fonctionne pas quand j'active le SMP). Le nombre de paramètres dans ip_select_ident a changé ce qui conduit à des erreurs de compilation (le nouveau paramètre a la valeur 0, je l'ai juste effacé - ca a compilé mais je ne sais si ce code ne me lachera pas)? J'ai aussi trouvé quelques packages qui ne compilent pas avec gcc-3.3.
Récupérer les fichiers : directeur, serveurs réels
Noyau standard pour le directeur et les serveurs réels Pour le directeur, vous avez besoin du noyau standard, qui peut être obtenu sur le site ftp noyau (Anglais). Pour les noyaux linux-2.4.x, vous devrez patcher avec le patch 'caché' (hidden); (qui a été testé seulement avec ces noyaux standards). Le noyau fourni avec votre distribution est généralement une version évoluée du noyau standard et qui ne sera surement pas patché correctement avec LVS. Le noyau RedHat a les patchs LVS pré-appliqués, mais a une version qui sera déjà dépassée lorsque vous lirez ces lignes. SuSE (Mai 2003) fait de même. Si vous arrivez à faire fonctionner LVS avec le noyau standard mais pas avec celui de votre distribution, alors nous pouvons peut être trouver la source du probléme, mais vous feriez mieux de contacter votre distributeur - ils ont besoin de votre feedback, nous non. Si vous êtes vraiment intéressé par le fait de faire fonctionner LVS avec le noyau de votre distribution, vous pouvez le faire après avoir réussi avec le noyau standard.
Patch IPVs pour le directeur Cliquez sur le lien 'software' sur la page de garde de LVS (Anglais). Récupérez la dernière archive tar ipvs pour le directeur (disponible en version 2.2.x, 2.4.x, et 2.5.x). Elle contient le patch pour le noyau et le code source pour quelques programmes et utilitaires. Vous devez patcher le noyau standard avec le patch ip_vs correspondant, re-compiler le noyau, rebooter et compiler ensuite le programme ipvsadm. Le directeur fonctionne dans une (parmis plusieurs) méthode de transfert; LVS-NAT (network address translation (Translation d'Adresse Réseau)); LVS-DR (direct routing (routage direct)) et LVS-Tun (tunneling (par tunnel)). La méthode de transfert est configurée pour chaque service/serveur réel par ipvsadm. Le code du directeur a été bien testé sur les processeurs Intel. Il est également utilisé avec succès par quelques personnes sur du matériel Alpha. En général, il devrait fonctionner sur n'importe quel matériel qui peut faire tourner Linux.
Fichiers pour les serveurs réels Les serveurs réels doivent être configurés correctement par rapport à la méthode de tranfert. Pour cela vous devez régler le problème arp. (Vous trouverez ici plus d'infos au sujet du problème arp (Anglais).) configurer la passerelle. LVS-NAT: la DIP LVS-DR, LVS-Tun: un routeur (pas le directeur). Pour régler le problème arp pour LVS-DR/LVS-Tun, les serveurs réels avec des noyaus linux 2.2.x/2.4.x, faites tourner un noyau standard patché avec le patch "hidden" (disponible sur la page de patchs et de programmes de Julian (Anglais)). Pour les noyaux 2.2.x, ce patch est déjà dans le noyau standard ( c'est à dire qu'il est prépatché pour vous). Pour les noyaux 2.4.x, vous devrez appliquer ce patch vous même. A la fin 2001, il était possible d'appliquer au noyau le patch hidden et le patch ipvs en même temps, ce qui permettait d'utiliser le même noyau pour le directeur et pour les serveurs réels. La partie du noyau touchée par le patch ne change pas beaucoup d'une version à une autre de noyau, donc le patch hidden pour le noyau 2.4.5 est toujours valable pour le noyau 2.4.19pre4. Voici la liste des OS qui ont été testés avec les méthodes de transfert. (nous pensons qu'on peut arriver à faire fonctionner les OS avec toutes les méthodes d'une manière ou d'une autre.) Serveurs réels par Mode - LVS-NAT - n'importe quel OS LVS-DR - la plupart des OS (tous devraient y arriver). Le problème avec les OS autre que linux est (comme d'habitude) de régler le problème arp. Ratz a rassemblé des instructions pour configurer des serveur réels utilisant des OS autre que Linux (Anglais). LVS-Tun - linux uniquement Serveurs réels par OS - Les autres OS LVS-NAT - auncune modification nécessaire sur les serveurs réels LVS-DR - fonctionne avec la plupart des OS rencontrés jusqu'a présent, bien que quelques astuces ont été nécessaires pour trouver les commandes indispensable à la configuration de la VIP sur les serveurs réels pour quelques OS. Si vous faites tourner Linux-2.2.x, ou Linux-2.4.x, vous devez régler le problème arp. LVS-Tun - linux uniquement (les serveurs réels doivent pouvoir désencapsuler les packets IP sur IP). Si vous faites tourner Linux-2.2.x, ou Linux-2.4.x, vous devez régler le problème arp. Linux 2.0.36: aucune modification ni patch ne sont nécessaires. Fonctionne avec tous les modes LVS : LVS-NAT, LVS-Tun et LVS-DR. Linux 2.2.x,2.4.x: LVS-NAT - aucune modification aux serveurs réels. LVS-DR and LVS-Tun - (roulement de tambours - ceci est la partie difficile, connue sous le nom du ;). La théorie du problème arp peut être sautée lors d'une première lecture. Vous devrez comprendre ce problème pour mettre en place votre propre configuration LVS. Voici un résumé : Pour faire simple, en général vous devrez gérer le problème arp. La manière la plus courante de régler le probleme arp est de cacher la VIP des requêtes arp. 2.2.x: Le noyau standard est déjà patché avec le patch hidden. Utilisez le noyau 2.2.x prépatché de la distribution standard. 2.4.x: Le noyau standard n'a pas le patch hidden appliqué. Vous devez patcher le noyau standard avec le patch hidden 2.4.x trouvé sur la page 'software' de LVS. Les exemples suivants vont vous montrer comment gérer le problème arp. Toutes ces méthodes pour gérer le problème arp fonctionnent, avec à peu près le même indice de performance (débit, lantence) et sont à peu près aussi faciles/difficiles à mettre en place. La méthode "hidden" pour dissimuler des interfaces aux requêtes arp est la plus proche du comportement standard NOARP d'unix et c'est la méthode la plus utilisée sur les serveurs réels Linux. Pour des noyaux plus anciens (2.0.x et au moins les premiers 2.2.x), une autre méthode simple est d'installer une carte réseau supplémentaire dans les serveurs réels pour la VIP et de ne pas la connecter au réseau. La carte réseau ne reçoit pas de paquets, c'est juste un moyen d'avoir la VIP sur les serveurs réels. La carte réseau peut être une vieille carte ISA 10Mbps. La prix de certaines cartes tulip PCI 100Mbps est maintenant inférieur au salaire que vous seriez payé pour recompiler un noyau avec le patch 'hidden'. (Note, 2002: - cela ne marche pas pour les noyaux 2.4.x).
Mettre à jour LVS Le seul moyen est de compiler un nouveau noyau, redémarrer puis compiler/installer l'ipvsadm correspondant, comme si vous faisiez une installation depuis le début. Vous ne pouvez pas mettre à jour in situ, vous aurez à éteindre votre directeur. J'utilise le script rc.system_map (qui est fourni avec le configure_script) pour être sur d'avoir la bonne version d'ipvsadm, du noyau et des fichiers system.map bien synchrones, quand j'utilise de multiples versions de LVS (c'est à dire une version 2.2 et 2.4).
Logiciel
Compiler Wensong utilise egcs-2.91.66 sur RedHat 6.2 et gcc-2.96 sur RedHat 7.3. Mai 2003 - J'ai eu beaucoup de problème avec les nouveaux kernels et gcc-3.x . Les kernels sont construits mais ne marchent pas correctement (sur l'une de mes machines le scsi et le réseau ne fonctionne pas quand le SMP est allumé ). Le nombre de paramètres de la commande ip_select_ident a changé ce qui amène des erreurs de compilation (le nouveau paramètre a la valeur '0', Je l'ai simplement supprimé - Il se compile maintenant mais je ne sais pas si le code me renverras une erreur maintenant). J'ai aussi trouvé que certains packages ne se compilent pas avec gcc-3.3. Fev 2004 - Peu importe les problèmes, il semble qu'ils aient disparues. Avr 2004 - Il semble que gcc-2.95.3 est toujours le compilateur recommandé pour les kernels. L'utilisation d'un autre compilateur est à votre propre risque.
Utilisez le kernel standard Vous avez besoin du kernel standard pour à la fois le directeur ainsi que pour les serveus réels. Vous pouvez obtenir le kernel standard ici site kernel ftp (ftp://ftp.kernel.org/pub/linux/kernel/). Si vous utilisez une version commercial améliorée du kernel (i.e. d'une distribution linux), Il y a de forte chance que le patch ne marche pas correctement avec LVS. Le kernel de Redhat a les patches LVS pré-appliqués, avec une version qui sera déjà vieille au moment où vous parlerez avec nous. SuSE (Mai 2003) fait la même chose. Si vous arrivez à faire fonctionner LVS avec le kernel standard, mais que vous n'y arrivez pas avec votre distribution, nous savons peut etre quel est le problème, mais il serait mieux de contacter le distributeur - il ont besoin de ces retours, pas nous. Si vous ètes vraiment interressé par le fait de faire fonctionner le kernel de votre distribution avec LVS, vous pouvez faire ce que vous avez fait avec le kernel standard. Si vous venez sur la mailing list avec un problème et que vous utillisez un kernel commercial amélioré, prennez soin de nous dire que vous n'utilisez pas un kernel standard.
Utilisez les utilitaires standard (pas ifup) Utilisez les utilitaires standard, e.g. les outils iproute2 (ou les anciennes commandes ifconfig/route, qui ne marche bien qu'avec un noeud simple avec une IP). Nous mettons en place LVS depuis le premier jour avec ifconfig et des alias ip, mais ces derniers ne sont pas compatibles avec la plupart des outils réseaux, alors soyez prudent si vous utilisez ifconfig. Des personnes se sont rendus compte que LVS ne marche pas s'il a été mis en place avec le ifup de Redhat (regardez les archives LVS). Le problème est que ifup lance la commande arping qui n'a rien à faire là, et qui inonde votre configuration de LVS. D'autre logiciel réseau améliorés ajoutent des routes bizarre. Si vous voulez vous rouler vous même en utilisant des commandes qui ont été couçu pour améliorer l'unicité d'une distribution sur le marché, au lieu de faire le travail qui doit être fait, alors vous méritez amplement les problèmes qui vous arrive, mais nous, sur la mailing list devons cerner comment vous avez planté votre cofiguration et nous considérons que vous utilisez les utilitaires normaux. Nous sommes en général très content d'apprendre au bout de plusieurs échanges que vous avez utilisé délibérément des outils non fiable écris par des gens qui ne comprennent pas le réseau. Autant utiliser Windows... Utilisateur infortuné
Avant de lancer le script, je peut me connecter à tout mes serveurs réels, mais après l'avoir lancé je pert la connection et la seul différence dans la table de routage est :
Francois JEANMOUGIN Francois (dot) JEANMOUGIN (at) 123multimedia (dot) com 16 Jan 2004 and Avr 07, 2004 Vous ne devriez pas ajouter aucune route lo. N'utilisez jamais ifup pour monter des interfaces noarp. Dans le script ifup, vous trouverez des commandes arp. Si c'est le premier serveur réel que vous configurez, ce n'est pas vraiment un problème, mais si vous ajoutez un serveur réel à un groupe de serveur, celà va embrouiller la structure du routage de LVS en lançant une annonce arp. Christopher DeMarco cdemarco (at) md (dot) com (dot) my 07 Juil 2004 RedHat utilise ifup au démarrage. Pourquoi ne pas simplement commenter les bits ifup qui appel arp(8) et arping(8)? Ce n'est pas l'idéal dans cette situation car chaque mise à jour du système nécessitera le nétoyage du code de la commande ifup, mais il me semble que ce serait la procédure la moins envahissante. Ré_écrire des scriptes d'initialisation propre va interrompre les fonctionnalités de configuration point-n-drool de RedHat que les utilisateurs pourrait vouloir utiliser. Selon moi, la manipulation des caches arp est le seul empèchement à l'utilisation de RedHat avec LVS, ou y en a-t'il d'autre ? Horms Oui, c'est certainement ce que je ferais. Peut être que RedHat serait incité (à travers un rapport de bug sur bugzilla) à en faire une option de configuration. RedHat est la seul distribution qui à ma connaissance fait celà . Mais il semblerai normal que les autres aient le meme fonctionnement. Kjetil Torgrim Homme kjetilho (at) ifi (dot) uio (dot) no 11 Jul 2004
Arptables est une méthode supportée par Red Hat. Le package, arptables_jf, fait parti de l'Advanced Server, mais le fichier src.rpm peut etre téléchargé, reconstruit et utilisé sur une station de travail puisqu'il a le même support du kernel. La configuration est plutôt directe: Ce service est lancé avant que le réseau soit mis en place. Notez que vous avez à spécifier un niveau de lancement explicite, car bettement il ne démarrera pas en mode simple utilisateur par défaut.
Récupérer des fichiers dans un package Si vous voulez un package de fichier pour une distribution, en général, vous devrez allez chez son distributeur. Quelques fois des personnes de la mailing list font des packages de fichier pour une utilisation général. LVS est une activité pratiquée pendant le temps libre pour quelques d'entre nous. Nous sommes content de générer des fichiers que tout le monde peut utiliser, mais il n'y a vraiment pas de raison de créer des packages pour l'ensemble des distributions, alors qu'on ne peut les tester toutes et nous savons pas si quelqu'un les utilisera un jour. Mon point de vue personnel est que à moins de savoir compiler le code, vous devriez tout simplement utiliser windows. Je sais que certain sont soumis à des autoritées qui veulent des packages de codes originaire d'un distributeur homologué, et sont près à payer pour celà. Désolé, nous ne sommes pas organisé pour faire celà.
Récupérer des fichiers: le directeur Le logiciel est disponible ici http://www.linuxvirtualserver.org/software/ipvs.html. Le code pour le directeur a été testé sur les processeurs Intel. Comme plusieurs personnes utilisent du alpha hardware. On peut supposer qu'il devrait fonctionner sur tout matériel sur lequel Linux marche.
Patch du Kernel Vous avez besoin d'un Kernel avec le correctif the ip_vs 2.6.x kernels: le kernel (de ftp.kernel.org) est déjà corrigé avec le code ip_vs. 2.4.x kernels: pour les versions 2.4.23 et suivantes, le kernel (from ftp.kernel.org) est déjà corrigé avec le code ip_vs. Ne lancez pas la commande make patchkernel sur la version 2.4.23 kernel (ou précédentes). Ces kernels sont déjà patché avec LVS. Malgrè son nom la commande make patchkernel remplace les fichiers, au lieu de les corriger. La commande réussira mais va produire un kernel qui ne compilera pas. La version 2.4.23 a un problème d'exploitation root qui a été réglé à la version 2.4.24. La version 2.4.25 règle aussi un problème d'exploitation root. Il vaut mieux éviter les versions 2.4.23/24 pour les systèmes de production. Pour la version 2.4.22 et précedentes, il faut que vous téléchargiez le patch ip_vs pour la version de votre kernel et le patcher. 2.2.x kernels: Toute les versions ont besoin du téléchargement du patch et de son installation. Dans tous les cas quand vous compilez un kernel, vous devez mettre en marche l'option ip_vs dans la commande make configure (Networking options -> IP: Virtual Server Configuration). Si vous ne savez pas ce que vous faites, compilez toutes les options en tant que module et ne changez pas la taille de la table de connection (voir plus loin pour plus de détails sur les options de compilation).
Horms 14 Nov 2003 En général chaque version en fait en deux formes (faites votre choix pour le style de construction du kernel). Une archive tar (tarball) que vous pouvez utiliser pour construire LVS en dehors ou à l'intérieur de l'arborescence du kernel. Et un patch qui ne peut être utilisé pour construire LVS à l'intérieur de l'arborescence du kernel. Pour la version 2.4.22, le patch linux-2.4.21-ipvs-1.0.11.patch.gz peut être utilisé. A moins que vous ayez une excellente raison pour utiliser un kernel plus ancien, utilisez les versions 2.4.23 ou suivantes avec LVS inclus.
ipvsadm: L'interface utilisateur pour ip_vs Vous pouvez controler et configurer le code du kernel grâce à la commande ipvsadm Si vous avez un kernel avec ip_vs pré installé : téléchargez ipvsadm ici http://www.linuxvirtualserver.org/software/ipvs.html. Veillez à prendre la version de ipvsadm correspondant à votre kernel. Les différentes versions (2.2.x, 2.4.x, 2.6.x) nécessite différentes versions de ipvsadm. Mais attention les numéros de version de ipvsadm ne correspondent pas aux kernel. Vous ne pouvez pas deviner le kernel concerné grâce au numéro de version. (e.g. ipvsadm-1.24.tar.gz correspond aux kernels 2.6, alors que ipvsadm-1.21.tar.gz correspond aux kernels 2.4). Si vous venez de récupérer la dernière version de ipvsadm (Jan 2004 est v1.24), elle ne marchera pas avec les kernels 2.4 ). Si vous utilisez un patch ip_vs pour votre kernel: ipvsadm sera inclus dans le patch. Compilez ipvsadm après que vous ayez compilé le kernel et bootez sur votre nouveau kernel avec ip_vs, pour que ipvsadm soit compilé avec la version correcte des fichiers header du kernel. Vous devrez donc vous souvenir qu'après avoir lancé votre nouveau kernel il vous reste encore une étape de compilation et d'installation de ipvsadm.
Mise à jour de LVS Le seul moyen est de compiler un nouveau kernel, redémarrer, et ensuite de compiler et d'installer le patch ipvsadm correspondant, comme si vous reprenniez tout depuis le début. Vous ne pouvez pas mettre à jour en fonctionnement, vous devez arréter le directeur. J'utilise le script rc.system_map (qui vient avec le script configure_script) pour être sûr que j'ai les bonnes versions de ipvsadm, du kernel et des fichiers System.map qui fonctionnent ensemble, quand je teste plusieurs versions de LVS (e.g. une version 2.2 et 2.4). Horms 01 Fev 2005 LVS fait partie du kernel. Vous pouvez les compiler en tant que module ou alors à l'intérieur du kernel lui même. Pour le premier vous pouvez changer les modules n'importe quand, bien que LVS sera redémarrer et que toutes les connections en cours seront perdues - ceci peut etre évité en le synchronisant à un directeur Linux de backup. Toutefois, si vous avez besoin de mettre à jour d'autres parties du kernel, qui sont plus commune que LVS, vous avez alors besoin de rebooter. Cela inclus aussi la situation où la mise à jour de LVS réside dans un changement autre part dans le kernel.
LVS en CVS Le respository CVS de IPVS est disponible ici
Realserver OS avec la méthode de forwarding Les serveurs réels peuvent avoir à peu n'importe quel OS. Ils sont listés ici par la méthode de forwarding. LVS-NAT - n'importe quel OS. Puisque juste une adresse IP est nécessaire tout ce qui gère l'encapsulation IP marche. Vous pouvez utiliser une imprimante réseau comme serveur réel. LVS-DR - la plupart des OS (Ils peuvent peuvent tous échouer). LVS-Tun - seulement des Linux. L'outil tunl0 est nécessaire pour désencapsuler les paquets ipip (mis en marche dans la configuration du kernel sous "Network options"). Windows avait mis en place pendant peu de temps le tunneling sur leur dernières versions, mais l'ont finalemnent abandonné. Le problème des serveurs réels est de traiter le problème arp pour LVS-DR et LVS-Tun. Le problème se pose car toutes les machines (directeur, serveurs réels) ont la VIP et que seul le directeur peut répondre aux requètes pour l'adresse MAC de la VIP, si le LVS est en marche. Ratz a rassemblé les instructions pour la configuration des serveurs réels qui n'utilisent pas des OS Linux. Tous les modules standard respectent les flags -noarp pour ifconfig, par conséquent traiter le problème arp est trivial. Pour Linux vous devez appliquer les logiciels au kernel des serveurs réels, ou utiliser des astuces de routage (méthode Lars).
Serveur réel : Ai-je besoin de traiter le problème arp ? LVS-NAT: pas de problème arp (les serveurs réels n'ont pas de VIP) Pour les serveurs réels avec LVS-DR (et supposément LVS-Tun), vous aurez besoin de traiter le problème arp. La théorie pour les problèmes arp peut etre sautée à la première lecture. Finalement, vous aurez besoin de comprendre cela pour mettre en place votre configuration de LVS. En voila un résumé: En général vous aurez à gérer le problème arp.
Serveur Réel: problème arp par version de kernel Linux 2.0.x: respecte le flag -noarp pour la commande ifconfig. Aucun patch kernel nécessaire. Utilisez l'option NOARP dans ifconfig pour installer le VIP sur lo:0 (comme pour les unices) 2.2.x: ne respecte pas le flag -noarp. Le patch hidden de Julian est présent dans les kernels standard pour les versions 2.2.x (où x>=12). Aucun patch kernel n'est nécessaire. Le matériel est caché pour les appel arp en modifiant le fichier système /proc. Cela donne le même résultat que la configuration du matériel avec l'option -noarp. 2.4.x: ne respecte pas le flag -noarp. Il n'y a aucun patches dans le kernel pour traiter le problème arp. Vous pouvez corriger le kernel avec le patch hidden de Julian ou charger le module noarp de Maurizio. Pour les versions 2.4.26 et suivantes, Julian a un autre patch (voir 2.6.x). 2.6.x: ne respecte pas le flag -noarp. Il n'y a aucun patches dans le kernel pour traiter le problème arp. Pour les versions 2.6.x Julian a de nouveaux codes Julian Anastasov ja (at) ssi (dot) bg 25 Fev 2004
2.4.26pre et 2.6.4pre sortiront avec 2 nouveaux outils flag pour modifier l'encapsulation arp : arp_announce et arp_ignore. Tous les IPVS comme les setups peuvent utilisés arp_announce=2 et arp_ignore=1/2/3 pour résoudre le problème arp avec les setups DR/TUN. Ces flags vont alors remplacer les fonctionnalitées "cacher" qui ne marche pas très bien pour les directeurs quand ils changent de rôle entre master/slave dans une VIP. Le risque est que d'autres hôtes peuvent sonder les VIP qui utilisent des paquets unicast auxquels le flag hidden répond toujours. Je vais continuer à soutenir le hidden flag pour les versions 2.4 et 2.6 pour aider les installations existantes mais les remplacer par les outils flag (ou autre solution) est recommandé.
Serveur Réel: Méthodes pour traiter le problème arp Toutes les méthodes pour traiter le problème arp, ont toutes en gros la même performance (transfert, latence) et ont à peu près la même difficulté/facilité à installer. La méthode utiliisé courament pour traiter le problème arp est le patch hidden de Julian disponible ici Julian's patches and software page. Il arrète les réponses du matériel aux requètes (e.g. lo, où toutes les IP sur le matériel sont cachées). Ceci est la plus vieille méthode utilisée et donc est la plus familière pour les personnes qui utilisent LVS depuis quelques temps. En fin 2001, à la fois le hidden patch et le patch ipvs peuvent être appliqués simultanément au kernel, ce qui vous permet d'utiliser le même kernel pour le directeur ainsi que pour les serveurs réels. La partie du kernel modifié par le patch ne change pas beaucoup entre les versions du kernel, donc le patch hidden pour les versions 2.4.5 marche toujours pour les versions 2.4.19pre4. La commande pour le pacth est Le module noarp de Maurizio Sartori. (http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.arp_problem.html#sartori) noarp module. Vous n'avez pas besoin de patcher le kernel, il suffit de charger le module. Le module de Maurizio agit sur les adresses IP, et non pas sur le matériel donc vous pouvez faire le noarp VIP, en laissant les autres IP sur le même matériel répondrent aux requètes arp. C'est pour le moment (Fev 2004) disponible pour les kernels 2.4.x, une version pour les 2.6.x est attendu sous peu. Filtrage arp par Julian. (http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.arp_problem.html#arp_filtering) Julian a ajouté les extensions arp aux règles de filtrage des tables ip. Il semble que ce soit le moyen le plus simple pour traiter le problème, sauf que les gens hésitent à écrire les règles des tables IP. Il semble que personne n'utilise cette méthode. Combine de routagee.g. Lar's method. Pour des kernels plus ancien (2.0.x et jusqu'à 2.2.x ), une autre méthode simple est de mettre une carte réseau supplémentaire à l'intérieur des serveurs réels pour la VIP et ne pas la connecter au réseau. La carte ne gére aucun paquets, c'est juste un moyen de mettre la VIP sur les serveurs réels. La carte peut être une vieille carte ISA 10Mbps. Le prix d'une carte PCI 100Mbps tulip maintenant est moins chère que le salaire que vous seriez payé pour le temps de recompiler un kernel avec le patch hidden. (Note, 2002: - cela ne marche pas avec les kernels 2.4.x). Il y a eu des réponses (de la part de Ratz et Julian) doutant du fonctionnement de cette méthode. Enfin, les résultats des tests sont ici HOWTO: the arp problem (http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.arp_problem.html#vip_devices) si vous voulez en savoir plus. Cette propriété est surement discutable maintenant, puisque plus personne n'utilise ces kernels.
Pourquoi le netmask est à /32 pour le VIP avec LVS-DR? Horms 29 Oct 2003 Si vous utilisez le LVS-DR les paquets qui arrivent sur les serveurs réels portent l'adresse IP de destination de la VIP. Il faut donc quelque chose pour que les serveurs réels considèrent ce traffic comme étant local. Une façon de faire est d'ajouter une interface sur l'adresse locale et de la cacher pour qu'elle ne réponde pas aux requètes arp. Le netmask doit être 255.255.255.255 car l'adresse locale répondra aux paquets pour tous les hôtes sur chaque interface configurées. Donc l'adresse 192.168.1.110 avec un netmask de 255.255.255.0 amènera la machine à accepter des paquets pour toutes les adresses entre 192.168.1.0 et 192.168.1.255, ce qui n'est a priori pas ce que vous voulez. Josef Pospisil Juil 15, 2005
Pourquoi le VIP sur les serveurs réels doit être sur l'interface lo et non pas comme le directeur par exemple sur eth0:05 ?
Horms Vous pouvez le faire si vous préférez, toutefois soyez prudent sur le fait que les serveurs réels ne font pas de pub pour le VIP. Si vous utilisez lo, cela peut être facilement fait en utilisant arp_ignore et arp_announce. Si vous utilisez eth0, alors la solution des tables arp sera le façon de faire.
Choisir le type de Forwarding : LVS-NAT, LVS-DR et LVS-Tun Les serveurs réels doivent être corectement configurés selon la méthode de forwarding. Pour cela vous devez Gérer le problème arp. Pour plus d'information problème arp. Régler la passerelle par défaut. LVS-NAT: la DIP LVS-DR, LVS-Tun: un router (n'importe sauf le directeur). Si vou utilisez ceci Julian's martian modification (http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-DR.html#LVS-DR_director_default_gw) , vous pouvez router les paquets en repassant par un directeur LVS-DR. Mais vous ne voulez pas faire çà pour votre premier LVS. Les exemples en dessous vous montrerons comment installer un LVS-NAT et LVS-DR sur un directeur avec une carte réseau. Si vous voulez juste vous prouver que vous savez installer un LVS, alors LVS-NAT a l'avantage que n'importe quel OS peut être utililsé pour les serveurs réels et qu'aucune modifications n'est nécessaire sur le kernel des serveurs réels. Si vous avez une machine Linux avec un kernel 2.0.x, alors il peut être utilsé comme serveur réel pour un LVS de n'importe quel mode sans modifications. Parce que LVS-NAT a été le premier mode de LVS développé, il a été le premier utilisé par les personnes mettant en place un LVS. Pour les kernels 2.2.x, LVS-NAT est beaucoup plus gourmant en ressource processeur que le LVS-DR (LVS-NAT nécessite la réecriture des paquets). Pour les kernels 2.4.x LVS-NAT donne de meilleurs performances et se rapproche de LVS-DR. Quoi qu'il en soit pour un test simple, LVS-NAT ne nécessite que le patch d'une machine (le directeur) et une machine non modifiée avec n'importe quel OS comme serveur réel. Pour les serveurs de production LVS-DR est le meilleur choix. Après un simple test, à moins que vous ayez besoin des particularitées de LVS-NAT (possibilité d'utiliser les serveurs réels qui fournissent des services pas disponibles sur des machines Linux, remapping de port, les serveurs réels avec les couches tcpip primitive, imprimantes, services qui initient les requètes de connection), alors il serait mieux d'utiliser LVS-DR. Voici les contraintes de choix des différents LVS: LVS-NAT (network address translation), LVS-Tun (tunnelling) et LVS-DR (direct routing). Jusqu'à ce que vous sachiez quel méthode de réexpédition utiliser, choisisser dans cet ordre. VS-DR par défaut, a une haute production, peu être installé sur la plupart des OS. Les serveurs réels doivent être sur le même réseau que le directeur. (les serveurs réels et les directeur peuvent se joindre en arp). VS-NAT, production moindre, plus haute latence. Les serveurs ont juste besoin des couches tcpip (i.e n'importe quel OS, même une imprimante réseau). Fonctionne avec plusieurs instance de services (i.e. plusieurs exemplaire d'un demon sur différent ports). VS-Tun, serveur réels sous Linux seulement. Même production que LVS-DR. Nécessaire si les serveurs sont sur un autre réseau que le directeur (eg à un autre endroit).
plusieurs méthode de réexpédition Bien que se ne soit pas fait souvent, vous pouvez installer un directeur pour réexpédier avec plusieurs méthodes en même temps. Par conséquent, vous pouvez avoir telnet redirigé par LVS-NAT vers un groupe de serveurs réels, et http redirigé par LVS-DR vers un autre groupe de serveurs réels (même superposé).
Scripts et outils de configuration Il y a quelques outils pour vous aider à configurer un LVS. Joe a écrit un script de configuration pour tous les types, qui fait beaucoup de vérification de santé sur l'installation mais qui ne prend pas en charge la chute du directeur (dans le cas d'un directeur simple). Le script de configuration installera la commande mon pour prendre en charge l'échec de service sur les serveurs réels. Des outils qui incluent la chute du directeur, e.g. Ultra Monkey. par Horms, qui supporte la chute du directeur, mais doit etre configuré à la main. En avril, Horms a sorti UltraMonkey v3 (http://www.ultramonkey.org/download/3) Connection Syncronisation (synchronisation de connections) permet aux connections de continuer même si le directeur actif tombe est amené en ligne. Test de santé des serveurs MySQL natif (utilisant ldirectord). Prise en charge amélioré des paquets arp. Des kernels modifiés ne sont plus nécessaire (les patches LVS sont déjà dans la distribution standard des kernels et Horms n'a plus besoin de les distribuer les siens). Selon des enquètes, UltrMonkey est la méthode la plus fréquement utilisée pour mettre en place un LVS. vrrpd/keepalived par Alexandre Cassen, qui installe tout pour vous et est disponible ici keepalived . Il supporte les échecs du directeur et des serveurs réels. Sylvain Maugiron sm (at) edatis (dot) net 05 Fev 2003, a édité cgi interface. Malcolm Turnbull malcolm (dot) turnbull (at) crocus (dot) co (dot) uk 28 Jan 2003, a écrit une interface web php pour lvs/ldirectord Per Andreas Buer perbu (at) linpro (dot) no 27 Jan 2003 a écrit demon CLI-controlled LVS lvs-kiss qui utilise ipvsadm pour le balencement de charge et les échecs. Horms a écrit lvs-gui. Cela vient des début de LVS, il installe juste un LVS-DR, il n'est plus maintenu à jour et ne doit pas être utilisé pour un travail aujourd'hui. Sylvain Maugiron sm (at) edatis (dot) net 27 Jan 2003 L'interface ipvsadm est disponible ici Virtux J'essairai de développer cette interface. Malheureusement plusieurs de ces scripts créent des fichiers avec le nom rc.lvs (seulement pour rendre les choses plus interressante en lisant la mailing list). Une enquète sur les LVS en production (par Lorn Kay lorn_kay (at) hotmail (dot) com, résultats ici LVS website) a montré que 10 sur 19 ont été installés par des méthodes autres, i.e n'ont utilisé aucun des scripts du site LVS. Apparement les scripts ci dessus ne sont pas considéré par nos utilisateurs comme ayant la qualité nécessaire à la production.
Script de configuration Vous pouvez installer LVS à la main avec ipvsadm. Celà est néanmoins fastidieux et est enclain aux erreurs. Bien que ce soit faisable pour une configuration simple de LVS, mais ce n'est pas la bonne solution pour installer plusieurs configurations différentes de LVS. Le script de configuration est fait pour rapidement installer un LVS avec un service d'echec. Ecrit en perl, il écrit un script shell, que vous lancez sur toutes les machines (il se rend compte s'il est sur un directeur ou un serveur réel). Cela signifie que vous n'avez pas besoin que perl tourne sur vos serveurs réels. La version en court (0.9.x) réalise un bon nombre de vérification, récupérant toutes les erreurs ou pathologies que j'ai pu trouver ces 2 dernières années. Des vérifications élementaires sont faites sur le routage et la connectivité et le script a toujours généré un LVS qui fonctionne quand aucune erreur n'est renvoyée. Le script de configuration est lancé de la console du directeur (ou sur le directeur d'une connexion d'un réseau RIP ou alors d'une carte réseau d'administration pas utilisée pas LVS). Les connections tcpip connections passant par la carte réseau en façade seront coupées. Le script de configuration est sur le site de logiciel LVS (en bas de la page). Cela met en place un directeur simple et ne peut gérer l'échec du directeur. Pour les systèmes en production vous préfèrerez sûrement des outils qui gèrent les échecs du directeur. Le script de configuration teste et utilise les liens entre toutes les machines - le réseau doit être en fonctionnement. Vous devriez être capable de pinger toutes les machines du même réseau. Vous aurez besoin de carte réseau configuré avec RIP, SIP et PIP(pour les versions après 0.10.x) ou DIP (pour les versions 0.9.x et précédentes). Je n'est jamais publié la version v0.10.x. Le script de configuration lit un fichier conf et installe un lVS-DR, NAT, Tun avec des machines simple ou multi cartes réseaux en utilisant le matériel ethernet normal ou un proxi transparent pour accepter les paquets. Le résultat est deux fichiers bien commentés rc.lvs et rc.mon qui doivent être lancé au démarrage (ou quand vous installez un LVS). Le script de configuration détecte la version du kernel du directeur (pour les vieilles versions de ipvs/kernels) et est lancé sur le directeur pour générer le fichier rc.lvs. Le fichier rc.lvs est ensuite lancé sur le directeur puis sur les serveurs réels. Cela permet au script rc.lvs de vérifier les connections du directeur maintenant configuré. J'exporte par nfs les fichiers/dossiers vers les serveurs réels. Après avoir lancé le script rc.lvs sur le directeur, je peut lancer le même script sur les serveurs réels. (Après l'installation, les connections réseaux nécessaire pour l'exportation peuvent être enlevées.) En alternant, le script de configuration copie et execute le fichier rc.lvs sur les serveurs réels en utilisant ssh, avec l'option "-i" (pour vérifier que cela fonctionne lancez `ssh realserver_name_or_IP hostname` - vous devriez récupérer le nom d'hôte du serveur réel). Le fichier rc.lvs sait s'il tourne sur un directeur ou un serveur réel en regardant l'IP de la machine sur laquelle il tourne et en la comparant avec les IP du fichier conf. Le script rc.lvs est verbeux et fait des rapports sur son évolution. Le script est idempotent i.e.- vous pouvez lancer le script autant de fois que vous voulez sur une même machine. Vous pouvez copier le fichier rc.lvs du directeur sur les serveurs réels pour les lancer. J'ai mis le fichier conf sur le directeur dans le dossier (vous pouvez le mettre n'importe où) qui est exporté dans le même dossier sur les serveurs réels. De la même façon le script rc.lvs sur le directeur peut être lancé par les serveurs réels. Dans un système production, vous pouvez démonter les dossiers sur les serveurs réels après l'installation. En alternant, si vous lancez la configuration avec le "-i" (flag d'installation), le script de configuration va utiliser ssh pour copier les fichiers en sortie sur les serveurs réels et les éxécuter. Le script de configuration a été testé avec des kernels 2.2 et 2.4 Il renvoie un avertissement s'il rencontre un kernel plus jeune que ceux qu'il connait. Ces avertissement peuvent en fait être ignorés car ipvs n'est pas supposé changer de méthode de configuration. Le fichier conf et le script de configuration peuvent utiliser soit les IP ou les noms d'hôtes (de /etc/hosts) et peuvent utiliser soit les numéros de ports (eg 23) ou de service (telnet) (de /etc/services). Il est probable que des modifications de votre /etc/services soit nécessaire. Dans plusieurs instances, une machine aura besoin de plusieurs IP. Vous pouvez mettre plusieurs IP sur une carte réseau avec l'aliasing d'IP (une option à la construction du kernel) - entrez seulement l'interface aliased (eg eth0:12) pour cette IP dans le fichier *.conf. (Note: Les versions du script de configuration depuis 0.10.x seront déplacé vers les outils iproute2 et n'utiliseront pas les aliases. `ifconfig` et `netstat -rn` ne fonctionneront pas pour l'installation du réseau avec les outils iproute2 - Vous devrez utiliser uniquement les outils iproute2). La documentation du script de configuration est au format perldoc.
Le script de configuration a besion d'aide pour les kernels 2.6.x tito extlists (dot) e-inventa (dot) net 26 Mai 2004 J'ai résolu le problème du script n'étant pas compatible avec les versions 2.6 en changeant seulement le script rc.lvs_dr généré par configure-lvs, en cachant la version de mon kernel mais aussi en modifiant la fonction check_function_in_kernel(). Le problème avec cette fonction était qu'elle compare le résultat en cherchant avec grep -c dans System.map pour son module ip_vs_init, avec 1, et dans mon kernel il y a deux références à ip_vs_init (ip_vs_init et ip_vs_init_hash_table)
Installer le script de configuration Le script est en perl et requière les modules perl, pas nécessaire dans la démonstration. Toutefois, le script ne se lancera pas sans eux, donc vérifiez que vous avez les modules requis en lanceant : S'il vous manque un module perl (e.g. DNS.pm) vous aurez un message d'erreur comme Récupérez les modules supplémentaires ici perl website ou téléchargez avec le module perl cpan, ce que vous pouvez faire avec Vous aurez la ligne de commande cpan. Vous pouvez obtenir l'aide en tapant "help". Pour bien utiliser cpan, essayez la commande `r`, qui listera les plus récentes mise à jour pour les modules que vous avez installé. Vous devriez pouvoir installer Net::DNS avec la commande install Net::DNS ]]> Si votre mise à jour a besoin d'autre fichier, vous serez demandé de les télécharger. Le script rc.lvs utilise le fichierfping pour tester les connections. fping est disponible ici ftp://ftp.kernel.org/pub/software/admin/mon Les nouvelles versions de ping ont la fonctionnalités de fping et ce script de configuration teste cette fonctionnalité. Pour les anciennes configuration, si vous ne voulez pas télécharger fping, vous pouvez utiliser ce script au lieu de fping (mettez le dans /usr/local/bin et rendez le excécutable).
Lancer le script de configuration Choisissez un fichier template conf approprié (lvs_nat.conf, lvs_tun.conf ou lvs_dr.conf) pour le mode que vous lancez le LVS (VS-NAT, LVS-Tun ou LVS-DR respectivement) et modifiez les IPs et les services correspondant à votre situation. Il y a des fichiers de configuration d'exemple pour les différents types de redirection, nombre de réseaux et de carte réseaux. Le format du fichier conf est le même pour toutes les installations de LVS, seul les adresses IP/réseaux changent quand vous changez entre les directeurs avec une ou deux cartes réseaux. Plusieurs exemples de fichier conf sont fournis mais la seul chose qui change entre les diagrammes est le diagramme réseau (et la cible de la passerelle par défaut), mais pas le format des directives des fichiers conf. Les fichiers sont préconfigurés avec comme servive telnet. C'est le service le plus simple pour les testes initiaux : le client est directement disponible et connecté, la ligne de connexion vous dira sur quel serveur vous ètes connecté. Utilisez un progamme tournant pour vérifier qu'ils fonctionnent tous. D'autres services peuvent être ajouté en décommentant/ajoutant ou modifiant les entrées dans les fichiers *.conf d'exemple. Les fichiers *.conf donnent des suggestions d'IPs pour les différetes machines (192.168.1.x/24, 10.1.1.x/24). Lancé le script de configuration Celà génère un script rc.lvs_xxx (eg rc.lvs_nat, rc.lvs_tun, rc.lvs_dr), et un script mon_xxx.cf. (Après testes mettez rc.lvs_xxx dans /etc/rc.d ou /etc/init.d et mettez mon_xxx.cf dans /etc/mon) Lancez le script rc.lvs sur le directeur et sur les serveurs réels avec la commande ou alors (si vous avez des erreurs bizarre, eg il ne detecte pas correctement s'il tourne sur un directeur ou un serveur réel cela arrive sur serveur réel 2.0.36) $sh rc.lvs_dr Le script rc.lvs - ajoute objet ethernet et routes au directeur, serveurs réels (même les non Linux) vérifie les connexions avec fping. lance chaineip allume (VS-NAT) ou éteind (VS-DR, LVS-Tun) l'ipforwarding éteind les redirections icmp (VS-NAT) ajoute des services avec ipvsadm. Le script rc.lvs ne - connait pas l'échec du directeur. Il suppose qu'il y a qu'un seul directeur. Vérifiez les sorties de ipvsadm, ifconfig -a et netstat -rn sur le directeur et les serveurs réels, pour voir si les services/IPs sont correctes. Si non re modifiez et relancez les scriptes.
Test avec telnet Telnet est un service non-persistant (dans le sens http, plutôt que dans le sens LVS) et va vous permettre de vérifier que tous les serveurs réels sont présents (vous aurez la demande de login pour chaque serveur). Vérifiez que les services tournent sur chaque serveur sur l'IP du VIP utilisez netstat -an). Certains services (eg telnet écoute 0.0.0.0, ie toutes les IPs de la machine). S'il n'y pas d'erreurs lors de l'éxécution du script rc.lvs_xxx, alors faites un telnet du client jusqu'à la VIP (ici 192.168.1.110). Vous serez routé à travers le circuit jusqu'à l'un des serveurs réels et vous aurez la demande de login (et le nom réel) d'un serveur réel. Sur le directeur, regardez sur la sortie de ipvsadm, vous devriez voir une connexion à un serveur réel sur le port:23. Sur le serveur réel faites $ netstat -an | grep 23 et regardez les connexions sur le port telnet. Délogger vous et faites à nouveau un telnet sur le VIP. Vous arriverez alors sur la demande de login du serveur suivant.
Un test avec autre chose eg http Modifiez lvs_nat.conf et activez http, relancez configure.pl et relancez les nouveaux fichiers rc.lvs_nat. http: Faites pointer votre navigateur vers le VIP http://192.168.1.110. Vous obtiendrez le document root d'un des serveurs. Ouvrez un autre exemplaire du navigateur et connectez vous à nouveau. Vous devriez avoir l'autre serveur (ce sera plus facile à voir si les pages sont différentes). Regardez sur la sortie de ipvsadm sur le directeur, les connections aux ports httpd, et sur le serveur regardez, sur la sortie de netstat -an | grep 80 (ou 8080 si vous ètes en LVS-NAT avec le remappinng de ports), les connections. Si votre httpd est persistant (dans le sens http) il se peut que vous vous connectiez toujours au même site.
Installation - General
Abreviations/conventions pour installation/test/configuration Les DIP et VIP doivent avoir des IPs différentes (ils peuvent être sur la même carte réseau). Les DIP et VIP seront transférés vers un autre directeur en cas d'échec d'un directeur. Ces IPs seront mise en place en tant qu'IP secondaire (aliases dans le langage des kernels 2.0 et 2.2) pour vous puissiez utiliser l'échec d'un directeur. Le script de configuration met en place ces IPs pour vous (i.e. vous ne devez pas avoir les VIP et DIP comme adresse primaire déjà installé sur votre directeur). Julian Anastasov ja (at) ssi (dot) bg 06 Nov 2001
Si DIP == VIP les serveurs réels recevront des paquets avec l'adresse = ip_local de la part du directeur. Vous devez ajouter un IP(DIP) additionel à votre directeur et quand vous éxécutez ip la route devient x.y.z.230 vous devez vérifier que x.y.z.180 n'est pas votre adresse source préférée. La façon habituel pour faire celà est de configurer le VIP sur un autre matériel (eg lo) ou de les configurer après que le DIP soit configuré. De cette manière DIP sera votre source préféré lors d'échange dans votre sous réseau. Ajouter le DIP n'est pas obligatoire pour que l'installation de LVS fonctionne mais vous ne pourrez pas envoyer du traffic non LVS entre le directeur et les serveurs réels (ping dans ce cas).
Qu'est ce que vous ferez Chris chrisd (at) better-investing (dot) org 15 Avr 2002
J'ai téléchargé le kernel depuis kernel.org. J'ai téléchargé le patch ipvs (patch simple). J'ai téléchargé le patch "hidden". J'ai décompressé le kernel dans /usr/src. J'ai décompressé le patch "hiddent" dans /root. J'ai décompressé le fichhier simple ipvs. J'ai copié le patch "hidden" vers /usr/src/linux J'ai éxécuté : patch -p1 <hidden-2.4.5-1.diff J'ai copié le patch ipvs vers /usr/src/linux J'ai éxécuté: patch -p1 <linux-2.4.18-ipvs-1.0.2.patch J'ai configuré mon kernel J'ai fait exactement les mêmes étapes que tu as pour le compiler : J'ai n'ai pas eu le moindre bugs. Les choses à vérifier: N'appliquez pas les patches plus d'une fois! Si cela n'a pas marché en suivant les étapes suivantes et que vous avez RedHat 7.2, vérifiez que vous avez tout les packages gcc installés. Si vous le devez, remettez le CD dans le lecteur et faites une mise à jour et installez les outils nécessaire. Si ce n'est pas celà vérifiez que votre gcc est à jour. Une façon facile de le faire est de télécharger red-carpet de Ximian.org. C'est un outil de mise à jour Xwindows . Vous n'avez plus besoin de gnome pour le lancer . Si çà ne marche pas, trouvez vous un *vrai* guru, parce que là j'ai plus aucune idée !!
Le kernel du directeur - le construire soi-même (avec les suggestions de la part de John Cronin jsc3 (at) havoc (dot) gtf (dot) org) Ceci est la méthode préférée. Récupérez un kernell tout neuf iciftp.kernel.org et le ip_vs correspondant depuis le site LVS (sur la page software). Vous pouvez soit construire le code de ipvs dans le kernel soit en tant que module chargeable, suivant les deux versions de ip_vs pour chaque version d'OS. Les deux versions sont rarement publiés en même temps. (il y a un petit délai entre les deux). De Horms: Si vous voulez bidouiller le code ipvs, (e.g. changer la taile de la table de hashage, ce que nous ne vous recommandons pas) et que vous compilez ipvs comme un module, alors vous avez besoin de recompiler et recharger le module pour que les changements du module prennent effet. Vous avez quand même besoin de patcher et de recompiler le kernel pour pouvoir utiliser ipvs.Toutefois pour les kernels 2.4.x, çà vaut le coup de remarquer que c'est juste pour qu'un symbol, nécessaire à ipvsadm pour s'accrocher au netfilter, soit enregistré. Le kernel ne connait pas et se fiche du code du module ipvs quand il est compilé (à moins que vous compiliez directement ipvs dans le kernel). Dans les kernel 2.2 les patches ipvs font plus de travail. Vous devez commencer avec un arbre propre (tout juste téléchargé ou nétoyé avec la commande make mrproper). Si vous avez déjà configurez le kernel pour votre matériel sans ipvs vous devriez réutiliser votre fichier .config. Il sera patcher, en même temps que le code du kernel (rajoutant une nouvelle entrée dans la section networking), et votre configuration sans ipvs sera maintenu. (Faites une sauvegarde de votre fichier .config en cas de problème). Appliquez le patch ipvs du kernel en utitisant les instructions dans l'archive ipvs. Vous ferez quelque chose comme ext3 filesystems Il y a une collision dans les noms de variables quand les patch ipvs et ext3 sont mis tout les deux. Adam Kurzawa 4 Nov 2001
Après avoir appliqué les deux, patch lvs et ext3 pour 2.4.13 j'ai des erreurs de compilation. L'un appliqué sans l'autre marche très bien.
Wensong Enlevez la ligne de "EXPORT_SYMBOL(buffermem_pages);" dans le fichier linux/kernel/ksyms.c, puis recompilez le kernel.
Instructions de compilation Les instructions pour le patch du kernel varient selon la version du patch. Vous pouvez construire ipvs directement dans le kernel ou alors le laisser comme un module chargeable - les deux font l'affaire pour une première installation. Vous devez allumer "Prompt for developmental code... " sous la section "Code Maturity" . Dans la section "Networking", il faut que vous allumiez IP:masquerading avant d'avoir les options de ipvs. Certaines des options de compilation du kernel ci dessous ne sont explicitement nécessaire pour que LVS fonctionne, mais vous en aurez besoin un moment ou un autre - e.g. l'aliasing ip si vous avez besoin de construire un directeur avec une seul carte réseau ou le tunneling si vous utilisez LVS-Tun. En attendant de savoir ce que vous allez faire, activez toutes les options avec un "*" au début de la ligne. La configuration des options du kernel ci dessous sont juste pour LVS. Vous aurez besoin d'autre flag mis en place (e.g. filesystems, hardware...).
Les kernels2.2.x Les instructions de compilation du kernel varieront selon la version du patch. Voila ce que j'ai utilisé pour ipvs-0.9.9 sur un kernel 2.2.15pre9 dans les options Networking. Netlink device emulation * [*] Network firewalls [*] Socket Filtering <*> Unix domain sockets * [*] TCP/IP networking [ ] IP: multicasting * [*] IP: advanced router * [*] IP: policy routing [ ] IP: equal cost multipath [ ] IP: use TOS value as routing key [ ] IP: verbose route monitoring [ ] IP: large routing tables [ ] IP: kernel level autoconfiguration * [*] IP: firewalling [ ] IP: firewall packet netlink device * [*] IP: use FWMARK value as routing key (NEW) * [*] IP: transparent proxy support * [*] IP: masquerading --- Protocol-specific masquerading support will be built as modules. * [*] IP: ICMP masquerading --- Protocol-specific masquerading support will be built as modules. * [*] IP: masquerading special modules support * IP: ipautofw masq support (EXPERIMENTAL) * IP: ipportfw masq support (EXPERIMENTAL) * IP: ip fwmark masq-forwarding support (EXPERIMENTAL) * [*] IP: masquerading virtual server support (EXPERIMENTAL) * (12) IP masquerading LVS table size (the Nth power of 2) * IPVS: round-robin scheduling * IPVS: weighted round-robin scheduling * IPVS: least-connection scheduling * IPVS: weighted least-connection scheduling * [*] IP: optimize as router not host * IP: tunneling IP: GRE tunnels over IP [*] IP: broadcast GRE over IP [ ] IP: multicast routing [*] IP: PIM-SM version 1 support [*] IP: PIM-SM version 2 support * [*] IP: aliasing support [ ] IP: ARP daemon support (EXPERIMENTAL) * [*] IP: TCP syncookie support (not enabled per default) --- (it is safe to leave these untouched) < > IP: Reverse ARP [*] IP: Allow large windows (not recommended if <16Mb of memory) < > The IPv6 protocol (EXPERIMENTAL) ]]> Ne changez pas la taille de la table de masquage IP de LVS à moins que vous ne connaissiez LVS beaucoup mieux que nous. Si vous pensez toujours à changer la taille de la table de hashage au moins d'abord lisez le HOWTO (en anglais) . Faites tous les autres truc du kernel - faire les modules, installez les modules, copiez le nouveau kernel (et optionellement System.map, requie par le le script de configuration.) dans / ou /boot, et modifiez les fichiers de votre boot loader (lilo, grub). Veillez à gardez votre vieux kernel et vos anciennes config, pour que vos puissiez reprendre au départ au cas ou çà ne se passe pas bien. Redémarrez avec le nouveau kernel. En chargeant le nouveau kernel (avec ipvs en module), vérifiez que les modules sont bien chargés. Le fichier dans l'arborescence source du kernel à toutes les informations nécessaire.
Les kernels 2.4.x Les patches pour les premières versions des kernels 2.4.x ont été configurés et installés séparément du nemu "make menuconfig" du kernel. Cela requière de déplacer les fichiers dans le dossier /lib/modules et de charger les modules à la main. Avec des versions plus récentes du kernel, vous pouvez avoir un ensemble de fichier et disposé dans l'arborescence et configuré avec la commande make configure. L'installation change selon les versions de patch ip_vs. Veillez à lire la documentation. Les instructions ci-dessous sont pour un kernel 2.4.x . Vous pouvez vous attendre à voire des différences entre chaque kernel. Pour la version 2.4.18 (Simon Young simon-lvs (at) blackstar (dot) co (dot) uk, 1 Oct 2002)
Le Masquerading IP est : IP: Netfilter Configuration ---> IP tables support (required for filtering/masq/NAT) Full NAT MASQUERADE target support ]]> Tout les trucs pour LVS doivent ce trouver : IP: Virtual Server Configuration ---> ]]>
Voila la configuration du réseau Packet socket [ ] Packet socket: mmapped IO [*] Kernel/User netlink socket [*] Routing messages <*> Netlink device emulation [*] Network packet filtering (replaces ipchains) [*] Network packet filtering debugging [*] Socket Filtering <*> Unix domain sockets [*] TCP/IP networking [ ] IP: multicasting [*] IP: advanced router [*] IP: policy routing [*] IP: use netfilter MARK value as routing key [*] IP: fast network address translation [*] IP: equal cost multipath [*] IP: use TOS value as routing key [*] IP: verbose route monitoring [*] IP: large routing tables [*] IP: kernel level autoconfiguration [ ] IP: BOOTP support [ ] IP: RARP support IP: tunneling < > IP: GRE tunnels over IP [ ] IP: multicast routing [ ] IP: ARP daemon support (EXPERIMENTAL) [ ] IP: TCP Explicit Congestion Notification support [ ] IP: TCP syncookie support (disabled per default) IP: Netfilter Configuration ---> IP: Virtual Server Configuration ---> < > The IPv6 protocol (EXPERIMENTAL) < > Kernel httpd acceleration (EXPERIMENTAL) [ ] Asynchronous Transfer Mode (ATM) (EXPERIMENTAL) ]]> Voila ma configuration pour l'IP : Virtual Server configuration (turn it all on) virtual server support (EXPERIMENTAL) [*] IP virtual server debugging (NEW) (12) IPVS connection table size (the Nth power of 2) (NEW) --- IPVS scheduler round-robin scheduling (NEW) weighted round-robin scheduling (NEW) least-connection scheduling scheduling (NEW) weighted least-connection scheduling (NEW) locality-based least-connection scheduling (NEW) locality-based least-connection with replication scheduling (NEW) destination hashing scheduling (NEW) source hashing scheduling (NEW) --- IPVS application helper FTP protocol helper (NEW) ]]> Ne changez pas la taille de la table de hashage des connexions ipvs à moins que vous ne vous y connaissiez beaucoup plus que nous. Si vous voulez toujours changer la taille de la table de hashage, au moins d'abord lisez le HOWTO. Voici ma configuration pour la section netfilter Connection tracking (required for masq/NAT) FTP protocol support Userspace queueing via NETLINK (EXPERIMENTAL) IP tables support (required for filtering/masq/NAT) limit match support MAC address match support netfilter MARK match support Multiple port match support TOS match support Connection state match support Unclean match support (EXPERIMENTAL) Owner match support (EXPERIMENTAL) Packet filtering REJECT target support MIRROR target support (EXPERIMENTAL) Full NAT MASQUERADE target support REDIRECT target support Packet mangling TOS target support MARK target support LOG target support < > ipchains (2.2-style) support < > ipfwadm (2.0-style) support ]]>
iptables/ipchains problèmes de compatibilité J'ai enlevé les options ipchain ici. C'était mis à l'option <M> dans une version antérieur du mini-HOWTO. Toutefois çà soulève des problèmes pour les personnes qui n'ont pas compris les problème de compatibililté de ipchains. Les ipchains dans les kernels 2.2.x ont été remplacé par les iptables pour les kernels 2.4.x. Dans les kernels 2.4, ipchains est disponible pour la rétro-compatibilité. Toutefois les ipchains et iptables ne peuvent pas être utilisé en même temps. Vous ne devriez plus compiler les ipchains dans les kernels 2.4 (2.4.x sont sorties depuis 1999). Les ipchains sous 2.4 ralentissent le conntrack (voir le HOWTO). Le module ip_tables est incompatible avec les ipchains. S'il est présent, le module ip_tables doit être déchargé pour qu'ipchains fonctionne. Si ip_tables est chargé, vous aurez des erreurs incompréhensible si vous essayez de lancer la commande ipchains avec un 2.4. Plutôt que dire que les ipchains sous 2.4 sont la pour la compatibilité, il serait plus correcte de dire que la commande ipchains est la pour vous poser des problèmes et qu'il serait plus rapide de réécrire vos scriptes pour les iptables au lieu de tomber dans touts les trous en utilisant la compatibilité. Celà ne sera pas long avant que votre script/program doit lancer ip_tables sur votre machine 2.4 et au moment où çà arrive l'un ou les deux tomberont.
Compilation du kernel Faites tout les autres trucs pour le kernel - faites les modules, copiez le nouveau kernel dans / ou /boot (en lui donnant un nom différent de votre kernel en fonctionnement e.g. bzImage-0.9.4-2.4.12), modifiez lilo.conf et re-lancez lilo. Velliez à laisser les anciennes informations dans le lilo.conf pour pouvoir y revenir si çà ne se passe pas bien. Puis rebootez le nouveau kernel.
Si vous construisez ip_vs en dehors d'un kernel 2.4, faites fonctionner le kernel d'abord. Bootez avec le nouveau kernel et vérifiez que /usr/src/linux pointe vers votre arboréscence source du kernel (vous pouvez utiliser rc.system_map qui vient avec le script de configuration), avant de construire ipvs (si vous le faites séparément) et ipvsadm. N'oubliez pas de lancer la commande depmod -a après avoir installé les modules ip_vs.
Comment puis-je vérifier si le patch ipvs est installé sur mon kernel ? Réponse courte : Vous ne devriez pas utiliser le kernel de quelqu'un d'autre - compilez vous même un kernel avec un patch ipvs. Réponse longue : Si vous avez les binary de votre kernel, alors vous avez un peu de boulot devant vous. Si vous l'avez compilé vous même, alors vous devriez le nommé pour vous souvenir de ce que c'est (ici ip_vs 0.9.3 compilé comme module, kernel 2.4.9, avec patch forward-shared). Sinon Si ipvs est compilé dans le kernel Si le kernel est récent et que ipvs est compilé comme module, lancer ipvsadm chargera le module pour vous. De là vérifiez le module chargé avec lsmod. Pour des kernel plus vieux, vous devez charger le module avant de lancer ipvsadm Si le kernel n'as pas le patch ip_vs, le modulene ce lancera peu être pas.
Lister les symboles dans le kernel S.W.Seoohlyugen (at) yahoo (dot) co (dot) kr
Y a t'il une méthode pour voir les symboles dans une image kernel ? La commande nm montre les symboles dans un fichier, mais ne marche pas sur une imae kernel.
Peter T. Breuer ptb (at) oboe (dot) it (dot) uc3m (dot) es 8 Mar 2003 Dans l'image ou dans le kernel ? Quand il est lancé, vous cherchez /proc/ksyms. Mais vous pouvez utiliser la commande nm sur vmlinux et çà vous montrera les symboles. Je suppose que vous parlez de l'image compressé avec boot header, vmlinuz. Il va faloir vous sacrifier et le compresser d'abord.
ipvsadm Ipvsadm fait parti de l'archive ipvs et est l'interface utilisateur pour LVS. Ipvsadm s'utilise sur le directeur. Avant d'essayer de construire votre ipvsadm - relancez votre kernel nouvellement patché. Sinon vous aurez des erreurs à propos de fichier header manquant (vous utiliserez des header de la versions précédentes du kernel). Vérifiez que vous ètes dans le nouveau kernel patché. Faites uname -a, ou si vous avez compilé ip_vs comme un module, faites lsmod | grep ip_vs. Faites un make install pour ipvsadm. Vérifiez que le ipvsadm que vous utilisez vient de la même archive que les patches du kernel (si vous faites le kernel et que vous oubliez d'installer le nouveau ipvsadm vous aurez la vieille version de ipvsadm avec les nouveaux codes ipvs). Comme vous ne pouvez pas lancer/compiler ipvsadm avant d'avoir lancer le nouveau kernel, il arrive que vous oubliez de faire l'installation de ipvsadm après le redémarrage. La commande ipvsadm n'a pas de fortes capacités à tester les versions. Cà fonctionnera sur une version incompatible de ipvs et ce ne sera pas facile de se rendre compte, si vous ètes nouveau avec LVS que la sortie bizarre est dû un problème de version (Je l'ai fait et ai dû demander sur la mailing list). J'ai généralement plusieurs versions de ip_vs en cours pour des tests. J'ai installé ipvsadm comme /sbin/ipvsadm-(ip_vs_version-kernel_version) e.g. ipvsadm-0.2.12-2.4.4, et je laisse rc.system_map refaire le lien vers ipvsadm au démarrage.
Compiler ipvsadm avec popt Vous pouvez compiler ipvsadm avec popt libraries, qui permet à ipvsadm de soutenir des arguments plus compliqués dans la ligne de commande. Si votre librairie libpopt est trop ancienne, votre ipvsadm ne marchera pas.La compilation par défaut avant utilisait des librairies popt statique alors que maintenant il utilise des librairies dynamiques. Si vous avez des erreurs, POPT non trouvé, c'est que vous n'avez pas installé popt, ou que vous n'avez pas de popt récent. Torsten Buslei
Je viens juste de compiler et d'installer un nouveau kernel (2.4.18 avec patch 2.4.19-pre8 et linux-2.4.18-ipvs-1.0.2.patch.gz). Après le redémarrage (jusque là tout va bien), compilation de ipvsadm (soit ipvs-1.0.2.tar.gz ou ipvsadm-1.20.tar.gz) Je récupère ce message d'erreur: J'ai commenté cette partie de ipvsadm.c:345 Maintenant ipvsadm fonctionne correctement. Est ce correcte à faire ?
Horms horms (at) vergenet (dot) net 05 Mai 2002 Il semblerai que vous avez une version de popt qui ne supporte pas les arguments optionnel (POPT_ARGFLAG_OPTIONAL). Ta correction devrait être correcte, avec l'effet secondaire que vous devrez donner un argument à -p / --persistent si vous utilisez cette option.
Directeur: vérifié les logiciels Avec un peut d'adresse et de chance vous aurez chargé tout les logiciels sans aucun problèmes. Vérifiez que ipvsadm détecte les patches du kernel En cas de réussite sa devrait ressembler à çà RemoteAddress:Port Forward Weight ActiveConn InActConn ]]> Si vous ne faites pas fonctionner un kernel avec les patches ipvs vous aurez des messages d'erreurs à propos de modules ipvs manquants.
Kernel du directeur: trouver quelqu'un pour le faire à sa place Malgrè nos avertissement, pour vous essayez de construire votre premier kernel pour LVS les gens utilisent toujours les patches Certaines distribution ont leur kernel pré patché avec ipvs. RedHat a commencé à le faire fin 99 (mais a apparement arrété avec la version 2.4.20 d'après Peter Nash peter (dot) nash (at) changeworks (dot) do (do) uk 15 Mai 2003 et avec RedHat 9.0 selon James Bourne james (at) sublime (dot) com (dot) au). SuSE a déjà parlé de le faire (Dec 2000) (et a commencé à le faire en Mai 2003). Si vous avez l'une de ces distributions, suivez les instructions fournies avec la distribution pour avoir un directeur LVS qui fonctionne. Puisqu'en moyenne 2 versions d'ipvs sortent pour chaque versions de kernel, vous aurez certainement une version de ipvs plus ancienne si vous choisissez ce moyen. Ce n'est pas un problème - ipvs était assez fiable pour la production dès la première version, toutefois les versions vieilles de 6 à 12 mois ne sont plus supprotées sur la mailing list. On vous dira de revenir quand vous aurez mis à jour votre système. Si vous ne savez pas si vous avez un kernel prépatché avec ipvs, soit demandez à votre vendeur ou regardez dans l'arborescence source du kernel pour des fichiers ipvs (comme /usr/src/linux/net/ipv4/ip_vs_*.c). Si vous n'ètes pas sur, alors installez un nouveau kernel de ftp.kernel.org/pub/linux/kernel/. Vous pourrez toujours retourné à votre distribution patché plus tard. Si vous essayez de patché un kernel qui a déjà les patches ipvs appliqué vous aurez des erreurs de patch e.g. Hunk #1 succeeded at 121 with fuzz 2 (offset 18 lines). > Hunk #2 FAILED at 153. > Hunk #3 FAILED at 163. > Hunk #4 FAILED at 177. > 3 out of 4 hunks FAILED -- saving rejects to include/linux/ip_masq.h.rej > > patching file `include/net/ip_masq.h' > Reversed (or previously applied) patch detected! Assume -R? [n] ]]> Les personnes qui compile un kernel après l'échec d'une deuxième couche de patche arrive sur la mailing list avec des erreurs qui sont impossible à déchiffrer. Une des plus grandes source de question sur la mailing list est les personnes avec RedHat qui se retrouve avec une installation cassée après avoir suivi les instructions du mini-HOWTO. Ils ne démarrent pas avec un kernel standard et les instructions de RedHat ne leur disent pas ce qu'il ce passe. Voici des conseils de Larslmb (at) suse (dot) com
Si vous récupérez un message d'erreur, ou si votre distributon inclu déjà LVS, n'essayez pas d'appliquer le patch pas dessus. Premièrement essayez de vérifier avec votre vendeur s'il n'y a pas un package de mise à jour du kernel déjà disponible. Si vous pensez que cette révision des patches LVS a amené une amélioration significative par rapport aux précedentes, ou répare un bug critique pour vous, et que le vendeur ne fourni pas encore de kernel mis à jour, svp demandez leur de le faire. Si vous avez besoin d'une révision plus récentes que celle de votre distribution, svp récupérez une arborescence kernel propre et démarrez de là. Veillez à appliquer tout les autres patches dont vous avez besoin!
Traiter un kernel RedHat prépatché Ramish Patel a écrit:
J'utilise une Red Hat Linux 7.2, kernel 2.4.7-10, et j'ai essayez plusieurs patches pour LVS seulement deux d'entre eux ont été appliqué avec succés sans erreurs -- il venait de çà ipvs-1.0.4.tar.gz, qui contenai les deux patches qui ont été bien appliqué au kernel, linux_kernel_ksyms.c.diff , linux_net_netsyms.c.diff . J'ai recompilé le kernel après. Il me renvoie toujours des messages d'erreurs :
Horms horms (at) verge (dot) net (dot) au 31 Jul 2002 Premièrement, je recommenderai fortement que vous commenciez avec un kernel de kernel.org (comme le 2.4.18) au lieu d'utiliser un kernel RedHat à moins que vous ne sachiez ce que vous faites. ipvs-1.0.4 ne marche pas forcément directement avec un kernel RedHat 7.2 et vice versa. Toutefois si vous voulez le faire voici un guide approximatif. Vous avez besoin d'appliquer linux_kernel_ksyms.c.diff et linux_net_netsyms.c.diff Vous devez enlever la version existante de LVS qui est présente dans le kernel 7.2 . Vous pouvez le faire en examinant les patches qui sont donnés par les fichiers src.rpm et spec.file. Compilez le kernel - quelques petites choses devraient échouer. J'avais prévenu c'est le parcours du combatant. Construisez les modules du kernel mis à dispostion dans le sous dossier ipvs/ de ipvs-1.0.4.tar.gz. Vous aurez besoin de faire des modifications sur la source pour que çà marche, mais elles sont mineur. Alex Kramarov a (http://mail.incredimail.com/howto/lvs/install/ - lien mort Jul 2004) des instructions sur la construction/modification d'un kernel RedHat.
Directeur: problèmes de compilation Kim Le, Jul 25, 2001
J'ai des problèmes quand j'essaye de compiler LVS en tant que module. Il arrète pas de se plaindre pour "unresovled symbols - nf_register_hook" (symbole non résolu). J'ai cru que c'était parce que je n'avais selectionné NETFILTER, donc j'ai fait menuconfig, selectionné NETFILTER et recompilé le kernel. Je vérifie le System.map et je vois le symbole nf_register_hook symbol dedans.
Horms Je pense que vous avez un problème de symbol kernel comme est discuté ici http://marc.theaimsgroup.com/?l=linux-virtual-server&m=98766822929703&w=2 Vous pouvez trouver des informations sur comment résoudre ce problème http://lists.samba.org/listproc/netfilter/1999-November/002871.html Simplement les symboles de votre kernel ne sont plus à jour et vous avez besoin de reconstruire le kernel avec "make mrproper". Vous devriez faire une sauvegarde de votre kernel avant de faire celà. Une fois que vous l'avez fait allez dans le dossier ipvs et faites Wensong Ce que je comprend c'est que comme kernel/ksyms.c est patché nous devons faire la commande make mrproper pour être sûr que les ksyms sont à jour quand le kernel est construit. Est-ce correcte ? Si oui, cela ne ferait pas de mal de le mettre dans le README. Voici le post original pour réparer de la samba list. Erik Ratcliffe erik (at) calderasystems (dot) com 29 Nov 1999 Les symboles exportés du kernel devrait être stocké dans usr/src/linux/include/linux/modules. Plus précisément, le fichier ksyms.ver. Si votre kernel a été construit sur une arborescence existante et que vous n'avez pas lancé la commande 'make mrproper' avant, il y a des chances que les fichiers dans le dossier sus-cité soient corrompu. J'ai vu arriver cela sur plusieur systèmes quand un kernel SMP est utilisé face à une arborescence source linux qui contient des symboles non-SMP (vous pouvez deviner les symboles SMP par le préfixe "smp_" dans le CRC/version number, les symboles de kernel non-SMP n'ont pas ce préfixe). La meilleur façon de résoudre celà est de reconstruire le kernel depuis 'make mrproper' jusqu'à 'make modules_install'. Veillez à statuer que les versions doivent être assignées aux symboles des modules dans la configuration du kernel avant de la faire. Aisha aayesha83 (at) yahoo (dot) com Aou 25, 2005
Je suis nouvelle avec LVS et j'ai fait toutes les étapes décrites dans l'installation minimum, mais quand je fais modules_install, il me dit qu'il y a des symboles non résolu dans le fichierip_vs.o.
Horms Ce genre de problème ont en général une de ces trois causes. Le : vous avez allumé quelques options, comme netfilter, dans une arborescence qui a déjà été construite et quelques objets n'ont pas été reconstruit bien qu'ils auraient dû, et donc quelques symboles manquent. Je me souviens avoir vu souvent avec 2.4, il semble que ce soit un problème avec le système de construction. Heureusement, c'est facile mais assez long à faire. Du plus au niveau de source de kernel. Vous avez réussi à modifier votre fichier .config à la main et avez produit une configuration invalide - par exemple vous acceptez LVS sans le faire pour Netfilter. Ne faites pas celà!!! Utillisez make menuconfig ou make config selement si vous savez ce que vous faites. La construction est correcte, mais pendant modules_install, depmod est apellé, et depmod essaye de résoudre face au kernel en cours, il n'existe pas donc vous avez les erreurs que vous voyez. Celà peu être corrigé en redémarrant avec votre nouveau kernel.
Serveurs réels, autres unices Cette liste de serveurs réels vient de Ratz. La seul chose qu'il n'a pas essayé encore est le Plan 9. Noubliez pas de mettre le netmask =/32 pour le VIP sous LVS-DR et LVS-Tun (pour LVS-NAT vous pouvez n'importe quel netmask). Si vous utilisez des serveurs réels non Linux, vous pouvez en général traiter le problème arp en configurant le matériel supportant le VIP avec le switch -arp. Solaris 2.5.1, 2.6, 2.7 Linux (of course): 2.0.36, 2.2.9, 2.2.10, 2.2.12 FreeBSD 3.1, 3.2, 3.3 NT (bien que le Webserver crash): 4.0 no SP IRIX 6.5 (Indigo2) HPUX 11 HPUX fait l'arps même si vous lui dites de pas le faire. Vous aurez besoin de traiter le problème arp d'une autre façon. Le code de Ratz pour mettre en place des serveurs réels non linux est ici. Cette partie du script n'a pas été bien testé (vous pourez trouver que cela de configure pas bien votre boite unix, contactez moi - Joe). (Dans les 3 ans que ce script est sortie, je n'est pas entendu une seul personne utilisant cette partie du code, donc il n'y a aucune raison de le maintenir). Voici l'info original de Ratz pour les serveurs réels avec des OS non linux. Sous certains unix, vous devez plumber (activer) l'interface avant d'assigner une IP. L'instruction plumb n'est pas inclue ici. : ifconfig lo0 alias netmask 0xffffffff -arp up #ifconfig -a: lo0: flags=80c9mtu 16837 # inet 127.0.0.1 netmask 0xff000000 # inet netmask 0xffffffff #uname : IRIX #uname -r : 6.5 # : ifconfig lo0 alias netmask 0xffffffff -arp up #ifconfig -a: lo0: flags=18c9 # inet 127.0.0.1 netmask 0xff000000 # inet netmask 0xffffffff #uname : SunOS #uname -r : 5.7 # : ifconfig lo0:1 netmask 255.255.255.255 up #ifconfig -a: lo0: flags=849mtu 8232 # inet 127.0.0.1 netmask ff000000 # lo0:1 flags=849mtu 8232 # inet netmask ffffffff #uname : HP-UX #uname -r : B.11.00 # : ifconfig lan1:1 10.10.10.10 netmask 0xffffff00 -arp up #ifconfig -a: lan0: flags=842 # inet netmask ffffff00 # lan0:1: flags=8c2 # inet netmask ffffff00 # ]]> Ratz 16 Avr 2001
Dans la plupart des cas (en utilisant l'option NOARP) vous avez besoin du support des alias. Certains Unices n'ont pas de support pour les interfaces avec alias ou seulement limité, comme QNX, Aegis, ou Amoeba. D'autres ont des problèmes d'héritage de flag d'interface comme HP-UX où il est impossible de donner une interface avec alias un vecteur de flag différent comme pour interface physique sous-jacente (est déjà arrivé avec des Linux 2.2 et 2.4 - Joe). Donc pour HP/UX vous avez besoin d'une installation spéciale car avec l'installation standard présenté pour DR çà ne fonctionnera pas. J'ai essayé la plupart des unices en tant que serveur réels et j'ai été négativement impressionné par le nombre d'implémentation différentes. C'est sûrement le résultat d'instruction obscure de la part du RFC.
Gregory Boehnlein
Je vais bientôt me mettre à travailler sur quelque boites Solaris 9, et j'aimerais pouvoir les ajouter à mon groupe de machine LVS. Est-ce que quelqu'un sait comment une machine Solaris 9 peut être utilisé comme un serveur réels dans un groupe LVS-DR ? Sous linux, j'ai implémenté le patch arp "hidden". Comment le faire sous Solaris ?
Roberto Nibali ratz (at) drugphish (dot) ch 11 Aou 2003 Solaris n'a pas ce problème ;). Chris Kennedy ckennedy (at) iland (dot) net
Le truc que j'ai trouvé est que Solaris 2.6, et sûrement d'autres versions de Solaris aussi, vous devez faire un peu de magie pour mettre en place l'alias de loopback. Vous devez lancer ces commandes l'une après l'autre : ifconfig lo0:1 ifconfig lo0:1 netmask 255.255.255.255 ifconfig lo0:1 up ]]> Ce qui marche bien et est en fait un lien point à point comme ppp qui doit être la façon dont Solaris défini les aliases sur l'interface lo Il ne vous laissera pas tout faire d'un coup, seulement chaque étape séparément ou vous devrez tout reprendre du début.
Ramon Kagan rkagan (at) YorkU (dot) ca 05 Juin 2002
Au cas ou çà interresserait quelqu'un, vous pouvez faire ces opérations sur lo0:1 ou pour les paranoïaques comme moi sur hme1. plumb ifconfig ifconfig ifconfig netmask 255.255.255.255 ifconfig up ]]> Cela vient de la FAQ mais j'ajoute le faite que çà ne doit pas être obligatoirement sur lo0.
Interface de loopback sous Windows/Microsoft/NT/W2K Windows n'est pas prévu par le script de configuration (qui a besoin de bash pour fonctionner). Selon Horms vous n'avez pas besoin de grand chose pour traiter le poblème arp, apparement windows respecte le flag noarp. Les instructions pour mettre en place un serveur réel sous windows est l'une des questions les plus communes sur la mailing list. Cà doit être une partie difficile à trouver du mini-HOWTO ;-\. Il semble qu'il y est plusieurs façon de le faire. Voici quelque réponses. Mettre la metric à 254 semble être décisif. La recète de Wensong pour mettre en place le lo sur un serveur réel NT.
Si vous n'avez pas le driver loopback Adapter de MS installé sur vos sur vos machines NT, allez dans le Network Control Panel, clickez sur la section Adapter, clickez pour ajouter un nouvel adapter, selectionnez le Loopback Adapter MS. Votre CD NT est nécessaire pour cette étape. Puis ajoutez votre adresse VIP (Virtual IP) sur le Loopback Adapter de MS, ne saisissez pas d'adresse de passerelle sur le Loopback Adapter. Puisque le netmask 255.255.255.255 est considéré invalide par M$ NT, acceptez le netmask par défaut, puis allez dans la console MS-DOS, et supprimez la route en trop. ]]> Celà va faire que les paquets destinés à ce réseau vont traverser l'autre interface réseau et non l'interface de Loopback MS. Si je me souviens bien, mettre le netmask à 255.0.0.0 fonctionne aussi.
Jerome Richard jrichard (at) virtual-net (dot) fr
Sous Windows NT Server, vous avez juste à installer le network adapter nommé "MS Loopback" (Fourni sur le CDROM NT dans la section nouveau réseau) puis le mettre en place sur cette interface.
o1004g o1004g (at) nbuster (dot) com Clickez sur Démarrer, panneau de configuration, puis double-clickez sur ajout/suppression de matériel. Clickez sur Ajouter/Réparer un matériel, clickez sur suivant. Clickez sur Ajouter un matériel, clickez sur suivant. Clickez sur non, Je veut choisir un matériel dans une liste, clickez sur suivant. Clickez sur adaptateurs réseau, clckez sur suivant. Dans la liste des fabricants, clickez sur MS. Dans la liste des adaptateurs réseaux, clickez sur MS Loopback Adapter, puis clickez sur suivant. Clickez sur terminer. robert.gehr (at) web2cad (dot) de; 24 Oct 2001
Le Loopback adapter de MS est un outil virtuel sous windows çà ne résoud aucune requètes arp. Cà devrait être sur un CD Server Edition CD de WinNT/2000. Installez et assignez le à l'adresse IP appropriée. Comme MS ne vous laisse pas assigner un netmask à "x.x.x.x/32" pour le Loopback adapter, vous allez vous retrouver avec deux routes pointant sur le même réseau. Disons que votre RIP est 10.10.10.10 et que votre MS-Loopback VIP est 10.10.10.11. Vous aurez deux routes dans votre table de routage toutes les deux pointants vers 10.0.0.0. Vous pouvez supprimer la route lié au VIP sur le Loopback adapter avec une commande comme
Johan Ronkainen jr (at) mpoli (dot) fi
Vrai avec Windows NT4. Toutefois avec Win2000 vous pouvez simplement configurer une metric haute pour pour les interfaces de loopback. J'ai essayé celà avec la valeur 254 sans problèmes. Je crois que vous pouvez changer le netmask à /32 avec regedit. Je ne l'ai pas essayé avec WinNT4/2000. J'ai essayé ce truc avec Win98SE et çà a fonctionné.
Brent Knotts brent (dot) knotts (at) mylocalgov (dot) com 28 Jan 2003
Concernant les serveurs réels Windows 2000 : Il est possible de changer le mask de sous réseau à 255.255.255.255 dans le registre, et çà marche bien avec mon istallation DR. C'est plus simple que de supprimer la route en trop de l'interface local après chaque redémarrage. Dans Windows 2000, les interfaces se trouve dans : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces Trouvez l'interface avec la bonne adresse IP et changez le mask de sous réseau. Le redémarrage n'est pas nécessaire, mais il faut que vous éteignez et rallumiez l'interface.
Langue étrangère pour MS Sebastien Sebastien.Bonnet (at) experian (dot) fg 12 Avr 2002
En français "MS Lookback Adapter" correspond à "carte de bouclage"
Malcolm Turnbull
J'ai mis en place un balanceur de charge LVS-DR avec 4 serveurs web IIS (win2K) derrière. J'ai mis un loopback adapter sur chaque serveur 2K et mis la priorité à 254. Le balnaceur de charge fonctionne bien... Mais il semble que çà traumatise le réseau Windows, le navigateur de réseau SMB semble ne plus fonctionner. (nécessaire pour RoboCopy).
Martijn Klingens mklingens (at) ism (dot) nl 10 Sep 2002. Subject: Re: Configuration de LVS DR avec serveurs NT2K
On utilise une configuration presque similaire, on utilise en ce moment un xcopy simple et voulons migrer vers DFS. Celà ne change pas le basique mais voila les choses que j'ai rencontré : Windows ajoute toujours une route au sous réseau sur le loopback adapter. Si ce sous réseau est aussi disponible pour le réseau normal votre table de routage va être embrouillée. Dans notre cas, nous avons migré des sites vers LVS pour que nous ayons à prendre un mask de sous réseau de class C. Solution : supprimer manuellement la route /24 dans l'interface de loopback. Désactiver les services de fchier et d'impression aide aussi en général. Vérifiez les passerelles par défaut et le DNS sur les différentes interfaces. Si elles ne sont pas identiques vous aurez des comportements bizarre (bien qu'il y est des cas où il est utile qu'ils soient différents, mais ce n'est pas si souvent). J'espère que çà vous aide. Si non, mettez plus de détails sur votre configuration Si vous avez des problèmes sur les serveurs réels, sont ils capables de résoudre un autre serveur réel en utilisant DNS ou ping ? Et vous avez aussi parlé de navigation réseau, ce qui n'est pas exactement la même chose que d'ouvrir un partage sur un ordinateur avec un nom connu. Avez-vous vraiment besoin d'un navigateur ? En général le service de navigation est arrété pour qu'un intrus ne puisse pas immédiatement voir les autres hôtes Win2000 sur le réseau. Un peu inutile puisque DNS fourni les mêmes données, mais çà ne fait pas de mal non plus.
lstep (at) banquise (dot) org 11 Aou 2004
J'essaye de comprendre pourquoi vous avez mis la metric de l'interface local à 254 (selon la documentation trouvé sur LVS avec HA pour Win2k Terminal Servers (http://wiki.linuxquestions.org/wiki/LVS_with_HA_for_Win2k_Terminal_Servers) quand vous configurez le loopback d'un serveur réel Win2000 en mode de routage direct ? Si je ne le fait pas quel(s) problème(s) vais-je avoir ?
Malcolm Turnbull malcolm (at) loadbalancer (dot) org NT peut vraiment être une plaie quand sa table de routage est corrompue Dans ce que j'ai vu, mettre la métric à 254 résoud 95% des problèmes. Ratz
Désolé mais çà ne me convint pas vraiment. Où puis-je me renseigner ? Que fais vraiment NT quand on lui met un tel métric ?
Utilser le registre pour mettre le netmask à 255.255.255.255 corrige les 5% restants Semble nécessaire avec des domaines NT ou des serveurs avec plusieurs carte réseau. Un serveur réel avec un problème est facile à repérer puisqu'il ne marchera pas sous DR et que la table de routage sera incorrecte. Malcolm Turnbull malcolm (at) loadbalancer (dot) org 2005/04/15 Nous avons un petit outil basé sur .net pour mettre en place le loopback adapter pour le mode DR sur les serveurs web sous windows 2000/2003. L'idée était d'installer le loopback et mettre en place autant de VIP que nécessaire puis mettre le netmask à 255.255.255.255. Mais pendant les testes nous avons vu que windows arrète de répondre au balaceur de charge RIP (pour des contrôles de santé), alors que si vous utilisez le netmask de 255.0.0.0, Windows ignore cette route et cherche le plus petit sous réseau dans la table de routage en premier i.e. dans votre cas 255.255.255.0 (ou ce que vous utilisez pour votre RIP.) Le petit utilitaire nécessite le framework .net 1.1. Au démarrage, clickez sur l'alerte rouge 'no adapter found' pour installer le loopback. Puis ajoutez autant de VIP que vous voulez et clickez sur save. Plutôt inutile pour quelqu'un qui sait ce qu'il fait, mais quelqu'un pourrait trouver çà utile. Vous pouvez télécharger les binaire et source (http://www.loadbalancer.org/download/nt/). NB : Celui appelé BETA mettra le netmask à 255.255.255.255 (si c'est ce que vous voulez). Graeme Fowler graeme (at) graemef (dot) net 06/11/2005 Ajouter une machine WIN NT à une installation LVS : Si vous allez dans "ajouter un nouveau matériel" et "choisir dans la liste" vous devriez pouvoir le trouver sous Adaptateur réseau. Installez le "Microsoft Loopback Adapter" et assignez lui les adresses nécessaires. IIRC ne fait pas de arp du tout, et je l'ai utilisé en production pour plusieurs setup SLB - pas derrière un LVS mais, c'était des machine Cisco IOS ou des setups ExetremWare, utilisant NAT ou DR.
Mac OS X (et Solaris) Malcolm Turnbull
Est ce que quelqu'un a utilisé Mac OS X comme serveur réel sous LVS/DR ?
Jerome RICHARD jrichard (at) virtual-net (dot) fr 20 Nov 2002 Si vous voulez configurer plusieurs IP sous Mac OS X, vous devrez utiliser la commande suivante : Il y a plus d'info sur les documents AppleCare Roberto Nibali ratz (at) drugphish (dot) ch 20 Nov 2002 Oui, j'ai fais une présentation il y a un an à peu près et je me souviens que l'un des spectateurs avait un G4 tout neuf avec Mac OS X. Cà avait marché parfaitement.
Est ce que une interface loopback fonctionne ?
Oui, mais vous n'en avez pas besoin. OS X est BSDish, vous devez utiliser la syntaxe BSDish : Malcolm Turnbull Malcolm.Turnbull (at) crocus (dot) co (dot) uk 22 Nov 2002
Pour les faire marcher : Solaris: netmask 255.255.255.255 up ]]> Mac OS X:
Example 1: LVS utilisant la redirection LVS-NAT LVS-NAT était la première méthode utilisée pour mettre en place un LVS. Pour les kernels 2.2 sur le directeur, il est moins efficace pour de grosse charge comparé à LVS-DR ou LVS-Tun, à cause de l'ajout de la réécriture des paquets, mais est toujours utile dans certaines circonstances. Pour les kernels 2.4 sur le directeur, les performances de LVS-NAT sont meilleur. Mettre en place un LVS avec deux réseaux (ici 192.168.1.0/24 et 192.168.2.0/24) en utilisant une seul carte réseau sur chaque machine. (Pour les testes, ne mettez pas d'autres IP sur les machines). Le VIP sur l' alias ethernet (eth0:110) est mis en place par le script de configuration, i.e., n'ajoutez pas le VIP. Il ne devrait pas y avoir de route par défaut, et toutes les interfaces sur le réseau 192.168.1.0/24 devrait pouvoir ce pinguer. Le client ne doit pas pouvoir se connecter tant que le VIP n'est pas activé sur le directeur.
Installation avec le script de configuration Le fichier configure a un bug avec LVS-NAT. Il enlève la passerelle par défaut du directeur (qui devrait être le routeur local). Vous allez être obligé de le remettre à la main. (Le script enlève correctement la paserelle par défaut pour LVS-DR et LVS-Tun. Pour voir les raisons pour lesquelles vous ne devez pas avoir de passerelle par défaut pour les directeurs sous LVS-DR et LVS-Tun regardez conseil de sécurité : passerelle par défaut et routage avec LVS-DR/LVS-Tun . Il serait mieux pour LVS-NAT d'avoir simplement une route de VIP:80 vers 0/0:0 plutôt qu'une route par défaut). Pour les versions v0.9.x du script de configuration, utilisez le fichier conf lvs_nat.conf.one_NIC_two_network puis lancez le script de configuration celà va créer (entre autre) un fichier rc.lvs_nat (ou rc.lvs). Lancez ce fichier rc.lvs_nat en premier sur le directeur puis sur les deux serveurs réels (le fichier sait s'il est sur le directeur ou un serveur réel et agit en sorte). L'un des pièges dans l'installation d'un LVS-NAT est que vous devez faire du directeur la route par défaut pour le les serveurs réels (le script le fait pour vous) mais çà ne marchera pas si vous ne faites pas celà.
Installation à la main Lancez ce script sur le directeur. /proc/sys/net/ipv4/ip_forward #director is gw for realservers #turn OFF icmp redirects (1 on, 0 off) echo "0" >/proc/sys/net/ipv4/conf/all/send_redirects cat /proc/sys/net/ipv4/conf/all/send_redirects echo "0" >/proc/sys/net/ipv4/conf/default/send_redirects cat /proc/sys/net/ipv4/conf/default/send_redirects echo "0" >/proc/sys/net/ipv4/conf/eth0/send_redirects cat /proc/sys/net/ipv4/conf/eth0/send_redirects #setup VIP /sbin/ifconfig eth0:110 192.168.2.110 broadcast 192.168.2.255 netmask 255.255.255.0 #set default gateway /sbin/route add default gw 192.168.2.254 netmask 0.0.0.0 metric 1 #clear ipvsadm tables /sbin/ipvsadm -C #install LVS services with ipvsadm #add telnet to VIP with rr sheduling /sbin/ipvsadm -A -t 192.168.2.110:telnet -s rr #first realserver #forward telnet to realserver 192.168.1.11 using LVS-NAT (-m), with weight=1 /sbin/ipvsadm -a -t 192.168.2.110:telnet -r 192.168.1.11:telnet -m -w 1 #check that realserver is reachable from director ping -c 1 192.168.1.11 #second realserver #forward telnet to realserver 192.168.1.12 using LVS-NAT (-m), with weight=1 /sbin/ipvsadm -a -t 192.168.2.110:telnet -r 192.168.1.12:telnet -m -w 1 #checking if realserver is reachable from director ping -c 1 192.168.1.12 #list ipvsadm table /sbin/ipvsadm #------mini-HOWTO-setup-LVS-NAT-director---------- ]]> Lancez ce script sur les serveurs réels /proc/sys/net/ipv4/ip_forward cat /proc/sys/net/ipv4/ip_forward #---------mini-HOWTO-setup-LVS-NAT-realserver------- ]]>
Opération de testes LVS-NAT Sur le directeur lancez la commande La sortie devrait être quelque chose comme RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.2.110:telnet rr -> 192.168.1.11:telnet Masq 1 0 0 -> 192.168.1.12:telnet Masq 1 0 0 ]]> Maintenant faites un telnet du client vers 192.168.2.110. Vous aurez la demande de login pour l'un des serveurs réels notez lequel). Maintenant relancez ipvsadm sur le directeur. RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.2.110:telnet rr -> 192.168.1.11:telnet Masq 1 1 0 -> 192.168.1.12:telnet Masq 1 0 0 ]]> Notez que le compteur ActiveConn a augmenté. Ouvrez une autre fenètre sur le client et faites un telnet sur 192.168.2.110. Vous devriez tomber sur la demande de login de l'autre serveur réel. Re lancez ipvsadm. RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.2.110:telnet rr -> 192.168.1.11:telnet Masq 1 1 0 -> 192.168.1.12:telnet Masq 1 1 0 ]]> Il y a maintenant 2 connections active. Vous ètes maintenant connecté aux serveurs réels par une session telnet. Félicitations - vous avez mis en place un LVS-NAT pour le service telnet.
Setup de LVS-NAT pour le service http Vérifiez que les serveurs réels servent le http, ils écoutent sur le port 80 sur leur propre IP. (la RIP, e.g. 192.168.1.11, 192.168.1.12) i.e. sur une IP différentes pour chaque serveur réel. Faites les deux pages un peu différentes pour voir sur quelle machine vous vous connectez. Changez le fichier conf en décommetant la ligne http et en commentant la ligne telnet. Relancez le script de configuration sur le nouveau fichier conf, relancez le fichier rc.lvs sur le directeur et sur les serveurs réels. ou Pour la configuration à la main, remplacez telnet par http, dans le script du directeur, vous n'avez pas besoin de relancer les scripts des serveurs réels. Si vous n'avez pas d'erreur lancez ipvsadm RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.2.110:www rr -> 192.168.1.11:www Masq 1 0 0 -> 192.168.1.12:www Masq 1 0 0 ]]> Dirigez votre client http vers 192.168.2.110. Si vous recevez la page web attendu, rechargez plusieurs fois, et regardez les pages alterner sur les serveurs réels. Dans certains cas, supposèment à cause de la persistence du http, les connections continuerons sur un serveur réel. Dans ce cas utilisez lynx, curl ou telnet vers 192.168.2.110 80 et à la ligne de commande tapez pour utiliser lynx faites Relancez ipvsadm (sur le directeur) RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.2.110:www rr -> 192.168.1.11:www Masq 1 0 13 -> 192.168.1.12:www Masq 1 0 12 ]]> Contrairement à telnet il n'y a pas de ActiveConn bien qu'il y ai une page affichée chez le client. Le http se déconnecte après 15secs rendant donc les connexions InActConn. Les InActConn disparaisent au bout de 2 mins (relancez ipvsadm après 2 mins et InActConn devrait être à 0). Les timeout peuvent être vu en utilisant la commande ipchains -L -M -n (pour les kernels 2.2, pour les kernels 2.4 et plus d'info voir le HOWTO).
Example: Setup de LVS utilisant la redirection LVS-DR Mettre en place un LVS avec un simple réseau (ici 192.168.1.0/24) sur des machines avec une carte réseau. Les IPs sur les aliases ethernet (eg eth0:110, lo:0) sont mis en place par le script de configuration. Il ne doit pas y avoir de routes par défaut et toutes les machines doivent pouvoir se pinger.
VS-DR for the service telnet Pour les versions v0.9.x du script de configuration, utilisez le fichier conf lvs_drt.conf.one_NIC_one_network puis celà va créer (entre autre) un fichier rc.lvs_dr Lancez le fichier rc.lvs_dr en premier sur le directeur puis sur les deux serveurs réels (le fichier sait s'il est exécuté sur le directeur ou un serveur réel et agit en sorte).
Setup à la main Sur le directeur lancez ce script /proc/sys/net/ipv4/ip_forward #director is not gw for realservers: leave icmp redirects on echo 'setting icmp redirects (1 on, 0 off) ' echo "1" >/proc/sys/net/ipv4/conf/all/send_redirects cat /proc/sys/net/ipv4/conf/all/send_redirects echo "1" >/proc/sys/net/ipv4/conf/default/send_redirects cat /proc/sys/net/ipv4/conf/default/send_redirects echo "1" >/proc/sys/net/ipv4/conf/eth0/send_redirects cat /proc/sys/net/ipv4/conf/eth0/send_redirects #add ethernet device and routing for VIP 192.168.1.110 /sbin/ifconfig eth0:110 192.168.1.110 broadcast 192.168.1.110 netmask 255.255.255.255 /sbin/route add -host 192.168.1.110 dev eth0:110 #listing ifconfig info for VIP 192.168.1.110 /sbin/ifconfig eth0:110 #check VIP 192.168.1.110 is reachable from self (director) /bin/ping -c 1 192.168.1.110 #listing routing info for VIP 192.168.1.110 /bin/netstat -rn #setup_ipvsadm_table #clear ipvsadm table /sbin/ipvsadm -C #installing LVS services with ipvsadm #add telnet to VIP with round robin scheduling /sbin/ipvsadm -A -t 192.168.1.110:telnet -s rr #forward telnet to realserver using direct routing with weight 1 /sbin/ipvsadm -a -t 192.168.1.110:telnet -r 192.168.1.11 -g -w 1 #check realserver reachable from director ping -c 1 192.168.1.12 #forward telnet to realserver using direct routing with weight 1 /sbin/ipvsadm -a -t 192.168.1.110:telnet -r 192.168.1.12 -g -w 1 #check realserver reachable from director ping -c 1 192.168.1.12 #displaying ipvsadm settings /sbin/ipvsadm #not installing a default gw for LVS_TYPE vs-dr #---------------mini-rc.lvs_dr-director------------------------ ]]> Pat Villani Pat (dot) Villani (at) hp (dot) com 09 Oct 2004
J'utilise l'exemple de VS-DR du mini-HOWTO. Une des premières étapes est d'éteindre l'ip_forward. Pourquoi ? Il semble que çà marche sans cette étape et en plus le faire interfère avec mon service NAT.
Je l'ai juste éteind parce que vous n'en avez pas besoin pour LVS-DR, et que l'éteindre rend votre machine plus sûr. Vous pouvez l'allumer si vous avez des raisons de le faire. Sur les serveurs réels lancez ce script /proc/sys/net/ipv4/ip_forward cat /proc/sys/net/ipv4/ip_forward #looking for DIP 192.168.1.9 ping -c 1 192.168.1.9 #looking for VIP (will be on director) ping -c 1 192.168.1.110 #install_realserver_vip /sbin/ifconfig lo:110 192.168.1.110 broadcast 192.168.1.110 netmask 0xffffffff up #ifconfig output /sbin/ifconfig lo:110 #installing route for VIP 192.168.1.110 on device lo:110 /sbin/route add -host 192.168.1.110 dev lo:110 #listing routing info for VIP 192.168.1.110 /bin/netstat -rn #hiding interface lo:110, will not arp echo "1" >/proc/sys/net/ipv4/conf/all/hidden cat /proc/sys/net/ipv4/conf/all/hidden echo "1" >/proc/sys/net/ipv4/conf/lo/hidden cat /proc/sys/net/ipv4/conf/lo/hidden #----------mini-rc.lvs_dr-realserver------------------ ]]>
Test LVS-DR operation Puis sur le directeur lancez la commande La réponse devrait être quelque chose comme RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.1.110:telnet rr -> 192.168.1.11:telnet Route 1 0 0 -> 192.168.1.12:telnet Route 1 0 0 ]]> Notez que la méthode de forwarding a changé de Masq à Route. Maintenant faites un telnet du client vers 192.168.1.110. Vous obtiendrez la demande de login d'un des serveurs réels (notez lequel). Puis relancez ipvsadm. RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.1.110:telnet rr -> 192.168.1.11:telnet Route 1 1 0 -> 192.168.1.12:telnet Route 1 0 0 ]]> Si vous avez lancé des tcpwrappers autour de telnet sur les serveurs réels, le login sera retardé d'un interval de 7 secs(Slackware) et 3mins(RedHat). Vous pouvez changez çà en changeant la ligne dans le fichier inetd.conf. et de relancer (re-HUPing) inetd. Si vous avez un telnetd et login "pam-ifié" vous ne pourrez jamais réparé se retard (le manuel de RedHat 6.2 dit de changer des entrées dans le fichier /etc/pam.conf, un fichier qui n'existe pas). Après s'être logger, la session telnet se comporte normalment. Ce délai n'est qu'une nuisance mineur, mais il est difficile de la différencier d'un ralentissement de connexion dû à une mauvaise configuration. Ce délai n'existe pas avec LVS-NAT (voir la section sur identd dans le HOWTO pour une explication). Ouvrez une autre fenètre sur le client et faites un telnet sur 192.168.1.110. Vous devez avoir la demande de connection de l'autre serveur réel. Relancez ipvsadm. RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.1.110:telnet rr -> 192.168.1.11:telnet Route 1 1 0 -> 192.168.1.12:telnet Route 1 1 0 ]]> Il y a maintenant 2 connexions active. Vous ètes maintenant connecté aux serveurs réels par une session telnet normal. Fèlicitations - vous avez mis en place un LVS-DR pour le service telnet.
Setup de LVS-DR pour le service http IMPORTANT: Veillez à ce que le httpd sur les serveurs réels écoutent le VIP:80 (ici 192.168.1.110:80) i.e les deux serveurs réels écoutent la même IP. La connection du client va arriver sur VIP:80 sur le serveur réel. Il faut que vous mettiez en place le VIP sur le lo:0 avant que le https ne démarre. (Vous pouvez aussi mettre le httpd écouter sur le RIP , ici 192.168.1.11 ou 192.168.1.12, si vous préférez, mais ces IPs ne sont pas impliqué dans le LVS.) Faites les pages sur les serveurs réels différentes pour que vous puissiez savoir sur laquelle vous ètes connecté. Changez le fichier conf en ajoutant le ligne httpd et en commentant la ligne telnet. Relancez le script de configuration sur le fichier conf, relancez le fichier rc.lvs sur le directeur et sur les serveurs réels. ou Si vous le mettez en place à la main, changez le telnet par http et relancez le script sur le directeur. Vous n'avez pas besoin de relancez le script sur les serveurs réels. Si vous n'avez pas d'erreurs, lancez ipvsadm. director:/lvs/conf# ipvsadm IP Virtual Server version 0.9.14 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.1.110:www rr -> 192.168.1.11:www Route 1 0 0 -> 192.168.1.12:www Route 1 0 0 ]]> Connectez votre client http client à 192.168.1.110. Si vous avez la page attendu, recharger plusieurs fois, vous verez les pages web alterner entre les serveurs réels. Dans certains cas, supposément dû à une persistance de http, les connexions vont passées sur un serveur. Dans ce cas utilisez lynx ou telnet vers 192.168.1.110 80 et dans la demande de commande tappez pour utiliser lynx faites Relancez ipvsadm (sur le directeur) director:/lvs/conf# ipvsadm IP Virtual Server version 0.9.14 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.1.110:www rr -> 192.168.1.11:www Route 1 0 5 -> 192.168.1.12:www Route 1 0 4 ]]> Contrairement à telnet il n'y pas de ActiveConn bien que des pages se soit affichées sur le client. Le protocole http déconnecte après 15secs (max). Les connexions changent vers InActConn et expire au bout de 2 mins. Si vous relancez ipvsadm après 2 mins les InActConn seront à 0. Félicitations, c'est fini. Allez faire la fête. Pour plus d'information allez voir le HOWTO ou les docs sur le site LVS et regardez dans les archives des mails. Si vous avez une question, rejoignez la mailing list.
Comment d'autres utilisateurs ont fait
Dan Browning, LVS-DR sur Red Hat 7.2: traitement ARP, autres problèmes divers Le post original est ici : lvs mailing list archives Dan Browning db (at) kavod (dot) com 2002-01-05 Okay, c'est la dernière fois que je post ici, c'est promis. :-) La dernière fois j'ai été un peu vite pour envoyer le mail, donc cette fois j'envoie *toutes* les instructions (plus ou moins) que j'ai faites pour mettre en place un LVS-DR sur une Red Hat 7.2. J'espère que çà servira à quelqu'un un jour. Prochain projet : reprise du directeur automatique après échec... >~/.ssh/authorized_keys2' # Helpful Documentation http://ha.redhat.com/docs/high-availability/index.html http://www.linuxvirtualserver.org/docs/arp.html http://www.linux-vs.org/~julian/hidden.txt # Enabling IP Encapsulation # On each real server, establish a tunnel between it and each virtual server address. For example, these commands establish two tunnels (tunl0 and # # tunl1) to two virtual server addresses... # To prevent real servers, rather than the active router, # from intercepting ARP broadcasts, you also need to hide # tunnels from ARP broadcasts. For example, these commands # hide tunnels tunl0: # Insert the ipip module, if not statically compiled into the kernel already insmod ipip # Make the tunl0 device up ifconfig tunl0 0.0.0.0 up # Start the hiding interface functionality echo 1 > /proc/sys/net/ipv4/conf/all/hidden # Hide all addresses for this tunnel device echo 1 > /proc/sys/net/ipv4/conf/tunl0/hidden # Configure a VIP on an alias of tunnel device ifconfig tunl0:0 1.2.3.4 up # Testing lynx --dump http://VIP/test ab -n 100 -c 10 http://VIP/index.html Environment: Red Hat 7.2, Piranha 0.6.0-15, RH stock kernel (2.4.7-10) ________ | | | client | |________| CIP=5.6.7.8 | | | __________ | | | Internet | |__________| | | | VIP=1.2.3.4 (eth0:1) __________ | | | director | |__________| DIP=1.2.3.5 (eth0) | | /---------------------------------\ | | | | | | RIP1=1.2.3.10 N/A (yet) N/A (yet) _____________ _____________ _____________ | | | | | | | realserver | | realserver | | realserver | |_____________| |_____________| |_____________| ############### ## DETAILS: ############### Setup the Director: Install Piranha, lvsadm Configure like so: serial_no = 38 primary = 1.2.3.4 service = lvs backup = 0.0.0.0 heartbeat = 1 heartbeat_port = 539 keepalive = 6 deadtime = 18 network = direct reservation_conflict_action = preempt debug_level = NONE virtual http { active = 1 address = 1.2.3.5 eth1 port = 80 send = "GET / HTTP/1.0\r\n\r\n" expect = "HTTP" load_monitor = none scheduler = wlc protocol = tcp timeout = 6 reentry = 15 quiesce_server = 0 server www4real { address = 1.2.3.10 active = 1 weight = 1 } } IP Virtual Server version 0.8.1 (size=65536) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 1.2.3.5:80 rr -> 1.2.3.10:80 Route 1 0 0 CURRENT LVS PROCESSES root 1992 0.0 0.0 1604 600 ? S 15:45 0:00 pulse root 2295 0.0 0.0 1604 600 ? S 15:45 0:00 /usr/sbin/lvs --nofork -c /etc/sysconfig/ha/lvs.cf root 2299 0.0 0.0 1640 648 ? S 15:45 0:00 /usr/sbin/nanny -c -h 1.2.3.10 -p 80 -s GET / HTTP/1.0\r\n\r\n - ## Notes for recompiling 2.4.17 with ipvs and hidden patches on Red Hat 7.2 ## ## (On both real server and the director) # Download directory export D=/tmp/download mkdir $D cd $D #kernel wget http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.17.tar.gz #hidden patch wget http://www.linux-vs.org/~julian/hidden-2.4.5-1.diff #IPVS patch wget http://www.linuxvirtualserver.org/software/kernel-2.4/linux-2.4.12-ipvs- 0.8.2.patch.gz #net filter module - if you want to do just the module instead of the big kernel patch above. wget http://www.linuxvirtualserver.org/software/kernel-2.4/ipvs-0.8.2.tar.gz #ipvs admin wget ftp://rpmfind.net/linux/redhatbeta/ha/i386/ipvsadm-1.17-2.i386.rpm # Unpack new kernel tar zxvf linux-2.4.17.tar.gz # Unpack ipvs patch gunzip linux-2.4.12-ipvs-0.8.2.patch.gz # Unpack kernel mv linux /usr/src/linux-2.4.17 cd /usr/src # Recreate symlink rm -f linux-2.4 ln -s linux-2.4.17 linux-2.4 ln -s linux-2.4.17 linux # Apply "hidden" patch cd linux-2.4.17 patch -p1 < $D/hidden-2.4.5-1.diff Should see: ############################### patching file include/linux/inetdevice.h patching file include/linux/sysctl.h Hunk #1 succeeded at 334 (offset 9 lines). patching file net/ipv4/arp.c Hunk #3 succeeded at 754 (offset -1 lines). patching file net/ipv4/devinet.c Hunk #1 succeeded at 756 (offset 20 lines). Hunk #2 succeeded at 1013 (offset -4 lines). Hunk #3 succeeded at 1079 (offset 20 lines). patching file Documentation/filesystems/proc.txt Hunk #1 succeeded at 1583 (offset 5 lines). patching file Documentation/networking/ip-sysctl.txt ############################### # Apply ipvs patch patch -p1 < $D/linux-2.4.12-ipvs-0.8.2.patch # ipvsadm 1.18-8, which is newer, is already installed (from piranha project) make clean make mrproper make menuconfig make bzImage make modules make modules_install make install #doesn't support GRUB yet. - or can copy the arch/i386/boot/bzImage file manually vi /boot/grub/grub.conf: title 2.4.17_ipvs root (hd0,0) kernel /boot/vmlinuz-2.4.17 ro root=/dev/sda1 #now copy the /usr/src/linux-2.4.17 to the next linux box: tar czf linux-2.4.17-dir.tgz /usr/src/linux-2.4.17/ scp linux-2.4.17-dir.tgz SERVER_TWO:/usr/src #now unpack in SERVER_TWO tar zxvf linux-2.4.17-dir.tgz cd linux-2.4.17 make modules_install make install # do grub config again. title 2.4.17_ipvs root (hd0,0) kernel /boot/vmlinuz-2.4.17 ro root=/dev/sda1 # reboot! ]]>
Jezz Palmer, setup d'un LVS squid Jezz Palmer J (dot) D (dot) F (dot) Palmer (at) swansea (dot) ac (dot) uk 29 May 2002, pour mettre en place un squid LVS. Les directeurs tournent avec des kernels 2.4.18 Les serveurs réels avec des 2.4.7 (standard RH 7.2 mais recompilé). Squid ne marche pas avec 2.4.18 ou 2.4.17 pour quelque raison. Premièrement, j'ai créé le directeur. J'ai utilisé les instructions écrites par Dan Browning (plus haut) pour configurer le kernel. Note, j'ai seulement utilisé le bit de configuration du kernel, je l'ai édité pour 2.4.18 et les versions suivantes de ipvsadm et le patch et quelques autres choses. Notes pour recompiler 2.4.18 avce ipvs et le patch "hidden" sur Red Hat 7.2 Laissez toutes les autres options de la même façon mais allez à ... IP: Virtual Server Configuration and build in [*] virtual server support [EXPERIMENTAL] ]]> et acceptez les defauts. Si le matériel est substanciellement différent alors refaites le processus en utilisant le bon fichier par défaut de /usr/src/linux-2.4.7-10/configs/ Serveurs Réels. Pour les serveurs réels j'ai juste répété le processus ci-dessus mais avec le kernel par défaut (2.4.7) fourni avec RH 7.2. Le patch ipvsadm n'est pas nécessaire mais bon c'est ce que j'ai fait. Cà marcherais sûrement quand même sans le patch ipvsadm mais juste le "hidden" patch. Le faire marcher. J'utilise LVS-DR. Au départ, j'ai décidé de mettre en place un LVS http en utilisant un directeur et trois serveurs réels http. Http simplement parce que c'est plus facile d'être certain s'il marche ou pas. Donc j'ai mis en place Apache sur les trois machine, et fait des pages d'accueil pour afficher le nom de la machine. Puis j'ai utilisé le script de configuration de Joe Mack avec ma config pour générer le script rc.lvs pour le lancer sur les machines LVS. J'ai téléchargé configure-lvs_0.9.2 de http://www.linuxvirtualserver.org/Joseph.Mack/configure-lvs_0.9.2.tar.gz Il nécessite Net-DNS-0.19, que j'ai téléchargé de http://www.perl.com/CPAN-local/authors/id/B/BB/BBB/Net-DNS-0.19.tar.gz Donc après avoir "détaré" et installé Net-DNS-0.19, j'ai "détaré" le fichier configure-lvs_0.9.2.tar.gz. J'ai ensuite choisie le réseau le plus proche de ma configuration parmi la douzaine d'exemples et je l'ai édité pour qu'il ressemble à çà. Celui que j'ai choisi est lvs_dr.conf.one_NIC_one_network. (Les IPs, etc supprimées). J'ai utilisé le script de configuration pour généré le script rc.lvs. ./configure lvs_dr.conf.one_NIC_one_network Le script rc.lvs a été lancé sur la machine local et a été copié sur tous les autres serveurs du LVS. Maintenant en tapant ipvsadm vous devriez voir quelque chose comme çà. RemoteAddress:Port Forward Weight ActiveConn InActConn TCP vip:80 rr -> rip1:80 Route 1 0 0 -> rip2:80 Route 1 0 0 -> rip3:80 Route 1 0 0 ]]> Puis pour le tester allez sur une autre machine et tappez http://vip (ou ce qu'est votre VIP), vous devriez avoir un écran montrant le nom du premier serveur dans la liste, continuez à cliquez sur rechargez et vous verrez le nom changer comme il parcours la liste des serveurs réels. Celà ne marche qu'avec le planning de rr mais c'est une preuve que çà marche. Prochaine étape, l'appliquer à squid. Eek! Premièrement j'ai changé le fichier de config pour les serveurs et les ports de squid. Puis relancez. Et lancez le script rc.lvs en résultant sur tout les serveurs dans le LVS, note je n'ai que 2 serveurs réels dans la configuration de squid. Cà donne une sortie de ipvsadm comme çà RemoteAddress:Port Forward Weight ActiveConn InActConn TCP vip:3128 rr -> rip1:3128 Route 1 0 0 -> rip2:3128 Route 1 0 0 ]]> (De la part de Joe - à ce moment les serveurs réels, mis en place par le script de configuration, sont empéché d'accéder à un serveur web sur Internet. Ce problème est expliqué dans la section 3-Tier du HOWTO et à amené la version suivante du script de configuration.) Dans le même temps, j'ai découvert que si je redémarrais le réseau sur les serveurs réels après que le script rc.lvs ait été exécuté alors les serveurs réels pouvaient accéder au monde extérieur. Aussi pendant ce temps Joe travaillait sur les altérations du script de configuration que j'ai posé à propos du test de squid et écrivait des scripts pour traiter les échecs des serveurs réels et l'introduction d'un directeur de backup. A ce moment, j'avais un suid LVS qui utilisait le planning rr, celà mes vite apparu que le planning rr n'allait pas fonctionner tout seul. Quelques site HTTPS (e.g. services banquaire) n'accepterons pas des requètes d'un client avec plusieurs adresses IP j'ai donc essayé des plannificateur différents et l'utilisation de persistance pour que le LVS distribue de façon satisfaisante pour tout les sites. (Joe - c'est décrit plus amplement dans le HOWTO la section des services sous squid.) J'ai trouvé que wlc avec une persistance de 360 secondes marche parfaitement. Celà assure que les requètes d'un client particulier sont envoyé au même serveur réel pour 6 mins. Le timeout peut être augmenté, mais la plupart des services banquaires couperont la connexion si l'inactivité dépasse quelques minutes. RemoteAddress:Port Forward Weight ActiveConn InActConn TCP vip:3128 wlc -p 360 -> rip1:3128 Route 1 0 0 -> rip2:3128 Route 1 0 0 ]]>
LVS à deux machines Il est possible de mettre en place deux machines pour avoir une tolérence de panne complètement fonctionnelle. Quand l'une des machines est le directeur, elle est aussi un serveur réel avec une noeud local et l'autre est un autre serveur réel. Les deux machines ont un code de tolérence de panne pour leur permettre d'échanger les rôles de directeur. C'est un peu trop compliqué pour l'une de vos premières mise en place et en pratique il y a des problèmes avec la gestion du failover. Ils sont étudiés dans la section noeud local du HOWTO http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.localnode.html#two_box_lvs
Et s'il y a des problèmes
Peut pas patcher le kernel, peut pas compiler le kernel patché, peut pas compiler ipvsadm Utilisez vous le kernel standard? Est ce que votre version de ip_vs correspond à celle du kernel Est ce que votre ipvsadm vient de l'archive de votre version de ip_vs.
Je ne peut pas compiler ipvsadm Vous avez (probablement) installé un binaire kernel et quand vous avez essayé de compiler ipvsadm, vous avez eux des messages d'erreur pour des fichiers header manquant. Problème: Vous n'avez pas les fichier header du kernel (dans/usr/src/linux/include/linux/) relié à /usr/include/linux/. Solution: Installez vos fichiers header du kernel et faites le lien.
ip_tables ne fonctionne pas Symptome: Vous avez un 2.4.x et vous récupérez des messages d'erreur pas clair et bizarre de la part de ip_tables (ip_tables n'a pas de message clair) tel que Problème: Votre ipchains est chargé Solution: supprimer ipchains (i.e. déchargez avec la commande rmmod ipchains.o). Vous devriez aussi enlever le support d'ipchains de votre kernel pour que personne ne retombe dans le même piège.
ipvsadm renvoie des informations erronées Symptome: Vous avez des nom de personne, numéro d'IP, ports, services incohérent dans la sortie de la commande ipvsadm Problème: votre ipvsadm ne correspond pas à votre version de ip_vs. (Vous avez peut être oublié de compiler la nouvelle version de ipvsadm après avoir redémarrer l'ordinateur après le chargement du kernel patché pour LVS et donc vous utilisez une ancienne version de ipvsadm). Solution: récupérez la version de ipvsadm qui correspond à votre ip_vs.
Aidez moi! Mon LVS ne fonctionne pas Mettre en place un LVS en partant de rien pour la première fois demande de la réflexion, c'est quelques fois fastidieux et pas évident et il y a beaucoup de façon de faire des erreurs. Repérer le problème, il y a beaucoup de cas où LVS semble fonctionner, mais où vous ètes en faite directement connecté au serveur réel au lieu de rediriger les paquets à travers le directeur. Comprendre comment un LVS fonctionne vous demandera d'investir du temps. Notre réponse jusqu'à maintenant a été de traduire vos postes dans notre langage puis d'essayer de deviner ce que vous avez fait de travers. Nous n'avons pas eu de problème pour la mise en place d'un LVS basique depuis les premier temps, mais répondre toujours aux mêmes requètes prend vraiment beaucoup de temps (Mais il y a toujours des postes sur le sujet de savoir si un LVS marche ou pas dont personne n'a encore pensé, ce qui nous interresse beaucoup). Et puis de temps en temps après une dizaine d'échange avec 3 personnes de la mailing list qui essaye de comprendre le problème, le posteur de départ se souvient soudainement qu'ils ont des règles de filtrage (qu'ils aivaient "entièrement vérifiées" et sont sûrs qu'elles marchent) dont ils avaient complètement oublié de nous parler. (ndt : Cà doit énerver) Depuis 1999, des efforts substantiels ont été mis en place dans le HOWTO, le mini-HOWTO et le script de configuration pour permettre à des personnes avec peu ou pas de connaissance de mettre en place un LVS qui fonctionne. Si vous ne voulez pas utilisez un script de configuration, il y a ici assez d'information pour que vous puissiez mettre en place un LVS qui fonctionne à partir des lignes de commande. Nous avons malgré tout aussi besoin de nous occuper de nos boulots aussi, donc j'aimerais essayer un truc nouveau: - Si vous n'arrivez pas à mettre en place un LVS, avec 1 ou 2 serveurs réels telnet (ou httpd), alors au lieu de nous demander de deviner ce que vous avez mal fait, et si vous utilisiez les outils que nous avons fournis pour mettre en place un LVS basique. Un fois que vous avez ce LVS basique qui fonctionne vous pouvez essayer de mettre en place un LVS à votre façon. Si vous n'arrivez pas à faire fonctionner les scripts, alors nous essaierons de les réparer. Si vous avez besoin de nous contacter, regardez avant les informations de rapport de problème (HOWTO) correspondant à votre problème.
Le client affiche "connection refused" La machine qui reçoit le paquet de requète répond que elle n'écoute pas pour ce service. Les raisons possible pour cela (avec l'aide de Ratz) ipvsadm (sur le directeur) n'a pas ajouté le service à la table de redirection (à voir dans la sortie de ipvsadm) si le service est dans la table de ipvsadm, alors le directeur renvoie les paquets à un serveur réel, dont le service n'est pas en marche sur la VIP (pour LVS-DR et LVS-Tun) ou la RIP (pour LVS-NAT). une règle de filtrage de paquets le service dest n'est pas disponible le service n'est pas en marche sur le serveur réel il y a une faute dans l'adresse IP le cable réseu est débranché (vous devriez avoir la réponse icmp "host down")
accrocchage de la connection, ipvsadm montre des connections InActConn, mais pas de ActiveConn L'erreur habituel est d'avoir la passerelle par défaut pour les serveurs réels mal configurée. LVS-NAT: la passerelle par défaut doit être le directeur. Il ne peut pas y avoir un autre chemin vers le client autre que part le directeur. LVS-DR, LVS-Tun: la passerelle par défaut ne peut pas être le directeur - utilisez un router local. Si vous utilisez LVS-NAT et un réseau, vous devez aussi traiter les redirections ICMP. Billy ntadmin (at) reachone (dot) com 18 Mar 2004 Si votre LVS fonctionne et que vos connexions se déconnecte (comme avec http), au moment où vous avez téléchargé la page, la connexion sera dans l'état InActConn. Voir httpd est sans état et ferme normallement les connexions (http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.services.single-port.html#http_stateless). Les connexions qui sont dans le mode InActConn est un diagnostic seulement si la connexion est accroché (i.e. le client ne reçoi pas les pages du LVS).
La connection initial est retardé, mais une fois connecté tout marche bien En général le problème vient de authd/identd. La chose la plus simple est d'arréter le service sur les serveurs réels et d'empécher d'appeler le serveur identd sur le client (i.e.déconnetez votre service de identd). Un autre problème qui cause des ralentissement dans toutes les situations, est le timeout du DNS sur un appel. Ideallement vous ne devriez pas avoir de DNS lancé sur les machines du LVS - vous aurez besoin d'éteindre le sendmail de etc /etc/hosts. Toutefois si vous avez DNS, veillez à ce qu'il y a les entrées pour toutes les IPs sur cette machine (si vous avez plusieurs interfaces) et de chaque machine que vous appelerez. Pour vérifier, lancez des commandes qui ont besoin de la résolution de nom e.g. netstat -a (les entrées dans /etc/services sont nécessaires aussi) ou route (les entrées dans /etc/networks sont nécessaires aussi ). Si l'une d'entre elle pause, relancez les dans une forme où elle n'ont pas besoin de la résolution de nom (netstat -an, route -n) pour localiser les entrées forçant la pause - celles la n'ont pas besoin de la résolution de nom.
La connexion prend plusieurs secondes à se faire J'ai eu des problèmes avec çà une fois quand mon routage était mauvais et que ICMP devait le devinez pour moi. Une autre possibilitée est un délai de la part d'un lookup DNS Essayez de vous connectez au nom du VIP et à l'IP.
Mon LVS ne fait pas de balancement de charge, le client va toujours sur le même serveur Ceci est pour LVS-DR ou LVS-Tun. L'explication la plus probable est que vous n'avez pas résolu le problème arp (http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.arp_problem.html). Pour vérifier que vous l'avez fait vous pouvez tester l'interface sur le serveur réel (http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.arp_problem.html#testing_for_arp).
Mon LVS ne fonctionne toujours pas: je fais quoi maintenant ? Si vous avez essayé le LVS telnet simple du mini-HOWTO LVS et que maintenant vous essayez votre propre LVS, et qu'il ne marche pas, vous devez debugger votre installation. Premièrement mettez votre serveur réel hors ligne (tirez le cable réseau) et démarrez le service écoutant sur le RIP:port (VS-NAT) ou le VIP:port (VS-DR, LVS-Tun). peut importe le service que vous utillisez en production, mais un test telnet est plus facile à débugger. Je sais bien que vous voulez essayer votre serveur web shockwave super cool avec applets java, mais vous aurez le temps plus tard. Essayez avec telnet d'abord, OK? Cà va vous(et nous) éviter une série de question sur la mailing list. Vérifiez que le service (telnet donc) fonctionne (netstat -an). Connectez vous au service depuis un client simple tournant sur un serveur réel (eg telnet VIP 80, lynx VIP). Puis utiliser votre client habituel (un navigateur Internet). Veillez à ce que votre service puisse faire toutes les choses que vous voulez que le client sur Internet puisse faire. Puis connectez le serveur réel au réseau LVS et mettez sa passerelle par défaut (vers le DIP pour LVS-NAT, vers le routeur pour LVS-DR, LVS-Tun), ajoutez les VIP:services au directeur avec ipvsadm (ou le script de configuration, voir le mini-HOWTO) en utilisant le planning rr. Vérifiez que ipvsadm montre vos realserver:service. Veillez à ce que vous n'ayez pas de pare-feu entre le client et le LVS, sinon tous les jeux sont finis. Puis connectez vous au VIP:service depuis un client simple (e.g. telnet VIP port), vérifiez que vous pouvez atteindre tous les serveurs réels un à un (regardez avec le directeur avec ipvsadm). Puis utilisez votre client habituel pour le service (eg un navigateur web). Si vos requètes de connexion ne vous connectent pas, alors vous avez besoin de voir où les paquets sont stoppés. Vous pouvez voir le paquets avec tcpdump ou netstat -an (pour voir si la requète a quitté un noeud où est arrivé à un autre et de voir si les réponses ont été faites).