Dans « Plan de Reprise d’Activité », l’important, c’est le Plan !

Planifier la remise en service de votre système d’information

Le Plan de Reprise d’Activité ou Disaster Recovery Plan (également Plan de reprise Informatique) est un ensemble de processus et de procédures documentés, visant à assurer la remise en service dans des conditions acceptables du Système d’Information de l’entreprise. Ce plan fait généralement partie d’un autre ensemble de mesures : le Plan de Continuité d’Activité ou Business Continuity Plan, qui ne se limite pas forcément à au système d’information, et qui tente lorsque cela est possible de prévenir toute interruption des processus métiers critiques.

Dans cette série d’articles, nous évoquerons divers outils, risques et processus pouvant être rencontrés lors de la mise en place d’un PRA/PCA, l’objectif étant d’arriver à un compromis {mitigation du risque  / coût de fonctionnement / complexité de mise en œuvre} adapté au besoin de votre entreprise en termes de poursuite d’activité.

Episode 0 : La sauvegarde des données professionnelles

Conscient des risques encourus par votre entreprise en cas de perte de données, vous avez mis en place un système de sauvegarde, voir même peut être de réplication. Bien entendu, vous contrôlez régulièrement le bon fonctionnement de ce processus, en effectuant des tests de restauration, et cette copie de sauvegarde est externalisée, peut-être via une offre de « Backup as a Service« . Même si vous remplissez tous ces critères, une question subsiste :

Quel est le plan ?

Incendie, inondation, coupure de courant prolongée, dégradation ou vol de matériel serveur … Quelles procédures suivront vos équipes en cas d’incident majeur ? Quel plan de reprise mettrez-vous en place afin de poursuivre votre activité ?

– Allez-vous prier pour que vos fournisseurs soient en mesure de vous livrer du matériel de remplacement sous 24h ?

-Vos équipes transporteront-elles ce qui reste de votre système d’information jusqu’à un site de repli, dans le coffre de leurs voitures ?

-Devrez-vous reconfigurer manuellement l’ensemble de votre réseau sur le second site ?

-Une fois le site principal remis en service, comment allez-vous y retransférer les données ?

Episode 1 : Azure Site Recovery, un outil au très fort potentiel pour le PRA

Peut-être avez-vous déjà été impressionné  (sans pour autant être surpris) à la lecture d’un article  sur le Plan de Reprise d’Activité informatique d’un groupe bancaire international : réplication synchrone inter-datacenter, infrastructures entièrement doublées, bascules automatisées en cas d’incident … Un magnifique projet se chiffrant souvent à plusieurs dizaines de millions d’euros, et même si le résultat vous a laissé rêveur, vous estimez que ce type de sécurisation n’est pas à la portée d’une structure plus modeste …

Et pourtant, parmi la cinquantaine de services disponible sur la plateforme Azure de Microsoft, il en est un qui prétend vous permettre d’approcher un tel résultat (réplication, automatisation, planification, vérification, …) : Azure Site Recovery.

Trois entités participent ici à la réplication des données :

L’infrastructure de l’entreprise contenant les données sources :

-Serveurs Hyper-V 2012R2 Cloud privé Hyper-V + System Center 2012R2

-Infrastructure VMWare ESXi avec ou sans vCenter

-Serveurs physiques Windows ou Linux

Une infrastructure de destination :

-Cloud Privé Hyper-V/SystemCenter chez un hébergeur

-Cloud Privé Hyper-V/SystemCenter sur un autre site de l’entreprise

-Infrastructure VMWare sur un autre site de l’entreprise

-Cloud Public Microsoft Azure

Un moteur d’orchestration pour la réplication et la gestion du basculement : Azure Site Recovery

La technologie de réplication des données dépend de l’infrastructure source :

-Hyper-V Replica pour les infrastructures de virtualisation Microsoft, disponible dans Windows Server 2012/2012R2

-InMage Scout pour les infrastructure VMware, intégré dans Azure suite à l’acquisition par Microsoft d’InMage en 2014

Une fois les infrastructures principale et secondaire reliées à Azure Site Recovery, celui-ci propose d’établir des équivalences (« mapping ») entre la source et la destination, telles que :

-VLAN 10 « Management » de l’entreprise = Virtual Network 10 « Management » sur Azure IaaS

-Seules les machines virtuelles du cloud privé « Enterprise_BusinessCritical » seront répliquées vers le site distant, dans le cloud privé du provider « Openhost_ Enterprise_BusinessCritical »

La majeure partie des opérations de bascule est ainsi planifiée/automatisée à l’avance, et leur configuration peut (et doit) être vérifiée par de très simples « test failover » qui n’ont bien sûr aucun impact sur la production. En fonction des besoins, il est par exemple possible de réserver à l’avance des adresses IP publiques, qui seront attribuées à certaines machines virtuelles en cas de bascule, ce qui évite d’avoir à mettre à jour les procédures (ex: Url du portail web de secours) le jour J.

Les scénarios techniques actuellement supportés par Azure Site Recovery :

–Cloud Privé d’entreprise Hyper-V/SystemCenter vers Cloud Privé Hyper-V/SystemCenter chez Openhost

–Cloud Privé d’entreprise Hyper-V/SystemCenter vers Cloud Public Microsoft Azure géré par Openhost

–Machines virtuelles Hyper-V (sans System Center) vers Cloud Public Microsoft Azure géré par Openhost

–Cloud Privé d’entreprise Hyper-V/SystemCenter vers Cloud Privé d’entreprise sur second site physique

–Infrastructure VMware principale de l’entreprise vers infrastructure VMware secondaire

–Infrastructure VMware vers Cloud Public Microsoft Azure géré par Openhost

J’ai un projet de PRA

Les données répliquées restent en France

Point important : si les infrastructures de source et de destination sont toutes deux situées en France, alors vos données ne transitent pas en dehors de l’hexagone, et seules les métadonnées (nom et caractéristiques des machines virtuelles à répliquer, plan d’adressage, état de la réplication, etc …) sont envoyées vers le Cloud Public pour y être analysées par Azure Site Recovery et ainsi orchestrer les opérations.

La réplication chez un hébergeur limite le coût à celui du stockage

Le fait d’utiliser le datacenter d’un hébergeur ou le cloud public Azure comme site de repli permet de faire des économies importantes : pas besoin de doubler vos acquisitions de matériel pour déployer une infrastructure de secours qui – on vous le souhaite – ne servira que lors des tests. Dans ce type de scénario, seul le coût du stockage est à supporter ou presque, car le « compute » (CPU+RAM) n’est sollicité qu’en cas de besoin.

En espérant que ce premier épisode vous ait permis d’entrevoir les possibilités offertes par Azure Site Recovery, nous étudierons par la suite des scénarios de déploiement concrets ainsi que les mécanismes à maîtriser pour réussir ce type de projet.

Je souhaite en savoir plus sur le PRA

Arthur GERARD

Partageant mon temps entre l’architecture des systèmes internes d’Openhost et l’accompagnement de nos clients dans la conception de leurs projets Cloud, je suis en recherche permanente d’innovations pour accroitre performance et disponibilité. Infrastructure as a Service et Software-Defined Datacenter sont mes thèmes de prédilection.

Articles similaires :