Redondance de service

Transcription

1 BTS S.I.O. 2 nd Année Option SISR TP 15 Redondance de service 1 Objectifs Mettre en œuvre différentes techniques de haute disponibilité de services et de serveurs. 2 Présentation du déroulement Ce TP se déroule en trois étapes successives : 1. Mettre en place et tester un dispositif de haute disponibilité de type «Fail-Over», au niveau de votre serveur web, avec le logiciel heartbeat ; 2. Mettre en place et tester un dispositif de haute disponibilité de service de type «Répartition de charge» (load-balancing), au niveau de votre serveur web, avec le logiciel LVS ; 3. Mettre en place et tester un dispositif de haute disponibilité intégré dans un protocole tel que DNS sur votre serveur DNS. 1 Préparation de votre contexte pour la première partie Démarrer les machines «routeur-1» et «srv-dns» ; Cloner la machine «srv-web» sous le nom de «srv-web-bis» ; Assurer vous que votre machine physique est bien dans votre contexte et qu'elle a reçu une adresse en xxx. Note : : dans ce cas de figure, la machine physique joue le rôle d'un client du sous réseau Usagers. Dans le cas d'un contexte entièrement virtuel, on peut utiliser une machine cliente desktop debian virtuelle sur le réseau Usagers à la place de la machine physique. Donc utilisez la VM poste-de-ligue Configuration initiale des serveurs web Machine srv-web Nom : srv-web (Attention, pour la suite de ce TP le nom de la machine est très important) ; Une interfaces réseau : «eth0» liée à l'interface au réseau interne «sw-dmz-xx», configurée en «static» avec l'adresse /24, passerelle par défaut ; Nom de domaine DNS : mlif.local Serveur DNS : Modifier la page «/var/www/index.html» en ne mettant qu'une seule ligne : <h1>srv-web</h1> Pour faire apparaître le nom du serveur «srv-web» en gros caractères. Machine srv-web-bis Nom : srv-web-bis (Attention, pour la suite de ce TP le nom de la machine est très important) ; Une interfaces réseau : «eth0» liée à l'interface au réseau interne «sw-dmz-xx», configurée en «static» avec l'adresse /24, passerelle par défaut ; Nom de domaine DNS : mlif.local Serveur DNS : Modifier la page «/var/www/index.html»en ne mettant qu'une seule ligne : <h1>srv-web-bis</h1> Pour faire apparaître le nom du serveur «srv-web-bis» en gros caractères. Conception V.Perrin, révision V.Mauduit Document1 1/11

2 1.2 Vérifications Depuis votre machine Vérifiez que vous pouvez faire des ping sur les adresses IP de : serveur «srv-web» : ; serveur «srv-web-bis» : ; Lancer un navigateur et accéder successivement aux deux serveurs web. ( et ). Vérification depuis chacun des deux serveurs web Vérifiez que les deux serveurs communiquent entre eux ; Vérifiez qu'ils ont accès à internet ; Vérifiez qu'ils ont accès au serveur.sio.lms 1.3 Sauvegardes Comme ces deux serveurs web vont être utilisés plusieurs fois de façon différente dans ce Tp et le suivant, enregistrer un instantané de «srv-web» et «srv-web-bis» dans «virtualbox» nommés «apache-base». 1 - Appelez-moi pour que je vienne vérifier cette partie du TP. 1 Réalisation de haute disponibilité par fail-over (mode Actif/Passif) 1.1 Présentation et terminologie Heartbeat (battement de cœur) est un logiciel, installé sur le serveur maître et sur chaque serveur secondaire. L'ensemble des serveurs remplissant le même rôle de façon redondante se nomme un «Cluster» (une Grappe). Chaque serveur du «cluster» est un «node» (un nœud de la grappe). Le serveur secondaire (passif) va surveiller en permanence les battements de cœur du serveur principal (actif) et prendre le relais automatiquement en cas d'arrêt des battements. Il deviendra alors actif. Chaque serveur possède sa propre adresse IP, mais seul le nœud actif possède, en plus, une adresse virtuelle (dite adresse «flottante»). C'est par cette adresse flottante, et seulement par elle, que les clients accèdent au service. Lorsque le serveur secondaire prends la place du maître et devient actif, il prend cette adresse flottante. Comme les clients n'accèdent au service que par cette adresse flottante, ils accèdent donc au serveur secondaire sans s'en rendre compte. Le remplacement d'un nœud par l'autre s'est donc faite de façon transparente pour les clients. La configuration de «heartbeat» doit être identique sur tous les serveurs de la grappe. Elle repose sur trois fichiers : /etc/ha.d/ha.cf Configuration de heartbeat proprement dite ; /etc/ha.d/authkeys Clé partagée en les serveurs de la grappe ; /etc/ha.d/haresources Liste des ressources (adresses et/ou services) fournies par la grappe. Nota : le préfixe «ha» signifie «High Availability», (haute disponibilité). 1.2 Réalisation Sur le serveur maître «srv-web» Installer le paquet «heartbeat» ; Créer et éditer le fichier «/etc/ha.d/ha.cf» et remplissez-le de la façon suivante : #Configuration du cluster Conception V.Perrin, révision V.Mauduit Document1 2/11

