Accueil > SRM > vSphere Replication dans SRM
Août/12140
Par Commenter Dans SRM

Avec pas mal de retard, voici une synthèse de la session que j’ai présenté au PEX 2012 sur la partie vSphere Replication.

La réplication software asynchrone appelée « vSphere Replication » est apparue avec la version 5.0 de SRM. Les VMs peuvent ainsi être répliquées quel que soit le système de stockage sous-jacent et même entre des datastores hétérogènes. Il faut pour cela des composants supplémentaires à l’infrastructure SRM.

Les composants VR:

Le VRMS (vSphere Replication Management Server) aussi nommé VR appliance, est l’équivalent VMware de la pile de gestion de réplication de baies. Il fournit la couche de gestion de la réplication: mappe les datastores, configure la réplication coordonne les sites principaux et de réplication, coordonne les réseaux isolés de tests (TestBuble network). On peut avoir seulement 1 VRMS par vCenter. VRMS est fourni en Vitual Appliance et peut être mise à jour par l’interface d’admin de l’appliance ou par UpdateManager. Comme le vCenter et le serveur SRM, VRMS nécessite une base de donnée.
Le Service VR s’exécute dans l’agent de l’hôte (hostd), aussi nommé VR agent. Il met en place la configuration de réplication à la source, l’API VMODL est utilisé pour configurer, reconfigurer ou supprimer la configuration de réplication. Cette configuration de réplication est stockée dans le fichier de configuration de la VM (.vmx). Il gère le processus de réplication des VMs répliquées en planifiant la copie initiale et les deltas des disques, en coordonnant la cohérence de groupe de disques d’une VM et en répliquant les métadonnées de la VM (vmx, vmxf, nvram). Il s’interpose avec les opérations qui peuvent impacter la réplication (power off, supression des disques…).
Le VR Filter (ou vSCSI Filter) s’exécute dans le kernel ESXi, il est associé au périphérique virtuel et intercepte toutes les I/O destinés au disque et suit les zones disques virtuels modifiés. Chaque instance du filtre dispose d’un fichier d’état persistant dans lequel est stocké l’état de modification par rapport à la réplication. L’état en mémoire est effacé s’il y a destruction du périphérique virtuel. Il transfert les données au serveur VR (via TCP) à l’aide d’une interface vmknic. Il implémente la logique nécessaire au maintien de la cohérence.
Le serveur VR masque les informations détaillées du datacenter distant. Tout comme VRMS, il est déployé en Virtual Appliance et peut être mise à jour par l’interface d’admin ou par VUM. Il maintient en interne les relations de connectivité entre les hôtes et les datastores. Il crée et gère les instances de réplication. Il écrit les données sur les hôtes ESX via la couche NFC. Il manipule les disques virtuels via l’API VirtualDiskManager. Plusieurs serveurs VR peuvent être instanciés pour des raisons de disponibilités et d’évolutivité. Un Serveur VR peut gérer jusqu’à 50 VMs répliquées et l’on peut avoir jusqu’à 10 Serveurs VR par vCenter (soit maximum 500 VMs répliqués avec VR). La réplication reste opérationnelle si le serveur VR est disponible même s’il y a défaillance de VC, SRM ou VRMS, c’est pourquoi il est souhaitable de le sécuriser avec HA (voir même FT).

Voici la liste des ports de communication intersites entre les composants:

  • 8095 entre plugin SRM du vSphere Client et serveur SRM
  • 8043 entre plugin SRM du vSphere Client et VRMS
  • 80/443 entre vCenter et serveur SRM de l’autre site
  • 80/443 entre vCenter et VRMS de l’autre site
  • 44046 des Filtres VR vers Serveur VR (transfert en cours)
  • 31031 des Filtres VR vers Serveur VR (trafic initial/synchronisation complète)

Le mécanisme de VR:

Le mécanisme de réplication, synchronise complètement le disque à l’initialisation. Il lit entièrement les disques sources et destinations, compare les blocs (digest) pour créer une carte des différences et transfert uniquement les blocs différents. Ce qui veut dire que pour les gros disques il est possible de positionner manuellement les fichiers à la destination (par exemple restauration de sauvegarde ou transfert physique des disques virtuels sur un disque USB).
Ensuite, on ne transfère plus que les deltas appelés « Light-Weight Delta » (LWD). Ces LWDs sont consistés des deltas de plusieurs disques afin assurer la cohérence des données entre les disques d’une VM à un instant donné. En attendant le transfert des LWDs, les modifications apportées aux disques sources sont enregistrées par ESXi dans un fichier « persistent state file » (.psf).
A la destination, la réplication initiale (full-sync) arrive sur le port 31031 vers le Serveur VR avec échange préalable des checksums entre les 2 sites. Ensuite, la réplication incrémentale (deltas) transfère des LWDs en utilisant le port 44046. A la réception complète des LWDs, les deltas sont consolidés avec des fichiers Redo Log (hbrdisk.RDID.xxxxx) comme pour les Snapshots.
Lors de l’utilisation du mode Test Failover de SRM, la réplication continue de fonctionner. Pour cela, on utilise 2 types de Redo Log: celui du test (hbrimagedisk.RDID.xxxxx) et celui en cours pour la réplication (hbrdisk.RDID.xxxxx).

