Haute Disponibilité, concepts et principes

Transcription

1 Haute Disponibilité, concepts et principes Article publié dans le hors série spécial Haute Disponibilité du GNU/Linux Magazine France, numéro 18 (Février/Mars 2004). Introduction Depuis l'avènement relativement récent du règne informatique, les systèmes matériels et logiciels ont gagné régulièrement en complexité et en puissance. Ils ont envahi tous les recoins de notre vie quotidienne et sont désormais incontournables dans la majorité des secteurs clefs de notre industrie. Peu de domaines ont échappé à cette révolution au point que la cohésion de nos sociétés fortement industrialisées reposent sur la disponibilité de systèmes complexes qui rythment notre activité de tous les jours : Les transactions bancaires, les télé-communications, l'audiovisuel, Internet, le transport de personnes ou de biens (avion, train ou voiture), les systèmes d'informations des entreprises, etc. Ils font à ce point partie de notre mode de vie que toute interruption inattendue de ces services tourne rapidement à la catastrophe. Car, comme notre dépendance à de tels systèmes augmente, il en va de même de la gravité des pannes matériels ou autres dysfonctionnements logiciels : Ceux ci peuvent se révéler simplement gênants ou amusants mais peuvent aussi résulter en une perte significative de profit ou mettre en danger l'intégrité de personnes, voire de populations. Produire des systèmes fiables demande de passer beaucoup de temps en étude et en analyse, sans garantie du résultat. Heureusement, il existe des techniques simples permettant de pallier à la faillibilité des systèmes complexes, qu'ils soient matériels ou logiciels (les deux étant désormais indissociables). Plutôt que de chercher à rendre ces systèmes fiables, on peut inverser la démarche et intégrer à la source la notion de panne dans l'étude de ces systèmes : Si l'on peut prévoir la panne d'un composant matériel ou logiciel, on peut alors l'anticiper et mettre en oeuvre une solution de substitution. On parle alors de disponibilité du service, voire de Haute Disponibilité selon la nature de l'architecture mise en place. Toutes les techniques permettant de traiter cette intéressante problématique sont regroupées sous différentes appellations suivant le degré de la réponse qu'elles apportent au problème posé : Disponibilité des données : Même si votre système n'est pas critique et peut supporter un arrêt de service à durée variable, il est généralement inhabituel de se satisfaire de la perte de données. Dans ce cas précis, toutes les techniques utilisées convergent pour garantir l'intégrité des données ; Disponibilité des services : Dans le contexte d'un service critique rendu dans le cadre d'une entreprise (serveur de fichiers ou mail) ou vis à vis d'une clientèle (site marchand), une panne occasionnant un arrêt du service peut causer un tort considérable entraînant une perte de productivité voire une perte de confiance du client. Dans tous les cas, cela peut coûter à cours ou moyen terme beaucoup d'argent. On base la démarche sur la disponibilité des données pour ensuite fiabiliser par différentes techniques la continuité du service ; Tolérance aux désastres : Tremblements de terre, attentats, incendies sont des évènements certes inattendus mais aussi terriblement dévastateurs à la fois pour les biens, les personnes et, pour ce qui nous intéresse, les données et les services. Si ces derniers ne sont pas géographiquement éloignés à bonne distance les uns des autres, ce risque est réel : Cela peut paraître alarmiste et ne vaut peut être pas pour la petite PME locale mais devient un vrai problème pour les sociétés de taille conséquente qui brassent d'énormes flux d'informations et se doivent de fournir un service continu à leur clientèle (comme un opérateur téléphonique).

