Historique des révisions
 

N°	Date	Auteur	Contenu
0.1	23/05/2000	E.B.	Création
1.0	30/06/2000	E.B.	Mise à jour

Table des matières

1.Introduction

2.Fonctions spécifiques la haute disponibilité

2.1.Présentation générale

2.2.Mise en cluster

2.3.Disponibilité des données

2.4.Redondance matériellelocale

2.5.Redondance multi-sites

2.6.Equilibrage de charge

2.7.Administration et exploitation

3.Produits

3.1.Principaux produits étudiés

3.1.1.Linux

3.1.2.HeartBeat

3.1.3.Mon

3.1.4.DRBD

3.1.5.ReiserFS

3.1.6.GFS

3.1.7.LVS

3.2.Couverture fonctionnelle des produits

3.3.Aspects relatifs à la sécurité

4.Comparaison

4.1.Critères

4.1.1.Critères fonctionnels

4.1.2.Critères généraux

4.1.3.Notation

4.2.Tableaux de comparaison

4.3.Synthèse

5.Le futur

1. Introduction

• Etude des produits existants ;

• Comparaison avec deux des principales solutions commerciales ;

• Evaluation des problèmes de sécurité posés par les produits étudiés.

Le document comprend les parties suivantes :

• Présentation des fonctions relatives à la haute disponibilité ;

• Présentation des produits étudiés : fonctionnalités et caractéristiques techniques ;

• Résultat de l'évaluation : présentation des critères, et évaluation selon ces critères (pour les produit étudiés et les deux solutions commerciales retenues) ;

• Prévisions sur les évolutions des logiciels libres dans le domaine de la haute disponibilité.

  2. Fonctions spécifiques la haute disponibilité

2.1. Présentation générale

Ces fonctionnalités sont les suivantes :

• Mise en cluster ;

• Disponibilité des données ;

• Redondance matérielle locale ;

• Equilibrage de charge ;

• Redondance multi-sites.

  2.2. Mise en cluster

Les sous-fonctions sont détaillées ci-dessous :

• Mécanisme de reprise : tous les mécanismes permettant de reprendre un service qui a été interrompu par une panne. Cela inclut le lancement d'applications et la reprise de données et d'adresses réseau ;

• Détection de pannes : détection de problèmes matériels ou logiciels pouvant déclencher une action correctrice comme par exemple le basculement d'un service sur un noeud qui n'est pas touché par le problème.

  2.3. Disponibilité des données

• Support du RAID : indique le support de solutions matérielles existantes RAID, ou la fourniture d'une fonctionnalité équivalente purement logicielle ;

• Disques partagés entre plusieurs noeuds : support des solutions matérielles de disques partagés où plusieurs noeuds sont directement reliés aux disques concernés ;

• Volumes partagés : présence de mécanismes permettant d'utiliser des périphériques distants, ou de répliquer "au fil de l'eau" un périphérique local sur un noeud distant ;

• Haute disponibilité des systèmes de fichiers distants : inclut tous les mécanismes permettant la haute disponibilité d'un système de fichiers distant (tel que NFS) dans le cas où le serveur fournissant ce système de fichiers tombe en panne ;

• Reprise après panne : inclut le support de mécanismes permettant de reprendre un système de fichiers après un "crash" sans perte de données.

  2.4. Redondance matérielle locale

• Périphériques redondants (stockage, réseau, alimentations, CPUs, utilisation de crossbar pour rendre le bus redondant ?) ;

• Changement "à chaud" de périphériques ;

• Utilisation de watchdogs (périphériques permettant de déclencher un redémarrage matériel en cas de "plantage" du système d'exploitation) ;

• Gestion des onduleurs ;

• Support d'outils assurant l'arrêt ou le redémarrage d'un noeud à distance depuis une application tournant sur un noeud distant.

  2.5. Redondance multi-sites

2.6. Equilibrage de charge

Elle entre dans le cadre de la haute disponibilité car un produit d'équilibrage de charge ne redirigera pas les requêtes vers un serveur en panne. L'intérêt d'une telle solution est que la reprise est immédiate (il n'y a pas d'application à démarrer sur un noeud de backup lorsqu'une panne est détectée).

2.7. Administration et exploitation

3. Produits

3.1. Principaux produits étudiés

3.1.1. Linux

3.1.1.1. Fonction

• Raid logiciel : simulation du fonctionnement de contrôleurs RAID uniquement par logiciel ;

• Raid matériel : support de solutions RAID matérielles (contrôleurs RAID) ;

• Gestion des watchdogs : Linux supporte des solutions matérielles de watchdog pour déclencher le redémarrage d'une machine en cas de "plantage".

  3.1.1.2. Architecture

3.1.1.3. Caractéristiques

Les types de RAID supportés sont les suivants :

• RAID 0 : stripping : les informations sont découpées en "tranches" qui sont éclatées entre les différents disques ou partitions utilisés ;

