Travailler avec Site Recovery Manager et NSX fédération

Vous pouvez utiliser VMware Site Recovery Manager™ (SRM) avec NSX fédération pour les cas d'utilisation de récupération d'urgence.

Site Recovery Manager prend en charge les workflows suivants avec NSX-T Data Center :

Les VM NSX fédération Gestionnaire global (GM) prennent en charge la récupération complète et de test des VM GM (prises en charge avec ou sans VIP de cluster de gestion NSX fédération).
Les VM de calcul prennent en charge la récupération complète et de test des VM de calcul. Les VM récupérées sur le site de récupération d'urgence disposent de leurs balises NSX-T Data Center et de règles de pare-feu basées ou non sur ces balises NSX-T Data Center, telles que des adresses IP et des noms de VM.

Pour s'assurer que les groupes et les règles de pare-feu se répliquent à l'emplacement de récupération d'urgence pendant la récupération, le NSX-T Data Center Gestionnaire local gérant l'emplacement de récupération d'urgence doit disposer des balises NSX-T Data Center présentes au moment de la récupération.

Avant la fonctionnalité de fédération NSX 3.2, il n'y avait aucune prise en charge de la réplication des balises de VM entre les Gestionnaire local dans Site Recovery Manager. Par conséquent, NSX-T Data Center ne répliquait aucune sécurité basée sur des balises de VM sur les VM récupérées. La sécurité non basée sur des balises de VM, par exemple, des adresses IP ou des noms de VM, peut s'appliquer aux VM récupérées.

À partir de NSX fédération version 3.2.3, deux nouveaux champs sont ajoutés pour prendre en charge la réplication de baie de stockage : replication _type et tag_delay_delete_time. Si vous utilisez la réplication de baie de stockage de votre site principal vers votre site de récupération dans Site Recovery Manager, créez ou mettez à jour la stratégie de réplication de balises replication type comme STORAGE_ARRAY_REPLICATION.

L'exécution d'un plan de protection sur Site Recovery Manager pour migrer des machines virtuelles à l'aide d'options de récupération d'urgence ou de migration planifiée de votre site principal vers votre site de récupération déplacera les machines virtuelles vers le site de récupération et supprimera les machines virtuelles du site principal. Lorsque les machines virtuelles concernées sont supprimées du site principal et apparaissent sur le site de récupération dans le paramètre tag_delay_delete_time, les balises du site principal sont répliquées sur les machines virtuelles du site de récupération. Pour la réplication de baie de stockage, le temps d'affichage des machines virtuelles sur le site de récupération après leur suppression du site principal dépend du nombre de machines virtuelles configurées pour le basculement, des performances de la baie de stockage et de l'hôte ESXi.

Si la réplication vSphere est utilisée pour répliquer des machines virtuelles du site principal vers le site de récupération dans Site Recovery Manager, la machine virtuelle n'est pas supprimée du site principal. Par conséquent, il n'est pas nécessaire de spécifier replication_type ou tag_delay_delete_time dans la stratégie de réplication de balise.

Note : À partir de Gestionnaire global 3.2.3, si des types de réplication VSPHERE_REPLICATION ou autres options sont utilisés, la valeur tag_delay_delete_time est définie sur 0 minute.

Comment configurer la réplication de balises de VM sur des LM à l'aide de l'API du GM

À partir de NSX fédération version 3.2.3, pour configurer la réplication de balises de machine virtuelle sur Gestionnaire local, exécutez l'API suivante Gestionnaire global :

