De la disponibilité de l'ordonnanceur et du secours (2ème partie)

Nous avons vu dans la première partie de ce dossier qu'il existait plusieurs niveaux de disponibilité pour fiabiliser une solution d'ordonnanceur de Production informatique. Nous avons aussi constaté qu'un outil de planification de traitements peut être soumis à deux types de désastres le crash (arrêt brutal) ou la corruption de ses données d'ordonnancement. Pour enrichir ce dossier, il nous faut maintenant regarder les relations étroites qu'il existe entre un certain niveau de service (SLA) et la disponibilité de la solution. Ainsi que la pertinence des solutions de secours envisageable par rapport à nos 2 types de désastres.

Niveau de S.L.A. et solutions

Quel niveau de services doit-on garantir aux utilisateurs ? Quelles sont les contraintes de remise en service ? Les réponses ne sont pas les même en fonction des métiers de chacun et les solutions apportées seront donc différentes. On ne gère pas avec les mêmes moyens et les mêmes coûts, une indisponibilité de service d'une demi heure, comme un arrêt de production pouvant atteindre la journée.  Il ne faut  néanmoins pas négliger les 2 types de désastres que nous avons évoqué depuis le début de ce dossier. Car une solution technique peut parfaitement répondre aux besoins pour un type de problème et se révéler désastreuse dans l'autre cas. Ce sont des choix à faire, des risques à prendre dont il faut parfaitement maîtriser l'envergure afin de pouvoir les assumer pleinement.

Quelques Solutions techniques

Les technologies de clusters, de miroir de données permettent d'assurer la haute disponibilité dans le cadre d'un désastre de type "crash". En effet, les clusters O.S. (HP, SUN, IBM, Microsoft, …) permettent de disposer des données à jour de la dernière occurrence et de repartir dans les plus brefs délais. L'ensemble des ordonnanceurs du marché support ce type de technologie.  Si les contraintes sont plus élevées, et afin d'assurer le secours sur un site semi-actif de Secours, il existe des solutions plus élaboré comme les cluster Veritas que permettrons de dupliquer la données non seulement sur un serveur de secours immédiat, mais aussi sur un serveur installé dans un site distant dédié au Plan de Reprise d'Activité. Ces solutions n'apportent aucunes solutions aux problèmes de corruption de données.

Si l'ordonnanceur est appuyé sur une grande base de données du marché, celles-ci disposent dans leur arsenal d'utilitaires de solution de "mirroring". Mais cette technologie vie grossir la liste des moyens évoqués précédemment. Ce qui nous intéressera parmi les outils disponibles avec les bases de données, ce sont les mécanismes d'archives ou de "Re-do". En effet, ils ne permettent pas d'assurer directement une "haute-disponibilté" comme le ferais un miroir, mais le niveau de reprise est assez proche de la dernière occurrence. Et ils permettent surtout de gérer au mieux la reprise sur corruption de données. On pourra en ciblant la bonne archive, reprendre au plus près de l'instant avant la corruption des données.

Les sauvegardes permettent de répondre à certaines problématiques. Elle pourront être utilisée soit de manière régulières (une à plusieurs par jour) ou en utilisant le mécanisme de points de reprise qui consiste à réaliser des sauvegardes à chaud à des heures précises (fin des sauvegardes, ouverture ou fermeture de TP, …) ou à l'issue du bon déroulement d'une chaîne de traitements.

Si les contraintes ne sont pas élevées en terme de reprise d'activité, une simple sauvegarde journalière des environnements et des définitions d'enchaînements de traitements peut permettre de reprendre la main sur sa production dans un délai bien souvent inférieur à 24 heures, mais parfois au prix de gros efforts.

Des exercices réguliers  de secours

La mise en place d'un plan de secours comportant une architecture adaptée, des procédures testées et approuvées n'est rien sans la pratique. Les équipes tournent, le cerveau humain oubli et même si les procédures sont très détailler, rien de vaut des exercices réguliers permettant de simuler les 2 types de désastres que nous avons évoqué le crash et la corruption de données.

De la disponibilité de l'ordonnanceur et du secours.