Zen-Dreams

Avant de parler de Haute Disponibilité, j’aimerais introduire la notion de disponibilité. Un système, au sens large du terme, devient indisponible lorsqu’il n’est plus utilisable ou alors avec des fonctionnalités trop limitées.
De nombreuses raisons expliquent une indisponibilité, la plus courante étant liée à ce que l’on appelle SPOF (Single Point of Failure, autrement dit, un point faible), les autres étant liés à de mauvaises opérations ou à la loi de murphy.

La Haute Disponibilité est un concept utilisé pour rendre un système disponible autant que possible, c’est-à-dire avec le minimum d’interruption possible. Avant de penser votre architecture, vous devez définir un SLA (Service Level Agreement). Le SLA est le document qui répertorie les informations liées à l’indisponibilité du système, qu’elle soit planifiée ou non, mais aussi des temps de réponses, du monitoring à mettre en place ainsi que les actions préventives à définir.

La disponibilité est, la plupart du temps, exprimée en pourcentage de temps pendant lequel le système doit fonctionner. Ce pourcentage est calculé sur la moyenne annuelle et ramené par la suite en taux mensuel. Cela permet d’avoir une idée du temps d’interruption accepté mensuellement.

Par exemple, si vous voulez que votre système soit disponible en cinq neuf (99.999%), il doit être fonctionnel 525594.744 minutes par an. D’après ce calcul, vous pouvez donc avoir 5.25 minutes de coupure de service annuellement, et donc 44 secondes par mois.

Une fois votre taux de disponibilité calculé, vous pouvez passer à l’architecture du système, que ce soit pour le définir ou l’améliorer. Pour se faire, vous devez donc identifier les SPOF afin de les sécuriser.
Voici une liste non exhaustive des points faibles possible : Serveur de base de données, Eléments réseaux (tels que load-balancer, switch, routeur, firewall, etc…), Serveur d’application, Filers, Disques, Serveurs d’authentification.
L’identification des ces points permettront d’analyser le gain par rapport au coup d’optimisation.

Un exemple d’architecture en Haute disponibilité

Management

La Haute disponibilité n’est pas seulement un concept d’architecture, mais aborde aussi des bonnes pratiques de management. Cette partie est au moins aussi importante que l’architecture elle-même car même si vous avez créé la meilleure architecture, si vous ne faites pas d’améliorations continuellement, vous ne pourrez jamais faire de prévention.

Comme j’en parlais précédemment, votre SLA est là pour vous aider à définir ce qui doit être surveillé ainsi que les événements critiques/non critiques ainsi que divers indicateurs de performances (Key Performance Indicator).

Evidemment, le SLA n’est pas suffisant pour assurer la continuité de service, il faut aussi s’assurer que les manuels d’exploitation soient corrects et toujours à jour, que votre plan de récupération sur désastre (Disaster Recovery Plan) existe, et soit testé au moins chaque année. Ensuite, que les sauvegardes soient faites et stockées dans un lieu sûr. Et enfin, que les équipes opérationnelles soient correctement formées et disponibles 24/7.

Outils et Techniques

Les outils communément utilisés sont AIX HA-CMP, Sun Cluster, Heartbeat (Open Source), Cisco Load Balancers, EMC² filers, Network Appliance, etc…

Et enfin certaines techniques pour rendre un système Hautement disponible:

• Load Balancing
• Reverse Proxy
• Clustering
• Virtualization
• Failover

Je n’entre pas maintenant dans le détail de chaque technique car elles seront sujettes à de prochains articles.