Arbeiten mit Site Recovery Manager und NSX-Verbund

Sie können VMware Site Recovery Manager™ (SRM) mit NSX-Verbund für die Notfallwiederherstellung verwenden.

Site Recovery Manager unterstützt die folgenden Workflows mit NSX-Verbund:

NSX-Verbund Globaler Manager (GM)-VMs unterstützen die vollständige Wiederherstellung und die Testwiederherstellung von GM-VMs (unterstützt mit oder ohne NSX-Verbund Management-Cluster-VIP).
Computing-VMs unterstützen die vollständige Wiederherstellung und die Test-Wiederherstellung von Computing-VMs. Die wiederhergestellten VMs am Notfallwiederherstellungsort haben ihre NSX-Tags und Firewallregeln auf der Basis dieser NSX-Tags oder nicht, wie zum Beispiel IP-Adressen und VM-Namen.

Damit Gruppen und Firewallregeln während der Wiederherstellung am Notfallwiederherstellungsort repliziert werden, muss der NSX Lokaler Manager, der den Notfallwiederherstellungsort verwaltet, zum Zeitpunkt der Wiederherstellung, über die NSX-Tags verfügen.

Vor NSX-Verbund 3.2 hatte SRM keine Unterstützung für die Replizierung von VM-Tags zwischen Lokaler Managern. Dies führt dazu, dass NSX keine Sicherheit basierend auf VM-Tags auf wiederhergestellte VMs repliziert haben. Nicht auf VM-Tags basierende Sicherheit, z. B. IP-Adressen oder VM-Namen, konnten auf wiederhergestellte VMs angewendet werden.

In NSX-Verbund Version 4.1.1 unterstützen zwei Felder die Replizierung von Speicher-Arrays: replication _type und tag_delay_delete_time. Wenn Sie die Speicher-Array-Replizierung von Ihrer primären Site auf Ihre Wiederherstellungs-Site in SRM verwenden, erstellen oder aktualisieren Sie die Tag-Replizierungsrichtlinie replication type als STORAGE_ARRAY_REPLICATION.

Wenn Sie einen Schutzplan auf SRM ausführen, um virtuelle Maschinen mithilfe von Notfallwiederherstellungsoptionen oder geplanten Migrationsoptionen von Ihrer primären Site auf Ihre Wiederherstellungs-Site zu migrieren, werden die virtuellen Maschinen auf die Wiederherstellungs-Site verschoben und die virtuellen Maschinen werden von der primären Site gelöscht. Wenn die betreffenden virtuellen Maschinen von der primären Site gelöscht werden und innerhalb der tag_delay_delete_time-Einstellung auf der Wiederherstellungs-Site angezeigt werden, werden Tags der primären Site auf den virtuellen Maschinen auf der Wiederherstellungs-Site repliziert. Für die Speicher-Array-Replizierung hängt die Zeit für VMs, die auf der Wiederherstellungs-Site angezeigt werden, nachdem sie von der primären Site gelöscht wurden, von der für Failover konfigurierten VM-Anzahl, der Speicher-Array-Leistung und vom ESXi-Host ab.

Wenn die vSphere-Replizierung verwendet wird, um VMs von der primären Site auf die Wiederherstellungs-Site in SRM zu replizieren, wird die virtuelle Maschine nicht von der primären Site gelöscht. Daher ist es nicht erforderlich, replication_type oder tag_delay_delete_time in der Tag-Replizierungsrichtlinie anzugeben.

Hinweis: Wenn für Globaler Manager 4.1.1 Replizierungstypen vom Typ VSPHERE_REPLICATION oder Optionen vom Typ OTHER verwendet werden, wird der Wert für tag_delay_time auf 0 festgelegt. Die Einstellung replication_type wird auf den Standardwert „enum“ (ungültig) und die Einstellung tag_delay_delete_time wird auf 0 Minuten festgelegt.

Konfigurieren der VM-Tag-Replizierung über LMs hinweg mit der GM-API

Führen Sie in NSX-Verbund 4.1.1 die folgende Globaler Manager-API aus, um die VM-Tag-Replizierung Lokaler Manager-übergreifend zu konfigurieren:

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"

Führen Sie für NSX-Verbund-Versionen vor 3.2.3 und 4.1.1 die folgende Globaler Manager-API aus, um die VM-Tag-Replizierung Lokaler Manager-übergreifend zu konfigurieren:

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 sendet die Tag-Informationen der VMs für die BIOS-UUID der VMs in den Gruppen Web-VM-Group + DB-VM-Group an LM_London. Vor der Wiederherstellung der Londoner VMs durch SRM verfügt LM_London nicht über die VMs mit der BIOS-UUID, und die VMs sind in LM_London noch nicht sichtbar. Wenn SRM jedoch die VMs in London wiederherstellt, sieht LM_London diese VMs mit der BIOS-UUID und wendet ihre NSX-Tags auf sie an. Die VMs erhalten ihre Sicherheit basierend auf NSX-Tags.

Hinweis: vm_match_criteria verfügt über zwei mögliche Werte: MATCH_BIOS_UUID_NAME oder MATCH_NSX_ATTACHMENT_ID. Bei der Wiederherstellung kopiert SRM beide, sodass jede Konfiguration mit SRM gültig ist. Wenn jedoch ein anderes Produkt die VM-Replizierung abschließt und einen, aber nicht den anderen Wert kopiert, konfigurieren Sie GM mit dem entsprechenden vm_match_criteria-Wert.

Um zu schätzen, wie lange es dauern kann, bis die VM von der primären Site entfernt und auf der Schutz-Site angezeigt wird, können Sie einen Test des Schutzplans durchführen und das Zeitintervall zwischen dem Ende der Schritte Speicher synchronisieren und Einschalten von VMs mit der Priorität X messen. Legen Sie den Wert für tag_delay_delete_time auf mehr als diese geschätzte Zeit fest. Ein weiterer Tipp besteht darin, den Schutzplan in Site Recovery Manager auszuführen und die Einstellung für tag_delay_delete_time so festzulegen, dass sie immer länger als die Zeit zwischen dem Schritt VMs auf der Schutz-Site herunterfahren und dem Schritt zum Einschalten von VMs mit der Priorität X ist, während der Ausführung mit dem Schutzplan in SRM erfolgt.

Überprüfen der VM-Tag-Replizierung über LMs hinweg mit der GM-API

Um Details zur VM-Tag-Replizierung über Lokaler Manager hinweg abzurufen, führen Sie die folgende Globaler Manager-API aus:

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

Die Ausgabe sollte in etwa wie folgt aussehen:

{
  "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 unterstützt nur einen Eintrag von Wiederherstellungs-Sites. Weitere Informationen finden Sie in der API vm-tag-replication-policies/policy-name im Handbuch zur NSX Global Manager REST API.