Notion de disponibilité des systèmes

La notion de disponibilité des systèmes est un terme employé dans le monde informatique à propos d'architecture de systèmes (ou d'un service) pour désigner le fait que ces architectures (ou ce service) ont un taux de disponibilité en adéquation avec ses activités. La disponibilité est donc la possibilité d’utiliser l’ensemble des services de façon normale et continue, sans coupure de service.

L’absence de notion de haute disponibilité (HA, « high availability ») d’un système peut se traduire par des discontinuités de service à chaque défaillance (logicielle ou matérielle) et un besoin d’intervention humaine pour remettre le système dans un état stable et fonctionnel.

L’administrateur système et réseau (ASR) doit intervenir pour rechercher la cause du dysfonctionnement et prendre les mesures appropriées, comme par exemple :

Redémarrer les processus arrêtés, en restaurant l’état du logiciel ;

Contacter les services de support des logiciels défaillants, en cas de bug ou de limitation manifeste et reproductible ;

Reconnecter les machines ou remplacer les pièces matérielles défectueuses.

Le plus souvent, cette analyse de problème est consolidée par des actions correctives pour éviter tout nouveau dysfonctionnement identique. Ce sont des mesures principalement curatives.

A l’inverse, l’établissement d’un plan de HA est constitué d’un ensemble de mesures préventives visant à anticiper ce type de problème, généralement par plusieurs évolutions dans l’organisation. Ces évolutions consistent essentiellement à détecter les points de défaillance du système et à les réduire par la mise en place de techniques de redondance et/ou de réplication.

Mesure et estimation de la disponibilité

La discontinuité de service peut durer jusqu’à plusieurs heures selon la gravité du dysfonctionnement et affecter le temps de disponibilité du service rendu. On peut mesurer la disponibilité d’un service ou d’un système avec un pourcentage basé sur des mesures annuelles.

Ce taux de disponibilité d’un système ou d’un service s’obtient en appliquant la relation suivante :

Disponibilité (%) = MTBF / (MTBF + MTTR)

Où : MTBF (mean time between failure) = mesure du temps estimé (ou moyen) entre deux défaillances d’un système donné (fréquence de défaillance du système considéré).

MTTR (mean time to repair) = mesure du temps estimé (ou moyen) pour réparer le système suite à la défaillance.

On obtient donc un pourcentage indiquant le temps d’indisponibilité du système. Cette règle de calcul est connue sous le terme de « règle des ‘9’ » [17] [18], puisqu’on utilise généralement un pourcentage essentiellement composé de '9' pour l’expliquer:

• 99% désigne le fait que le service est indisponible moins de 3,65 jours par an • 99,9%, moins de 8,75 heures par an

• 99,99%, moins de 52 minutes par an • 99,999%, moins de 5,2 minutes par an • 99,9999%, moins de 54,8 secondes par an • 99,99999%, moins de 3,1 secondes par an • etc.

Par exemple, un service qui aurait dysfonctionné pendant deux heures durant l’année écoulée (8766 heures) aurait un taux de disponibilité de :

8766 / (8766 + 2) = 0,999 soit 99,9 %

Il faut cependant replacer le résultat obtenu dans le contexte de chaque entreprise et les mettre en adéquation avec les besoins de l’entité. Une interruption de service pendant quatre heures dans un laboratoire de recherche n’a pas le même impact que pour une chaine de production fonctionnant à flux tendu.

Indicateurs

Pour évaluer l’impact des dysfonctionnements dans l’environnement spécifique d’une entité, on peut s’appuyer sur deux critères : le RTO et le RPO.

Le RTO (Recovery Time Objective) qui est la durée maximale d'interruption admissible. Cet indicateur définit le temps alloué pour effectuer, en cas de dysfonctionnement du système, un basculement vers un nouveau système et une reprise des services.

Le RPO (Recovery Point Objective) qui est la perte de données maximale admissible. Cet indicateur définit l'état (au sens large) dans lequel doit se trouver le nouveau système après basculement et reprise des services. On fixe notamment la perte admissible d’informations que l’on peut potentiellement subir dans l’intervalle de temps où le système de secours permet de retrouver un fonctionnement normal.

Un exemple couramment donné est le cas du secteur bancaire où l’on pourra définir un RTO de 1 heure avec un RPO de 0 secondes, sans mode dégradé. Aucune transaction ne sera ainsi perdue, et le service pourra être disponible sous une heure.

Il faut pondérer ces résultats par le fait que la durée maximale d'interruption admissible varie selon les services. D’une manière générale, plus le RTO sera important et plus le risque de perte de données (RPO) sera élevé.

Cependant, la différence de criticité entre les services impliquera un ordonnancement de la relance des services afin d’obtenir le plus rapidement possible un retour à un fonctionnement normal avec le minimum de pertes d’informations.

Dernier point, mais tout aussi important, l’augmentation de la disponibilité a un impact fort sur le coût de mise en place et de maintenance d’un système en production. Mettre en place une architecture pérenne (redondée, architecture de secours, etc.) est une action qui doit impérativement être adaptée à l’activité et aux besoins de l’entreprise ou du laboratoire. En effet, chaque optimisation aura une incidence significative sur le coût de mise en place du système.

De plus, la redondance de services et la tolérance aux pannes sont des notions essentielles pour nos métiers. Cependant, il s’agit de notions difficilement justifiables d’un point de vue comptable puisque le renforcement de la disponibilité de l’architecture augmente le prix de revient de chaque service sans proposer de services supplémentaires pour l’utilisateur.

Il faut donc trouver un équilibre entre augmentation de la disponibilité et coût de revient des services offerts.

Pour cela, Il fallait estimer le taux de disponibilité cible et évaluer les actions à mettre en œuvre en tenant compte de notre environnement technologique et économique.

Mise en place de la disponibilité dans notre contexte

Pour mettre en place un système à haute disponibilité, il faut généralement établir un plan de continuité d’activité (PCA). Le PCA défini l’organisation que l’entreprise (l’entité) doit mettre en pratique afin d’assurer une disponibilité maximale de son système d’information. Il est propre à chaque entité et doit être développé, maintenu et ajusté en fonction des évolutions de l’environnement de l’entreprise : économique, technologique et politique.

C’est la solution que nous avons choisi d’adopter pour accroître la disponibilité du système d’information du LATT.

N’ayant pas initialement de compétences dans ce domaine, j’ai réalisé une période de veille technologique sur la mise en place de ce type de plan et ai proposé à ma hiérarchie des solutions à déployer dans notre environnement.

Je vais tout d’abord expliquer le cheminement que j’ai suivi et la méthode que j’ai appliquée pour établir le plan de continuité d’activité du système d’information du laboratoire. Je détaillerai ensuite les conséquences organisationnelles et technologiques de mes propositions sur l’infrastructure du système d’information et sur la mise en exploitation de la version.