Bonjour,
VMware a proposé un produit d’aide au DRP, dès sa version 3, avec la solution VMware Site Recovery Manager.
Les Virtuals Machines étant composées de simples fichiers, potentiellement, si l’on réplique l’espace de stockage, sur lequel sont posées les VMs, on va les retrouver sur le site distant.
La problématique de ce concept est d’inscrire les vmdk et vmx sur les serveurs du site distant, les volumes répliqués étant souvent en modes restreints.
Une marche à suivre, pour présenter les Datastores et naviguer à l’intérieur, pour renseigner les VMs est envisageable pour moins de 30 VMs, mais lorsque l’on en a 300 VMs, ça devient compliqué.
SRM permet de coordonner les inventaires des vCenter et communiquer avec les baies de stockage afin de valider la réplication de la VM et présenter les Datastore et VMs, aux ESXi du site DR, en cas de DRP.
Cette solution exige quelques prérequis :
- Un vCenter par site avec le Plug-in SRM installé (exige une DB et des licences séparées pour SRM)
- Un DC sur le site distant
- Les licences de réplication et de tests sur la baie de stockage.
- La compatibilité avec la baie de stockage et le Storage Replication Adapters (SRA)
Voici la liste de compatibilité avec les baies.
http://www.vmware.com/support/srm/srm-storage-partners.html
Pour la procédure de configuration:
On installe le plugin SRM sur les deux sites.
On renseigne les deux vCenter dans SRM, afin qu’ils puissent s’échanger leurs informations et communiquer.
Mapper les différents éléments d’inventaires (Ressources, Folder, Network), présenter un placeholder Datastore qui hébergera les vmx temporaire des VMs protégées.
Installer les SRA adapté à la baie et connecter chaque sites avec les baies de stockage. (Pour la partie vSphere Replication, un article va suivre)
On va pouvoir dès lors créer les Protections Groups, composés des VMs à protéger sur le site primaire et les Recovery Plan sur le site DR. SRM offre la possibilité, dans le Recovery Plan, de configurer un ordre de redémarrage des VMs, afin d’être certain d’une reprise d’activité optimisée et exigent un minimum d’action humaine.
Selon l’infrastructure réseau du client, les subnet ne sont pas toujours identiques sur les deux sites, ce qui empêche les VMs de communiquer lors de l’utilisation de SRM.
Une des forces de ce produit est de pouvoir simplement modifier l’adresse IP des VMs, lors du redéploiement sur le site distant, afin d’avoir une infrastructure compatible avec les subnets. Dans les versions précédentes de SRM, il fallait utiliser des fichiers CSV de réponses, pour renseigner ces nouvelles IP, mais avec SRM 5 l’intégration est simple et est configurée au niveau des propriétés avancées de la VM.
Une fois que votre plan de reprise est prêt, vous avez deux possibilités, le jouer le Recovery Plan ou de le tester.
La fonctionnalité de test va vous permettre de recréer votre infrastructure protégée, dans une bulle isolée de votre réseau d’entreprise. Cette bulle peut avoir un vSwitch créé à la volée lors du test et supprimé à la fin, ou on peut lui assigné un VM port group avec un VLAN séparé, afin de faire un test avec des desktops connecté sur ce VLAN dédié.
Attention d’avoir toutes les licences permettant les tests sur votre baie. NetApp exige le FlexClone pour présenter les VMs sans casser la réplication.
Selon le constructeur de la baie, il est possible d’automatiser le Failback des VMs ou d’inverser la réplication, une fois la cause de DR résolue, mais cela n’est pas le cas de tous les constructeurs.
Cet outil est, je trouve, très puissant dans ses fonctionnalités mais surtout dans sa simplicité de configuration et d’utilisation. Pour avoir eu l’occasion de l’implémenter chez plusieurs clients, il a toujours donné de bons résultats. Il faut tout fois faire très attention dans la validation de l’architecture, avec les baies de stockage car l’oubli de licences peut faire mal financièrement.
Autre révolution avec SRM 5 est dans le faite qu’il peut également répliquer par lui-même les VMs, à l’aide de vSphere Replication, fonctionnalité que je présenterai dans mon prochain article.
Bon DRP
Pingback: VMware Site Recovery Manager (partie 2) |