Travailler avec Site Recovery Manager et NSX Federation

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

Site Recovery Manager prend en charge les workflows suivants avec NSX Federation :

Les VM NSX Federation 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 Federation).
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 et de règles de pare-feu basées ou non sur ces balises NSX, 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 Gestionnaire local gérant l'emplacement de récupération d'urgence doit disposer des balises NSX présentes au moment de la récupération.

Avant NSX Federation 3.2, SRM ne prenait pas en charge la réplication des balises de machine virtuelle entre Gestionnaire local. Par conséquent, NSX n'a pas répliqué de sécurité basée sur des balises de machine virtuelle sur les machines virtuelles 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.

Dans NSX Federation version 4.1.1, deux champs prennent 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 SRM, 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 SRM 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 SRM, 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 : Pour Gestionnaire global 4.1.1, si des types de réplication VSPHERE_REPLICATION ou autres options sont utilisés, la valeur tag_delay_time est définie sur 0. Le replication_type est défini sur la valeur par défaut enum (invalide) et la tag_delay_delete_time est définie sur 0 minute.

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

Dans NSX Federation 4.1.1, pour configurer la réplication de balises de machine virtuelle entre 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",
    "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 Federation versions antérieures à 3.2.3 et 4.1.1, 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 SRM, 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 SRM récupère les VM à Londres, LM_London voit ces VM avec l'UUID du BIOS et applique ses balises NSX dessus. Les VM obtiennent leur sécurité en fonction des balises NSX.

Note : vm_match_criteria présente deux valeurs possibles MATCH_BIOS_UUID_NAME ou MATCH_NSX_ATTACHMENT_ID. Lors de la récupération, SRM copie les deux afin qu'une configuration soit valide avec celui-ci. 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.

Vérifier la réplication des balises de VM sur les 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 du gestionnaire global 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 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.