3 #Interface émettant et recevant les battements de cœur bcast eth0 #Temps, en secondes, avant que le serveur soit déclaré mort deadtime 5 #Intervalle, en secondes, entre deux battement de cœur keepalive 1 #liste des nœud (serveurs) formant le cluster node srv-web srv-web-bis Enregistrer le fichier ; Créer et éditer le fichier «/etc/ha.d/haresources» et remplissez-le de la façon suivante : #Ressources fournies par le serveur actif srv-web IPaddr:: apache2 Signification des paramètres de ce fichier srv-web indique le serveur actif par défaut (le maître du cluster) ; IPaddr:: Adresse flottante attribuée au serveur actif ; apache2 Service à lancer sur le serveur lorsqu'il devient actif. Enregistrer le fichier ; Éditer le fichier «/etc/ha.d/authkeys» et remplissez-le de la façon suivante : #numéro de méthode d authentification (1 = 1ère méthode) auth 1 #type de hachage et mot de passe à utiliser pour la méthode 1 #Le mot de passe utilisé est libre. 1 md5 motdepasse Enregistrer le fichier ; Remarquer que dans ce fichier le mot de passe est indiqué en clair. Il faut donc restreindre les droits sur ce fichier au seul utilisateur «root». Il faut donc lancer la commande : chmod 600 /etc/ha.d/authkeys Conception V.Perrin, révision V.Mauduit Document1 3/11

