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 risolvere i problemi relativi all'aggiornamento ACI (Application Centric Infrastructure) e vengono descritte le procedure ottimali da seguire prima e durante il processo di aggiornamento.
L'aggiornamento ACI comporta l'aggiornamento del software Application Policy Infrastructure Controller (APIC) e degli switch (foglia e dorso). Un aggiornamento dello switch è in genere molto semplice, ma un aggiornamento APIC può comportare alcuni problemi del cluster. Di seguito sono riportati alcuni controlli preliminari che Cisco consiglia di preparare prima di avviare un aggiornamento.
Prima di avviare l'aggiornamento ACI, accertarsi di eseguire alcune verifiche preliminari per evitare comportamenti imprevisti.
Molti errori nell'infrastruttura ACI indicano che sono presenti criteri non validi o in conflitto oppure interfacce disconnesse e così via. Comprendere il trigger e cancellarlo prima di avviare l'aggiornamento. Tenere presente che i difetti encap already been used
o Routed port is in L2 mode
potrebbe causare un'interruzione imprevista. Quando si aggiorna lo switch, vengono scaricate da zero tutte le policy dall'APIC. Di conseguenza, i criteri imprevisti potrebbero assumere il controllo dei criteri previsti e causare un'interruzione delle attività.
Nota: Se si abilita la crittografia per il backup, assicurarsi di salvare la chiave di crittografia. In caso contrario, tutte le password degli account utente, inclusa la password admin, non verrebbero importate correttamente.
date
per controllare l'ora di sistema corrente. Immettere il comando grep "ipmi" /var/log/dme/log/svc_ifc_ae.bin.log | tail -5
e controllare l'ultima volta in cui il processo AE ha interrogato l'IPMI. Confrontare l'ora con l'ora di sistema per verificare se l'ultima query rientra nella finestra di 10 secondi dell'ora di sistema. Nota: Non riavviare due o più APIC contemporaneamente per evitare problemi di cluster.
acidiag avread | grep id= | cut -d ' ' -f 9,10,20,26,46
da qualsiasi CLI APIC per controllare lo stato di integrità di APIC. Se il livello di integrità non è 255 per nessun APIC, non avviare l'aggiornamento. Avviare sempre la risoluzione dei problemi di APIC1 se l'aggiornamento si blocca o non riesce. Se l'aggiornamento di APIC1 non è ancora stato completato, non eseguire alcuna operazione in APIC2 e APIC3. Il processo di aggiornamento di APIC è incrementale, pertanto APIC2 eseguirà l'aggiornamento solo dopo il completamento dell'aggiornamento e ne informerà APIC2 e così via. La violazione di questa condizione potrebbe pertanto compromettere il funzionamento del cluster, causando il danneggiamento del database e la ricostruzione del cluster.
In questo scenario, l'aggiornamento di APIC1 è riuscito, ma APIC2 è ancora bloccato al 75%. Questo problema si verifica se le informazioni sulla versione di aggiornamento di APIC1 non vengono propagate ad APIC2 o versione successiva. Si tenga presente che svc_ifc_appliance_director
è responsabile della sincronizzazione della versione tra gli APIC.
Passaggio 1: Accertarsi che l'APIC1 possa eseguire il ping sul resto degli APIC con il relativo indirizzo IP TEP (Tunnel End Point), in modo da stabilire se è necessario risolvere il problema dallo switch foglia o continuare dall'APIC stesso. Se APIC1 non comunica con APIC2, è possibile chiamare il Technical Assistance Center (TAC) per risolvere il problema dello switch. Se APIC1 è in grado di eseguire il ping di APIC2, procedere con il secondo passaggio.
Passaggio 2: Poiché gli APIC possono eseguire il ping tra loro, le informazioni sulla versione APIC1 avrebbero dovuto essere replicate nel peer, ma in qualche modo non sono state accettate dal peer. Le informazioni sulla versione sono identificate da un timestamp della versione. È possibile confermare il timestamp della versione di APIC1 dalla CLI e dalla CLI di APIC2 che è in attesa al 75%.
Su APIC1
apic1# acidiag avread | grep id=1 | cut -d ' ' -f20-21
version=2.0(2f) lm(t):1(2018-07-25T18:01:04.907+11:00)
Su APIC2
apic2# acidiag avread | grep id=1 | cut -d ' ' -f20-21
version=2.0(1m) lm(t):1(2018-07-25T18:20:04.907+11:00)
Come si può vedere, il timestamp della versione di APIC2 (18:20:04) in esecuzione nella versione 2.0(1m) di questo esempio è superiore al timestamp della versione di APIC1 (18:01:04) in esecuzione nella versione 2.0(2f). Il processo di installazione di APIC2, pertanto, ritiene che l'aggiornamento di APIC1 non sia ancora completo e attende il 75%. L'aggiornamento di APIC2 ha inizio quando il timestamp della versione di APIC1 supera il timestamp della versione di APIC2. In base alla differenza di tempo, tuttavia, l'attesa potrebbe essere eccessiva. Per ripristinare il fabric da questo stato, è possibile aprire una richiesta TAC per ottenere assistenza nella risoluzione dei problemi e risolvere il problema da APIC1.