Bonjour,
Suite aux articles introduisant les notions de DRP (ici) et sur Site Recovery Manager (ici), je vais aborder les nouvelles fonctionnalités de SRM 5.
Comme indiqué dans l’article précédent, VMware a offert une solution de réplication, intégré à SRM, permettant de se détacher de toutes contraintes liées aux baies de stockage et leurs réplications propriétaires.
A l’aide de vSphere Replication, on a la possibilité de répliquer les VMs d’une manière simple sur le site distant, sur n’importe quel stockage local ou partagé.
Cette technologie supportant des environnements jusqu’à 500 VMs est intégrée à toutes les licences SRM. Sympa non ?
Pour mettre en place vSphere Replication, il faut avoir installé SRM, sur chacun des vCenter, avec l’option vSphere Replication activée.
Elle est composée de :
vRA — vSphere Replication Agent
C’est lui qui va manager la réplication du serveur ESXi hébergent la VM, vers le site distant.
Il gère les cycles de réplication (RPO), il transfère les données via le VMkernel, d’une manière non compressée, ni encryptées et utilise la technologie CBT (Change Block Tracking) pour la réplication.
Il est intégré au serveur ESXi
vRS — vSphere Replication Server
C’est une Virtual Appliance déployé et configurée à travers SRM. Elle permet de récupérer le trafic répliqué depuis le Protection Site. Une fois reçu, il va écrire les blocks dans le VMDK de la VM à l’aide de Redo logs pour la consistance (1 point de consistance par VM). Max 100 VM par VRS sinon il faut augmenter la mémoire à 1 GB.
vRMS –vSphere Replication Management Server
C’est une Virtual Appliance Linux managée depuis SRM (1 par vCenter). Elle permet de manager les vSphere replication, la création de test et failover et le mapping des disques protégés avec les VMDK du site distant.
Les bases de données
Le vCenter, SRM et VRMS ont chacun besoin d’une base de données (SQL, Oracle, DB2)
Une fois que tous ces éléments sont mis en place et communiquent, il n’y a plus qu’à faire un clic droite sur la VM que vous voulez protéger, sélectionner vSphere Replication et suivre le Wizard.
Simple non ?
Il faut juste décider du RPO (minimum 15, minutes maximum 24h), sur quel datastore du site distant on va la répliquer, quel vR Server on utilise
La première chose que la vSphere Replication fait et une “full synch” qui permet de copier l’entier des VMDK des VMs protégées. En principe cela ne se passe qu’une seul fois.
C’est alors que le vRA et le vSCSI filter, intégrés au VMkernel, prennent le relais, afin de tracer les I / O et maintenir un bitmap en mémoire, des blocs modifiés et écrit dans un ” persistent state file ” (. psf ) intégré au répertoire de la machine virtuelle. Ce fichier ne contient que des pointeurs vers les blocs modifiés. Quand il est temps de répliquer les modifications, sur le site distant, un paquet est créé avec les blocs qui ont été modifiés, afin d’être poussées vers le site distant, pour y être intégré dans le vmdk.
SRM outil de migration
Une autre nouveauté, dans SRM 5, est le faite de pouvoir utiliser cet outil comme aide à la migration.
Imaginez que vous rachetez une petite boite qui avait déjà de la virtualisation et que le but est de rapatrier ces VMs sur le site principal. Évidemment les baies ne sont pas du même constructeur ou compatibles, bref ça risque d’être un projet compliqué… et bien non !
Vous mettez en place SRM avec vSphere Replication, vous répliquez les VMs sur votre site principal et le jour où vous décidez de faire la migration, vous utilisez la fonction ‘’Planned Migration’’.
SRM va arrêter les VMs, sur le site distant, faire une dernière réplication pour garantir la consistance des données et jouer votre Recovery Plan, afin de remonter vos VMs sur le site principale. Simple non ?
Si j’ose dire c’est le second effet Kiss Cool… de SRM.
Comme vous avez pu le lire, cet outil relativement simple d’utilisation, un peu plus compliqué pour la mise en place mais vraiment puissant dans ces possibilités.
Évidemment cela ne remplace pas vos procédures de DRP, qu’il faut quand même mettre en place et les jouer régulièrement, afin d’être certain de la faisabilité de votre DRP.
Bon DRP et migrations.
Pingback: VMware Site Recovery Manager (partie 1) |