La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
In questo documento viene descritto come comprendere e risolvere i problemi relativi all'integrazione di ACI Virtual Machine Manager (VMM).
Il materiale di questo documento è stato estratto dai capitoli Risoluzione dei problemi relativi a Cisco Application Centric Infrastructure, Second Edition, in particolare Integrazione VMM - Panoramica, Integrazione VMM - Connettività vCenter, Integrazione VMM - Individuazione dinamica host e Integrazione VMM - Bilanciamento del carico uplink di Hypervisor.
I controller ACI sono in grado di integrarsi con VMM (Virtual Machine Manager) di terze parti.
Questa è una delle caratteristiche principali di ACI in quanto semplifica e automatizza le operazioni per la configurazione di rete end-to-end del fabric e per i carichi di lavoro che vi si connettono. ACI offre un unico modello di criteri di sovrapposizione che può essere esteso a più tipi di carico di lavoro, ovvero macchine virtuali, server bare metal e contenitori.
In questo capitolo verranno trattati in modo specifico alcuni scenari tipici di risoluzione dei problemi relativi all'integrazione di VMware vCenter VMM.
Il lettore procederà attraverso:
I meccanismi tramite i quali APIC è in grado di interfacciarsi con il controller vCenter dipendono dall'account utente associato a un determinato dominio VMM. L'utente vCenter associato al dominio VMM deve soddisfare requisiti specifici per garantire che l'APIC possa eseguire correttamente le operazioni su vCenter, sia che esegua il push e il recupero dell'inventario e delle configurazioni, sia che esegua il monitoraggio e l'ascolto degli eventi correlati all'inventario gestito.
Il modo più semplice per eliminare il problema relativo a tali requisiti consiste nell'utilizzare l'account vCenter dell'amministratore con accesso completo; tuttavia, questo tipo di libertà non è sempre disponibile per l'amministratore ACI.
I privilegi minimi per un account utente personalizzato, a partire dalla versione ACI 4.2, sono i seguenti:
I problemi RBAC si verificano più spesso durante la configurazione iniziale di un dominio VMM, ma potrebbero verificarsi se un amministratore di vCenter modificasse le autorizzazioni dell'account utente associato al dominio VMM dopo l'installazione iniziale.
Il sintomo può presentarsi in questi modi:
Verificare che tutte le autorizzazioni siano concesse all'utente vCenter configurato nel dominio VMM.
In alternativa, è possibile accedere direttamente a vCenter con le stesse credenziali definite nella configurazione del dominio VMM e tentare operazioni simili (inclusa la creazione di gruppi di porte). Se l'utente non è in grado di eseguire queste stesse operazioni mentre è connesso direttamente a vCenter, è evidente che all'utente non vengono concesse le autorizzazioni corrette.
Quando si risolve un problema relativo alla connettività VMM, è importante notare alcuni dei comportamenti fondamentali della comunicazione di ACI con vCenter.
Il primo e più pertinente comportamento è che solo un APIC nel cluster invia la configurazione e raccoglie l'inventario in un determinato punto. L'APIC è indicato come coordinatore della condivisione per questo dominio VMM. Tuttavia, più APIC sono in ascolto di eventi vCenter al fine di tenere conto di uno scenario in cui il coordinatore della condivisione ha perso un evento per qualsiasi motivo. In base alla stessa architettura distribuita degli APIC, un determinato dominio VMM disporrà di un APIC che gestisce i dati primari e le funzionalità (in questo caso, la linea guida della condivisione) e di due repliche (nel caso di VMM sono denominate follower). Per distribuire la gestione delle comunicazioni e delle funzionalità VMM tra gli APIC, due domini VMM possono avere lo stesso o un diverso coordinatore di condivisione.
Per individuare lo stato di connettività di vCenter, passare al controller VMM di interesse nella GUI o utilizzare il comando CLI riportato di seguito:
Dominio VMM VMWare - stato connettività vCenter
apic2# show vmware domain name VDS_Site1 vcenter 10.48.176.69
Name : bdsol-aci37-vc
Type : vCenter
Hostname or IP : 10.48.176.69
Datacenter : Site1
DVS Version : 6.0
Status : online
Last Inventory Sync : 2019-10-02 09:27:23
Last Event Seen : 1970-01-01 00:00:00
Username : administrator@vsphere.local
Number of ESX Servers : 2
Number of VMs : 2
Faults by Severity : 0, 0, 0, 0
Leader : bdsol-aci37-apic1
Managed Hosts:
ESX VMs Adjacency Interfaces
--------------- -------- ---------- ------------------------------------------------
10.48.176.66 1 Direct leaf-101 eth1/11, leaf-102 eth1/11
10.48.176.67 1 Direct leaf-301 eth1/11, leaf-302 eth1/11
Se un controller VMM è indicato come offline, verrà generato un errore simile al seguente:
Fault fltCompCtrlrConnectFailed
Rule ID:130
Explanation:
This fault is raised when the VMM Controller is marked offline. Recovery is in process.
Code: F0130
Message: Connection to VMM controller: hostOrIp with name name in datacenter rootContName in domain: domName is failing repeatedly with error: [remoteErrMsg]. Please verify network connectivity of VMM controller hostOrIp and check VMM controller user credentials are valid.
Questa procedura può essere utilizzata per risolvere i problemi di connettività tra VC e APIC.
1. Identificazione della linea guida condivisa
Il primo passaggio per la risoluzione di un problema di connettività tra APIC e vCenter consiste nel capire quale APIC è il leader condiviso per il dominio VMM specificato. Il modo più semplice per determinare queste informazioni è eseguire il comando show vmware domain name <dominio> su qualsiasi access point APIC.
apic1# show vmware domain name VDS_Site1
Domain Name : VDS_Site1
Virtual Switch Mode : VMware Distributed Switch
Vlan Domain : VDS_Site1 (1001-1100)
Physical Interfaces : leaf-102 eth1/11, leaf-301 eth1/11, leaf-302 eth1/11,
leaf-101 eth1/11
Number of EPGs : 2
Faults by Severity : 0, 0, 0, 0
LLDP override : RX: enabled, TX: enabled
CDP override : no
Channel Mode override : mac-pinning
NetFlow Exporter Policy : no
Health Monitoring : no
vCenters:
Faults: Grouped by severity (Critical, Major, Minor, Warning)
vCenter Type Datacenter Status ESXs VMs Faults
-------------------- -------- -------------------- -------- ----- ----- ---------------
10.48.176.69 vCenter Site1 online 2 2 0,0,0,0
APIC Owner:
Controller APIC Ownership
------------ -------- ---------------
bdsol- apic1 Leader
aci37-vc
bdsol- apic2 NonLeader
aci37-vc
bdsol- apic3 NonLeader
aci37-vc
2. Verifica della connettività a vCenter
Dopo aver identificato l'APIC che comunica attivamente con vCenter, verificare la connettività IP con strumenti quali il comando ping.
apic1# ping 10.48.176.69
PING 10.48.176.69 (10.48.176.69) 56(84) bytes of data.
64 bytes from 10.48.176.69: icmp_seq=1 ttl=64 time=0.217 ms
64 bytes from 10.48.176.69: icmp_seq=2 ttl=64 time=0.274 ms
64 bytes from 10.48.176.69: icmp_seq=3 ttl=64 time=0.346 ms
64 bytes from 10.48.176.69: icmp_seq=4 ttl=64 time=0.264 ms
64 bytes from 10.48.176.69: icmp_seq=5 ttl=64 time=0.350 ms
^C
--- 10.48.176.69 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4084ms
rtt min/avg/max/mdev = 0.217/0.290/0.350/0.052 ms
Se vCenter è stato configurato utilizzando l'FQDN anziché l'indirizzo IP, è possibile utilizzare il comando nslookup per verificare la risoluzione dei nomi.
apic1:~> nslookup bdsol-aci37-vc
Server: 10.48.37.150
Address: 10.48.37.150#53
Non-authoritative answer:
Name: bdsol-aci37-vc.cisco.com
Address: 10.48.176.69
3. Verificare se viene utilizzato OOB o INB
Controllare la tabella di routing APIC per verificare se per la connettività si preferisce usare il protocollo fuori banda o in banda e quale gateway viene usato:
apic1# bash
admin@apic1:~> route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.48.176.1 0.0.0.0 UG 16 0 0 oobmgmt
4. Verificare che la porta 443 sia consentita tra tutti gli APIC e vCenter, inclusi eventuali firewall nel percorso di comunicazione.
vCenter <-> APIC - HTTPS (porta TCP 443) - comunicazione
La raggiungibilità HTTPS generale dagli APIC a vCenter può essere verificata con un ricciolo:
apic2# curl -v -k https://10.48.176.69
* Rebuilt URL to: https://10.48.176.69/* Trying 10.48.176.69...
* TCP_NODELAY set
* Connected to 10.48.176.69 (10.48.176.69) port 443 (#0)
...
Verificare che il coordinatore della condivisione abbia una connessione TCP stabilita sulla porta 443 utilizzando il comando netstat.
apic1:~> netstat -tulaen | grep 10.48.176.69
tcp 0 0 10.48.176.57:40806 10.48.176.69:443 ESTABLISHED 600 13062800
5. Acquisire un pacchetto
Se possibile, eseguire un'acquisizione dei pacchetti lungo il percorso tra il dispositivo master e vCenter per identificare se il traffico viene inviato e ricevuto da entrambi i dispositivi.
Questa tabella mostra un elenco di parametri VMWare VDS e specifica se possono essere configurati da APIC.
VMware VDS |
Valore predefinito |
Configurabile con i criteri APIC di Cisco? |
Nome |
Nome dominio VMM |
Sì (derivato da dominio) |
Descrizione |
'Switch virtuale APIC' |
No |
Nome cartella |
Nome dominio VMM |
Sì (derivato da dominio) |
Version |
Massima supportata da vCenter |
Sì |
Discovery Protocol |
LLDP |
Sì |
Porte uplink e nomi uplink |
8 |
Sì (da Cisco APIC release 4.2(1)) |
Prefisso nome uplink |
uplink |
Sì (da Cisco APIC release 4.2(1)) |
MTU massima |
9000 |
Sì |
Criteri LACP |
disabled |
Sì |
Mirroring delle porte |
0 sessioni |
Sì |
Allarmi |
2 allarmi aggiunti a livello di cartella |
No |
Questa tabella mostra un elenco di parametri del gruppo di porte VMWare VDS e specifica se possono essere configurati dall'APIC.
Gruppo porte VDS VMware |
Valore predefinito |
Configurabile tramite criteri APIC |
Nome |
Nome tenant | Nome profilo applicazione | Nome EPG |
Sì (derivato da EPG) |
Binding porta |
Associazione statica |
No |
VLAN |
Selezionato dal pool di VLAN |
Sì |
Algoritmo di bilanciamento del carico |
Derivato in base alla policy del canale della porta su APIC |
Sì |
Modalità promiscua |
Disabled |
Sì |
Trasmissione falsificata |
Disabled |
Sì |
Cambia MAC |
Disabled |
Sì |
Blocca tutte le porte |
FALSO |
No |
Gli eventi di sincronizzazione dell'inventario vengono generati per garantire che l'APIC riconosca gli eventi vCenter che richiedono l'aggiornamento dinamico dei criteri. Esistono due tipi di eventi di sincronizzazione dell'inventario che possono verificarsi tra vCenter e APIC: una sincronizzazione dell'inventario completa e una sincronizzazione dell'inventario basata sugli eventi. La pianificazione predefinita di una sincronizzazione dell'inventario completa tra APIC e vCenter è ogni 24 ore, ma anche queste possono essere attivate manualmente. Le sincronizzazioni dell'inventario basate su eventi sono in genere legate ad attività attivate, ad esempio vMotion. In questo scenario, se una macchina virtuale si sposta da un host all'altro e tali host sono collegati a due switch foglia diversi, l'APIC ascolterà l'evento di migrazione della VM e, nello scenario di immediatezza dell'installazione su richiesta, annullerà la programmazione dell'EPG sulla foglia di origine e programmerà l'EPG sulla foglia di destinazione.
A seconda dell'immediatezza dell'installazione degli EPG associati a un dominio VMM, la mancata estrazione dell'inventario da vCenter potrebbe avere conseguenze indesiderate. Nello scenario in cui l'inventario non è stato completato o è parziale, verrà sempre generato un errore che indica l'oggetto o gli oggetti che hanno causato il problema.
Scenario 1 - Macchina virtuale con supporto non valido:
Se una macchina virtuale viene spostata da un vCenter a un altro o se la macchina virtuale presenta un supporto non valido (ad esempio, un collegamento di un gruppo di porte a un DVS precedente/eliminato), verranno segnalati problemi operativi per la vNIC.
Fault fltCompVNicOperationalIssues
Rule ID:2842
Explanation:
This fault is raised when ACI controller failed to update the properties of a VNIC (for instance, it can not find the EPG that the VNIC attached to).
Code: F2842
Message: Operational issues detected for VNic name on VM name in VMM controller: hostOrIp with name name in datacenter rootContName in domain: domName due to error: issues.
Resolution:
Remediate the virtual machines indicated in the fault by assigning a valid port group on the affected vNIC of the VM.
Scenario 2: l'amministratore di vCenter ha modificato un oggetto gestito da VMM in vCenter:
La modifica degli oggetti gestiti da APIC da vCenter non è un'operazione supportata. Questo errore si verifica se viene eseguita un'operazione non supportata su vCenter.
Fault fltCompCtrlrUnsupportedOperation
Rule ID:133
Explanation:
This fault is raised when deployment of given configuration fails for a Controller.
Code: F0133
Message: Unsupported remote operation on controller: hostOrIp with name name in datacenter rootContName in domain domName detected, error: [deployIssues]
Resolution:
If this scenario is encountered, try to undo the unsupported change in vCenter and then trigger an 'inventory sync' manually.
Dominio VMM VMWare - controller vCenter - attiva sincronizzazione inventario
Quando si crea un nuovo controller vCenter come parte di un dominio VMM, l'impostazione predefinita per la versione DVS sarà l'utilizzo di "vCenter Default". Se si seleziona questa opzione, la versione DVS verrà creata con la versione di vCenter.
Dominio VMM VMWare - Creazione controller vCenter
Ciò significa che nell'esempio di un vCenter con server 6.5 ed ESXi con server 6.0, l'APIC creerà un DVS con versione 6.5 e quindi l'amministratore di vCenter non sarà in grado di aggiungere i server ESXi con versione 6.0 ad ACI DVS.
DVS gestito APIC - aggiunta host vCenter - elenco vuoto
DVS gestito APIC - aggiunta host vCenter - host incompatibili
Pertanto, quando si crea un dominio VMM, assicurarsi di selezionare la "versione DVS" corretta in modo che i server ESXi necessari possano essere aggiunti al DVS.
L'integrazione di VMM in ACI si differenzia dal provisioning manuale in quanto la struttura è in grado di individuare in modo dinamico dove gli host e le macchine virtuali applicabili sono connessi per implementare in modo efficiente le regole. Tramite questo processo dinamico, ACI è in grado di ottimizzare l'utilizzo delle risorse hardware sugli switch foglia, in quanto VLAN, SVI, regole di zoning e altro ancora vengono implementati sui nodi solo quando è connesso un endpoint che richiede la policy. Il vantaggio per l'amministratore di rete, da un punto di vista di facilità d'uso, è che ACI fornirà la VLAN/policy quando le VM si connettono in modo automatizzato. Per determinare dove distribuire i criteri, l'APIC utilizzerà le informazioni provenienti da più origini. In questo diagramma vengono illustrati i passaggi di base del processo di individuazione host quando si utilizza un dominio VMM basato su DVS.
Dominio VMM VMWare: flusso di lavoro di distribuzione
In breve, questi passaggi fondamentali si verificano quando:
Come si può notare, CDP/LLDP svolge un ruolo chiave nel processo di rilevamento ed è importante verificare che sia configurato correttamente ed entrambi i dispositivi utilizzino lo stesso protocollo.
In un'implementazione che utilizza uno chassis blade con uno switch intermedio tra gli switch foglia e l'hypervisor, l'APIC deve "unire" l'adiacenza. In questo scenario, è possibile utilizzare più protocolli di rilevamento, in quanto lo switch intermedio ha requisiti di protocollo diversi rispetto all'host.
In una configurazione con un server blade e uno switch intermedio (ossia, uno switch con chassis blade), ACI è in grado di rilevare lo switch intermedio e mappare gli hypervisor sottostanti. In ACI, lo switch intermedio è detto "LooseNode" o "Unmanaged Fabric Node". I LooseNodes rilevati possono essere visualizzati in Fabric > Inventario > Appartenenza fabric > Nodi fabric non gestiti. Passando a uno di questi tipi di server nella GUI, l'utente può visualizzare il percorso dallo switch foglia a quello intermedio fino all'host.
Interfaccia utente APIC - Nodi fabric non gestiti (LooseNodes)
Con il rilevamento LLDP o CDP, ACI può determinare la topologia per tali LooseNodes, dato che l'hypervisor a valle dello switch intermedio è gestito tramite l'integrazione VMM e la foglia stessa ha una adiacenza allo switch intermedio da downstream.
Questo concetto è illustrato dalla seguente immagine:
Interfaccia utente APIC - Percorso nodo fabric non gestito
Negli scenari in cui i servizi critici utilizzano i DVS integrati in VMM, ad esempio la connettività di gestione a vCenter/ESXi, è prudente utilizzare l'Immediatezza della risoluzione di pre-provisioning. Con questa impostazione, il meccanismo di rilevamento dinamico dell'host viene rimosso e le policy/VLAN vengono invece programmate in modo statico sulle interfacce rivolte all'host. In questa configurazione, le VLAN VMM verranno sempre distribuite su tutte le interfacce collegate all'AEP a cui fa riferimento il dominio VMM. In questo modo si evita che una VLAN critica (ad esempio la gestione) venga rimossa da una porta a causa di un evento adiacente al protocollo di rilevamento.
Per ulteriori informazioni, fare riferimento al seguente diagramma:
Esempio di pre-provisioning della distribuzione
Se è stato impostato il pre-provisioning per un EPG nel dominio VMM ACI_VDS1, le VLAN verranno distribuite sui collegamenti per Server1 ma non per Server2, in quanto l'AEP di Server2 non include il dominio VMM ACI_VDS1.
Per riepilogare le impostazioni di immediatezza della risoluzione:
In questo scenario, l'integrazione VMM è stata configurata e il DVS è stato aggiunto all'hypervisor, ma la VM non è in grado di risolvere ARP per il gateway in ACI. Affinché la VM disponga della connettività di rete, verificare che l'adiacenza sia stata stabilita e che le VLAN siano installate.
In primo luogo, l'utente può verificare se la foglia ha rilevato l'host usando show lldp neighbors o show cdp neighbors sulla foglia, a seconda del protocollo selezionato.
Leaf101# show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID
bdsol-aci37-apic1 Eth1/1 120 eth2-1
bdsol-aci37-apic2 Eth1/2 120 eth2-1
bdsol-aci37-os1 Eth1/11 180 B 0050.565a.55a7
S1P1-Spine201 Eth1/49 120 BR Eth1/1
S1P1-Spine202 Eth1/50 120 BR Eth1/1
Total entries displayed: 5
Se necessario, dal punto di vista della risoluzione dei problemi, è possibile convalidare questa condizione dal lato ESXi sia sulla CLI che sulla GUI:
[root@host:~] esxcli network vswitch dvs vmware list
VDS_Site1
Name: VDS_Site1
...
Uplinks: vmnic7, vmnic6
VMware Branded: true
DVPort:
Client: vmnic6
DVPortgroup ID: dvportgroup-122
In Use: true
Port ID: 0
Client: vmnic7
DVPortgroup ID: dvportgroup-122
In Use: true
Port ID: 1
[root@host:~] esxcfg-nics -l
Name PCI Driver Link Speed Duplex MAC Address MTU Description
vmnic6 0000:09:00.0 enic Up 10000Mbps Full 4c:77:6d:49:cf:30 9000 Cisco Systems Inc Cisco VIC Ethernet NIC
vmnic7 0000:0a:00.0 enic Up 10000Mbps Full 4c:77:6d:49:cf:31 9000 Cisco Systems Inc Cisco VIC Ethernet NIC
[root@host:~] vim-cmd hostsvc/net/query_networkhint --pnic-name=vmnic6 | grep -A2 "System Name"
key = "System Name",
value = "Leaf101"
}
vCenter Web Client - host - dettagli adiacenze LLDP/CDP vmnic
Se l'adiacenza LLDP foglia non può essere rilevata dall'host ESXi, ciò è spesso causato dall'utilizzo di una scheda di rete configurata per generare LLDPDU anziché il sistema operativo ESXi. Assicurarsi di verificare se la scheda di rete ha il protocollo LLDP abilitato e quindi sta utilizzando tutte le informazioni LLDP. In questo caso, accertarsi di disattivare LLDP sulla scheda stessa in modo che sia controllata tramite i criteri vSwitch.
Un'altra causa può essere un disallineamento tra i protocolli di rilevamento utilizzati tra leaf ed ESXi Hypervisor. Assicurarsi che su entrambe le estremità venga utilizzato lo stesso protocollo di rilevamento.
Per verificare se le impostazioni CDP/LLDP sono allineate tra ACI e DVS nell'interfaccia utente APIC, selezionare Networking virtuale > Domini VMM > VMWare > Criteri > Criteri vSwitch. Assicurarsi di abilitare solo i criteri LLDP o CDP in quanto si escludono a vicenda.
Interfaccia utente APIC - Dominio VMM VMWare - Criteri vSwitch
In vCenter andare su: Reti > VDS > Configura.
Interfaccia utente di vCenter Web Client - Proprietà VDS
Se necessario, correggere le impostazioni LLDP/CDP.
Convalidare quindi che l'APIC osservi il vicinato LLDP/CDP dell'host ESXi rispetto allo switch foglia nell'interfaccia utente in Networking virtuale > Domini VMM > VMWare > Criteri > Controller > Hypervisor > Generale.
Interfaccia utente APIC - Dominio VMWare VMM - Dettagli hypervisor
Se vengono visualizzati i valori previsti, l'utente può verificare che la VLAN sia presente sulla porta verso l'host.
S1P1-Leaf101# show vlan encap-id 1035
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
12 Ecommerce:Electronics:APP active Eth1/11
VLAN Type Vlan-mode
---- ----- ----------
12 enet CE
In uno scenario in cui il traffico di gestione di vCenter o ESXi deve utilizzare il DVS integrato VMM, è importante prestare particolare attenzione ad evitare una situazione di stallo nell'attivazione delle adiacenze dinamiche e nell'attivazione delle VLAN richieste.
Per vCenter, che in genere viene generato prima della configurazione dell'integrazione VMM, è importante utilizzare un dominio fisico e un percorso statico per garantire che la VLAN di crittografia VM di vCenter sia sempre programmata sugli switch foglia in modo da poter essere utilizzata prima della completa configurazione dell'integrazione VMM. Anche dopo aver impostato l'integrazione VMM, si consiglia di lasciare questo percorso statico in posizione per garantire sempre la disponibilità di questo EPG.
Per gli hypervisor ESXi, come indicato nella Cisco ACI Virtualization Guide (Guida alla virtualizzazione di Cisco ACI) su Cisco.com, durante la migrazione al vDS è importante assicurarsi che l'EPG a cui verrà connessa l'interfaccia VMK sia installato con l'immediatezza della risoluzione impostata su Pre-provision. Ciò garantirà che la VLAN sia sempre programmata sugli switch foglia senza fare affidamento sul rilevamento LLDP/CDP degli host ESXi.
Le cause tipiche dei problemi di individuazione LooseNode sono:
Quando viene visualizzato questo errore:
Affected Object: comp/prov-VMware/ctrlr-[DVS-DC1-ACI-LAB]-DVS1/hv-host-104
Fault delegate: [FSM:FAILED]: Get LLDP/CDP adjacency information for the physical adapters on the host: bdsol-aci20-os3 (TASK:ifc:vmmmgr:CompHvGetHpNicAdj)
Esaminare il flusso di lavoro nella sezione VM non è in grado di risolvere ARP per il gateway predefinito poiché ciò significa che mancano le adiacenze CDP/LLDP. Queste adiacenze possono essere verificate in modo completo.
Quando si collegano hypervisor come ESXi a una struttura ACI, in genere sono connessi a più uplink. Infatti, si consiglia di collegare un host ESXi ad almeno due switch foglia. In questo modo si riduce al minimo l'impatto degli scenari di errore o degli aggiornamenti.
Per ottimizzare l'utilizzo degli uplink da parte dei carichi di lavoro in esecuzione su un hypervisor, le configurazioni di VMware vCenter consentono di configurare più algoritmi di bilanciamento del carico per il traffico generato da VM verso gli uplink dell'hypervisor.
Per garantire la corretta connettività, è fondamentale che tutti gli hypervisor e la struttura ACI siano allineati alla stessa configurazione dell'algoritmo di bilanciamento del carico. In caso contrario, il flusso del traffico e gli spostamenti degli endpoint nell'infrastruttura ACI potrebbero diminuire in modo intermittente.
Questa condizione può essere rilevata in un fabric ACI da un numero eccessivo di avvisi, ad esempio:
F3083 fault
ACI has detected multiple MACs using the same IP address 172.16.202.237.
MACs: Context: 2981888. fvCEps:
uni/tn-BSE_PROD/ap-202_Voice/epg-VLAN202_Voice/cep-00:50:56:9D:55:B2;
uni/tn-BSE_PROD/ap-202_Voice/epg-VLAN202_Voice/cep-00:50:56:9D:B7:01;
or
[F1197][raised][bd-limits-exceeded][major][sys/ctx-[vxlan-2818048]/bd-[vxlan-16252885]/fault-F1197]
Learning is disabled on BD Ecommerce:BD01
In questo capitolo verrà illustrata la connettività host VMWare ESXi in ACI, ma è applicabile alla maggior parte degli hypervisor.
Se si esaminano i vari modi in cui un host ESXi può connettersi a un fabric ACI, questi sono suddivisi in 2 gruppi, algoritmi di bilanciamento del carico dipendenti e indipendenti dallo switch.
Gli algoritmi di bilanciamento del carico indipendenti dallo switch consentono di stabilire connessioni in cui non è necessaria alcuna configurazione specifica dello switch. Per il bilanciamento del carico dipendente dallo switch, sono necessarie configurazioni specifiche dello switch.
Verificare che il criterio vSwitch sia in linea con i requisiti del gruppo di criteri di accesso ACI indicati nella tabella seguente:
Modalità di raggruppamento e failover di VMware |
Criterio ACI vSwitch |
Descrizione |
Gruppo di criteri di accesso ACI - Canale porta richiesto |
Route basata sulla porta virtuale di origine |
Pinning MAC |
Selezionare un uplink in base agli ID delle porte virtuali sullo switch. Dopo aver selezionato un uplink per una macchina virtuale o una scheda VMKernel, lo switch virtuale inoltra sempre il traffico attraverso lo stesso uplink per questa macchina virtuale o scheda VMKernel. |
No |
Route basata sull'hash MAC di origine |
N/D |
Selezionare un uplink in base a un hash dell'indirizzo MAC di origine |
N/D |
Ordine di failover esplicito |
Usa modalità di failover esplicito |
Dall'elenco delle schede attive, utilizzare sempre l'uplink di ordine più alto che soddisfa i criteri di rilevamento del failover. Con questa opzione non viene eseguito alcun bilanciamento del carico effettivo. |
No |
Aggregazione link (LAG) - Basata su hash IP |
Canale statico - Modalità attiva |
Selezionare un uplink in base a un hash degli indirizzi IP di origine e di destinazione di ciascun pacchetto. Per i pacchetti non IP, lo switch usa i dati di questi campi per calcolare l'hash. Per i raggruppamenti basati su IP, è necessario che sul lato ACI un canale porta/VPC sia configurato con la modalità 'on'. |
Sì (modalità canale impostata su 'on') |
Aggregazione link (LAG) - LACP |
LACP attivo/passivo |
Selezionare un uplink in base a un hash selezionato (sono disponibili 20 diverse opzioni di hash). Per il raggruppamento basato su LACP, sul lato ACI è necessario configurare una porta-canale/VPC con LACP abilitato. Assicurarsi di creare una regola per il ritardo avanzato in ACI e applicarla alla policy VSswitch. |
Sì (modalità canale impostata su 'LACP attivo/passivo') |
Route basata su carico fisico NIC (LBT) |
Pinning MAC - Caricamento NIC fisico |
Disponibile per gruppi di porte distribuite o porte distribuite. Selezionare un uplink in base al carico corrente delle schede di rete fisiche collegate al gruppo di porte o alla porta. Se un uplink rimane occupato al 75% o a una velocità superiore per 30 secondi, l'host vSwitch sposta una parte del traffico della macchina virtuale in una scheda fisica con capacità disponibile. |
No |
Visualizza questa schermata su come convalidare la policy port-channel come parte della policy vSwitch in uso.
Policy ACI vSwitch — Port Channel Policy
Nota: per una descrizione più dettagliata delle funzionalità di rete di VMware, vedere il documento sulla rete vSphere all'indirizzo https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.networking.doc/GUID-D34B1ADD-B8A7-43CD-AA7E-2832A0F7EE76.html
Quando si utilizzano server Cisco UCS serie B, è importante notare che si connettono all'interno dello chassis a interconnessioni fabric UCS (FI) che non dispongono di una corsia dati unificata. Questo caso di utilizzo si applica anche ad altri fornitori che utilizzano una topologia simile. Per questo motivo può esserci una differenza tra il metodo di bilanciamento del carico utilizzato da un lato dello switch foglia ACI e il lato vSwitch.
Questa è una topologia UCS FI con ACI:
Cisco UCS FI con switch foglia ACI - topologia
Aspetti principali da notare:
Per configurare correttamente questa opzione:
Quando il ping MAC è configurato sulla policy port-channel come parte del criterio vSwitch in ACI, viene mostrato come configurazione del raggruppamento "Route based on the original virtual port" (Route basato sulla porta virtuale di origine) dei gruppi di porte sul VDS.
ACI — Port Channel Policy (Policy del canale della porta) come parte della policy vSwitch
Il criterio del canale della porta utilizzato nell'esempio è denominato automaticamente dalla procedura guidata, pertanto è denominato "CDS_lacpLagPol" anche se viene utilizzata la modalità "MAC Pinning".
VMware vCenter — ACI VDS — Port Group — Load Balancing impostazione
Revisione | Data di pubblicazione | Commenti |
---|---|---|
2.0 |
16-Aug-2024 |
Formattazione, problemi di stile, testo dei, intestazioni |
1.0 |
05-Aug-2022 |
Versione iniziale |