Multi-TEP-Hochverfügbarkeit

Um Konnektivitätsverluste bei Arbeitslasten (VMs oder Container) zu vermeiden, die mit einem virtuellen Tunnel-Endpoint (TEP) verbunden sind, konfigurieren Sie ein TEP HA-Host-Switch-Profil und wenden Sie das auf Cluster-Transportknoten oder individuelle Transportknoten an.

Da Overlay-Netzwerke, die sich über L2- oder L3-Netzwerke erstrecken, Kapselungsprotokolle verwenden, werden ausgehende oder eingehende Pakete von Arbeitslasten (VMs oder Container) innerhalb des inneren Pakets eines virtuellen Tunnel-Endpoints (TEP) gekapselt. Wechselt ein TEP in einen fehlerhaften Zustand, sind die damit verknüpften VMs nicht erreichbar. Es gibt eine 1:1-Zuordnung zwischen VMs und TEPs.

Ein TEP ist fehlerhaft, wenn einer der folgenden Punkte zutrifft:

Alle BFD-Sitzungen eines TEP sind aufgrund von Problemen im Underlay-Fabric inaktiv.
Der TEP hat keine IP-Adresse.

Ein funktionsfähiger TEP weist die folgenden Merkmale auf:

Er verfügt über eine IP-Adresse.
Mindestens eine BFD-Sitzung mit dem TEP ist aktiv.

Wenn NSX erkennt, dass ein TEP ausgefallen ist, werden vNICs von VMs vom fehlerhaften TEP zu einem fehlerfreien TEP auf demselben ESXi-Host migriert. Verfügt ein ESXi über zwei TEPs und beide sind fehlerhaft, können VM-vNICs nicht migriert werden.

VMs können über mehrere vNICs verfügen. Jede vNIC ist einem einzelnen TEP zugeordnet. Die Pakete aus der vNIC werden gekapselt, bevor sie auf dem Uplink gesendet werden. Einem einzelnen TEP können mehrere vNICs zugeordnet sein. Die Zuordnung wird basierend auf Uplink-Teaming-Richtlinien festgelegt.

Hinweis: TEP HA unterstützt nur IPv4-TEPs.

Voraussetzungen

Mindestens zwei TEPs sind auf einem einzelnen ESXi-Host konfiguriert. Stellen Sie sicher, dass das Uplink-Profil, das Sie zum Erstellen eines Transportknotenprofils (TNP) oder einer einzelnen Transportknotenkonfiguration verwenden, mindestens zwei aktive Uplinks (TEPs) verwendet.

Prozedur

Erstellen Sie ein TEP HA-Host-Switch-Profil.
PUT https://<nsx-policy-manager>/policy/api/v1/infra/host-switch-profiles/vtephaprofile1
```
{
"enabled": "true",
"failover_timeout":"5",
"auto_recovery" : "true",
"auto_recovery_initial_wait" : "300",
"auto_recovery_max_backoff" : "86400",
"resource_type": "PolicyVtepHAHostSwitchProfile",
"display_name": "VtepHAProfile1"
}
```
Dabei gilt:
- enabled: gibt an, dass TEP HA aktiviert ist oder nicht. Der Wert „true“ gibt an, dass TEP HA aktiviert ist, „false“ hingegen, dass sie deaktiviert ist.
- failover_timeout: ist die Zeitüberschreitung für das TEP High Availability-Failover (in Sekunden). Diese Eigenschaft steuert, nach welchem Zeitraum die VM vNIC in einen alternativen fehlerfreien TEP verschoben werden soll, nachdem ein Fehler auf einem vmknic erkannt wurde. Der Standardwert für die Zeitüberschreitung beträgt 5 Sekunden. Der unterstützte Maximalwert beträgt 60 Sekunden.
- auto_recovery: gibt den Status der autonomen Wiederherstellungsoption für die TEP High Availability-Funktion an. Wenn auto_recovery auf „true“ festgelegt ist, wird die fehlerhafte vmknic nach jeder zyklische Sequenz intern überprüft. Wird die fehlerhafte vmknic wiederhergestellt, wird die VM zurück in ihre ursprünglichen TEP-Zuordnung verschoben, vorausgesetzt, die vNIC der VMs wurde diesem TEP zugeordnet. Standardmäßig ist auto_recovery auf „true“ festgelegt. Bei der automatischen Wiederherstellung kommt es zu einem Ausfall von VMs, wenn sich TEP noch im fehlerhaften Zustand befindet. Die Ausfallzeit wird mithilfe der Formel failover_timeout + bfd timeout + 1 berechnet. Der Standardwert für bfd timeout beträgt 4 Sekunden.
- auto_recovery_initial_wait: Diese Eigenschaft steuert, nach welchem Zeitraum die autonome Wiederherstellung gestartet werden soll. Die minimale anfängliche Wartezeit beträgt 300 Sekunden, die maximale Wartezeit 3600 Sekunden. Wenn die anfängliche Wartezeit 300 Sekunden beträgt, beginnt die automatische Wiederherstellung bei 300 Sekunden.
- auto_recovery_max_backoff: Nach auto_recovery_initial_wait wird versucht, eine erste Wiederherstellung durchzuführen. Wenn diese Wiederherstellung fehlschlägt, werden nach Verdoppelung der vorherigen Verzögerungszeit zusätzliche Versuche unternommen. Wenn die Verzögerung auto_recovery_max_backoff erreicht, steigt sie nicht mehr und alle weiteren Versuche werden nach jeweils auto_recovery_max_backoff unternommen.