La technologie utilisée pour constituer les LWDs est comparable un mélange de CBT + Snapshot mais elle n’interfère pas avec l’utilisation de Snapshot ou de sauvegarde utilisant CBT pendant que la réplication est active. Pendant le transfert, les I/Os de la VM ne sont pas impactés.

Les données transférées ne sont pas cryptées lors de la réplication. Il est donc souhaitable d’utiliser un réseau sécurisé (VPN). Les réplications initiales et incrémentales utilisent des ports bien spécifiques, il est facilement possible de prioriser ou de limiter leur trafic avec de la QoS. De plus, des boitiers d’accélération WAN peuvent également améliorer ce trafic.

La configuration des RPO de VR:

La réplication est gérée comme une propriété d’une VM et se configure d’un click-droit via le menu contexte de chaque VM. Cette configuration de réplication est granulaire et par VM. On peut ainsi sélectionner par VM:

  • de répliquer tout u partie des disques,
  • l’emplacement de destination pour les disques cibles,
  • l’objectif de récupération (RPO),
  • le mécanisme utilisé pour la consistance du guest OS

Lors de la configuration de la réplication (asynchrone) d’une VM, on définit le RPO maximum acceptable (de 15 minutes à 24 heures). C’est l’agent VR de l’hostd qui définit la planification appropriée en se basant sur l’historique des 15 précédentes réplications et y ajoute une marge de sécurité de 20%. De plus, il établit un calendrier de réplication pour les prochaines 48 heures (peut-être modifié en fonction des tâches du vCenter) pour minimiser les chevauchements entre les différentes réplications. Cette planification est conservée de façon non persistante par ESXi, si un hôte est redémarré ou une VM est déplacée, cette planification est recrée sans l’historique.
Si un RPO n’est pas respecté, il sera indiqué en erreur dans la partie vSphere Replication de SRM, il est souhaitable de configurer des alarmes vCenter pour surveiller qu’il n’y a pas violation des RPOs.

Les limitations de la solution VR:

Seuls les disques virtuels des VMs allumés sont pris en compte. Les images ISO, les disquettes, les VM éteintes et/ou en pause et les templates ne peuvent être répliqués. Les fichiers non essentiels ne sont également pas répliqués (fichiers logs, statistiques, fichier de swap et de lump). La Réplication vSphere dispose également des limitations suivantes:

  • Les disques virtuels RDM en mode physique ne sont pas prise en charge.
  • Les snapshots sont supportés côté source par la réplication mais les snapshots sont consolidé sur le site de secours.
  • FT, Clones-liés ne sont pas supporté.
  • Les VMs doivent être en Virtual Hardware 7 ou supérieur.
  • Maximum 50 VMs répliqués par VRMS et maximum 10 VRMS
  • Maximum 500 VMs répliquées (dans un vCenter).
  • Prérequis ESXi 5.0, vCenter 5.0 et SRM 5.0
  • Le Failback n’est pas géré automatiquement dans SRM 5.0 avec la réplication vSphere. Il faudra attendre la prochaine version.

Par contre, il n’y a une indépendance vis-à-vis des spécificités des formats de disques.

Les Scénarii d’implémentation VR:

L’architecture de PRA que l’on peut mettre en place avec VR dans SRM est plus flexible et moins couteuse qu’une solution de réplication de stockage. Il est donc possible d’envisager différents types de topologie en fonction du besoin.
Par exemple, une topologie de site de secours mutualité qui chez un fournisseur de service pourrait être du PRA en mode Cloud: DRaaS (Disaster Recovery a a Service). Avec la réplication vSphere, les clients sont indépendants par rapport type de stockage du fournisseur de service et le fonctionnement asynchrone supprime l’obligation d’avoir une fibre noire. Généralement le périmètre d’exploitation du fournisseur de service s’étant jusqu’aux serveurs SRM chez les clients.

Pour le fournisseur de service qui souhaite mutualiser une infra destinée au DRaaS, il est possible de mutualiser les ESXs, le vCenter et le VRMS comme indiqué dans le schéma ci-dessous. En revanche, il faudra une instance SRM par client et un Serveur VR par tranche de 50 VMs répliquées et par client. Ce qui veut dire que ce type d’infra DRaaS mutualité support maximum 10 clients.

Ou aussi, protéger les serveurs des sites distants en central pour les intégrer à un PRA plus global même si ces serveurs n’utilise que leurs disques internes.

Voici quelques ressources utiles:

  1. Pas encore de commentaire
  1. Pas encore de trackbacks