Alta disponibilidad Multi-TEP

Para evitar la pérdida de conectividad de las cargas de trabajo (máquinas virtuales o contenedores) asociadas a un endpoint de túnel virtual (TEP), configure el perfil de conmutador de host de HA de TEP y aplíquelo a los nodos de transporte del clúster o a los nodos de transporte individuales.

Puesto que las redes superpuestas que abarcan redes de capa 2 o capa 3 utilizan protocolos de encapsulación, la salida o la entrada de paquetes desde cargas de trabajo (máquinas virtuales o contenedores) se encapsulan dentro del paquete externo de un endpoint de túnel virtual (TEP). Si un TEP entra en un estado de error, no se podrá acceder a las máquinas virtuales asociadas a él. Hay una asignación de uno a uno entre las máquinas virtuales y los TEP.

Se considera que un TEP tiene errores cuando se cumple uno de los siguientes puntos:

Todas las sesiones de BFD de un TEP están inactivas debido a problemas en el tejido subyacente.
Un TEP no tiene una dirección IP.

Un TEP en estado correcto debe tener las siguientes características:

Tiene una dirección IP.
Al menos una sesión de BFD relacionada con el TEP está activa.

Cuando NSX detecta que un TEP está inactivo, las vNIC de las máquinas virtuales se migran desde el TEP con errores a un TEP en estado correcto en el mismo host ESXi. Si un ESXi tiene dos TEP y ambos tienen errores, no se podrán migrar las vNIC de las máquinas virtuales.

Cada máquina virtual puede tener más de una vNIC. Cada vNIC está asociada a un solo TEP. Los paquetes de la vNIC se encapsulan antes de enviarlos en el vínculo superior. Puede haber varias vNIC asignadas a un solo TEP. La asignación se decide en función de las directivas de formación de equipos de vínculo superior.

Nota: HA de TEP solo admite TEP de IPv4.

Requisitos previos

Se configuran al menos dos TEP en un solo host ESXi. Asegúrese de que el perfil de vínculo superior que usa para crear un perfil de nodo de transporte (TNP) o una configuración de nodo de transporte individual utilice al menos dos vínculos superiores activos (TEP).

Procedimiento

Cree un perfil de conmutador de host de HA de TEP.
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"
}
```
donde,
- enabled: indica si HA de TEP está habilitado o no. El valor "true" indica que HA de TEP está habilitado y "false" que está deshabilitado.
- failover_timeout: indica si se agotó el tiempo de espera de conmutación por error de alta disponibilidad de TEP (en segundos). Esta propiedad controla después de cuánto tiempo se debe mover la vNIC de las máquinas virtuales a un TEP alternativo en estado correcto una vez que se detecta un error en una vmknic. El tiempo de espera predeterminado es 5 segundos. El valor máximo admitido es de 60 segundos.
- auto_recovery: especifica el estado de la opción de recuperación autónoma para la función de alta disponibilidad de TEP. Cuando auto_recovery se establece en true, la vmknic con errores se hace una comprobación interna después de cada secuencia cíclica. Si la vmknic con errores se recupera, la máquina virtual se moverá de nuevo a su asignación de TEP inicial, siempre que la vNIC de las máquinas virtuales se hayan asignado a ese TEP. De forma predeterminada, auto_recovery tiene el valor true. Durante la recuperación automática, las máquinas virtuales sufrirán una interrupción si el TEP sigue teniendo errores. El tiempo de interrupción se calcula utilizando esta fórmula: failover_timeout + bfd timeout + 1. El valor predeterminado de bfd timeout es 4 segundos.
- auto_recovery_initial_wait: esta propiedad controla después de cuánto tiempo debe iniciarse la recuperación automática. El período de espera inicial mínimo es de 300 segundos, mientras que el máximo es de 3600 segundos. Si el período de espera inicial es de 300 segundos, la recuperación automática comenzará transcurridos 300 segundos.
- auto_recovery_max_backoff: se intenta una recuperación inicial después del valor de auto_recovery_initial_wait. Si se produce un error en esta recuperación, se realizarán intentos adicionales después de duplicar el tiempo de retraso anterior. Cuando el retraso alcance el valor de auto_recovery_max_backoff, el retraso dejará de aumentar y se realizarán todos los intentos en cada auto_recovery_max_backoff.

Para asociar un perfil de HA de TEP a todos los hosts ESXi, cree un TNP con la clave de perfil de HA de TEP y las propiedades de valor agregadas a la sección Perfiles de conmutador de host o prepare nodos de transporte individuales con las propiedades de valor y clave del perfil de HA de TEP.

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

En el parámetro <tnp-id>, introduzca el identificador de perfil del nodo de transporte.

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

Nota: Si no configura un TNP con HA de TEP, NSX creará un perfil de HA de TEP predeterminado. Este perfil de HA de TEP predeterminado se configurará con los valores predeterminados. HA de TEP está deshabilitada.

Para conocer el identificador de perfil de HA de TEP que creó en el paso 1, ejecute la siguiente API:

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

En la respuesta GET, puede obtener el valor del perfil de HA de TEP en el campo id.
Para comprobar si el perfil de conmutador de host de HA de TEP se aplica a los nodos de transporte, ejecute la siguiente API.
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> es el identificador que se devuelve al crear el perfil de HA de TEP en el paso 1.
También puede activar una recuperación manual de un TEP con errores y migrar las máquinas virtuales asociadas a un TEP en estado correcto sin esperar a que comience la recuperación automática.
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"
}
```
donde vmk10 es el nombre del TEP.
Si las vmknic del TEP tienen errores, ejecute la API de alarma para ver los detalles del error, o también puede consultar el error en panel de control de NSX Manager.

NSX puede tardar al menos 60 segundos en activar una alarma si una vmknic tiene errores. De forma similar, cuando un TEP vuelve a activarse después de un estado de error, NSX puede tardar hasta 60 segundos en reflejar el nuevo estado.
GET https://<nsx-manager>/api/v1/alarms?feature_name=tep_health

Después de solucionar los errores relacionados con IP o BFD, compruebe el parámetro state para conocer el estado de las vmknic o el 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"
      },

Resultados

Si BFD está inactivo, NSX determinará si el TEP con errores se vuelve a activar mediante el mecanismo de recuperación automática o manual.

Si la IP no está disponible inicialmente, pero se reasigna a un TEP con errores, NSX utilizará un mecanismo integrado para determinar cuándo se realizará una copia de seguridad del TEP. No se basa en un mecanismo de recuperación manual o automática.

Si el TEP con errores no vuelve a activarse:

Durante el proceso de recuperación automática o manual, es posible que la vNIC de la máquina sufra una interrupción temporal de la red.
La interrupción de la red puede deberse a que, durante la comprobación de BFD, la vNIC de la máquina virtual aún está asignada al TEP con errores.
El tiempo de interrupción de la red se calcula mediante la fórmula failover_timeout + bfd timeout + 1, que es de 10 segundos. El valor predeterminado de bfd timeout es 4 segundos.

Si el TEP con errores sigue sin activarse, la vNIC de la máquina virtual se reasignará a un TEP en estado correcto que esté disponible en el host. Si ningún TEP está en estado correcto, la vNIC de la máquina virtual se asignará a su TEP original.