4 Sur le serveur srv-web-bis Installer le paquet «heartbeat» ; Avec «scp», recopier les trois fichiers de configuration depuis le serveur «srv-web». Ainsi on est sûr qu'ils seront identiques. Sur chacun des deux serveurs (srv-web et srv-web-bis) relancer le démon heartbeat : /etc/init.d/heartbeat restart Vérifier qu'il n'y a pas d'erreurs dans /var/log/syslog sur les deux serveurs. 1.3 Vérification du fonctionnement Sur «srv-web» la commande ifconfig doit faire apparaître, en plus de «eth0», l'interface virtuelle «eth0:0» avec l'adresse flottante « ». Par contre «srv-web-bis» ne possède que son adresse normale. Avec le navigateur de votre machine, accéder à l'adresse flottante C'est le serveur «srv-web» qui vous répond ; Rafraîchissez plusieurs fois la page, c'est toujours «srv-web» qui assure le service http ; Éteignez, «à la barbare» (avec «poweroff») le serveur «srv-web» ; Rafraîchissez la page web dans votre navigateur. Après au plus cinq secondes pendant lesquelles le service est interrompu, c'est le serveur «srv-web-bis» qui assure le service http ; Une commande «ifconfig» sur «srv-web-bis» fait apparaître que c'est lui maintenant qui possède l'adresse flottante ; Redémarrer le serveur «srv-web» ; Rafraîchissez la page web dans votre navigateur. Après quelques secondes, c'est à nouveau le serveur «srv-web» qui assure le service http ; Une commande «ifconfig» sur «sv-web» fait apparaître que c'est lui maintenant qui possède l'adresse flottante ; Une commande «ifconfig» sur «srv-web-bis» montre qu'il ne possède plus l'adresse flottante. 1.4 Conclusion Vous venez de mettre en œuvre un système de haute disponibilité de type «fail-over», d'une manière extrêmement simple et rapide, avec deux serveurs. Cette technique présente toutefois plusieurs inconvénients inhérents au «fail-over» : Un serveur est monopolisé à ne rien faire (srv-web-bis) en attendant que le serveur maître tombe en panne ; C'est le serveur (srv-web) et non pas le service (apache) qui est sécurisé. Si on arrête le service «apache2» sur «srv-web», les battements de cœur vont continuer et donc le serveur «srv-web-bis» ne va prendre la relève. Une attaque par DoS (ou une surcharge réseau) risque d'empêcher la transmission des battements de cœur et déclencher le remplacement de «srv-web» par «srv-web-bis» alors que «srvweb» fonctionne encore. Les deux serveurs possédant alors la même adresse flottante! Lors de la panne de «srv-web», le service est indisponible pendant quelques secondes (5 dans notre exemple) ; Cela peut être gênant sur certains services ou dans certains usages. 1.5 Sauvegarde Sauvegarder l'état des deux serveurs web (srv-web et srv-web-bis) en réalisant un instantané dans «virtualbox» nommé «heartbeat». 2- Appelez-moi pour que je vienne vérifier cette partie du TP. 1 Réalisation de haute disponibilité par load-balancing (mode Actif/Actif) 1.1 Présentation et terminologie Conception V.Perrin, révision V.Mauduit Document1 4/11

