Duquesne Group Duquesne Group

English version
Blog des experts

Les avis et les commentaires exprimés dans les blogs sont ceux des experts individuels. Ils ne représentent pas nécessairement l'opinion du cabinet. Contactez-nous pour en savoir +
French version
Blogs

In these blogs, individual experts freely express their own opinions and comments. They do not necessarily reflect the opinion of the firm. Contact us to find out more


Reprises informatiques en cas de sinistre : tout n'est pas possible


En cas de sinistre d'un ensemble informatique, la manière de redémarrer les applications va dépendre de nombreux paramètres techniques.

Certains paramètres dépendent de choix technologiques, mais d'autres, plus subtils, sont la conséquence d'accumulation de manières de faire au fil des décennies.

Voici quelques considérations et remarques...



D.R.
D.R.

Le classement des reprises possibles

Les tactiques de reprise en cas de sinistre ont beaucoup évolué, car les technologies matérielles et de middleware offrent une multitude de solutions implémentables de diverses manières dont peuvent bénéficier tout ou partie des applications.

S’il est difficile de tirer des règles générales, on peut néanmoins constater différents niveaux de reprise en cas de sinistre :

  • La bascule quasi immédiate d’un nœud de cluster d’un site sur un autre nœud (d’un site suffisamment voisin) : lorsqu’un serveur sur un site est indisponible, le système bascule la charge concernée sur le nœud-serveur de l’autre site. Cela suppose que les connexions au réseau et au stockage le permettent, ce qui peut être impossible en cas de gros sinistre.

  • La bascule en quelques minutes (ou dizaine de minutes) : des manipulations par des exploitants sont nécessaires pour réveiller des tâches en veille ou pour appliquer des logs de mise à jour sur un équipement semblable à celui qui est devenu indisponible. Il faut agir vite (et détecter vite le problème). Pendant dix à vingt minutes les applications sont indisponibles. La perte de données peut rester minime voire nulle. Ces activités peuvent pour partie s’automatiser.

  • La bascule en quelques heures (typiquement quatre ou six heures) : dans ce cas, il faut récupérer des machines qui ont été prévues pour cela, finir de les configurer, réajuster les écarts de logiciel si besoin et récupérer un niveau acceptable de données, suffisant pour travailler. C’est typiquement la situation lors d’une reprise sur site distant (plus de 150 km) déjà préparé pour cela avec accès rapide à des matériels convenables et mise à disposition efficace des sauvegardes de données appropriées.

  • Enfin, la situation la plus longue : bascule au bout d’une à deux journées voire plus, lorsque le degré de préparation des éléments techniques est faible ou que le recours aux données est lent ou problématique.

Ce temps variable qui s’écoule entre le moment de l’indisponibilité et la récupération d’un service informatique « acceptable » est souvent appelé RTO (recovery time objective). On notera qu’acceptable dans ce contexte ne veut pas dire identique à celui qui prévalait avant le sinistre. En particulier les données sur lesquelles les applications travaillent peuvent ne pas être totalement à jour et nécessiter divers traitements automatisés ou manuels pour revenir au niveau voulu.

Le délai qui s’est écoulé entre la dernière sauvegarde utilisable et le sinistre s’appelle le RPO (recovery point objective) et correspond à un ensemble de données perdues qu’il sera possible ou non de récupérer selon les cas.

Toute exploitation informatique pratique à des degrés divers ces quatre niveaux de reprise, idéalement en fonction de la criticité des applications utilisées.

Attention au comportement des applications

Les applications mises à la disposition des utilisateurs présentent des caractéristiques d’architectures techniques diverses et sont l’objet d’exigences variées en termes de continuité d’activité ou de reprise en cas de panne ou sinistre.

En ce qui concerne les architectures techniques et les fonctions de middleware, on peut rencontrer les situations typiques suivantes présentées à titre d’illustration :

  • Les applications sont ou ne sont pas répartissables sur deux environnements plus ou moins synchronisés et distants.

  • Les applications produisent ou pas des états cohérents de données « points propres » qu’il est possible ou non de conserver et de dupliquer à distance rapidement.

  • Le middleware sous l’application connaît la notion de transaction qui s’applique en entier ou ne s’applique pas et qui peut être routée à distance ou défaite.

