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