Haute disponibilité multi-TEP

Pour éviter la perte de connectivité des charges de travail (VM ou conteneurs) associées à un point de terminaison du tunnel virtuel (TEP), configurez le profil de commutateur d'hôte du TEP HA et appliquez-le aux nœuds de transport de cluster ou aux nœuds de transport individuels.

Comme les réseaux de superposition s'étendant sur des réseaux L2 ou L3 utilisent des protocoles d'encapsulation, les paquets sortants ou entrants à partir des charges de travail (VM ou conteneurs) sont encapsulés dans le paquet externe d'un point de terminaison de réseau virtuel (TEP, Virtual Tunnel End Point). Si un TEP passe à un état défectueux, les VM qui lui sont associées ne sont pas accessibles. Un mappage un-à-un s'effectue entre les VM et les TEP.

Un TEP est défectueux lorsque l'un des points suivants est vrai :

Toutes les sessions BFD d'un TEP sont inactives en raison de problèmes dans l'infrastructure de sous-couche.
Le TEP ne dispose d'aucune adresse IP.

Un TEP sain présente les caractéristiques suivantes :

Il dispose d'une adresse IP.
Au moins une session BFD impliquant le TEP est active.

Lorsque NSX découvre qu'un TEP est inactif, les vNIC des VM sont migrées du TEP défectueux vers un TEP sain sur le même hôte ESXi. Si un ESXi dispose de deux TEP et que les deux sont défectueux, les vNIC de la VM ne peuvent pas être migrées.

Plusieurs vNIC peuvent être attribuées à chaque VM. Chaque vNIC est associée à un seul TEP. Les paquets de la vNIC sont encapsulés avant d'être envoyés sur la liaison montante. Plusieurs vNIC peuvent être mappées à un seul TEP. Le mappage est déterminé en fonction des stratégies d'association de liaisons montantes.

Note : Le TEP HA prend uniquement en charge les TEP IPv4.

Conditions préalables

Au moins deux TEP sont configurés sur un hôte ESXi unique. Assurez-vous que le profil de liaison montante que vous utilisez pour créer un profil de nœud de transport (TNP) ou que la configuration des nœuds de transport individuels utilise au moins deux liaisons montantes actives (TEP).

Procédure

Créez un profil de commutateur d'hôte TEP HA.
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"
}
```
où,
- enabled : indique l'activation ou non du TEP HA. La valeur « true » indique que le TEP HA est activé et « false » indique qu'il est désactivé.
- failover_timeout : délai d'expiration du basculement de la haute disponibilité TEP (en secondes). Cette propriété contrôle après combien de temps la vNIC des VM doit elle être déplacée vers un autre TEP sain une fois qu'une panne est détectée sur une vmknic. Le délai d'expiration par défaut est de 5 secondes. La valeur maximale prise en charge est de 60 secondes au maximum.
- auto_recovery : spécifie l'état de l'option de récupération autonome pour la fonctionnalité de TEP haute disponibilité. Lorsque auto_recovery est défini sur true, la carte vmknic défectueuse est vérifiée en interne après chaque séquence cyclique. Si la carte vmknic défectueuse reprend, la VM revient à son mappage TEP initial, à condition que la vNIC des VM ait été mappée à ce TEP. Par défaut, auto_recovery est défini sur true. Lors de la récupération automatique, les VM sont confrontées à une panne si le TEP est toujours dans un état défectueux. La durée de la panne est calculée à l'aide de la formule : failover_timeout + bfd timeout + 1. La valeur bfd timeout par défaut est de 4 secondes.
- auto_recovery_initial_wait : cette propriété contrôle après combien de temps la récupération autonome doit démarrer. La période d'attente initiale minimale est de 300 secondes, tandis que la période d'attente maximale est de 3 600 secondes. Si la période d'attente initiale est de 300 secondes, la récupération automatique démarre à 300 secondes.
- auto_recovery_max_backoff : une tentative de récupération initiale est effectuée après auto_recovery_initial_wait. Si cette récupération échoue, des tentatives supplémentaires sont effectuées après avoir doublé le retard précédent. Lorsque le retard atteint auto_recovery_max_backoff, il cesse d'augmenter et toutes les autres tentatives sont effectuées chaque auto_recovery_max_backoff.

Pour attacher un profil TEP HA à tous les hôtes ESXi, créez un TNP avec les propriétés de clé et de valeur de profil TEP HA ajoutées à la section Profils de commutateur d'hôte ou préparez des nœuds de transport individuels avec les propriétés de clé et de valeur du profil TEP HA.

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

Dans le paramètre <tnp-id>, entrez l'ID de profil de nœud de transport.

{
    "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"
 }

Note : Si vous ne configurez pas le TNP avec le TEP HA, NSX crée un profil TEP HA par défaut. Ce profil TEP HA par défaut est configuré avec des valeurs par défaut. Le TEP HA est désactivé.

Pour connaître l'ID de profil TEP HA que vous avez créé à l'étape 1, exécutez l'API suivante :

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

Dans la réponse GET, vous pouvez obtenir la valeur du profil TEP HA dans le champ id.
Pour vérifier si le profil de commutateur d'hôte TEP HA est appliqué aux nœuds de transport, exécutez l'API suivante.
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> est l'ID renvoyé lorsque vous avez créé le profil TEP HA à l'étape 1.
Vous pouvez également déclencher une récupération manuelle d'un TEP défectueux et migrer les VM associées vers un TEP sain sans attendre le début de la récupération automatique.
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"
}
```
où vmk10 est le nom du TEP.
Si les cartes vmknic des TEP sont défectueuses, exécutez l'API d'alarme pour afficher les détails liés à l'erreur ou afficher cette dernière sur le tableau de bord de NSX Manager.

NSX peut prendre au moins 60 secondes pour déclencher une alarme si une vmknic est défectueuse. De même, lorsqu'un TEP se réactive après avoir été dans un état défectueux, NSX peut prendre jusqu'à 60 secondes pour refléter le nouvel état.
GET https://<nsx-manager>/api/v1/alarms?feature_name=tep_health

Après avoir corrigé les erreurs liées à l'adresse IP ou à BFD, vérifiez le paramètre state pour connaître l'état des cartes vmknic ou du TEP.

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"
      },

Résultats

Si BFD est inactif, NSX détermine si un TEP défectueux est réactivé à l'aide du mécanisme de récupération automatique ou manuelle.

Si l'adresse IP n'est pas disponible initialement, mais qu'elle est réattribuée à un TEP défectueux, NSX utilise un mécanisme intégré pour déterminer lorsqu'un TEP est réactivé. Il ne repose pas sur le mécanisme de récupération manuelle ou automatique.

Si le TEP défectueux ne se réactive pas :

Pendant le processus de récupération automatique ou manuelle, la vNIC de la VM peut subir une panne temporaire du réseau.
Une panne du réseau peut être due au fait que, pendant la vérification de BFD, la vNIC de la VM est toujours mappée au TEP défectueux.
La durée de panne du réseau est calculée à l'aide de la formule : failover_timeout + bfd timeout + 1, qui est de 10 secondes. La valeur bfd timeout par défaut est de 4 secondes.

Si le TEP défectueux ne se réactive toujours pas, la vNIC de la VM est remappée à un TEP sain disponible sur l'hôte. Si aucun TEP n'est sain, la vNIC de la VM est mappée à son VTEP d'origine.