• RAID 1 : mirroring simple : les mêmes informations sont écrites sur tous les disques ;

• RAID 4 : stripping avec utilisation d'un disque supplémentaire pour stocker les informations de parité. Ce type de RAID supporte la panne d'un disque ;

• RAID 5 : comme le RAID 4, mais les informations de parité sont réparties entre les disques ;

• Linear mode (il ne s'agit pas un mode RAID standard) : fonctionnalité équivalente au Raid 0, mais sans striping (le système "voit" un volume qui est en réalité la concaténation des informations des disques physiques ou partitions utilisés).

Les différences par rapport au RAID matériel sont les suivantes :

• Le RAID matériel ne s'applique qu'à des disques entiers, le RAID logiciel peut ne comporter que certaines partitions ;

• Les traitements normalement assurés par un contrôleur RAID sont réalisés par logiciel dans le cas du RAID logiciel, ce qui est susceptible de dégrader les performances ;

• Le RAID matériel rend les pannes transparentes pour l'OS et les applications (à part éventuellement une remontée d'alerte le cas échéant). Dans le cas du RAID logiciel, où l'on utilise du matériel standard, certaines pannes peuvent empêcher le serveur de fonctionner et nécessitent une intervention manuelle pour la reprise du service (arrêt du serveur, retrait et éventuellement remplacement du disque fautif) ;

