Duquesne Group Duquesne Group

English version
Recherche et Analyse

Pour éclairer les décideurs dans le domaine de la Continuité d'Activité et de la Sécurité de l'Information, Duquesne Group propose ses analyses et réflexions issues de ses réalisations concrètes en clientèle. Observation critique du terrain par nos experts, contacts permanents avec les principaux acteurs du domaine et expérience vécue dans nos missions de conseil sont nos principales sources. Contactez-nous pour en savoir +
French version
Research

To support decision makers in the management and optimisation of information systems, Duquesne Group delivers in-depth analyses of information technologies, their implementations and their markets. Our research is based on critical observation of the market by our analysts and their on-going contacts with the vendor community, together with hands-on, practical experience from our consulting work. Contact us to find out more


Architecture technique et continuité : généralités


L’étude des capacités d’une infrastructure à permettre la continuité d’activité aborde en général un certain nombre de points. Cet article les présente succinctement.



E.Besluau
E.Besluau

Des architectures au comportement différent

Les architectures techniques pratiquées depuis longtemps peuvent se classer en deux catégories au comportement très différent en cas de sinistre :

  • Les architectures monolithiques dans lesquelles une vision unique sur l’ensemble des données d’un lot applicatif est nécessaire. Il est impossible de répartir les données sur deux sites qui en traiteraient chacun la moitié par exemple. Il faut qu’une mise à jour réalisée sur l’un des sites soit aussi faite sur l’autre dans des délais compatibles et de manière coordonnée. Les temps d’exécution de ces copies à distance doivent être très faibles pour ne pas pénaliser l’ensemble. Les machines travaillant en quelques millisecondes, l’éloignement entre deux sites synchrones ne pourra dépasser une distance de l’ordre de cinquante kilomètres au grand maximum (voire beaucoup moins, en fonction des durées de traitement souhaitées). Sinon, il faut renoncer au synchronisme et accepter un décalage dans la mise à jour. Des techniques qui consistent à regrouper les écritures par lots diminuent un peu les contraintes en introduisant un décalage de mise à jour.

  • Les architectures granulaires, dans lesquelles des données à pertinence locale sont réparties sur des batteries de serveurs interchangeables utilisés chacun par un nombre restreint de personnes. Si un serveur tombe en panne, les utilisateurs sont reconnectés sur un autre du même site ou d’ailleurs ; la seule contrainte est que le réseau sache router les utilisateurs au bon site. Les data centres dans ce cas peuvent être plus éloignés et leurs besoins de synchronisation sont moins élevés.

Toute entreprise pratique ces deux types d’architecture et une exploitation courante mélange les deux situations à des degrés divers. Les entreprises qui manipulent de gros volumes de données sensibles (les banques et compagnies d’assurance) sont plus traditionnellement portées vers les architectures monolithiques et nécessitent donc des tenues de données redondantes pour partie synchrone et pour partie asynchrone.

La problématique du couplage

Ajoutées à ces aspects, des considérations sur le couplage de systèmes différents ayant à travailler ensemble peuvent avoir de l’influence. On distingue en effet deux types de couplage :

  • Le couplage étroit entre deux systèmes qui doivent partager des actions communes et doivent s’attendre mutuellement, comme les clusters par exemple. Ces systèmes ne peuvent être trop éloignés l’un de l’autre sous peine de dégradations importantes des performances. Ils seront situés à faible distance l’un de l’autre.

  • Le couplage « lâche » entre systèmes qui ont juste à s’échanger des messages avec confirmation ultérieure de bonne réception et traitement éventuel ensuite. Ces systèmes peuvent être plus distants les uns des autres et résider dans des sites ayant 200 km d’éloignement.

Clairement il y a là deux orientations contradictoires : le besoin de synchroniser des données ou traitements sur deux sites pousse à réduire la distance entre ceux-ci, alors que la protection contre les sinistres qui les menacent, voudrait au contraire l’augmenter.

Résilience interne ou réparation facile ?

Face à un besoin élevé de disponibilité d’une infrastructure, deux tactiques peuvent être menées :

  • Diminuer les situations de pannes en rendant davantage résilients les éléments vitaux du site et des divers matériels : doublement des alimentations électriques, protection antisismique par exemple font partie de cette approche. Cette « chasse à la panne » s’arrête là où la panne de mode commun arrive : la chute d’aéronef ou l’attentat mettront à mal de toute façon tout centre même très résilient.

  • Faciliter le redémarrage dans un site de secours acceptable ou sur du matériel prévu pour cela. Il faut alors mettre en œuvre des techniques rapides qui permettent de fonctionner en tout ou partie sur une infrastructure qui n’est pas soumise au même sinistre et présente des caractéristiques correctes pour rendre le service. Différents niveaux de fonctionnement (normal, mode dégradé) sont alors envisageables.

L’entreprise en général cherche à investir de manière équilibrée entre ces deux orientations. Il ne sert à rien de privilégier l’une ou l’autre, les deux sont nécessaires en parallèle. Avoir un site très résilient mais unique ne protège pas de la perte du site par sinistre régional par exemple ; à l’inverse, un site trop peu fiable secouru par un autre centre éloigné poussera à une activation très fréquente et dispendieuse du PRA.

Situations courantes

Pour satisfaire cette double exigence, les bonnes pratiques consistent à développer des infrastructures ayant par exemple les caractéristiques suivantes :

  • Un bon niveau de résilience interne. Le site est ainsi divisé en zones ou cellules dont certaines se secourent mutuellement. Cela permet de pallier localement et rapidement certaines défaillances. Les cellules n’ont pas les mêmes alimentations et climatisations par exemple. Des serveurs en répartition de charge peuvent être dans des cellules distinctes.

  • Des doublements de matériels et de sites de type « campus » qui sont en miroir l’un de l’autre avec un éloignement minime (de quelques centaines de mètres, jusqu’à dix kilomètres) permettant des répartitions de charges sur les deux sites avec un réseau de fort débit ne passant pas sur le domaine public dans certains cas et doublé pour des raisons évidentes de fiabilité.

  • Des sites éloignés d’au moins 10 km l’un de l’autre (mais de moins de 50 km) permettant de limiter les sinistres communs tout en autorisant un bon niveau de synchronisation entre eux. Cette situation est fréquente en région parisienne. Elle se rencontre aussi après des fusions/acquisitions de sociétés qui étaient voisines.

  • Des sites dits « distants » ou « éloignés » équipés de matériels que l’on réserve à une reprise après un sinistre fort survenu sur un site principal ou sur des sites voisins touchés simultanément. L’éloignement des sites doit être suffisant pour se prémunir d’un sinistre régional (plus de 150 à 200 km en général). L’activation est plus lente que pour un site proche, car les données ne sont pas synchronisées, les personnels ne sont pas forcément prêts immédiatement. C’est le rôle du Plan de reprise d’aménager cela.

Les grandes sociétés disposent en général d’une approche double avec d’une part un site très résilient (ou deux sites campus ou voisins) et d’autre part un site distant qui peut d’ailleurs être externalisé chez un tiers.
Emmanuel Besluau
Vendredi 24 Août 2012

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


Duquesne Research Newsletter