5 Dans cette partie, la haute disponibilité sera obtenue grâce un «load-balancer» (répartiteur de charge) qui sera intercalé entre les clients et la grappe de serveurs. Les clients enverront leur requête au «load-balancer» qui se chargera de les transmettre à un des serveurs de la grappe. Le «load-balancer» se comporte donc, comme un «firewall» qui ferait du «DNAT/PAT» en redirigeant les requêtes reçues sur un port vers un des serveurs disponibles d'une DMZ. La charge de travail est donc répartie entre les différents serveurs car ils sont tous actifs simultanément. En cas de panne de l'un d'eux, le travail sera réparti entre les serveurs restants. De plus, le «load-balancer», en isolant les serveurs du reste du réseau, augmente la sécurité des serveurs en les cachant à la vue des clients qui ne connaissent que l'adresse du «loadbalancer», comme c'est cas dans les DMZ. La fonction de «load-balancing» est obtenue, dans ce TP, grâce au logiciel LVS (Linux Virtual Server). L'algorithme de répartition de charge utilisé dans l'exemple est le «Round- Robin» (tourniquet) qui attribue chaque nouvelle requête au serveur suivant de la grappe. Comme dans cet exemple il n'y a que deux serveurs, les requêtes seront donc attribuées alternativement à l'un et à l'autre serveur. Dans ce mode, les serveurs ignorent qu'ils sont en grappe, ils n'ont donc aucune configuration particulière, toute la configuration se fait sur le «load-balancer». La seule contrainte est que la passerelle par défaut des nœuds du cluster doit-être le «load-balancer». 1.2 Préparation Restaurer l'instantané «apache-base» des deux serveur web (srv-web et srv-web-bis) ; Modifier la connexion réseau de chacun d'eux : Une seule interface réseau «eth0» qui sera raccordée à un réseau interne nommé «cluster-xx» (où xx représente votre numéro d'étudiant), adresse statique /24 pour srv-web et /24 pour web2 ; La passerelle par défaut devra être Nom de domaine DNS : mlif.local Serveur DNS : Cloner une nouvelle machine virtuelle, à partir du «serveur modèle», avec les caractéristiques suivantes : Nom : load-balancer Mémoire 265 Mo Deux interfaces réseau : «eth0» liée à l'interface «sw-dmz-xx», configurée en «static» avec l'adresse /24. La passerelle par défaut devra être Nom de domaine DNS : mlif.local Serveur DNS : C'est l'interface par laquelle les clients accéderont au service ; «eth1» liée au réseau interne nommé «cluster-xx» avec l'adresse statique /24. c'est l'interface permettant l'accès à la grappe de serveurs ; Le routage doit être activé de façon permanente. Vérifier que votre machine physique peut accéder au «load-balancer» avec un «ping » ; Vérifier que le load-balancer accède bien aux deux serveurs web par un «ping » et un «ping » ; Vérifiez que les deux serveurs communiquent entre eux et avec le «load-balancer ( ) ; Vérifiez que les deux serveurs et le «load-balancer ont accès à internet ; Conception V.Perrin, révision V.Mauduit Document1 5/11

6 Vérifiez que les deux serveurs et le «load-balnacer» ont accès au serveur srv-debian.rdescartes.local. Vérifier, sur le load-balancer que le routage est bien activé avec la commande : cat /proc/sys/net/ipv4/ip_forward qui doit renvoyer la valeur «1». 3 - Appelez-moi pour que je vienne vérifier cette partie du TP. 1.3 Réalisation Sur le load-balancer Installer le paquet «ipvsadm» qui installera le répartiteur de charge «LVS» ; La configuration repose sur un seul fichier : /etc/ipvsadm.rules. Ce fichier ressemble, par sa structure aux fichiers de règles «iptables» ; Il est constitué par un ensemble de commandes «ipvsadm» qui vont configurer LVS, comme les commandes «iptables» configuraient le firewall.. Conception V.Perrin, révision V.Mauduit Document1 6/11

7 Éditer le fichier /etc/ipvsadm.rules et complétez-le avec : #Définition du service ipvsadm -A -t :80 -s rr #Définition des membres du cluster ipvsadm -a -t :80 -r :80 - m ipvsadm -a -t :80 -r :80 - m Signification 1ère ligne : -A ajouter un service. Un service est défini par : Son protocole de transport (tcp ou udp), L'adresse sur laquelle arrive les requêtes Le port. Le service ajouté est donc défini derrière -A et précise l'algorithme de répartition de charge : -t protocole tcp ; :80 adresse:port du service ; -s rr algorithme de répartition «Round Robin». Signification de la 2nd et de la 3ème ligne : -a ajouter un nœud à un service -t :80 Service concerné ; -r :80 Adresse et port du nœud participant au cluster ; -m -> «masquerade» des requêtes pour que le serveur renvoie la réponse au «load-balancer» et non directement au client. Cela est indispensable pour que les réponses, vues du client, semblent revenir du répartiteur c'est-à-dire de l'adresse à laquelle a été envoyée la requête, et non du serveur réel. Lancer la commande : dpkg-reconfigure ipvsadm Cette commande permet à la fois de prendre en compte les règles que vous venez de définir dans ipvsadm.rules et de configurer ipvsadm avec les réponses suivantes : Choisir de charger automatiquement les règles d'ipvs au démarrage ; Choisir «maître» puisqu'il est le seul «load-balancer» de la grappe ; Choisir l'écoute de l'interface «eth0» puisque c'est sur cette interface qu'arrivent les requêtes. Nota : Cette commande est à relancer à chaque modification du fichier ipvsadm.rules. Conception V.Perrin, révision V.Mauduit Document1 7/11

8 1.4 Tests Depuis le navigateur web de la machine physique accéder à l'adresse du «load-balancer» ( ) ; Rafraîchissez plusieurs fois la page, en attendant environ 6 à 10 secondes entre chaque, afin de générer une nouvelle requête (sinon c'est le cache du navigateur qui répond. A chaque nouvelle requête c'est un nœud différent du cluster qui répond (srv-web ou srv-web-bis). Arrêter «à la barbare» un des deux serveur web ; Rafraîchissez à nouveau plusieurs fois la page. Cette fois c'est toujours le même serveur qui répond vu qu'il est maintenant seul dans la grappe. Remarquez qu'il n'y a pas eu d'interruption de service suite à la panne d'un des nœuds de la grappe ; Redémarrer le serveur web arrêté ; Rafraîchissez à nouveau plusieurs fois la page. Le serveur à repris sa place dans la grappe et assure de nouveau une partie de la charge de travail. 1.5 Sauvegarde Sauvegarder l'état des deux serveurs web (srv-web et srv-web-bis) et du load-balancer en réalisant un instantané dans «virtualbox» nommé «Lvs». 1.6 Conclusion Les inconvénients vu dans le «fail-over» sont cette fois levés. Tous les serveurs sont exploités, il n'y a pas d'interruption de service lors de la panne d'un des nœuds du cluster. Le point délicat est cette fois-ci le «load-balancer» lui-même, puisque son attaque ou sa panne entraînerait l arrêt de l'accès au service. En production réelle, il sera donc indispensable de le doubler (ou plus). Ceci est bien sûr prévu dans LVS, comme vous avez pu le constater lors de la configuration. Dans ce cas, un des «load-balancer» est déclaré «maître», le ou les autres «load-balancer» sont en attente selon le mécanisme vu avec «heartbeat». 4 - Appelez-moi pour que je vienne vérifier cette partie du TP. 1 Haute disponibilité native au protocole 1.1 Principe Certains protocoles, tels que DNS, AD (Active Directory) incluent un processus de haute disponibilité plus ou moins performant, assurant : le fail-over, la répartition de charge et la réplication des données. Nous prendrons comme exemple dans cette partie du TP le protocole DNS. Dans ce protocole, coté serveur, on a la possibilité de déclarer un serveur DNS comme maître (master) ou esclave (slave). Pour un maître il peut y avoir zéro, un ou plusieurs esclaves. Les serveurs esclaves sont «actifs» comme le maître mais ne possèdent qu'une copie de la base de données. Ils se synchronisent régulièrement sur le maître pour tenir à jour leur base de données. Coté client, on a la possibilité de déclarer plusieurs serveurs DNS, sans tenir compte qu'ils soient maître ou esclaves. Si le premier de la liste ne répond pas, le client interrogera le second et ainsi de suite. Cela assure le fail-over. Si on prend soin de ne pas mettre sur tous les clients le même serveur en premier, cela assurera également une répartition de charge entre tous les serveurs. 1.2 Préparation Dans votre contexte, vous possédez un serveur DNS maître (srv-dns ). Vous allez créer une redondance avec un second serveur DNS, qui sera esclave de «srv-dns». Arrêtez proprement «srv-dns» et dupliquer-le sous le nom de srv-dns-2 puis configurez «srvdns-2» de la manière suivante : Nom : srv-dns-2 Une interface réseau «eth0» liée à «sw-srv-xx» du contexte configurée en dhcp ; Modifier le serveur dhcp du contexte : Pour qu'il fournisse l'adresse à srv-dns-2 ; Conception V.Perrin, révision V.Mauduit Document1 8/11

9 Pour qu'il fournisse aux clients dhcp les serveurs DNS et ; Lancer «srv-dns» et «srv-dns-2» et vérifier que «srv-dns-2» a bien obtenu l'adresse ; Vérifier que les deux serveurs DNS communiquent bien entre eux ; Renouveler l'adresse de votre machine physique et vérifiez que les DNS primaire et secondaire sont bien et ; A partir de votre machine physique, vérifier par des ping que le réseau fonctionne normalement vers : srv-dns.mlif.local Appelez-moi pour que je vienne vérifier cette partie du TP. Conception V.Perrin, révision V.Mauduit Document1 9/11

10 1.3 Réalisation Comme srv-dns-2 à été obtenu par clonage de srv-dns, il est déjà presque entièrement configuré. Pour l'instant les deux serveurs sont «maîtres» ce qui implique que toutes les modifications dans une des bases de données devraient être faites dans chacun des serveurs. Rendre «srv-dns-2» «esclave» de «srv-dns», va permettre de copier et de maintenir à jour la base de données de «srv-dns-2» à partir de celle de «srv-dns». Les modifications n'auront plus à être faites que sur «srv-dns». Elles seront ensuite automatiquement répliquées sur «srv-dns-2». Sur srv-dns Éditer le fichier «/etc/bind/named.conf.local» et ajouter dans la définition de chacune des zones (sauf ad.mlif.local qui n'est pas concernée) : also-notify { ;} ; afin que le maître prévienne (notify) l'esclave ( ) des changements dans chaque zone ; Redémarrer le démon bind9. Sur srv-dns2 Éditer le fichier /etc/bind/named.conf.local et modifier chaque zone (sauf ad.mlif.local qui n'est pas concernée) de la façon suivante : zone "mlif.local" { type slave; masters { ;}; file "/var/lib/bind/mlif.directe"; }; Signification : Chaque zone est déclarée de type «slave» ; Le serveur dns maître est ; Les fichiers de zone doivent être stockés dans «/var/lib/bind» car il est interdit au démon DNS d'écrire dans «/etc/bind» pour des raisons de sécurité (revoir DynDns) ; Enregistrer le fichier ; Supprimer les fichiers de zones directe et inverses de «/etc/bind/» ainsi que tous les fichiers de «/var/lib/bind/» puisqu ils ne sont plus utiles. Ces fichiers seront maintenant obtenus automatiquement par copie de ceux de «srv-dns» et placés dans «/var/lib/bind/». Relancer le démon DNS, la synchronisation doit se faire ; Vérifier qu'il n'y a pas d'erreurs dans «/var/log/syslog» et que la synchronisation a bien eu lieu sur les quatre zones ; Vérifier le contenu de «/var/lib/bind/» vous devriez y trouver les quatre fichiers de zone qui on été recopiés depuis «srv-dns». 1.4 Tests Depuis la machine physique Lancer la commande : nslookup srv-2k8.mlif.local Conception V.Perrin, révision V.Mauduit Document1 10/11

11 Puis la commande : nslookup srv-2k8.mlif.local Vous devez obtenir la même réponse dans les deux cas alors que vous avez interrogé «srvdns» la première fois et «srv-dns-2» la seconde fois. Lancer la commande : nslookup srv-2k8.mlif.local Regardez bien, la réponse est fournie par «srv-dns» ( ) puisque c'est le premier DNS de votre liste ; Arrêter, «à la barbare» srv-dns ; Lancer à nouveau la commande nslookup srv-2k8.mlif.local La réponse est cette fois plus longue à venir (au moins 10 secondes), mais vous l'obtenez quand même. Mais cette fois c'est «srv-dns2» ( ) qui a répondu. Le fail-over fonctionne donc correctement. Remettez en route «srv-dns». Depuis srv-dns Ajouter dans la zone directe le nouveau serveur «srv-dns-2» srv-dns-2 IN A Incrémenter le numéro de version. Ceci est indispensable car la synchronisation entre les serveurs a lieu en fonction de ce numéro de version ; Relancer le démon DNS. Depuis srv-dns2 Consulter le fichier de zone directe «/var/lib/bind/mlif.directe». L'enregistrement de «srv-dns-2» s'y trouve. La synchronisation des deux serveurs a donc fonctionné correctement. 1.5 Conclusion Vous avez mis en place le système de haute disponibilité inclus dans le protocole DNS. Celui-ci est très rudimentaire bien qu'efficace. On note cependant : Que la panne du DNS maître entraîne un temps de résolution des noms très sensiblement supérieur ; Que les modifications ne peuvent se faire que sur le maître ; Que la répartition de charge se fait artisanalement en inversant l'ordre des DNS sur les clients. Toutefois, ces inconvénients sont relativement acceptables pour le protocole DNS. La redondance DNS présente l'avantage d'être simple à mettre en place. On retiendra surtout l'efficacité de la réplication d'un serveur sur l'autre. Pour le fail-over et la répartition de charge, on préférera cependant des mécanismes comme LVS, bien plus performants. En définitive, on utilisera donc le plus souvent un serveur DNS maître et N serveurs DNS esclaves pour bénéficier de la réplication automatique des bases de données. Ces serveurs seront placés en cluster, derrière deux répartiteurs de charges gérés en fail-over avec heartbeat. 6 - Appelez-moi pour que je vienne vérifier cette partie du TP. Conception V.Perrin, révision V.Mauduit Document1 11/11