• Les solutions de RAID logicielles ne supportent pas le "Hot-swap" (remplacement à chaud d'un disque) ;

• Les solution à base de RAID logiciel sont indépendantes du type de disque utilisé. En particulier, il est possible d'utiliser des disques IDE très peu chers.

RAID matériel :

Le seul contrôleur RAID supporté par Linux (version 2.2.15) est celui de la société DPT (http://www.dpt.com/).

Watchdogs :

Le module watchdog du noyau linux supporte plusieurs solutions matérielles de watchdog (Berkshire et ICS pour la version 2.2.15). La liste exhaustive est présente dans le fichier Documentation/watchdog.txt des sources du noyau Linux.

Ce module permet de déclencher un redémarrage (reset matériel) si un applicatif ne communique plus avec le watchdog pendant une certaine période de temps configurable, ce qui se produit dans le cas d'un "plantage" (c'est à dire un blocage de l'ordinateur dû à un bug logiciel ou un problème matériel) : cela assure le redémarrage de l'applicatif dans tous les cas de plantage qui n'ont pas été causés par une défaillance matérielle permanente.

Il est également possible de simuler cette fonction uniquement par logiciel (utilisation d'un timer), mais cette solution s'avère beaucoup moins fiable (beaucoup de cas de plantage vont aussi bloquer le timer).

De plus certaines des solutions matérielles supportées fournissent une fonction de surveillance de la température exploitable par un applicatif, par l'intermédiaire d'une interface de bas niveau (device UNIX /dev/temperature).

Remarque : Les fonctions de surveillance de température, des ventilateurs, et de détection d'intrusion physique présentes sur certaines cartes mères sont utilisables par un produit tiers lm-sensors (licence GNU : accessible à l'URL http://www.netroedge.com/~lm78), non évaluées dans cette étude.

3.1.1.4. Type de licence

3.1.1.5. Où le trouver ?

3.1.2. HeartBeat

3.1.2.1. Fonction

Il constitue l'une des réalisations du projet Linux-HA (www.linux-ha.org) qui a pour but de fournir une solution de clustering avec haute disponibilité sous Linux.

Il permet de gérer un nombre quelconque de services sur deux serveurs. Chaque service est associé à un serveur (serveur principal du service). En cas de panne d'un serveur, les services associés à ce serveur sont démarrés sur l'autre noeud (noeud de backup). Lorsque le serveur principal est à nouveau disponible, ces services sont arrêtés sur le noeud de backup et démarrés sur le noeud principal.

Dans le cas de services réseau, Hearbeat prend en charge la reprise d'adresses IP et la mise à jour des caches ARP des machines connectées au réseau local (clients ou routeurs) pour qu'ils tiennent compte du basculement.

3.1.2.2. Architecture

3.1.2.3. Caractéristiques

En cas de dépendances entre plusieurs services, on peut fixer l'ordre de démarrage ou d'arrêt de ces services (quand ils ont le même noeud principal).

Un service peut être matérialisé par n'importe quelle application. La seule contrainte est de fournir un script permettant de démarrer, d'arrêter et de connaître l'état du service (démarré ou arrêté). Ces scripts implémentent la même interface que les scripts de démarrage de la distribution RedHat (ainsi que d'autres distributions), cela permet d'utiliser directement tous les programmes livrés avec des scripts respectant cette interface comme par exemple apache, samba, named, sendmail ? sans avoir à écrire de script.

Il est possible d'arrêter ou de démarrer un des serveurs manuellement, par exemple pour des opérations de maintenance, dans ce cas tous les services sont basculés sur l'autre serveur.

Heartbeat n'offre qu'un seul mode de reprise : un service est toujours actif sur son noeud principal quand celui-ci fonctionne.

La surveillance s'effectue par plusieurs canaux simultanément (une ou plusieurs interfaces réseau plus une ou plusieurs liaisons série). Cela permet de distinguer une coupure réseau entre les deux serveurs d'une panne matérielle d'un noeud. En particulier cela évite de se retrouver dans une situation ou les deux noeuds lancent simultanément les mêmes services. Ce mécanisme de surveillance ne détecte que les pannes matérielles ou les problèmes réseau. Il est nécessaire d'utiliser d'autres produits tels que Mon (cf. 3.1.3) pour réaliser la surveillance applicative (ces produits peuvent déclencher le basculement par l'intermédiaire de scripts fournis avec Heartbeat).

Heartbeat ne gère pas les interfaces réseau ou les réseaux redondants.

3.1.2.4. Type de licence

3.1.2.5. Où le trouver ?

3.1.3. Mon

3.1.3.1. Fonction

3.1.3.2. Architecture

Le client permet d'administrer le serveur Mon. Il est disponible sous forme d'un outil en ligne de commande, d'une interface Web (CGI), ou d'une API Perl.

Les actions possibles depuis un client comprennent (cette liste n'est pas exhaustive) :

• Marche/arrêt du serveur ;

• Marche/arrêt de la surveillance d'un service ;

• Envoi d'un accusé de réception pour une alerte. Cette alerte ne sera plus envoyée après un accusé de réception ;

• Consultation de l'état des ressources surveillées et des alertes ;

• Déclenchement immédiat du test d'une ressource ;

• Déclenchement d'une alerte (pour test).

  3.1.3.3. Caractéristiques

Les scripts d'alertes livrés sont les suivants : envoi de mail, envoi de trap, envoi de message SMS ou vers pager. De même que pour les scripts de surveillance, il est possible d'ajouter ses propres scripts (déclenchement d'actions correctrices ou autres méthodes de remontée d'alertes).

Le produit est hautement configurable : il est possible de paramétrer, pour chacune des ressources, l'intervalle de surveillance, le délai de répétition des alertes et le nombre d'échecs lors de la surveillance de cette ressource avant déclenchement de l'alerte. Les règles peuvent dépendre de la plage horaire (par exemple les traitements peuvent être différents en semaine pendant la journée). Pour faciliter la configuration, il est possible de définir des groupes de services réseau à surveiller, et de fixer des dépendances (par exemple si un routeur surveillé tombe en panne, Mon n'enverra pas d'alertes parce qu'un serveur accèdé par l'intermédiaire de ce routeur n'est plus disponible).

Mon surveille des ressources en parallèle. Un seul serveur est capable de surveiller un nombre important de ressources.

Les communications entre un client et un serveur sont authentifiées par un mot de passe (passé en clair).

Cohabitation Mon / Heartbeat :

Le produit Heartbeat seul ne peut suffire à la réalisation d'un cluster redondant, car il ne propose pas de fonction de surveillance des applications. Il est possible d'utiliser en complément le produit Mon pour pallier à ce manque.

Une solution utilisant les deux produits permet par exemple de déclencher le basculement du cluster géré par Heartbeat si l'application ne fonctionne plus sur le noeud actif.

L'intégration des deux produits est "manuelle " : il faut développer le script qui sera déclenché par Mon en cas de problème applicatif et qui lancera le basculement du cluster géré par Heartbeat, par l'intermédiaire de l'interface en ligne de commande de ce dernier.

3.1.3.4. Type de licence

3.1.3.5. Où le trouver ?

3.1.4. DRBD

3.1.4.1. Fonction

DRBD inclut des mécanismes de synchronisation partielle (après une déconnexion réseau) ou complète (pour une première utilisation ou après le changement de l'un des disques).

DRBD permet de réaliser des clusters hautement disponibles gérant des données dynamiques (bases de données, serveurs de fichiers ?).

3.1.4.2. Architecture

En cas de panne du serveur principal, DRBD fonctionne selon la configuration présentée dans le schéma ci-dessous :

DRBD se présente sous la forme d'un module noyau réalisant la réplication de données, et d'un outil d'administration en ligne de commande permettant de configurer et de changer le mode (primaire/secondaire/arrêté) de DRBD. Toutes les fonctions de communication sont réalisées de manière asynchrone par des threads noyau, ce qui ne bloque pas les applications locales lors d'une écriture sur un disque répliqué.

3.1.4.3. Caractéristiques

DRBD supporte les déconnexions ou les pannes temporaires du serveur secondaire, y compris un crash suivi d'un redémarrage, en conservant une copie locale des modifications. Lors de la reconnexion, le serveur primaire renvoie toutes les mises à jour qui ont été "ratées" par le secondaire.

Les mécanismes de détection de pannes et le déclenchement du basculement ne font pas partie du produit et sont à réaliser par ailleurs. DRBD est fourni avec des scripts permettant de l'intégrer à Heartbeat. Dans la version évaluée, ces scripts peuvent amener les deux serveurs à se retrouver simultanément dans le mode primaire lors d'un basculement manuel, et nécessitent donc d'être modifiés afin d'éviter ce problème.

Le produit n'assure aucune fonction relative à la sécurité. En particulier il n'y a pas de mécanisme d'authentification, de contrôle d'accès, d'intégrité ou de confidentialité des données échangées sur le réseau.

Dans le cas où les deux serveurs tentent de devenir primaires simultanément, le produit s'arrête immédiatement de fonctionner (ce cas ne doit pas se produire en fonctionnement normal, mais ceci garantit que s'il se produit, les données ne sont pas perdues)

DRBD propose trois protocoles différents pour la transmission de données (par ordre décroissant de performance) :
 

Protocole	Description
A	Une opération d'écriture est considérée comme terminée avec succès dès que les données sont écrites sur le disque local et envoyées sur le réseau vers le noeud secondaire
B	Une opération d'écriture est considérée comme terminée avec succès dès que les données sont écrites sur le disque local et que le noeud secondaire a accusé réception des données
C	Une opération d'écriture est considérée comme terminée avec succès dès que les données sont écrites sur le disque local et que le noeud secondaire a indiqué qu'il a écrit les données sur son disque

Seul le protocole C garantit que, en cas de crash du serveur primaire, aucune écriture ayant abouti sur le primaire ne sera perdue lors de la reprise par le secondaire. Cela est expliqué dans le schéma suivant :

Ce schéma correspond à l'utilisation du protocole C (attente de l'écriture pour accuser réception de la notification), où les caches disque en écriture sont désactivés (voir remarque importante 2 plus loin).

