Dans la partie précédente nous avons mis en place nos réplications et vu comment les surveiller. Maintenant, nous allons explorer les possibilités de récupération de nos machines virtuelles.

Pour rappel, dans notre scénario nous avons deux sites (un de production, un de secours), et chaque site dispose d’un vCenter et d’une appliance de réplication. Nous nous placerons donc sur le site de secours pour récupérer une machine virtuelle du site de production. A l’issue de la récupération, nous remettrons en route la réplication normale (production vers site de secours) en tirant parti des fichiers disque déjà existant sur le site de secours pour éviter une nouvelle réplication complète. C’est parti !

Récupération d’une machine virtuelle

On se connecte donc au vCenter du site de secours pour effectuer la récupération, puis on va dans vSphere Replication, Surveiller, Réplications entrantes, on clic droit sur la machine à récupérer et finalement, on choisit Récupération…Nous avons maintenant deux possibilités  :

• Synchroniser les modifications récentes : cela permet de redémarrer la machine de récupération avec les toutes dernières données présentes sur la machine de production. Cela semble être un bon choix, mais il y a des contraintes :
  • La machine de production doit être accessible : si vous vous trouvez dans un scénario de reprise après sinistre, il est probable que ce ne soit pas le cas. Autant tester dans les plus mauvaises conditions possibles.
  • La machine de production doit être arrêtée : si vous effectuez un test de reprise en heures ouvrées, cela va évidemment poser problème.
• Utiliser les données disponibles les plus récentes : dans ce cas on effectuera la récupération de la machine sur la base des données disponibles sur l’appliance de réplication. C’est probablement la cas qui sera activé en cas de sinistre.

La première option trouvera donc son utilité dans le cas d’une bascule de site planifiée, comme pour une longue maintenance électrique ou un déménagement. Dans les cas non planifiés on sera le plus souvent confronté au second cas. C’est le choix que nous allons retenir pour la suite de la récupération.Nous allons ensuite choisir où restaurer la machine virtuelle. Nous sélectionnons notre datacenter, puis l’hôte qui exécutera la machine récupérée. La restauration est alors prête à démarrer. Vous pouvez cocher la case Mettre la machine virtuelle sous tension… si vous le souhaitez, puis cliquez sur Terminer.Comme il n’y a finalement qu’à enregistrer la machine virtuelle, l’opération est quasi instantanée et dans les secondes qui suivent notre machine démarre avec succès.

Il faut cependant savoir que par défaut la machine récupérée n’est pas connectée au réseau, on n’effectue donc à ce stade qu’un test de récupération du système d’exploitation. Pour faire un vrai test applicatif, il faudra arrêter la machine de production, connecter la machine de test au réseau et tester les applications, mais cela dépasse le cadre de cet article.

Quoi qu’il en soit, notre test de restauration est donc (au moins pour la partie système) un succès. Et maintenant ?

Retour à la normale

Lorsque vous avez récupéré une machine virtuelle, le système de réplication s’est automatiquement désactivé pour cette VM. Même après avoir arrêté la machine récupérée, la réplication restera arrêtée. Il est donc indispensable de remettre le système en route.

La première possibilité, la plus simple, est de supprimer complètement la machine récupérée, sa réplication, et de créer une nouvelle réplication comme nous l’avons vu dans l’article précédent. Cela serait cependant un peu dommage ! En effet, les données de la machine récupérée peuvent servir à limiter le trafic réseau de la réplication initiale. C’est cette possibilité que nous allons explorer ici.

Nous démarrons immédiatement après le test de récupération : notre machine récupérée est encore allumée ; commençons par l’éteindre (clic droit, Arrêter le SE client). Puis nous allons la supprimer de l’inventaire (clic droit, Toutes les actions vCenter, Supprimer de l’inventaire). Évidemment, ne choisissez pas de supprimer du disque, il ne resterait alors plus de données pour accélérer la réplication initiale :).

Retournez maintenant dans vSphere Replication, mais sur le site de production (dans vSphere Replication, Surveiller, Réplications sortantes). Vous voyez notre VM de test dans l’état Récupéré. La seule action que l’on peut faire, c’est d’arrêter cette réplication : clic droit, Arrêter.Cliquez sur OK à la question suivante, où l’on vous dit en substance que la réplication ne peut être supprimée proprement que si les deux sites sont connectés. Cela devrait être le cas chez nous.La machine disparaît alors de la liste des machines répliquées. Vous pouvez aller vérifier dans les Réplications entrantes du site de secours que la machine y a bien été supprimée aussi.

Nous sommes donc revenus au point zéro ? Non, pas tout à fait, car nous avons déjà 99% des données de notre machine de test sur le site de secours ! Pour les exploiter, nous allons créer une nouvelle réplication comme d’ordinaire, mais activer ces données lorsque nous en aurons l’occasion.

Nous démarrons donc à partir de notre VM, clic droit, Toutes les actions vSphere Replication, Configurer la réplication. La procédure est alors la même que celle décrite dans l’article précédent jusqu’à l’étape 4, Emplacement cible.

A cette étape, il va falloir sélectionner le même datastore que précédemment (c’était notre volume local), puis cliquer sur Parcourir pour aller pointer vers le dossier où se trouve les données existantes. Puis OK.Vous devriez alors avoir le message suivant. C’est exactement ce que nous voulons ! Cliquez sur Oui.Vous pouvez alors terminer l’assistant comme vous en avez l’habitude (activation de VSS si possible, définition du RPO et d’éventuels snapshots). Puis vous pouvez terminer l’assistant. La réplication initiale démarre alors, mais en s’appuyant sur les données déjà existantes sur le site. Cela devrait être beaucoup plus rapide :Remarquez au passage que cette méthode pourrait également être utilisée si vous devez répliquer une très grosse machine virtuelle entre deux sites : copiez les données de la machine source sur un disque externe que vous enverrez au site de destination, puis copiez les données sur le stockage de destination. Puis, reprenez les étapes précédentes pour ne répliquer que les différences !

Conclusion

Dans cette série d’articles nous avons vu comment déployer et configurer vSphere Replication, comment configurer des réplications et les tester, puis comment rétablir une réplication interrompue par un test de récupération.

Nous avons vu également que vSphere Replication est un produit assez souple, qui permet de nombreuses topologies de réplication et peut aller jusqu’à couvrir un scénario de reprise après sinistre pour un site complet. Pas mal pour un outil “gratuit” ! (vSphere Replication est inclut dans presque toutes les versions de vSphere).

Cependant, dans un environnement de plus grande taille, les limitations de l’outil apparaîtront : pas d’automatisation et de personnalisation de la reprise (par exemple par un changement automatisé de l’adresse IP), pas de retour arrière intégré, pas de possibilité de répliquer des LUNs complètes… Vous pourrez alors vous tourner vers SRM (Site Recovery Manager) pour combler ces lacunes, mais pas au même prix !