PUT https://{{gm}}/global-manager/api/v1/global-infra/vm-tag-replication-policies/policy1
{
    "display_name":"vm tag replication policy Paris to London",
    "description":"vm tag replication policy1",
    "protected_site": "/global-infra/sites/LM_Paris",
    "replication_type": "STORAGE_ARRAY_REPLICATION", 
    "tag_delay_delete_time": 30,
    "recovery_sites": [
        "/global-infra/sites/LM_London"
    ],
    "groups":[
        "/global-infra/domains/default/groups/Web-VM-Group",
        "/global-infra/domains/default/groups/DB-VM-Group"
    ],
    "vm_match_criteria": "MATCH_BIOS_UUID_NAME"

Pour NSX fédération versions antérieures à 3.2.3, pour configurer la réplication de balises de machine virtuelle sur Gestionnaire local, exécutez l'API Gestionnaire global suivante :

PUT https://{{gm}}/global-manager/api/v1/global-infra/vm-tag-replication-policies/policy1
{
    "display_name":"vm tag replication policy Paris to London",
    "description":"vm tag replication policy1",
    "protected_site": "/global-infra/sites/LM_Paris",
    "recovery_sites": [
        "/global-infra/sites/LM_London"
    ],
    "groups":[
        "/global-infra/domains/default/groups/Web-VM-Group",
        "/global-infra/domains/default/groups/DB-VM-Group"
    ],
    "vm_match_criteria": "MATCH_BIOS_UUID_NAME"

LM_Paris envoie les informations de balises des VM pour l'UUID du BIOS des VM dans les groupes Web-VM-Group + DB-VM-Group à LM_London. Avant la récupération des VM de Londres par Site Recovery Manager, LM_London ne dispose pas encore des VM avec l'UUID du BIOS. Les VM ne sont alors pas encore visibles dans LM_London. Toutefois, lorsque Site Recovery Manager récupère les VM de Londres, LM_London voit ces VM avec l'UUID du BIOS et applique ses balises NSX-T Data Center dessus. Les VM obtiennent leur sécurité en fonction des balises NSX-T Data Center.

Note : vm_match_criteria présente deux valeurs possibles MATCH_BIOS_UUID_NAME ou MATCH_NSX_ATTACHMENT_ID. Lors de la récupération, Site Recovery Manager copie les deux afin qu'une configuration soit valide avec Site Recovery Manager. Cependant, si un autre produit termine la réplication de VM et copie l'une des valeurs, mais pas l'autre, configurez le GM à l'aide de la valeur vm_match_criteria appropriée.

Pour estimer le temps nécessaire à la disparition de la machine virtuelle du site principal et à son apparition sur le site protégé, vous pouvez effectuer un test sur le plan de protection et mesurer l'intervalle de temps entre la fin des étapes Synchroniser le stockage et Alimentation sur les machines virtuelles X prioritaires. Définissez votre tag_delay_delete_time pour qu'elle soit supérieure à cette durée estimée. Une autre astuce consiste à exécuter le plan de protection dans Site Recovery Manager et à définir le tag_delay_delete_time de manière à ce qu'il soit toujours plus long qu'il faut entre l'étape VM inactives sur le site protégé et pour terminer l'étape de Utilisation sur les VM X prioritaires lors de l'exécution sur le plan de protection dans SRM.

Comment vérifier la réplication de balises de VM sur des LM à l'aide de l'API du GM

Pour obtenir des détails sur la réplication des balises de VM dans les Gestionnaire local, exécutez l'API suivante Gestionnaire global :

GET https://{{gm}}/global-manager/api/v1/global-infra/vm-tag-replication-policies

La sortie renvoie les éléments semblables :

{
  "protected_site": "/global-infra/sites/LM_Paris",
  "recovery_sites": [
    "/global-infra/sites/LM_London"
  ],
  "vm_match_criteria": "MATCH_BIOS_UUID_NAME",
  "groups": [
    "/global-infra/domains/default/groups/Web-VM-Group",
    "/global-infra/domains/default/groups/DB-VM-Group"
  ],
  "resource_type": "VMTagReplicationPolicy",
  "id": "policy1",
  "display_name": "vm tag replication policy Paris to London",
  "description": "vm tag replication policy1",
  "path": "/global-infra/vm-tag-replication-policies/policy1",
  "relative_path": "policy1",
  "parent_path": "/global-infra",
  "unique_id": "9ee18586-5480-41d9-8223-690c9226d763",
  "marked_for_delete": false,
  "overridden": false,
  "_create_time": 1638413861377,
  "_create_user": "admin",
  "_last_modified_time": 1638413861377,
  "_last_modified_user": "admin",
  "_system_owned": false,
  "_protection": "NOT_PROTECTED",
  "_revision": 0
}

NSX-T Data Center ne prend en charge qu'une seule entrée des sites de récupération. Pour plus d'informations, reportez-vous à l'API vm-tag-replication-policies/policy-name du Guide de REST API du gestionnaire global NSX.