Remarque importante 1 : lors de la reprise par le secondaire après un crash du primaire, la partition répliquée est récupéré "en l'état" telle qu'elle était à l'instant du crash. On se trouve ainsi dans le même cas que lors de la reprise d'une partition locale après un crash. Un solution utilisant DRBD doit donc inclure des mécanisme de reprise de données, comme par exemple :

• La partition est utilisée par une base de données comprenant ses propres mécanismes de reconstruction des données (par exemple Oracle) ;

• Utilisation d'un système de fichiers classique avec vérification et réparation lors de la reprise (fsck). Cela peut s'avérer pénalisant en termes de performances et n'offre pas de garantie de réussite ;

• Utilisation d'un système de fichiers journalisé assurant une reprise très rapide du système de fichiers et garantit qu'il est dans un état cohérent vis-à-vis du système (mais pas forcément des applications).

Dans les deux derniers cas, les applications gérant leurs données doivent elles aussi posséder un mécanisme de reprise de leurs données : par exemple, une application qui était en train d'écrire un fichier au moment du crash pourra retrouver un fichier tronqué lors de son démarrage sur le secondaire.

Remarque importante 2 : les systèmes d'exploitation retardent généralement les écritures sur disque pour des raisons de performances. Un tel mécanisme doit être désactivé sur une partition répliquée par DRBD (utilisation de l'option de montage "sync" sous Linux, ou utilisation d'une application qui force la mise à jour immédiate du disque lors d'une écriture comme par exemple l'annuaire OpenLDAP ou toute application stockant ses données dans une base gdbm). De la même manière, tous les mécanismes de caches en écriture (write-back caching) implémentés sur les contrôleurs de disques ou les disques eux-mêmes doivent être désactivés.

Les produits gérant eux même leur cache en écriture de façon à permettre une reprise après un crash (c'est par exemple le cas d'Oracle) peuvent être utilisés avec DRBD, mais cela peut impliquer un impact sur les performances (un appel système qui réalise effectivement l'écriture sur disque, tel qu'un sync ou une écriture quand le cache du système est désactivé, restera bloqué tant que l'écriture n'a pas été réalisée et acquittée par le noeud secondaire).

La roadmap du produit indique que les versions futures prévoient le mirroring simultané sur plusieurs serveurs secondaires distant (utilisation du multicast).

3.1.4.4. Type de licence

3.1.4.5. Où le trouver ?

3.1.5. ReiserFS

3.1.5.1. Fonction

3.1.5.2. Architecture

3.1.5.3. Caractéristiques

• Après une reprise d'un système de fichiers, ReiserFS garantit que l'ensemble des méta-données sont récupérées dans un état cohérent. En particulier l'arborescence des fichiers présents n'est pas impactée. Après un re-jeu du log lors du montage de la partition, le système de fichiers ne présente pas d'erreurs et ne nécessite donc pas de réparation (de type fsck) ;

• Cependant, les modifications des données elles mêmes ne sont pas journalisées. Après une reprise, les fichiers qui étaient en cours de modification au moment d'un crash sont dans un état indéterminé.