2 Cet article va s'attacher à décrire les principes fondamentaux qui régissent l'étude et le développement de systèmes critiques Hautement Disponibles (résumé sous l'acronyme HA pour High Availability). Nous verrons d'abord de façon succincte comment nous pouvons aborder le problème d'un point de vue théorique pour ensuite élaborer une architecture hautement disponible à partir de différents composants logiciels ou matériels. Les briques logicielles que nous allons nous efforcer d'utiliser sont pour la plupart basées sur les logiciels libres : La tentation est donc forte de vouloir mettre en oeuvre vous même, et à peu de frais, des solutions de ce type au sein de votre entreprise. Un petit bémol amical cependant : Il ne faut pas avoir peur de faire appel à des entités commerciales ou des spécialistes indépendants qui pourront les utiliser pour vous proposer des solutions éprouvées et déjà largement déployées (ce qui prouve, si besoin est, que la notion de libre et de commerciale n'est pas antinomique) : Mettre en place ce type de solution demande une compétence particulière que vous ne possédez peut être pas au sein de votre société. C'est exactement par ce type de services que le logiciel libre trouve sa cohérence et sa pertinence en offrant à disposition de tous de multiples briques pour concevoir vos architectures logicielles : N'hésitez pas à externaliser ce type d'étude car le temps passé en interne à élaborer une solution de Haute Disponibilité peut rapidement excéder le coût prévu initialement. Fiabilité versus disponibilité Pour appréhender la notion même de Haute Disponibilité, il nous faut d'abord aborder les différences qui existent entre la fiabilité d'un système et sa disponibilité. La fiabilité est un attribut permettant de mesurer la continuité d'un service en l'absence de panne. Les constructeurs fournissent généralement une estimation statistique de cette valeur pour leurs équipements : On parle alors de MTBF (pour Mean Time Between Failure). Un MTBF fort donne une indication précieuse sur la capacité d'un composant à ne pas tomber en panne trop souvent. Dans le cas d'un système complexe (que l'on peut décomposer en un certain nombre de composants matériels ou logiciels), on va alors parler de MTTF pour Mean Time To Failure, soit le temps moyen passé jusqu'à l'arrêt de service consécutif à la panne d'un composant ou d'un logiciel. L'attribut de disponibilité est plus difficile à calculer car il englobe la capacité du système complexe à réagir correctement en cas de panne pour redémarrer le service le plus rapidement possible. Il est alors nécessaire de quantifier l'intervalle moyen de temps ou le service est indisponible avant son rétablissement : On utilise l'acronyme MTTR (Mean Time To Repair) pour représenter cette valeur. La formule qui permet de calculer le taux de disponibilité relative à un système est la suivante : Un système qui aspire à une forte disponibilité se doit d'avoir soit un MTTF fort, soit un MTTR faible. Une autre approche, plus pratique, consiste à mesurer la période de temps ou le service n'est plus rendu pour évaluer le niveau de disponibilité. C'est la méthode la plus souvent utilisée même si elle ne tient pas compte de la fréquence des pannes mais plutôt de leur durée.

3 Le calcul se fait le plus souvent sur une année calendaire. Plus le pourcentage de disponibilité du service est fort, plus nous pouvons parler de Haute Disponibilité. Il est assez facile de qualifier le niveau de Haute Disponibilité d'un service à partir de la durée d'arrêt cumulée en utilisant le principe normalisé des "9" (en dessous de 3 neuf, il n'est plus possible de parle de Haute Disponibilité mais simplement de disponibilité) : Nombre de 9 Arrêt du service sur 1 an 3 neuf (99,9%) environ 9 heures 4 neuf (99,99%) environ 1 heure 5 neuf (99,999%) environ 5 minutes 6 neuf (99,9999%) environ 30 secondes A vous d'évaluer le niveau de disponibilité que vous ambitionnez d'atteindre. Définition des objectifs Une bonne démarche, permettant de mettre une oeuvre assez rapidement une infrastructure solide capable de garantir la Haute Disponibilité d'un service critique, consiste à évaluer les différents objectifs suivants : Définition des critères d'indisponibilité du service : Niveau de disponibilité, temps de rétablissement ou encore temps d'engagement du service ; Analyse de la volumétrie des données et des performances nécessaires au bon fonctionnement du service ; Prise en compte des différents critères de coûts ; Évolution des configurations matérielles et logicielles (si applicable) ; Transfert des compétences aux équipes d'exploitation sur les problématiques liées à la haute disponibilité ; Surveillance du service et planification de la maintenance corrective et préventive (qui, quand, comment). A ce stade de l'étude, vous devriez commencer à avoir une idée assez précise du type d'architecture qu'il vous sera nécessaire de mettre en oeuvre pour répondre au besoin posé. Vous devrez évaluer ensuite les différentes architectures possibles et sélectionnez celle qui vous semblera répondre le mieux aux différentes contraintes. Cette phase terminée, vous allez devoir imaginer quel type de panne n'a pas encore été prise en compte dans votre architecture : Cela peut être la panne du disque dur, de l'alimentation, du réseau ou encore un crash du système d'exploitation ou de l'applicatif. Il vous faudra pour cela décomposer consciencieusement la totalité du système pour localiser chaque élément susceptible de tomber en panne. On utilise le terme anglais SPOF (Single Point Of Failure) pour désigner une ressource critique (un composant matériel ou un logiciel) dont la panne peut être à l'origine d'un arrêt de service. Tous les SPOF de votre architecture devront donc disposer d'un palliatif efficace ou être correctement pris en compte par votre applicatif. Identifier les faiblesses d'un système informatique est la première étape permettant de fiabiliser son fonctionnement et d'initier une réflexion sur les moyens qu'il sera possible de mettre en oeuvre

4 pour garantir la continuité du service, et donc la Haute Disponibilité. Linux et la Haute Disponibilité Le support de la Haute Disponibilité existe depuis déjà quelques années sous Linux et même si le niveau de maturité n'est pas encore celui d'autres environnements propriétaires de type Unix, il est déjà largement suffisant dans la plupart des cas. Un site [1] centralise toutes les informations liées à la haute disponibilité sous Linux. N'hésitez pas à aller y faire un tour. Une bonne part des techniques disponibles reposent sur la multiplication des ressources critiques (physiques ou logicielles) constituant un serveur. En multipliant les ressources, on supprime du même coup leurs caractères critiques. Le service pourra donc être assuré même en cas de panne d'un composant. Cela permet notamment d'utiliser des composants moins cher puisque la fiabilité du composant ne devient plus le critère principal. Une seconde approche considère que l'on peut assez facilement mettre en place une solution où ce n'est plus la ressource que l'on va chercher à dupliquer, mais directement le serveur. L'utilisation de grappes de machines (cluster en anglais) est un bon moyen de répondre à cette problématique. Si l'on parvient à disposer d'au moins deux machines sur lesquelles le service est exécuté de façon unique (sur l'un ou l'autre des noeuds), la continuité du service sera garantie moyennant le temps de basculement d'une machine à l'autre (On parle en anglais de Failover Services, FOS). La principale difficulté consiste à maintenir une copie des données entre les noeuds (dans ce type de cluster dit de Haute Disponibilité, une machine s'appelle un noeud) pour que le service puisse être indifféremment lancé sur l'un ou l'autre des serveurs. Pour accomplir cela, il existe différentes techniques basées soit sur la réplication plus ou moins temps-réel des données entre les noeuds, soit sur le partage d'une ressource unique en utilisant notamment un système de fichiers distribués ou partagés. Dans ce type de configuration, il est important de faire en sorte que le temps de rétablissement du service soit le plus faible possible pour réduire la gène occasionnée aux utilisateurs. Le basculement du service dans le cluster ne doit pas être (trop) perceptible et ne doit surtout pas occasionner une modification du paramétrage coté client : Afin de rendre transparent cette étape, on utilise la notion d'alias IP pour associer une adresse IP dite flottante sur le noeud hébergeant le service. La continuité apparente du service coté client est donc assurée. Une dernière technique moins connue permet de répartir la charge sur un ensemble de noeuds physiques sur lesquels un service de type réseau est exécuté en parallèle et en concurrence. Un noeud maître se charge de répartir les requêtes sur le noeud le moins chargé du cluster. Si un noeud tombe en panne, il sera détecté par le maître qui pourra facilement le retirer de sa liste des noeuds actifs. La plus grande partie des architectures misent en oeuvre pour garantir la disponibilité d'un service dérivent plus ou moins directement de ces trois approches. Les composants de la haute disponibilité En premier point, à quoi bon élaborer une architecture complexe et Hautement Disponible si une simple panne de courant ou la perte d'une alimentation anéantie la continuité de votre service. Vous devez donc prévenir (faire en sorte qu'une panne de courant n'affecte pas la viabilité de votre système) mais aussi savoir soigner (en cas de perte d'une alimentation, une seconde doit pouvoir

5 prendre la relève). Comme nous l'avons déjà vu, anticiper les pannes fait partie du travail préliminaire dans la constitution d'une architecture HA. En ce sens, il est important de pouvoir suivre fidèlement les modifications de l'environnement dans lequel évolue vos machines : Une augmentation anormale de la température (par exemple) pouvant notamment provoquer des pannes qui ne se seraient pas produites en temps normal. Deux axes de réflexion peuvent être évalués pour réduire ce type de risques : Climatisation et hydrométrie Onduleurs La salle dans laquelle dans laquelle vous prévoyez de déployer vos machines doit garantir une température stable et une hydrométrie raisonnable. Il faut éviter les accumulations de poussière sur vos machines et nettoyer de façon préventive les accès d'air et autres ventilateurs. N'hésitez pas à rajouter justement un ventilateur : Certains modèles peuvent par exemple facilement s'insérer dans un slot PCI vide En cas de panne de courant, il faut garantir au moins pendant un certain lapse de temps la bonne alimentation électrique de votre serveur : Si les batteries de votre onduleur devaient ne pas suffire, il pourra envoyer un signal à votre système pour lui intimer l'ordre de s'arrêter proprement. Le mot onduleur est traduit de l'anglais sous l'acronyme UPS pour Uninterruptible Power Supplies Ce périphérique est particulièrement bien géré sous Linux par l'intermédiaire du projet NUT [2] (Network UPS Tools) qui supporte un grand nombre d'onduleurs USB ou séries La multiplication des différents composants critiques présents dans votre système peut vous permettre de survivre à une panne en considérant que les solutions matérielles de Haute Disponibilité disponibles sous Linux se rapprochent de plus en plus de celles proposées sur les serveurs Unix haut de gamme. Il est assez simple de redonder les alimentations électriques (transparent pour le système d'exploitation) mais aussi les disques durs, les contrôleurs disques et les interfaces réseaux : Alimentation redondée Utilisation de grappes de disques durs Certains constructeurs proposent de fournir deux ou trois alimentations pour prévenir la perte de ce composant. Les alimentations sont des composants critiques et il n'est pas rare de voir celles-ci faillir bien avant les autres composants du système. Les alimentations ATX par exemple ne sont pas réputées pour être des plus fiables (elles sont notamment très sensibles aux variations de tension) L'utilisation des technologies RAID [3] est un bon moyen de sécuriser vos données et prendre en compte notamment la perte d'un disque. On peut disposer de cette technologie de façon logicielle sous Linux même si il est tout à fait envisageable de l'utiliser par l'intermédiaire de cartes d'interface IDE ou SCSI à enficher dans votre système (Linux en supporte un grand nombre)

6 Multiplication des cartes réseaux Sécuriser l'accès aux unités de stockage externes Un câble réseau peut être accidentellement débranché ; Une carte réseau peut subir les aléas d'une panne et ne plus pouvoir être utilisable. Le service réseau que vous proposez est donc fortement tributaire de la disponibilité de ce type de composants. Heureusement pour nous, il existe une couche logicielle sous Linux permettant de créer une interface réseau virtuelle regroupant plusieurs cartes : On appelle cela, le Channel Bonding [4]. Ce procédé est normalisé, vous pourrez donc l'utiliser en point à point mais aussi en interface avec des switchs et mêmes des hubs selon le type d'algorithme sélectionné. En considérant le prix modeste de certaines cartes réseaux, il parait incontournable d'utiliser massivement cet artifice Le RAID logiciel sous Linux (driver MD) supporte depuis peu un nouveau mode dit Multipath [3] qui s'utilise dans le cas ou vous disposez de deux liens physiques qui pointent vers une seule et même ressource. Un seul des deux liens sera effectivement utilisé et, en cas de panne, c'est le second qui prendra la relève. Cela peut être très utile si vous disposez d'une baie de stockage externe en SCSI ou en Fibre Channel disposant de deux interface d'entrées/sorties. Il vous faudra prévoir deux contrôleurs dans votre serveur mais cela reste la solution idéale pour sécuriser vos écritures disque si votre baie de disque supporte cette fonctionnalité Multipliez les serveurs peut être, au même titre que la multiplication des composants, un bon moyen de garantir la disponibilité d'un service : Si le service est rendu par l'intermédiaire d'un cluster de machines, on pourra alors survivre à la perte de N-1 noeuds.

7 Heartbeat FailSafe Fake Heartbeat [5] est un maillon essentiel dans la construction d'un cluster avec basculement de services (de type Failover Services). Les services sont démarrés généralement sur un seul noeud du cluster, appelé communément le noeud principal : En cas de détection d'une panne, les services sont alors basculés sur le noeud de secours. Pour garantir la continuité apparente du service coté utilisateur, on utilise le principe des alias IP pour associer une adresse IP virtuelle à la machine qui héberge le service (Heartbeat utilise le programme Fake qui s'occupe de plus de mettre à jour les tables ARP). Les deux machines du cluster communiquent entre elles par l'intermédiaire de liaisons Ethernet et de liaisons séries dédiées pour obtenir toutes les informations utiles sur l'état du cluster et décider éventuellement de déplacer un service d'un noeud vers un autre On peut choisir d'équilibrer la charge en démarrant une partie des services sur le noeud principal et une seconde partie sur le noeud secondaire : Heartbeat sait parfaitement gérer ce type de configuration. La principale difficulté consiste à disposer des données utilisées par les services indifféremment sur l'un ou l'autre des noeuds du cluster : Pour cela, il est possible de répliquer les données entre les noeuds ou partager ces dernières à partir d'une source commune partagée. La mécanique de surveillance de Heartbeat ne détecte que les pannes matérielles ou résultant d'un blocage du système d'exploitation. Il est alors nécessaire d'utiliser un logiciel dédié (Mon) pour réaliser la surveillance applicative des services. FailSafe [7] est une contribution de SGI qui nous permet de disposer d'un outil similaire à Heartbeat pour basculer des services entre plusieurs noeuds d'un cluster. L'approche est un petit peu différente avec une notion de plugins plus construite que sous Heartbeat et avec le support d'un plus grand nombre de noeuds (jusqu'à 16). L'application est architecturée pour fonctionner avec des données partagées mais rien ne vous empêche de l'utiliser sur de la réplication de données (un plugin pour DRBD est disponible). Moins connu que Heartbeat mais nettement plus puissant, ce programme mérite clairement qu'on lui donne sa chance Fake [6] permet de prendre l'identité d'un service présent dans un cluster en démarrant une adresse IP virtuelle (alias IP) et en s'occupant de mettre à jour les caches ARP des machines connectées pour qu'ils tiennent compte du basculement. Heartbeat intègre ce logiciel en standard

8 STONITH Derrière cet acronyme barbare se cache une fonctionnalité indispensable lorsque l'on souhaite mettre un oeuvre un cluster basé sur le basculement de services : Dans cette configuration, si un noeud est considéré comme indisponible, on est toujours confronté au risque de lancer le même service en concurrence sur plusieurs noeuds si la communication (lien Ethernet et lien série) à l'intérieur du cluster est rompue (il donc possible que les noeuds se posent la même question au même moment). Pour garantir l'intégrité des données, une solution toute simple a été trouvée qui permet de définitivement clarifier la situation : Tuer le noeud voisin. Cette approche donne finalement de très bon résultats si l'on considère que l'on coupe l'alimentation électrique de ce dernier en utilisant un équipement appelé Power Switches (intraduisible en Français). Ce sera donc au noeud le plus rapide de gagner (à moins que le noeud voisin ne soit réellement indisponible). La communication avec ce dernier se fait généralement par une connexion série et de nombreux modèles sont supportés par les solutions clusters disponibles sous Linux (par exemple Heartbeat pour ne citer que celui là). Que signifie STONITH en fait? Tout simplement, «Shoot The Other Node In The Head»! LVS Keepalived A la différence des solutions basées sur Heartbeat ou FailSafe, toutes les machines présentes dans un cluster LVS [8] (Linux Virtuel Server) sont capables de fournir le même service et accèdent donc toutes aux mêmes données partagées. Un noeud chef d'orchestre (dispatcher) s'occupe de répartir de façon transparente les requêtes réseau en équilibrant la charge sur l'ensemble du cluster. Coté client, ce mécanisme est transparent car seule l'adresse IP du chef d'orchestre est visible. Plusieurs avantages découlent de cette architecture : En cas de panne d'un des noeuds du cluster, on retire ce dernier de la liste des noeuds actifs ; Augmenter la puissance de traitement consiste simplement à ajouter à chaud un nouveau noeud dans le cluster. Il est habituel de placer le noeud chef d'orchestre au sein d'un cluster basé sur du basculement de services (Heartbeat ou FailSafe) pour éliminer son caractère critique. Le routage se fait par l'intermédiaire d'un module noyau, la performance est donc au rendez-vous Si vous utilisez LVS, vous avez sans doute besoin d'une solution efficace et robuste pour surveiller la santé de votre cluster et supprimer automatiquement les noeuds en panne ou déconnectés du réseau : Keepalived [9] est donc fait pour vous! La disponibilité d'un service est indissociable de la disponibilité des données. Dans la constitution de votre architecture HA, parvenir à garantir l'intégrité de vos données est l'un des paliers parmi les plus importants à franchir.

9 Les données sont sécurisées en multipliant les disques durs (RAID) ou par réplication sur un second serveur. De même, la notion de réplication est soit transparente pour l'application (on réplique une partition ou un répertoire), soit intégrée dans une application comme c'est le cas de certaines bases de données. Des systèmes de fichiers spécifiques offrent aussi des fonctionnalités de tolérance aux pannes intéressantes : On parle alors de systèmes de fichiers distribués ou partagés. Reste la solution ultime du clustering HA : L'utilisation d'une baie de disques partagée qui va permettre de centraliser les données sur un support unique accessible en concurrence ou non (selon le type de la solution) par l'un ou l'autre des noeuds. Utilisation du RAID Utilisation d'un gestionnaire de volume DRBD ENBD Le RAID est un mécanisme permettant d'agréger virtuellement plusieurs ressources de types blocs (dans notre cas, des disques durs) pour offrir à l'utilisateur une vision unifiée du stockage de ses données. De nombreux algorithmes sont disponibles pour sécuriser les données et améliorer les performances : Dans ce cas, la perte d'un disque sera transparente pour l'utilisateur et n'affectera pas l'intégrité des données. Il est classique d'utiliser un RAID de niveau 1 (miroir) pour sécuriser le système d'exploitation et un RAID de niveau 5 pour les données Lorsque vous installez votre système d'exploitation, il est possible que vous n'ayez pas encore d'idée précise de la volumétrie dont auront besoin vos partitions systèmes et vos données. Une mauvaise estimation sur la taille d'une partition pourra avoir des conséquences importantes. Il est pour cela fortement conseillé d'utiliser un gestionnaire de volume comme LVM [10] (Logical Volume Manager) ou EVMS [11] (Enterprise Volume Management System) pour manipuler vos données : Il sera par exemple possible d'augmenter la taille de certaines partitions à chaud (sans arrêt de votre applicatif) ou encore de rajouter un nouveau disque pour étendre le volume de données disponibles. En conjonction avec le RAID, cela permet d'obtenir une solution de gestion de données performante et évolutive DRBD est un outil de réplication réseau de données localisées sur deux serveurs distincts. La synchronisation peut se faire de façon partielle (après une déconnexion réseau par exemple) ou complète (dans le cadre d'un changement de média ou d'une première utilisation). DRBD ne gère pas directement les mécanismes de détection des pannes et de basculement des services pour une utilisation dans un cluster : Il fournit toutefois des scripts qui lui permettent d'être intégré assez facilement à Heartbeat. L'utilisation d'une telle couche de réplication (livré sous la forme d'un driver) est absolument transparente pour les applications ENBD [12] est une version améliorée du driver NBD (Network Block Device) que l'on trouve habituellement sous Linux. Ce driver nous permet de disposer en local d'une ressource présente sur un serveur distant ; Les échanges de données se faisant par l'intermédiaire du réseau. L'accès aux données est ensuite absolument transparente pour le système et les applications. Cela a donné l'idée à certains d'utiliser cette technique conjointement avec celle du RAID 1 (miroir) pour la réplication de données entre deux serveurs comme c'est le cas avec le driver DRBD

10 SafeKit NFS Baie de stockage partagée OpenGFS Ce produit de la société Evidian (Groupe BULL) offre un large panel de solutions clefs en main pour répliquer des données, équilibrer la charge et basculer des services dans des clusters Linux. SafeKit [13] fonctionne, au moins sur la partie réplication, sur un principe équivalent à DRBD. L'ensemble est cohérent et semble plutôt prometteur (non testé) ; C'est pour cette raison qu'il apparaît dans cette liste (pour ne rien gâcher, le produit est multi-plateformes) NFS est un système de fichiers distribués, bâtit sur un modèle client/serveur, permettant de partager des données entre plusieurs machines. Dans le cadre d'un cluster, on peut envisager une configuration où chaque noeud récupère ses données sur un serveur NFS ce qui simplifie les problématiques de réplication de données entre les noeuds. Par contre, le problème est déporté sur le serveur NFS qui doit être lui même sécurisé... Plutôt que de chercher à répliquer les données entre tous les noeuds d'un cluster, une solution idéale consiste à utiliser une baie de disques partagée pour stocker les données. Afin d'éviter les accès concurrents, seul un noeud du cluster à la possibilité de monter les données présentes sur la baie. En cas de panne, le noeud de secours réagit en récupérant la ressource et en redémarrant les services (adresse IP inclus). Le matériel nécessaire pour monter une architecture de ce type est assez spécifique : La baie de disques (de type Fibre Channel ou SCSI), les contrôleurs d'entrée/sortie et les câbles devront supporter cette fonctionnalité Le Global File System (GFS) [14] réalisé par la société SISTINA (auteurs de LVM) est un système de fichiers journalisé qui permet de manipuler sans risque des données présentes sur un support de stockage partagé par plusieurs machines. Sa caractéristique principale est de laisser les systèmes lire et écrire directement les données : Celles-ci ne passent pas par le réseau (ce qui permet un gain important au niveau des performances par rapport à un protocole comme NFS), seul transite un flux protocolaire permettant de verrouiller les accès et d'éviter les conflits. GFS coordonne en effet les accès en écriture à travers un gestionnaire de verrous distribués (DLM pour Distributed Lock Manager) qui permet de garantir l'intégrité des données. GFS supporte les baies de disques SCSI ou Fibre Channel ainsi que les protocoles iscsi et Firewire. On peut aussi l'utiliser au dessus du gestionnaire de volume EVMS. OpenGFS [15] est une implémentation libre en constante évolution de ce système de fichiers (les deux proviennent de la même souche)

11 InterMezzo CodaFS RSYNC Réplication de base de données InterMezzo [16] est un système de fichiers distribué permettant de propager des modifications apportées à des données entre plusieurs machines. Sa principale caractéristique, par rapport à ses confrères, est de supporter parfaitement la phase de déconnexion : Vous pouvez continuer, dans ce cas, à travailler sur une copie locale des fichiers. Lors de la re-connexion, vos données seront mises à jour automatiquement (phase de synchronisation). Initialement, on l'utilise plutôt sur de l'informatique mobile comme un parc de portable ; On peut alors éviter de fastidieuses mises à jour de données avec un serveur de fichiers. Même si le logiciel est jeune et reste assez rugueux à mettre en oeuvre, il devient possible d'envisager son utilisation au sein d'un cluster HA pour répliquer des données entre deux ou plusieurs noeuds On pourrait dire que CodaFS [17] est l'ancêtre de InterMezzo car ce dernier est fait par quasiment la même équipe. Il offre donc les mêmes fonctionnalités tout est étant plus stable et plus aboutit au niveau technique RSYNC est un petit programme assez sympathique qui peut nous permettre de synchroniser à la demande deux répertoires localisés sur deux machines distantes. Le protocole utilise soit la couche RPC, soit la couche SSH pour transporter les données. Ces dernières peuvent être compressées et seules les données réellement modifiées sont échangées. C'est une brique élémentaire indispensable lorsque l'on souhaite répliquer des données qui évoluent peu, ce qui est le cas d'un serveur web statique Les bases de données relationnelles fonctionnent sur un modèle transactionnel : La tentation est donc forte de vouloir placer au niveau de la base de données la notion même de réplication en considérant très justement qu'un tel mécanisme sera forcément plus efficace qu'une réplication de type DRBD. C'est le moyen idéal pour répliquer des données entre deux serveurs dans le cadre d'un cluster avec basculement de services (Heartbeat) lorsque ce dernier est constitué d'un service rendu par l'intermédiaire d'une base de données Il ne faut pas hésiter à l'utiliser si cela est supporté par votre base de données : MySQL [18] et PostgreSQL [19], en particulier, supportent parfaitement cette fonctionnalité Redonder les composants matériels de votre architecture permettra certainement au système d'exploitation de réagir correctement en cas de panne mais nécessitera à terme une intervention manuelle corrective : Plus vous attendez avant de remplacer un composant en panne, plus le risque est important d'en voir un second suivre le même chemin. L'arrêt de service doit être évité au maximum : Une architecture cluster vous permet d'arrêter uniquement le noeud hébergeant un élément défectueux ; Une approche moins brutale consiste à changer à chaud le composant en panne (aucun arrêt de la machine) si ce dernier supporte la fonctionnalité sous Linux.

12 Une panne peut aussi affecter l'ensemble de votre architecture imposant un arrêt brutal qui peut laisser votre système de fichier dans un état instable. Ce dernier doit donc pouvoir être vérifié au redémarrage de la machine en un temps raisonnable. Toutes ces techniques sont regroupées dans la notion de reprise sur panne : Système de fichiers journalisé Chargement à chaud des périphériques Changement à chaud des composants matériels En cas d'arrêt violent d'un serveur, rien ne peut garantir l'intégrité des systèmes de fichiers si l'on considère les mécanismes de cache mémoire mis en place pour accélérer les entrées/sorties. Linux a été longtemps pénalisé par l'absence de solutions adaptées : Tout arrêt anormal résultait en une vérification minutieuse de la surface du disque pour localiser et réparer les erreurs de cohérence dans les systèmes de fichiers (le fameux fsck). Depuis environ 2 ans, des systèmes de fichiers dit journalisés se sont mis à fleurir sous Linux : Ext3, Reiserfs, Xfs ou encore JFS. Ces systèmes de fichiers mémorisent dans un journal de bord tous les évènements et sont donc capables, en cas de problèmes, de ne vérifier que les derniers échanges en cours sur le disque. Le redémarrage d'un serveur qui utilise un système de fichiers journalisé est donc quasiment immédiat : Cette brique élémentaire est donc indispensable Si vous utilisez une solution RAID, il est dommage de devoir arrêter votre système juste pour changer un disque dur en panne (changement à froid). Pour vous éviter cette étape inutile, certains constructeurs de cartes RAID vous permettent de changer vos disques durs à chaud (indispensable dans la pratique). Dans le cas du RAID logiciel, la situation est plus compliquée car vous devez d'abord enlever le périphérique du système d'exploitation avant de pouvoir le remplacer physiquement par un nouveau disque. La situation est différente suivant le type du contrôleur : Le SCSI permet assez facilement ce type de manipulation en jouant sur un fichier virtuel présent sous /proc ; Le cas de l'ide est plus complexe mais peut en certaines circonstances être envisagé. Attention, cela doit être supporté par votre matériel! Ne jouez donc pas aux apprentis sorciers avec vos périphériques (les manipulations sont décrites dans l'article sur le RAID logiciel) Le regroupement PCIMG (PCI Industrial Manufacturers Group) a élaboré tout un ensemble de normes et de recommandations pour faciliter la maintenance des composants au format CompactPCI : Ceux ci peuvent être remplacés à chaud dans un serveur du moment que toute la chaîne logicielle et matérielle supporte la fonctionnalité. Vous pouvez consulter le site officiel [20] du support CompactPCI sous Linux (PCIMGR standard 2.12) pour obtenir plus d'informations A force de chercher à corriger les dysfonctionnements matériels, vous pourriez facilement oublier le logiciel qui est un des aspects les plus imprévisibles de votre architecture. Aucun code n'est exempte de bogues et rien ne peut garantir que le système d'exploitation ne va pas vous trahir, ou que vos applications ne vont pas imploser. Il est donc nécessaire de surveiller la bonne marche du logiciel, quitte à le relancer automatiquement en cas de nécessité :

13 Mon Scriptage maison Utilisation d'un chien de garde Mon [21] est un outil de surveillance applicative qui va vous permettre de surveiller l'état de vos ressources logicielles et de déclencher des actions paramétrables. C'est un composant essentiel pour déclencher un basculement dans le cadre d'un cluster avec migration de services (Heartbeat) si l'application ne tourne plus sur le noeud actif Un script taillé à la mesure de vos applications est peut être la solution idéale qui vous permettra de surveiller la bonne marche de vos services et de relancer ceux-ci automatiquement en cas de problème ou de provoquer un basculement dans un cluster. La réalisation d'un tel script peut prendre une petite heure à une personne expérimentée Linux a la réputation d'être un système stable et robuste : Mais comme tout logiciel, celui-ci n'est pas exempte de bogues. La tentation est souvent forte pour les éditeurs d'intégrer dans leurs distributions une version récente du noyau au détriment d'une version plus ancienne, moins performante, mais plus éprouvée. Généralement, cela se traduit par un blocage général du système entraînant à coup sûr un redémarrage. Une carte de type WATCHDOG permet de provoquer automatiquement une telle relance (reset matériel) du moment que le système d'exploitation cesse de la stimuler. Cela assure le redémarrage de l'applicatif lorsque l'arrêt n'a pas été causé par une défaillance matérielle permanente. Cette solution n'est à utiliser que dans les cas extrêmes car une mise à jour du noyau est à envisager en cas de répétition du problème Les phases d'administration et d'exploitation d'un système en Haute Disponibilité ne se comparent pas avec celles des autres serveurs moins critiques. Il faut notamment parvenir à détecter une panne le plus rapidement possible pour pouvoir rétablir le service sous les meilleurs délais : Surveiller l'état du système Redémarrage à distance du serveur Dimensionner correctement le serveur Suivre l'évolution de la température ou vérifier la bonne marche des ventilateurs font partie du travail à accomplir dans le cadre de la surveillance d'un système critique : Le projet lm_sensors [22] vous permettra de disposer de ces informations. Ce projet supporte une large gamme de chipset, il y a de bonnes chances qui vous puissiez y trouver votre bonheur Votre système est arrêté et vous ne voulez pas perdre un temps précieux à descendre en salle machine pour redémarrer manuellement le serveur. Pas d'inquiétude, si votre système est de type ATX et moyennant une configuration adéquate dans le BIOS, vous pourrez démarrer à distance votre serveur en envoyant une simple requête UDP sur l'adresse MAC de votre serveur. La technique s'appelle le "Wake On Lan" [23] (le réveil par le réseau) De nombreuses pannes ou dysfonctionnements ont pour origine une installation bâclée ou une sous-évaluation de la charge que devra tenir le serveur. Veillez donc à disposer d'une partition de swap adaptée, d'une volumétrie disque évolutive et d'une puissance CPU convenable. Il est aussi inutile de lancer un serveur X sur votre système : Cela consomme du CPU et le driver pourrait être à l'origine de fuites mémoire qui dégraderaient progressivement les performances (c'est du vécu)

14 Démarrage dès la mise sous tension Accès distant Remontée des évènements Imaginons que suite à une panne de courant, votre système soit de nouveau alimenté. Il pourrait être souhaitable de ne pas à avoir à redémarrer manuellement le serveur (pour gagner du temps) : Certains BIOS autorise ce type de configuration à utiliser néanmoins avec précaution (il faut éviter les redémarrages en boucle) Même si cela parait être une chose évidente pour un utilisateur habitué aux systèmes Unix et Linux, disposer d'un accès distant sur le serveur vous permettra de gagner en temps et en réactivité. N'oubliez donc pas d'activer un serveur telnet ou ssh et (re)découvrez le plaisir des commandes shell peu consommatrices en bande passante réseau Si vous utilisez des briques logicielles aussi diverses que le Channel Bonding ou le RAID logiciel, vous devez mettre en place des moyens pour remonter les évènements (perte d'une carte, perte d'un disque) vers un exploitant (par un généralement). N'hésitez donc pas dans ce cas à user et abuser de scripts shell qui feront ce travail à votre place. Surveiller le pourcentage de saturation des partitions systèmes peut aussi donner une indication précieuse sur un dysfonctionnement à venir (surtout si c'est la partition /var qui est pleine...) Exemples d'architectures Cluster basé sur la réplication de données Ce type de cluster connaît plusieurs variantes suite aux nombreuses briques logicielles ou matérielles misent à notre disposition. Nous avons choisi d'utiliser DRBD pour répliquer les données entre les noeuds, MON pour surveiller l'état de nos services et du système, le Channel Bonding pour sécuriser les composants réseaux et améliorer en particulier les performances entre les noeuds (la vitesse de réplication dépend directement de la performance du réseau), une carte RAID pour fiabiliser les données et héberger le système d'exploitation, un onduleur (UPS) couplé à NUT pour sécuriser l'alimentation électrique et enfin Heartbeat pour lancer et basculer les services. Un petit schéma peut vous aider à appréhender la configuration nécessaire :

15 Cluster basé sur le partage des données La difficulté principale consiste à réunir au sein d'une même configuration tous les composants matériels nécessaires pour autoriser le partage d'une ressource par plusieurs machines. Ce n'est pas une étape triviale à mener et il s'agit de ne pas se tromper dans le choix des composants. Il nous faut d'abord trouver une baie de disques externe qui supporte l'accès simultané de tous les noeuds de notre cluster. Il est conseillé de choisir une baie de type RAID permettant de garantir la disponibilité des données à la différence d'une baie standard moins cher : On utilise justement le terme JBOD (Just a Bunch Of Disks) pour désigner une baie de disque qui n'intègre pas de contrôleur RAID interne ; La Haute Disponibilité des données n'est donc pas garantie dans ce cas. On peut toutefois utiliser du RAID logiciel (RAID 1 ou RAID 5) pour sécuriser les données (activé sur un noeud à la fois). Voici une liste non exhaustive extraite du manuel d'utilisation de la distribution RedHat Enterprise Server [24] : Les baies de disques RAID FlashDisk de la société Winchester Systems ; Les systèmes de stockage SANnet de la société Dot Hill ; Les baies de disques RAID Silicon Image. Il nous faut ensuite sélectionner un contrôleur SCSI ou Fibre Channel pour connecter notre baie aux machines présentes dans le cluster : Le choix d'une interface de type SCSI vous permettra de partager une ressource entre deux et quatre noeuds alors que le Fibre Channel pourra en supporter beaucoup plus. Le choix final va donc dépendre du type de configuration que vous souhaitez mettre en oeuvre. Voici une liste de contrôleur qui sont supportés dans ce type de configuration : Contrôleurs SCSI Adaptec 2940U2W, 29160, 29160LP, et 3950U2 (ainsi que le contrôleur AIC-7896 présent sur la carte mère Intel L440GX+)

16 QLOGIC LSI Logic TEKRAM Contrôleurs Fibre Channel QLOGIC QLA1080 et QLA12160 SYM22915 Ultra2 DC-390U2W QLA2200 Le logiciel que nous allons ensuite utiliser pour gérer le cluster doit pouvoir nous garantir l'unicité du service si les connexions dédiées (Ethernet et liaison série) entre les noeuds du cluster sont rompues. Dans ce cas précis, personne ne sait dans quel état se trouve le voisin et le logiciel est donc dans l'incapacité de prendre une décision (choix d'un basculement de services). On dit alors que le cluster est en «site partition» : Une situation qui ne doit pas arriver. Une première solution consiste à dialoguer par l'intermédiaire d'une partition quorum dédiée sur la baie de disques pour échanger des informations et réserver des disques ou des partitions : C'est la solution technique la plus souvent implémentée sous Linux de par son indépendance au niveau du matériel ; Une seconde approche (dans un cluster de 2 noeuds) consiste à poser un verrou (commande SCSI RESERVE) sur le disque ou sur la partition que l'on souhaite réserver. Si le noeud de secours ne sait pas dans quel état se trouve son voisin, il va chercher à libérer la ressource par la commande SCSI RELEASE. Si le noeud principal du cluster repose immédiatement le verrou, c'est indubitablement qu'il est en vie. A ma connaissance, cette technique n'est pas implémentée sous Linux ; Une dernière approche met à contribution des équipements Power Switches pour essayer de "tuer" (au niveau électrique) le noeud voisin avant de récupérer ses services : On est alors certain de ne pas entrer en conflit avec un noeud avec lequel on ne parvient plus à communiquer. C'est une méthode simple mais particulièrement efficace. Seules la première et la troisième approche sont, à ma connaissance, implémentées sous Linux (il doit en exister d'autres, ce n'est sans doute pas exhaustif). Les clients ne discutent pas directement avec les adresses IP des machines du cluster mais uniquement avec des adresses IP flottantes qui permettent d'abstraire complètement la localisation des services dans le cluster. Il est possible, en combinant des composants logiciels et matériels que nous vous avons présentés tout au long de cet article, de réaliser ce type de cluster (le coeur principal étant constitué de Heartbeat ou bien de FailSafe). Il peut être prudent de considérer des logiciels clefs en main qui garantissent le résultat et qui vous permettront de gagner du temps : Convolo Cluster Dataguard Edition [25] : La société Mission Critical Linux est un précurseur dans la construction de clusters Linux HA car elle est constituée en partie d'ingénieurs ayant fait leurs armes chez DIGITAL (les premiers clusters HA ont été basés sur VMS, un système d'exploitation maison). Ce produit est donc le résultat de leurs expertises et offre toute les garanties suffisantes pour la Haute Disponibilité (interface graphique incluse) avec une limitation néanmoins à deux noeuds ; Cluster Kimberlite [26] : Ce logiciel est le petit frère du précédent car il a été placé sous une

17 licence libre par la même société. Le fonctionnel est le même mais vous ne disposerez alors d'aucun support ou conseil en dehors de celui de la communauté. Si vous vous sentez suffisamment sûr de vous techniquement ou si vos finances vous l'impose, vous pouvez considérer positivement l'installation et l'utilisation de ce logiciel ; Red Hat Cluster Manager [27] : Ce produit offre sensiblement les mêmes fonctionnalités que les précédents mais il est proposé par une pointure du monde Linux, ce qui en fait toute son originalité. Son intégration au coeur même du système d'exploitation du même nom en est forcément facilité ce qui pourrait emporter l'adhésion (il supporte de plus un nombre plus important de noeuds) ; HP Serviceguard [28] : A la différence des HA-CMP et autres TruCluster, HP a sauté le pas et propose sur ses serveurs Linux sa solution de clustering proposée auparavant uniquement sur HP-UX. Le produit bénéficie donc de l'expérience et du sérieux d'un grand constructeur Unix. Bien que d'un niveau technique largement suffisant pour des besoins standards, la solution précédente est pourtant handicapée par la notion même de partage des données qu'elle impose : La réservation est forcément exclusive et implique de verrouiller les accès au niveau du disque ou de la partition pour un seul noeud. Il est pourtant possible de descendre à un niveau beaucoup plus fin en considérant l'utilisation d'un système de fichiers distribué comme GFS ou OpenGFS. Par son intermédiaire et son arbitrage, chaque noeud pourra accéder aux mêmes données (pas forcément au même moment) et réduire d'autant les risques de corruption des données. Cluster en équilibrage de charge Un type de cluster est constitué d'une multitude de serveurs qui hébergent tous le même service ainsi qu'un noeud principal (appelé chef d'orchestre) qui reçoit les demandes des clients et les redistribue en équilibrant la charge. Cette architecture constitue de fait un cluster en Haute

18 Disponibilité puisque la perte d'un noeud ne met pas en péril l'intégrité du service (on peut ajouter ou soustraire un noeud à chaud). Les serveurs sont tous connectés sur un réseau et partagent habituellement, selon le type du service (FTP, HTTP, DNS,...), les mêmes données. L'architecture est transparent pour le client final qui ne discute jamais qu'avec une seule machine (le chef d'orchestre) qui peut elle même être sécurisée dans un second cluster. Grâce à Linux et aux logiciels libres, on peut mettre en place un cluster de ce type en utilisant LVS comme logiciel de clustering, Keepalived pour gérer la surveillance des noeuds, Heartbeat pour sécuriser le noeud principal, Mon pour surveiller l'état des services et un système de fichiers distribué comme CodaFS pour partager les données. Des solutions clefs en main existent qui permettent de mettre en place rapidement ce type de solution (la liste est sans doute plus longue mais cela vous donnera un bon aperçu) : Ultramonkey [29] : Cette solution est basée exclusivement sur l'assemblage de composants libres. Une référence en la matière ; Piranha [30] : Proposé par le leader historique des solutions à base de composants Linux, ce produit offre l'avantage d'être bien intégré dans l'offre commerciale de Redhat. Au même titre que son équivalent basé sur le partage de données et le basculement de services, celui-ci offre un gage sérieux de crédibilité ; Alinka raisin [31] : C'est fois-ci c'est au tour de la société Française Alinka de nous présenter un produit architecturé autour de LVS. Après avoir réalisé un cluster dans le domaine du calcul scientifique, ils ont utilisé leur expérience pour réaliser l'équivalent dans le domaine de la Haute Disponibilité et de l'équilibrage de charge ; En conclusion La Haute Disponibilité s'installe de plus en plus dans notre vie quotidienne ; Il est donc indispensable d'en maîtriser les principes. Nous espérons que cet article a vaincu vos dernières réticences (si nécessaire) et vous a donné envie d'aller voir plus loin dans ce domaine qui n'est finalement pas si compliqué que ça. Linux se révèle, comme à son habitude, un système d'exploitation complet doté d'une force d'adaptation peu commune. L'ombre du logiciel libre n'est pas très loin derrière et prouve que son modèle fonctionne parfaitement, notamment par le grand nombre de solutions commerciales qui cohabitent ou reposent sur des solutions libres. Si le domaine vous intéresse, vous pouvez poursuivre votre lecture par un article très intéressant parut dans le Linux Journal [32] sur le thème de la Haute Disponibilité. L'article date un peu (2000) mais les concepts et principes présentés n'ont pas vieillis. La société française Alcove [33] a fait paraître un livre blanc sur la Haute Disponibilité sous Linux. Même si le document mériterait une mise à jour, il reste encore un des rares documents paru en France traitant de la Haute Disponibilité. Lionel Tricon Références [1] Haute Disponibilité sous Linux : [2] Network UPS Tools (NUT) :

19 [3] RAID : et [4] Channel Bonding : [5] Heartbeat : [6] Fake : [7] FailSafe : [8] LVS : [9] Keepalived : [10] LVM : [11] EVMS : [12] DRBD : [13] SafeKit : [14] GFS : [15] OpenGFS : [16] InterMezzo : [17] CodaFS : [18] MySQL : [19] PostgreSQL : [20] PCIMG Hot-Swap site : [21] Mon : [22] lm_sensors : [23] Wake On Lan : [24] Liste de matériels supportés : Manual/cluster-manager/ch-hardware.html [25] Convolo Cluster Dataguard Edition : [26] Cluster Kimberlite : [27] Red Hat Cluster Manager : [28] HP Serviceguard : [29] Ultramonkey : [30] Piranha : [31] Alinka raisin : [32] High Availability Cluster Checklist : [33] Livre blanc Alcove sur la Haute Disponibilité :