Um ein TEP HA-Profil an alle ESXi-Hosts anzuhängen, erstellen Sie ein TNP mit dem TEP HA-Profilschlüssel und den Werteigenschaften, die dem Abschnitt für Host-Switch-Profile hinzugefügt wurden, oder bereiten Sie einzelne Transportknoten mit dem Schlüssel und den Werteigenschaften des TEP HA-Profils vor.

PUT https://<nsx-policy-manager>/policy/api/v1/infra/host-transport-node-profiles/<tnp-id>

Geben Sie im Parameter <tnp-id> die Transportknotenprofil-ID ein.

{
    "host_switch_spec": {
        "host_switches": [
            {
                "host_switch_name": "vtepha_vds",
                "host_switch_id": "50 22 ee c4 f6 40 79 8b-0e a4 2b da 6a 4c 36 b3",
                "host_switch_type": "VDS",
                "host_switch_mode": "ENS_INTERRUPT",
                "host_switch_profile_ids": [
                    {
                        "key": "UplinkHostSwitchProfile",
                        "value": "/infra/host-switch-profiles/b32e6ce6-f1ba-4e31-a2c4-33d550505cdd"
                    },
                    {
                        "key": "VtepHAHostSwitchProfile",
                        "value": "/infra/host-switch-profiles/vtephaprofile1"
                    }
                ],
                "uplinks": [
                    {
                        "vds_uplink_name": "Uplink 1",
                        "uplink_name": "uplink-1"
                    },
                    {
                        "vds_uplink_name": "Uplink 2",
                        "uplink_name": "uplink-2"
                    }
                ],
                "is_migrate_pnics": false,
                "ip_assignment_spec": {
                    "ip_pool_id": "/infra/ip-pools/v4",
                    "resource_type": "StaticIpPoolSpec"
                },
                "cpu_config": [],
                "transport_zone_endpoints": [
                    {
                        "transport_zone_id": "/infra/sites/default/enforcement-points/default/transport-zones/de47a6b9-fa4c-4bf3-bd75-385859895949",
                        "transport_zone_profile_ids": []
                    }
                ],
                "not_ready": false
            }
        ],
        "resource_type": "StandardHostSwitchSpec"
    },
    "ignore_overridden_hosts": false,
    "resource_type": "PolicyHostTransportNodeProfile"
 }

Hinweis: Wenn Sie TNP nicht mit TEP HA konfigurieren, erstellt NSX ein TEP-HA-Standardprofil. Dieses TEP HA-Standardprofil ist mit Standardwerten konfiguriert. TEP HA ist deaktiviert.

Führen Sie die folgende API aus, um die von Ihnen in Schritt 1 erstellte TEP HA-Profil-ID in Erfahrung zu bringen:

get https://<nsx-manager>/policy/api/v1/infra/host-switch-profiles/vtephaprofile1