D'autres produits fournissent une fonction de journalisation complète (tel que par exemple le système de fichiers ext3). Ces produits ne se situent pas à un stade très avancé de réalisation. Pour de la journalisation dans le cadre de disques partagés, voir GFS (partie 3.1.6).

ReiserFS peut être utilisé comme système de fichiers de boot (système de fichiers contenant le répertoire racine) sur un système Linux.

3.1.5.4. Type de licence

3.1.5.5. Où le trouver ?

3.1.6. GFS

3.1.6.1. Fonction

GFS fournit en plus une fonction de journalisation.

3.1.6.2. Architecture

GFS supporte un nombre quelconque de clients reliés à un ou plusieurs disques par 'un moyen de communication pouvant être l'un des suivants :

• Un bus SCSI ;

• Un réseau Fibre Channel ;

• Un réseau IP. Dans ce cas, il faut adopter une solution permettant d'utiliser un disque distant par l'intermédiaire d'un réseau IP. Les solutions possibles comprennent NBD (Network Block Device) livré en standard avec Linux, ou GNBD, en cours de développement par l'équipe qui a réalisé GFS.

GFS permet d'accéder des disques simples ou des baies RAID.

GFS se présente sous la forme d'un module ajoutant le support du système de fichiers GFS et d'utilitaires permettant la création et la gestion de disques ou de partitions partagés.

3.1.6.3. Caractéristiques

La spécification de Dlock est présente à l'URL http://www.globalfilesystem.org/Pages/dlock.html.

Elle a été implémentée par plusieurs constructeurs de disques (Seagate, Silicon Gear) ou de baies RAID (Dot Hill). Les versions du firmware pour ces produits avec le support de la spécification Dlock et les outils de mise à jour sont disponibles sur le site Web de GFS.

Dans le cas ou Dlock ne serait pas supporté par les disques ou les baies de disques, il est possible d'utiliser une solution uniquement logicielle (produit GLMD) intégrée à la distribution GFS, mais qui est encore en cours de développement.

La plus grosse configuration basée sur GFS a été présentée à la Linux World Expo 2000, et comprenait 16 clients et 64 disques répartis en 8 baies, le tout relié par Fibre Channel.

La fonctionnalité de journalisation est en phase de développement actuellement.

3.1.6.4. Type de licence

3.1.6.5. Où le trouver ?

3.1.7. LVS

3.1.7.1. Fonction

Deux solutions complètes basées sur LVS sont en cours de développement :

• Virtual Monkey, réalisé par la société VA Linux compte proposer un produit intégrant LVS et Heartbeat pour fournir une solution complète pour la mise en place de "fermes de serveurs".