Ces exemples montrent qu’une application, selon son architecture technique, pourra (ou ne pourra pas) être répartie sur deux machines en mode actif-actif hébergées sur deux sites campus ou distants de moins de 50 km.

L’architecture technique des applications dicte donc le mode de répartition possible dans les centres et la qualité de la synchronisation. A partir de cet état de fait technique, les délais de reprise sont imposés. Ce délai peut fort bien ne pas convenir aux attentes des utilisateurs.


Des inégalités dans le patrimoine applicatif

De nos jours, toute société dispose d’un riche patrimoine applicatif produit tout au long de ces vingt dernières années, voire plus. Ce patrimoine présente des possibilités techniques variables qui vont déterminer les caractéristiques de résilience et de disponibilité des applications.

Lorsque l’inadéquation entre les capacités technologiques d’une application et l’exigence en termes de reprise est trop forte, l’application doit être reconçue, réaménagée en profondeur ou remplacée par des produits du marché adéquats. Cela ne va pas sans coûts qui peuvent être très élevés.

Le patrimoine applicatif peut ainsi se classer en plusieurs lots :

  • les applications qui pourront être reprises de manière quasiment instantanée ;

  • les applications pouvant reprendre dans un délai de l’ordre du quart d’heure à une heure, après réactivation de données par exemple ou traitement de mise à jour ;

  • les applications qu’il sera impossible de reprendre en moins de quatre heures, avec des traitements assez lourds potentiellement difficiles à faire en cas de sinistre ;

  • les applications impossibles à redémarrer en moins d’une ou deux journée –voire plus- après recours à des sauvegardes et diverses opérations techniques et logistiques.

Les caractéristiques techniques du patrimoine applicatif imposent donc les conditions de la reprise.

Le choix de la répartition sur les différents sites s’en déduit alors par ordre logique : les serveurs nécessaires sur les sites qui conviennent, les différents systèmes de stockage nécessaires, enfin le réseau qu’il faut bien dimensionner pour cela.

Si le degré de disponibilité résultant n’est pas acceptable par les utilisateurs, il faut modifier les caractéristiques techniques en cause pour pouvoir changer les dispositions sur les sites et obtenir les temps de reprise souhaités. Si cela s’avère impossible ou trop coûteux, il faut alléger les exigences sur les temps de reprise et les allonger.


Le casse-tête des échanges entre applications

Il est très courant que des applications échangent des données entre elles. Si elles ne reposent pas sur la même base de données, c'est même obligatoire.

Cette situation se rencontre aussi lorsqu'un ensemble d'applications maison a été remplacé par un progiciel du commerce qui devient alors un "dépôt de données" pour beaucoup d'applications anciennes ou récentes.

On peut alors aboutir à une situation où une application capable de redémarrer très vite suite à sinistre est malgré tout bloquée car elle attend des données d'une application qui ne pourra redémarrer que dans deux jours...

Par ailleurs, le système qui assure les échanges doit être très méticuleux et fiable...sinon sa perte et son redémarrage brouillon poseront d'énormes problèmes de consistance des données.

Les applications qui échangent entre elles se trouvent embarquées dans la même galère.

Conclusion : un vue d'ensemble est nécessaire

Pour assurer une bonne capacité de reprise aux applications, il ne suffit pas d'avoir des clusters actifs-actifs à certains endroits, même si cela y contribue.

Il est important de construire et maintenir une vue globale sur le patrimoine applicatif en se posant quelques questions :

  • comment découper et former des ensembles applicatifs relativement autonomes et capables de redémarrer dans des conditions aisées avec un RTO acceptable ?

  • quels sont les échanges de données vitaux à sécuriser avec une plate-forme solide et propre ?

  • existe-t-il des modes de fonctionnement permettant de soulager l'utilisateur en cas de sinistre ? (par exemple fonctionner d'abord en lecture seule,...)


Tout ceci ne s'improvise pas !

Emmanuel Besluau
Mercredi 22 Mai 2013

Home Home    Mail Mail    Print Print    Zoom + Zoom +    Zoom - Zoom -    Share Share


Articles du même auteur :

Halte aux PCA bidons ! - 19/01/2014

1 2