Les conditions d’une stratégie de reprise après sinistre pour OpenStack

En cette période où les règles du jeu de l’IT d’entreprise ne cessent d’évoluer, où une nouvelle application naît chaque jour dans le Cloud, il faut prendre le temps de s’interroger sur les difficultés que réservent ces changements et le développement rapide d’applications.

Que faire pour mieux se protéger ? Quelles passerelles entre les technologies bâtir pour se rapprocher des objectifs de niveau de service et de maintien de la disponibilité des charges de travail dans le Cloud ?

La réalité du Cloud hybride

Le développement du Cloud se poursuit à un rythme soutenu, et permet de trouver un équilibre entre les opérations sur site et dans le Cloud.
Les entreprises souhaitent conserver en interne une part importante de leurs ressources IT, mais dès lors qu’elles envisagent de se doter de Clouds privés combinant ressources sur site et ressources hébergées en Cloud privé ou public, elles requièrent aussi de nouvelles capacités, notamment en matière d’automatisation du provisioning et d’administration hybride. Parmi ces capacités figure le maintien de la continuité de l’activité et de la disponibilité des services en cas de sinistre risquant d’entraîner la perte totale d’un datacenter (inondation, tornade, ouragan, incendie, etc.).

Les passerelles de la reprise après sinistre

Pour se préparer au pire, il faut réfléchir aux conditions de restauration de l’infrastructure technologique en cas de sinistre. Cela suppose de prévoir une distribution géographique, autrement dit de répliquer les données applicatives dans le datacenter qui servira à la restauration. A cet égard, OpenStack manque encore de maturité. En tant que plate-forme IaaS émergente, de plus en plus adoptée par les entreprises, OpenStack doit évoluer pour supporter plus facilement la reprise après sinistre.
OpenStack devrait proposer un mécanisme comparable au support de la reprise après sinistre ou Disaster Recovery (DR) intégré par de nombreux systèmes d’entreprise, offrir un niveau d’automatisation supérieur, et permettre de configurer ces mécanismes facilement en une solution DR adaptée à la charge de travail.
La reprise après sinistre pour OpenStack est un vaste sujet qui recouvre ce qu’il faut planifier pour que les applications et les services (la charge de travail) exécutés dans un Cloud OpenStack puissent survivre à un sinistre de grande ampleur.
La reprise après sinistre d’une charge de travail est une tâche complexe englobant l’infrastructure, les logiciels et une bonne compréhension de la charge de travail. Pour y parvenir, l’administrateur doit exécuter tout un ensemble d’opérations de configuration pour refléter le fonctionnement quotidien dans un autre environnement.
Pour permettre la reprise de charges de travail hébergées par OpenStack, il faut des API d’activation des composants d’OpenStack (ex. Cinder) et des outils, y compris extérieurs à OpenStack (ex. des scripts), pour invoquer, orchestrer et exploiter ces API spécifiques.

L’objectif

L’objectif est qu’un mécanisme repère et protège les applications et les services, qui constituent un ensemble d’entités OpenStack, également appelé charge de travail hébergée.
Dans ce contexte, le Cloud est l’équivalent de l’équipement physique, et ce n’est pas l’équipement qu’il faut restaurer, mais bien les applications, les services et leurs données.
Un mécanisme de reprise distinct doit veiller à rétablir la disponibilité du Cloud principal pour qu’il puisse reprendre l’exécution des charges de travail après un sinistre. Le mécanisme de reprise après sinistre des applications et des services se charge alors du basculement retour (fail-back) vers le Cloud principal.
Exemples:
  • Service applicatif exécuté dans le Cloud d’un client, avec reprise sur Cloud hébergé.
  • Service applicatif exécuté dans le Cloud d’un client dans un datacenter #1 avec reprise dans le datacenter #2 du client.
Le plan consiste à fournir une solution pour les applications conçues pour le Cloud selon le concept « Design for Failure », qui sont par nature sans état, ainsi que pour les applications traditionnelles qu’il faut stocker et dont il faut suivre l’état.

Une stratégie de reprise après sinistre devrait prévoir :

  • la capture des métadonnées de la pile de gestion du Cloud, concernant les charges de travail/ressources à protéger : par des instantanés ponctuels des métadonnées ou par réplication continue.
  • la mise à disposition des images VM permettant d’exécuter la charge de travail hébergée sur le Cloud cible.
  • la réplication des données de la charge de travail, au niveau du stockage, au niveau de l’application ou par sauvegarde/restauration.