• Piranha, inclu avec la distribution RedHat, fournit en plus de LVS un outil permettant d'assurer la haute disponibilité du noeud dispatcher lui-même et une interface d'administration accessible depuis un browser Web (voir copie d'écran ci-dessous). Cette interface permet de configurer le noeud dispatcher, et éventuellement un noeud de backup, de consulter l'état des serveurs, d'ajouter ou supprimer des serveurs.

Ces deux produit sont distribués sous licence GPL.

La copie d'écran ci-dessous présente l'interface Web de Piranha :

3.1.7.2. Architecture

• Serveurs virtuels avec translation d'adresse (NAT) ;

• Serveurs virtuels avec tunneling IP ;

• Serveurs virtuels avec routage direct.

Ces trois solutions sont décrites ci-dessous.

Les schémas présentés dans les parties suivantes comportent un serveur dispatcher de backup. Le mécanisme de backup ne fait pas partie du produit LVS standard, mais est inclus dans les solutions complètes Piranha et Ultramonkey.

Translation d'adresses (NAT)

Le schéma suivant présente l'architecture réseau dans le cadre de la solution avec translation d'adresses. Cette solution montre un fonctionnement équivalent à celui du produit commercial CISCO Local Director.

Le noeud dispatcher réalise la translation des adresses source et destination pour les paquets entrants et sortants.

Avantage :

• Aucune contrainte au niveau des serveurs pour qui la solution semble transparente (du point de vue du serveur, les requêtes semblent venir du noeud dispatcher).

Inconvénient : 

• Faible "scalabilité" : le noeud dispatcher doit réaliser la translation d'adresses pour tous les paquets entrants et sortants.

Tunneling IP

L'architecture réseau, dans la solution avec tunneling IP, est la même que dans le cas de la translation d'adresse (voir ci-dessus).

Le dispatcher encapsule les paquets en provenance du client qui lui sont donc destinés, dans un paquet IP qu'il envoie au serveur qu'il a choisi. Le schéma suivant illustre le format d'un paquet IP entrant (envoyé par le dispatcher à un serveur) :

Les paquets IP sortants (envoyés par les serveurs vers un client) sont relayés par le dispatcher à l'aide du mécanisme de routage IP standard.

Avantage :

• Permet d'utiliser une architecture avec deux réseaux physiquement séparés comme dans la solution NAT, mais avec un impact moindre sur les performances : seuls les paquets entrants doivent être réécrits, les paquets sortants sont acheminés par le mécanisme de routage IP standard par le noeud dispatcher.

Inconvénients :

• Les serveurs doivent supporter l'encapsulation IP/IP. Aujourd'hui seul Linux le supporte ;

• Contrainte sur les serveurs : ils doivent posséder une "adresse IP virtuelle" (par exemple une IP sur l'interface loopback) identique à celle utilisée par le client, pour pouvoir accepter les paquets encapsulés.

Routage direct

Le schéma suivant présente l'architecture réseau dans le cadre de la solution avec routage direct. Elle présente un fonctionnement équivalent à celui du produit commercial Network Dispatcher d'IBM.

Dans cette configuration seuls les paquets IP en provenance des clients sont traités par le dispatcher. Les paquets à destination du client ne passent pas par le dispatcher. De même que dans la solution précédente, les serveurs doivent avoir une adresse IP virtuelle qui est la même que celle du dispatcher.

Avantage :

• Meilleure performances et "scalabilité" : seuls les paquets entrants sont traités par le dispatcher.

Inconvénients :

• Le dispatcher et les serveurs doivent tous se trouver sur le même réseau ethernet physique ;

• Contrainte sur les serveurs : ils doivent avoir une "adresse IP virtuelle" (par exemple une IP sur l'interface loopback) identique à celle utilisée par le client, pour pouvoir accepter les paquets encapsulés.

3.1.7.3. Caractéristiques

• Round-Robin : les requêtes sont renvoyées vers chacun des serveurs indépendamment de leur charge ou du nombre de connexions ;

• Round-Robin avec pondération : même principe que le Round-Robin simple, mais certains serveurs sont plus sollicités que d'autres (selon des coefficients fixés par l'administrateur) ;

• Selon le nombre de connexions actives : le serveur possédant le moins de connexions actives reçoit la requête ;

• Selon le nombre de connexions actives avec pondération : même principe que le critère précédent, mais des coefficients sont appliqués aux nombres de connexions pour chaque serveur.

Il n'est pas possible d'obtenir des critères dépendant de l'état des serveurs (charge, occupation CPU?).

Les fonctions de haute disponibilité (dispatcher redondant et détection des serveurs en panne) ne sont pas incluses dans la version standard de base de LVS, mais sont fournies avec les solutions complètes présentées au 3.1.7.1.

Remarque importante : certains systèmes d'exploitation répondent à des requêtes ARP arrivant sur une interface différente de celle de l'adresse demandée. C'est en particulier le cas des versions 2.2.x de Linux. Ces systèmes ne peuvent pas être utilisés comme serveurs dans les architectures avec tunneling ou routage direct. Pour Linux 2.2.x un patch est disponible sur le site de LVS afin de corriger ce problème.

3.1.7.4. Type de licence

3.1.7.5. Où le trouver ?

UltraMonkey est accessible à l'URL http://ultramonkey.sourceforge.net/.

Piranha est inclus dans les distributions RedHat 6.1 et ultérieures. Le produit est présenté à l'URL http://www.redhat.com/support/wpapers/paranha/x32.html.

3.2. Couverture fonctionnelle des produits

3.3. Aspects relatifs à la sécurité

Authentification

Les produits qui communiquent entre noeuds d'un cluster utilisent des mécanismes d'authentification variables :

• Hearbeat permet d'authentifier les paquets de surveillance à l'aide d'une clef connue par chacun des serveurs et d'une fonction de hachage (MD5 ou SHA). Cependant ce mécanisme ne protège pas du re-jeu. On peut par exemple envisager une attaque de type déni de service en envoyant périodiquement des paquets de ping préalablement "reniflés" pour faire croire qu'un noeud en panne fonctionne toujours ;

• Mon authentifie ses client par un nom d'utilisateur et un mot de passe qui sont transmis en clair sur le réseau ;

• DRBD ne possède aucun mécanisme d'authentification pour ses paquets de mise à jour du disque secondaire et d'acquittement. En particulier, il est très aisé de produire des "faux" paquets pour modifier le contenu du disque secondaire.

Contrôle d'accès

Aucun produit ne fournit de fonction de contrôle d'accès pour ses échanges réseau : les paquets authentifiés sont toujours acceptés.

Dans le cadre de l'utilisation de DRBD, l'authentification sur les systèmes de fichiers Unix est basée sur les UID. Les UID doivent donc être les mêmes sur les deux serveurs.

Intégrité

Hormis Heartbeat qui utilise MD5 ou SHA pour signer ses paquets, aucun des produits ne propose de fonction assurant l'intégrité des données échangées.

En particulier, DRBD ne garantit pas l'intégrité des informations écrites sur le disque du noeud secondaire.

Confidentialité :

Aucun des produits étudiés ne propose de mécanisme pour assurer la confidentialité des données. En particulier, si on utilise DRBD, on peut reconstituer le disque répliqué ou une partie de celui-ci en "reniflant" suffisamment de paquets échangés.

Solutions :

Ce paragraphe présente des solutions destinées à sécuriser l'utilisation des produits étudiés :

1^ère solution : sécurité de périmètre :

Cette solution consiste à intercaler un firewall entre le cluster de serveurs hautement disponibles et l'extérieur.

Cette configuration garantit que seules les requêtes autorisées venant des clients atteignent les noeuds composant le cluster. En particulier, un client connecté au réseau non sécurisé ne peut pas interférer avec les produits assurant la haute disponibilité.

2^ème solution : utilisation des réseaux physiques distincts :

Une autre possibilité consiste à utiliser des réseaux physiques différents pour les informations sensibles ou pour les applications dont les communications ne sont pas protégées par des mécanismes de sécurité suffisants. Le schéma ci-dessous présente un exemple de cluster sécurisé :

Les précautions suivantes doivent être prises :

• Désactiver les mécanismes de routage sur les serveurs reliés aux deux réseaux ;

• Mettre en place des règles de filtrage IP sur ces serveurs pour interdire des connexions vers les outils utilisant le réseau privé par l'intermédiaire de l'interface reliée au réseau public.

Ce type d'architecture est supporté par tout les produits étudiés.

Les deux solutions présentées ci-dessus ne sont pas exclusives et il est possible de les combiner.

4. Comparaison

4.1. Critères

• Critères fonctionnels ;

• Critères généraux.

  4.1.1. Critères fonctionnels

Cette partie décrit plus précisément quels points seront considérés pour chacune des fonctions et éventuellement sous-fonctions étudiés et de quelle façon il seront évalués.

4.1.1.1. Mise en cluster

Mécanismes de reprise :

• Support de différents modes de "clustérisation" (attente active, "failover" en cascade?) ;

• Nombre maximal de noeuds supportés ;

• Sélection dynamique du noeud de backup à utiliser en cas de panne (quels sont les critères de sélection, est-il possible d'en ajouter ?) ;

• Compatibilité avec les produits d'équilibrage de charge existants : support d'instances multiples de services, remontée d'informations (tels que charge CPU, noeud opérationnel ou non?) du cluster vers l'équilibreur de charge, liste des produits supportés ;

• Actions correctrices possibles : traitements que le produit peut déclencher automatiquement en cas de panne (basculement, redémarrage d'application ?). Support de plusieurs actions correctrices (par exemple si un service ne répond pas, le service est redémarré, et si cela échoue le noeud est redémarré).

Détection de pannes :

• Détection de pannes logicielles : capacité à détecter un problème (application ou service réseau défaillant ou arrêté) sans modifier l'application. Quels sont les applications ou services réseau surveillés ? ;

• Détection de pannes matérielles : quels sont les types de pannes qui peuvent être détectés et peut-on déclencher une action de basculement vers un autre noeud ? mécanismes de détection, support de chemins multiples pour la détection de noeuds en panne ;

• Détection de problèmes de ressources : déclenchement du basculement sur des critères tels que charge, espace disque ou mémoire ?. ;

• Interfaces : existence d'une interface (API ou outils en ligne de commande) permettant aux applications de déclencher un basculement ou consulter l'état du cluster.

• Extensibilité : ajout par l'administrateur de critères de basculement, de mécanismes de détection de panne, d'actions correctrices (ajout possible de scripts personnalisés) ? ;

• Réglages possibles : quels sont les paramètres réglables? Peut-on configurer les délais (pour déclarer un noeud comme en panne ou effectuer la reprise), le nombre d'essais pour les actions correctrices ?

  4.1.1.2. Disponibilité des données

• RAID logiciel. Types de RAID supportés (0,1,5) ;

• RAID matériel. Types de RAID supportés. Liste des solutions matérielles supportées. En particulier on vérifiera l'existence de mécanismes de remontée d'erreur pris en charge par le produit de haute disponibilité et le support du "hot-swap".

Disques partagés physiquement entre plusieurs noeuds:

• Liste des produits supportés ;

• Accès concurrent : Plusieurs noeuds peuvent-ils accéder simultanément au disque, quelles sont les restrictions (par exemple accès en écriture limité à un seul noeud) ;

• Nombre de noeuds supportés : il s'agit du nombre de noeuds pouvant être reliés simultanément aux disques.

Volumes partagés :

• Utilisation de volumes distants ou réplication de volumes locaux sur un noeud différent ;

• Accès concurrents ;

• Existence d'un mécanisme de resynchronisation après une déconnexion ou une panne ;

• Nombre de noeuds supportés : nombre de noeuds pouvant être reliés simultanément aux disques.

Haute disponibilité des systèmes de fichiers :

• Maintien de l'état d'un système de fichiers distant après une panne du noeud l'hébergeant (par exemple conservation des verrous dans le cas de NFS) ;

• Support de systèmes de fichiers journalisés.

  4.1.1.3. Equilibrage de charge

• Haute disponibilité du mécanisme d'équilibrage de charge ;

• Services supportés (services réseau TCP/IP, autres ?) ;

• Critères de "dispatching" supportés : quels critères sont possibles pour sélectionner le noeud traitant une requête (Round Robin, hasard, sélection selon ressources disponibles? Peut-on envoyer toutes les requêtes d'un client vers un seul noeud?) ;

• Ressources surveillées et utilisées dans les critères de dispatching (CPU utilisé, charge, nombre de connexions?) ;

• Détection des noeuds en panne. Le produit ne doit pas aiguiller une requête vers un noeud en panne.

• Mécanismes supportés (NAT, tunneling, routage direct?)

  4.1.1.4. Redondance matérielle locale

• Support des matériels hautement disponibles (liste des périphériques redondants et "hot-swappables"). Impact sur les applications ;

• Support des solution matérielles de watchdog. Liste des produits supportés ;

• Gestion des onduleurs (détection coupure, consultation de la batterie, gestion du redémarrage ?) ;

• Support des solutions matérielles permettant de déclencher le démarrage, le redémarrage ou l'arrêt d'un noeud à distance.

  4.1.1.5. Redondance multi-sites

• Mécanismes de synchronisation de données entre sites (synchrone, asynchrone ?) ;

• Mécanismes de reprise multi-sites

  4.1.2. Critères généraux

• La notoriété du produit et de l?éditeur ;

• La qualité technique du produit ;

• L'administrabilité du produit ;

• Le maintien en conditions opérationnelles ;

• Les aspects financiers et juridiques.

Ces critères sont détaillés ci-dessous :

Notoriété :

Appréciation de la notoriété du produit et de la société qui l'édite.

Les références connues du produit seront prises en compte.

Qualité technique du produit :

Synthèse de la qualité des produits sur le plan technique.

En particulier, les sous-critères suivants seront évalués :

• Robustesse ;

• Sécurité : ce critère estime les problèmes de sécurité posés par l'utilisation des produits étudiés. Les questions de sécurité sont présentés plus en détail dans la partie 3.3).

Administration et exploitation :

Les points suivants seront jugés :

• Configuration à chaud (y compris ajout et suppression de noeuds dans un cluster) ;

• Configuration centralisée ;

• Console d'exploitation centralisée ;

• Mécanismes d'alertes (SNMP, notification des utilisateurs, méthodes externes : E-Mail, pager, téléphone ?) ;

• Existence d'une API (pour la configuration, remontée de l'état du cluster, et déclenchement de basculement) ;

• Centralisation de la configuration des systèmes d'exploitation des différents noeuds (nommage, paramétrage ?).

Maintien en conditions opérationnelles :

Ce critère constitue une synthèse des sous-critères suivants :

• Documentation : évaluation de la qualité et de la complétude de la documentation du produit, ainsi que de l'existence d'une aide en ligne intégrée au produit ou disponible sur le Web ;

• Support : existence et qualité du support ;

• Prise en main : facilité de prise en main du produit.

  4.1.3. Notation

On comparera trois solutions décrites ci-dessous :

• AIX/HACMP ;

• Digital Unix/TruClusters ;

• Logiciels libres : l'ensemble des produits décrits dans ce document. Pour chacun des critères fonctionnels, on rappellera quels sont les produits concernés.

Pour chacune des solutions sont évalués :

• Les sous-critères : à chacun d'eux sera associée une notation qui dépendra du sous-critère. Elle pourra être + si la fonctionnalité est présente et implémentée de façon satisfaisante, - pour indiquer que la fonctionnalité n'est pas implémentée ou de manière non satisfaisante. On indiquera n/a si la fonctionnalité ne s'applique pas, et pas de notation si la fonctionnalité n'a pu être évaluée. On pourra aussi associer à un sous-critère une évaluation informelle, par exemple une valeur numérique pour le sous-critère "nombre de noeuds supportés".

• Les critères (fonctionnels ou généraux) : à chacun des critères sera associée une note *,**,*** selon que l'évaluation du critère correspondant est mauvaise, moyenne ou bonne. Cette note sera déduite des évaluations des sous-critères dépendant de ce critère.

Ces notations seront récapitulées sous la forme de deux tableaux :

• Un tableau d'évaluation présentant l'ensemble des critères et de leurs sous-critères ;

• Un tableau de synthèse ne montrant que les critères.

Les colonnes de ces tableaux sont les suivantes :

• Critères : critères ou sous-critères évalués ;

• HACMP / Trucluster / Logiciel libres : notation du critère ou sous-critère comme présenté ci-dessus ;

• Produits : dans le cas des critères fonctionnels, cette colonne indique quels sont les produits concernés par la fonction associée au critère ;

• Remarques : Cette rubrique précise la notation de la solution logiciels libres et peut éventuellement présenter des éléments de comparaison avec les autres solutions.

  4.2. Tableaux de comparaison