Pannes de disque

La reprise sur panne telle qu’elle est présentée dans le cours permet de s’assurer de l’absence de perte de données, ce qui est déjà beaucoup. En revanche, elle n’assure pas la disponibilité constante du serveur de données puisque ce dernier peut être arrêté pour cause de panne pendant une période allant de quelques secondes (par exemple, relance instantanée du processus serveur après plantage) à quelques heures (par exemple, perte d’un disque suivie d’un remplacement, suivie d’une restauration à partir de la sauvegarde).

De nombreux systèmes applicatifs ne peuvent pas tolérer une telle période d’indisponibilité. C’est le cas par exemple des grands sites de commerce électronique, ou plus généralement des applications dont dépendent de très nombreux utilisateurs (transports, banques, etc.). Il faut dans ce cas développer des méthodes de reprise sur panne pour diminuer le temps de restauration des services et arriver — idéalement — à la garantie d’une disponibilité totale, 24 heures sur 24, 365 jours par an.

Examinons la chaine complète des communications entre un client et les données. On peut imaginer par exemple un navigateur web accédant à une application de commerce électronique, lui-même s’appuyant sur un serveur de données gérant le catalogue, le stock, etc. Cette chaine est résumée sur la figure ci-dessous:

Comment assurer une disponibilité totale de cette chaîne ? Il est clair que la communication entre le client et l’application est hors de notre contrôle. Si le boitier ADSL de l’utilisateur est défaillant, la transaction sera perdue. Nous pouvons envisager d’agir, en revanche, sur la disponibilité de l’application et du serveur de données.

Les solutions de haute disponibilité s’appuient sur la redondance des données et des services. La reprise sur panne telle que nous l’avons exposée en cours s’appuie d’ailleurs également sur ce principe. Pour être capable de pallier immédiatement la défaillance d’un serveur, il faut un serveur de secours ; pour pallier la défaillance d’un disque, il faut un disque de secours.

Le schéma de base est donc celui présenté sur la figure suivante. Le serveur et la base disposent de copies « fantômes », inactives, mais prêtes à prendre le relais en cas de panne. En mode normal, le serveur fantôme se contente de surveiller l’état du serveur principal en échangeant avec lui des messages à intervalles réguliers (mécanisme dit de « heartbeat »). Une copie continue et de préférence synchrone de la base et du journal est effectuée par ailleurs depuis les disques principaux vers les disques fantômes.

Un petit composant complémentaire, le routeur, sert à orienter la connexion des applications. En mode normal, l’adresse fournie par le routeur est celle du serveur principal. En cas de panne de ce dernier, le serveur fantôme va détecter la panne grâce à l’absence de réponse aux messages heartbeat, et prendre immédiatement le relais en demandant au routeur de lui adresser les requêtes. Si la base et le journal sont des copies fidèles de la base initiale, le service peut continuer sans interruption et sans perturbation des applications.

Conceptuellement, c’est simple, mais en pratique c’est bien entendu assez compliqué, et donc... coûteux. Il faut doubler l’infrastructure (deux fois plus de disques, deux fois plus de serveurs). Il est essentiel de répartir ces infrastructures dans deux clouds séparés physiquement, pour éviter la dépendance à de grosses pannes électriques affectant tout un centre de données, des inondations, ou autres catastrophes naturelles. Il faut mettre en place une architecture logicielle assez lourde, avec le personnel, les procédures de contrôle et de test qui vont avec. Il faut enfin assurer la synchronisation des services fantômes et des services principaux grâce à des composants logiciels spécialisés.

Pour les bases de données (qui ne sont qu’un exemple particulier de service dont la disponibilité doit être assurée), la synchronisation des fichiers de base et du journal pose des problèmes spécifiques. Une solution prête à l’emploi est celle des disk arrays, qui assurent des écritures en parallèle sur plusieurs disques. Ces dispositifs permettent de se prémunir contre des pannes fréquentes venant de problèmes matériels sur les disques : il est peu probable que plusieurs disques soient affectés simultanément. En revanche, ils sont peu efficaces contre les événements externes plus exceptionnels, qui demandent d’autres solutions. Certains SGBD proposent une réplication basée sur les écritures dans le fichier journal. Les mises à jour de ce fichier sont transmises vers un disque miroir, ce qui assure une reprise sur panne rapide (mais pas instantanée) avec le serveur fantôme. Enfin, on peut ajouter des composants de réplication synchrone au niveau du système de fichiers lui-même.

Les architectures de haute disponibilité sont étroitement liées aux systèmes de gestion de données distribués. Il est en effet tentant d’utiliser le serveur fantôme pour satisfaire des requêtes au lieu de le confiner à un rôle essentiellement passif. Les systèmes relationnels, dans leur version distribuée, associent clairement les deux problématiques. Une des (rares) caractéristiques commune des systèmes dits « NoSQL » est cette combinaison des fonctionnalités de reprise sur panne et de passage à l’échelle par distribution, au prix de l’abandon de certaines fonctionnalités.

Pour conclure, on notera que le sujet de la haute disponibilité date des débuts de l’informatique. Par exemple, la NASA a fait fortement progresser le domaine dans les années soixante avec le projet Apollo. Il faut aussi noter que les exigences en terme de haute disponibilité dépendent de façon directe de l’application et des coûts induits par une interruption de service. Une panne même de moins d’une minute dans une base de données d’une centrale nucléaire peut avoir des coûts potentiels en vie humaine inacceptables. L’arrêt pendant plusieurs heures du système de paiement d’une entreprise de vente sur Internet peut avoir un coût financier lourd pour l’entreprise. En revanche, la non-disponibilité pendant plusieurs jours de la base de données d’une association locale de protection des grenouilles, si elle peut être gênante pour les membres de l’association, a des conséquences moins sérieuses. La très haute disponibilité coûte cher, on adaptera donc les solutions aux besoins de l’application.

Pour en savoir plus :

• Haute disponibilité sous ORACLE
• Sous PostgreSQL
• Sous MySQL
• Le système DBBD (Distributed Replication Block Device)