Quels sont les défis de la reprise après sinistre des machines virtuelles ?
Pour garantir que toutes les machines d'un environnement virtualisé sont correctement protégées dans le cadre d'un scénario de reprise après sinistre, il est important de maintenir un contrôle sur le provisioning des VM. Des VM provisionnées de façon sauvage peuvent en effet échapper au périmètre de DR et causer de gros problèmes ultérieurement.
Bien que la reprise après sinistre (DR) des machines virtuelles change la donne par rapport aux pratiques physiques de reprise après sinistre qui tendent à être lentes et inflexibles, il y a un inconvénient potentiel. La reprise après désastre ne laisse pas de place au hasard. Elle doit être planifiée, gérée efficacement et testée de manière appropriée. Bien que la saisie manuelle des données et des détails nécessaires à la mise en œuvre, à la configuration et à la gestion de la DR virtuelle puisse être simple pour les petits environnements, cette approche devient rapidement plus complexe à gérer dans de grands environnements.
L’un des problèmes inhérents des grands environnements virtualisés est la prolifération des machines virtuelles (VM). Ce qui rend cette prolifération particulièrement insidieuse, est le fait que des VM sont parfois provisionnées sans politique associée et échappent aux règles conçues spécifiquement pour les protéger. Il devient dès lors délicat en cas de sinistre d’appliquer les règles idoines en matière de reprise après sinistre de la machine virtuelle.
Lorsque le provisioning d’une VM échappe aux règles, une grande partie des informations critiques qui seront nécessaires dans une situation de reprise après sinistre d'une machine virtuelle ou même dans le support quotidien n'a pas été collectée et stockée correctement, ce qui rend ces deux tâches plus difficiles.
Protéger correctement les VM en production
Pire encore, il se peut que la machine virtuelle ou le service ne soit pas associé à un plan test de DR. Fréquemment, les administrateurs trouvent des machines de production qui ne sont pas compatibles avec la DR. Il se peut que la documentation et la configuration du DR n'aient pas eu lieu.
Si le gestionnaire de DR n'est pas au courant de l'existence de ces machines, il se peut que cela ne devienne apparent que lorsqu'un scénario de DR réel se produit. Si le groupe d'entreprises ou le propriétaire croit que la reprise après sinistre de la machine virtuelle a été activée et qu'elle ne l'a pas été, cela peut entraîner non seulement une perte de confiance dans le fournisseur, mais aussi un impact financier important.
Les grandes entreprises sont notoirement mauvaises en matière de communication, c'est pourquoi chaque VM de production doit passer par un déploiement complet de production. C'est précisément pour cette raison que les tests d'acceptation par les utilisateurs et les VM de développement ne doivent jamais être réutilisés dans des machines virtuelles de production.
Un processus de déploiement approprié doit permettre de cerner ces problèmes avant qu'ils ne deviennent critiques. Faire cela correctement signifie aussi que les propriétaires des VM sont clairement identifiés, que les coûts sont répartis et qu'il y a une chaîne de commandement et de prise de décision pour la VM.
Ce sont toutes des choses que personne ne veut faire si la reprise après sinistre de la machine virtuelle est réellement nécessaire. Il est dans l'intérêt de l'entreprise de vérifier et de comparer les VM avec les plans de RD à intervalles réguliers. Toutes les machines n'auront pas forcément un plan de reprise après sinistre associé, mais cet exercice permettra justement d'identifier et de corriger ce point. De cela dépend la bonne protection de vos applications et des données de l'entreprise.
