Per evitare la perdita di connettività dei carichi di lavoro (macchine virtuali o container) associati a un endpoint del tunnel virtuale (TEP), configurare il profilo del commutatore host HA TEP e applicarlo ai nodi di trasporto del cluster o ai singoli nodi di trasporto.
Poiché le reti di overlay che si estendono attraverso le reti L2 o L3 utilizzano protocolli di incapsulamento, i pacchetti in uscita o in ingresso dai carichi di lavoro (macchine virtuali o container) vengono incapsulati nel pacchetto esterno di un endpoint del tunnel virtuale (TEP). Se un TEP passa allo stato di errore, le macchine virtuali associate non sono raggiungibili. Tra le macchine virtuali e i TEP è presente una mappatura uno-a-uno.
In un TEP si verifica un errore quando uno dei seguenti punti è vero:
- Tutte le sessioni BFD di un TEP sono inattive a causa di problemi dell'infrastruttura underlay.
- TEP non ha un indirizzo IP.
Un TEP integro ha le seguenti caratteristiche:
- Ha un indirizzo IP.
- Almeno una sessione BFD che coinvolge TEP è attiva.
Quando NSX rileva che un TEP è inattivo, le vNIC delle macchine virtuali vengono migrate dal TEP con errore a un TEP integro nello stesso host ESXi. Se un ESXi ha due TEP ed entrambi includono errori, le vNIC delle macchine virtuali non possono essere migrate.
Ogni macchina virtuale può avere più di una vNIC. Ogni vNIC è associata a un singolo TEP. I pacchetti della vNIC vengono incapsulati prima di essere inviati nell'uplink. Più vNIC possono essere mappate a un singolo TEP. La mappatura viene decisa in base ai criteri di raggruppamento uplink.
Nota: HA TEP supporta solo TEP IPv4.
Prerequisiti
In un singolo host ESXi sono configurati almeno due TEP. Assicurarsi che il profilo uplink utilizzato per creare un profilo del nodo di trasporto (TNP) o la configurazione di un singolo nodo di trasporto utilizzi almeno due uplink attivi (TEP).
Procedura
- Creare un profilo del commutatore host HA 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"
}
in cui
- enabled: indica se HA TEP è abilitata o meno. Il valore "true" indica che HA TEP è abilitata mentre il valore "false" indica che è disabilitata.
- failover_timeout: timeout del failover dell'alta disponibilità di TEP (in secondi). Questa proprietà controlla dopo quanto tempo la vNIC delle macchine virtuali deve essere spostata in un TEP integro alternativo dopo che viene rilevato un errore in una vmknic. Il valore di timeout predefinito è 5 secondi. Il valore massimo supportato è 60 secondi.
- auto_recovery: specifica lo stato dell'opzione di ripristino autonomo per la funzionalità alta disponibilità TEP. Quando auto_recovery è impostato su true, la vmknic con errore viene verificata internamente dopo ogni sequenza ciclica. Se la vmknic con errore viene ripristinata, la macchina virtuale viene spostata di nuovo nella mappatura TEP iniziale, a condizione che la vNIC delle macchine virtuali fosse mappata a tale TEP. Per impostazione predefinita, auto_recovery è impostato su true. Durante il ripristino automatico, si verifica un'interruzione delle macchine virtuali se TEP ha ancora lo stato di errore. Il tempo di interruzione viene calcolato utilizzando la formula:
failover_timeout + bfd timeout + 1
. Il valore predefinito di bfd timeout
è 4 secondi.
- auto_recovery_initial_wait: questa proprietà controlla dopo quanto tempo deve essere avviato il ripristino autonomo. Il periodo di attesa iniziale minimo è 300 secondi, mentre il periodo di attesa massimo è 3600 secondi. Se il periodo di attesa iniziale è 300 secondi, il ripristino automatico inizia dopo 300 secondi.
- auto_recovery_max_backoff: viene eseguito un tentativo di ripristino iniziale dopo auto_recovery_initial_wait. Se il ripristino non riesce, vengono effettuati tentativi aggiuntivi dopo il raddoppio del tempo di ritardo precedente. Quando il ritardo raggiunge auto_recovery_max_backoff, il ritardo smette di aumentare e vengono effettuati tutti gli altri tentativi ogni auto_recovery_max_backoff.
- Per collegare un profilo HA TEP a tutti gli host ESXi, creare un TNP con la chiave del profilo HA TEP e le proprietà del valore aggiunte alla sezione Profili commutator host oppure preparare singoli nodi di trasporto con la chiave del profilo HA TEP e le proprietà del valore.
PUT https://<nsx-policy-manager>/policy/api/v1/infra/host-transport-node-profiles/<tnp-id>
Nel parametro <tnp-id>
, immettere l'ID del profilo del nodo di trasporto.
{
"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: Se non si configura TNP con HA TEP, NSX crea un profilo HA TEP predefinito. Questo profilo HA TEP predefinito è configurato con valori predefiniti. HA TEP è disabilitato.
- Per conoscere l'ID del profilo HA TEP creato nel passaggio 1, eseguire l'API seguente:
get https://<nsx-manager>/policy/api/v1/infra/host-switch-profiles/vtephaprofile1
Nella risposta GET è possibile recuperare il valore del profilo HA TEP indicato nel campo id
.
- Per verificare se il profilo del commutatore host HA TEP è applicato ai nodi di trasporto, eseguire l'API seguente.
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>
è l'ID restituito durante la creazione del profilo HA TEP nel passaggio 1.
- È inoltre possibile attivare un ripristino manuale di un TEP con errore e migrare le macchine virtuali associate in un TEP integro senza attendere l'avvio del ripristino automatico.
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"
}
in cui vmk10 è il nome di TEP.
- Se nelle vmknic dei TEP si verificano errori, eseguire l'API di allarme per visualizzare i dettagli relativi agli errori o visualizzare gli errori nel dashboard di NSX Manager.
Quando si verifica un errore in una vmknic, è possibile che NSX impieghi almeno 60 secondi per generare un allarme. Analogamente, quando un TEP torna attivo dopo lo stato di errore, NSX può impiegare fino a 60 secondi per riportare il nuovo stato.
GET https://<nsx-manager>/api/v1/alarms?feature_name=tep_health
- Dopo aver corretto gli errori relativi a IP o BFD, verificare il parametro state per conoscere lo stato delle vmknic o di 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"
},
risultati
Se BFD è inattivo, NSX determina se il TEP con errore è di nuovo attivo utilizzando il meccanismo di ripristino automatico o manuale.
Se l'IP non è inizialmente disponibile ma viene riassegnato a un TEP con errore, NSX utilizza un meccanismo integrato per determinare quando TEP è di nuovo attivo. Non utilizza il meccanismo di ripristino manuale o automatico.
Se il TEP con errore non torna attivo:
- Durante il processo di ripristino automatico o manuale, è possibile che nella vNIC della macchina virtuale si verifichi un'interruzione temporanea della rete.
- L'interruzione della rete potrebbe verificarsi perché durante il controllo BFD la vNIC della macchina virtuale è ancora mappata al TEP con errore.
- Il tempo di interruzione della rete viene calcolato utilizzando la formula:
failover_timeout + bfd timeout + 1
, ovvero 10 secondi. Il valore predefinito di bfd timeout
è 4 secondi.
Se il TEP con errore non torna comunque attivo, la vNIC della macchina virtuale viene rimappata a un TEP integro disponibile nell'host. Se nessun TEP è integro, la vNIC della macchina virtuale viene mappata al TEP originale.