Peut-on s'offrir le luxe d'une haute disponibilité là on un secours suffirait amplement ? A contrario, peut-on s'octroyer le privilège de ne pas avoir de secours avec les moyens dont nous disposons aujourd'hui ?
Ces questions, je me les suis souvent pausé avec des responsables de Production ou des exploitants pour arriver à la conclusion que la mise en place d'une solution de secours pour un outil de planification de traitements est un projet à étudier en fonction de ces propres contraintes de Production et de ses moyens.
Disponibilités, Secours et sauvegardes :
Mais avant tout, qu'appelons-nous haute disponibilité, moyenne disponibilité ou secours et quelle est la place de la sauvegarde régulière.
En terme d'ordonnancement de Production, je qualifie de haute disponibilité tout mécanisme qui permet de repartir dans un temps très bref de la situation qui précédait le dernier instant avant un crash.
La moyenne disponibilité laisse plus de latitude sur les deux paramètres. Elle permet d'être plus souple sur le temps de remise en service et d'avoir une plus grande latitude sur le point de reprise (dernier archive log d'une base de données par exemple).
Le secours offre la possibilité de disposer d'un serveur pouvant être activé ou converti dans un délai raisonnable avec une archive des données dont le statut peut-être proche (dernier archive log d'une base de données), éloigné (dernier point de sauvegarde à chaud), ou inexistant (reprise manuelle à partir des définitions).
La simple sauvegarde, ne prévoit pas de serveur de secours. On devra impérativement repartir en cas de sinistre d'un nouveau serveur et d'une restauration complète.
Avant d'associer une solution à une problématique de disponibilité d'un ordonnanceur, il nous faut étudier de près les causes d'un incident de Production. Seul le ou les moteurs d'ordonnancement sont impactés. En effet, pour les solutions offrant des serveurs de GUI, la haute disponibilité est un luxe qui n'a pas de nécessité. Sauf, si ceux-ci sont les seuls moyens d'administration de la Production. De même, pour les produits fonctionnant en relation maître/agent, la disponibilité de l'agent sera calquée sur celle du serveur applicatif qu'il pilote.
2 types de désastres :
Un incident de production sur le moteur d'ordonnancement peut être de deux types :
- Celui que j'ai plus haut appelé un crash et qui représente une indisponibilité hardware du serveur ou un disfonctionnement majeur du système d'exploitation.
- L'autre est une corruption des données de l'ordonnanceur. Cette dégradation pouvant être la cause : d'une erreur humaine ou d'une malfaçon, d'un disfonctionnement du logiciel d'ordonnancement ou d'un disfonctionnement du gestionnaire de bases de données.
Il faut donc mettre en œuvre une solution de secours prenant en compte ces deux types de situations. Car, il est évident que les mécanismes de haute disponibilité ne sont valables que lors d'un crash, ils perdent leur intérêt pour une corruption de base de données. En effet, disposer de la dernière image des données corrompue ne permettra pas réparer la panne. On devra faire appelle à une archive permettant de rétablir une situation avant corruption.
Je vous laisse réfléchir à ces notions et nous reprendrons dans quelques jours ce dossier, afin de voir quels sont les liens qui lis la qualité de service à la notion de disponibilité, quelles sont les solution dont nous disposons aujourd'hui et nous essayerons d'aborder quelques conseils de mise en œuvre.