In der GET-Antwort können Sie den Wert des TEP HA-Profils aus dem Feld id abrufen.
Um zu überprüfen, ob das TEP HA-Host-Switch-Profil auf Transportknoten angewendet wird, führen Sie die folgende API aus.
GET https://<nsx-manager>/policy/api/v1/infra/host-transport-nodes-profiles/<tnp_id>
```
 "host_switch_profile_ids": [
     {
        "key": "VtepHAHostSwitchProfile",
        "value": "/infra/host-switch-profiles/<vtephaprofile1>"
      }
    ],
```
<vtephaprofile1> ist die beim Erstellen des TEP HA-Profils in Schritt 1 zurückgegebene ID.
Sie können auch eine manuelle Wiederherstellung eines fehlerhaften TEP auslösen und zugeordnete VMs auf einen fehlerfreien TEP migrieren, ohne auf den Start der automatischen Wiederherstellung zu warten.
POST https://<nsx-mgr>/policy/api/v1/infra/sites/<site-id>/enforcement-points/<enforcementpoint-id>/host-transport-nodes/<host-transport-node-id>/vteps/actions
```
{
    "action_type": "TransportNodeVtepRecoveryRequest",
    "device_name": "vmk10"
}
```
vmk10 ist der TEP-Name.
Wenn vmknics von TEPs fehlerhaft sind, führen Sie die Alarm-API aus, um weitere Informationen zum Fehler anzuzeigen, oder prüfen Sie den Fehler im NSX Manager-Dashboard.

NSX braucht mindestens 60 Sekunden, bis ein Alarm für eine fehlerhafte vmknic ausgelöst wird. Wenn ein TEP nach einem fehlerhaften Zustand wieder aktiviert wird, kann es ebenfalls bis zu 60 Sekunden dauern, bis der neue Zustand angezeigt wird.
GET https://<nsx-manager>/api/v1/alarms?feature_name=tep_health

Haben Sie IP- oder BFD-bezogene Fehler behoben, überprüfen Sie den Parameter state, um den Status der vmknics oder TEP in Erfahrung zu bringen.

GET https://<nsx-manager>/api/v1/transport-nodes/<node-id>/network/interfaces?source=realtime

{
        "interfaceId": "vmk10",
        "linkStatus": "UP",
        "adminStatus": "UP",
        "mtu": "1600",
        "interfaceAlias": [{
          "broadcastAddress": "133.117.22.255",
          "ipAddress": {
            "ipv4": 2239043120
          },
          "ipConfiguration": "STATIC",
          "netmask": "255.255.255.0",
          "macAddress": "00:50:56:66:67:a6"
        }],
        "state": "NORMAL"
      },

Ergebnisse

Ist BFD ausgefallen, bestimmt NSX, ob die Sicherung eines fehlerhaften TEP mithilfe der automatischen Wiederherstellung oder des manuellen Wiederherstellungsmechanismus erfolgt.

Wenn die IP anfänglich nicht verfügbar ist, aber einem fehlerhaften TEP neu zugewiesen wird, bestimmt NSX über einen integrierten Mechanismus, wann der TEP wieder funktionsfähig ist. Der manuelle oder automatische Wiederherstellungsmechanismus kommt dabei nicht zum Tragen.

Wenn der fehlerhafte TEP nicht wieder funktionsbereit ist:

Während der automatischen Wiederherstellung oder des manuellen Wiederherstellungsvorgangs kann es bei der VM vNIC zu einem temporären Netzwerkausfall kommen.
Der Netzwerkausfall kann darauf zurückzuführen sein, dass die VM vNIC während der BFD-Prüfung weiterhin dem fehlerhaften TEP zugeordnet ist.
Die Netzwerkausfallzeit wird mithilfe der Formel failover_timeout + bfd timeout + 1 berechnet, die 10 Sekunden beträgt. Der Standardwert für bfd timeout beträgt 4 Sekunden.

Wechselt ein fehlerhafter TEP weiterhin nicht in den aktiven Status, wird die VM vNIC einem fehlerfreien TEP neu zugeordnet. Wenn keine TEPs fehlerfrei sind, wird die VM vNIC ihrem ursprünglichen TEP zugeordnet.