Risoluzione dei problemi quando Element Manager viene eseguito in modalità standalone

Introduzione

In questo documento viene illustrato come risolvere i problemi quando Element Manager viene eseguito in modalità autonoma.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• StarOs
• Architettura di base Ultra-M

Componenti usati

Le informazioni fornite in questo documento si basano sulla versione Ultra 5.1.x.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Ultra-M è una soluzione di base di pacchetti mobili preconfezionata e convalidata, progettata per semplificare l'installazione di VNF. OpenStack è Virtualized Infrastructure Manager (VIM) per Ultra-M ed è costituito dai seguenti tipi di nodi:

• Calcola
• Disco Object Storage - Compute (OSD - Compute)
• Controller
• Piattaforma OpenStack - Director (OSPD)

L'architettura di alto livello di Ultra-M e i componenti coinvolti sono illustrati in questa immagine:

Architettura UltraM

Questo documento è destinato al personale Cisco che ha familiarità con la piattaforma Cisco Ultra-M e descrive i passaggi richiesti da eseguire a livello OpenStack e StarOS VNF al momento della sostituzione del server dei controller.

Abbreviazioni

In questo articolo vengono utilizzate le abbreviazioni seguenti:

VNF	Funzione di rete virtuale
EM	Gestione elementi
VIP	Virtual IP Address
CLI	Riga di comando

Problema: EM può finire in questo stato come sembra da Ultra-M Health Manager

EM: 1 is not part of HA-CLUSTER,EM is running in standalone mode

A seconda della versione, possono essere presenti 2 o 3 EM in esecuzione sul sistema.

Nel caso in cui si disponga di 3 EM, due di essi sarebbero funzionali e il terzo solo per poter avere il cluster Zookeeper. Tuttavia, non viene utilizzato. 
Se uno dei due moduli funzionali non dovesse funzionare o non fosse raggiungibile, l'unità operativa sarebbe in modalità indipendente. 

Se sono stati distribuiti 2 moduli EM, nel caso in cui uno di essi non funzioni o non sia raggiungibile, i moduli EM rimanenti possono essere in modalità standalone. 

In questo documento viene spiegato cosa verificare in questo caso e come eseguire il ripristino.

  

Procedure di risoluzione dei problemi e ripristino

Passaggio 1. Verificare lo stato degli EM.

Connettersi all'indirizzo VIP EM e verificare che il nodo si trovi in questo stato:

root@em-0:~# ncs_cli -u admin -C
admin connected from 127.0.0.1 using console on em-0 
admin@scm# show ems 
EM VNFM ID SLA SCM PROXY
3 up down up
admin@scm#

Quindi, da qui, potete vedere che c'è solo una voce in SCM - ed è la voce per il nostro nodo. 

Se si riesce a collegarsi all'altro EM, è possibile visualizzare qualcosa come:

  
root@em-1# ncs_cli -u admin -C admin connected from 127.0.0.1 using
admin connected from 127.0.0.1 using console on em-1
admin@scm# show ems 
% No entries found. 

A seconda del problema riscontrato in EM, NCS CLI non è accessibile o il nodo può essere riavviato. 

Passaggio 2. Controllare i log in /var/log/em sul nodo che non fa parte del cluster.

Controllare i registri nel nodo in stato di problema. Quindi, per il campione menzionato, si naviga em-1 /var/log/em/zookeeper logs:

...
2018-02-01 09:52:33,591 [myid:4] - INFO [main:QuorumPeerMain@127] - Starting quorum peer
2018-02-01 09:52:33,619 [myid:4] - INFO [main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:2181
2018-02-01 09:52:33,627 [myid:4] - INFO [main:QuorumPeer@1019] - tickTime set to 3000
2018-02-01 09:52:33,628 [myid:4] - INFO [main:QuorumPeer@1039] - minSessionTimeout set to -1
2018-02-01 09:52:33,628 [myid:4] - INFO [main:QuorumPeer@1050] - maxSessionTimeout set to -1
2018-02-01 09:52:33,628 [myid:4] - INFO [main:QuorumPeer@1065] - initLimit set to 5
2018-02-01 09:52:33,641 [myid:4] - INFO [main:FileSnap@83] - Reading snapshot /var/lib/zookeeper/data/version-2/snapshot.5000000b3
2018-02-01 09:52:33,665 [myid:4] - ERROR [main:QuorumPeer@557] - Unable to load database on disk
java.io.IOException: The current epoch, 5, is older than the last zxid, 25769803777
at org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:539)
at org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:500)
at org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:153)
at org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:111)
at org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)
2018-02-01 09:52:33,671 [myid:4] - ERROR [main:QuorumPeerMain@89] - Unexpected exception, exiting abnormally
java.lang.RuntimeException: Unable to run quorum server
at org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:558)
at org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:500)
at org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:153)
at org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:111)
at org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)
Caused by: java.io.IOException: The current epoch, 5, is older than the last zxid, 25769803777
at org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:539)

 Passaggio 3. Verificare che lo snapshot in questione esista.

Passare a /var/lib/zookeeper/data/version-2 e verificare che sia presente un'istantanea rossa nel passaggio 2.

300000042 log.500000001 snapshot.300000041 snapshot.40000003b
ubuntu@em-1:/var/lib/zookeeper/data/version-2$ ls -la
total 424
drwxrwxr-x 2 zk zk 4096 Jan 30 12:12 .
drwxr-xr-x 3 zk zk 4096 Feb 1 10:33 ..
-rw-rw-r-- 1 zk zk 1 Jan 30 12:12 acceptedEpoch
-rw-rw-r-- 1 zk zk 1 Jan 30 12:09 currentEpoch
-rw-rw-r-- 1 zk zk 1 Jan 30 12:12 currentEpoch.tmp
-rw-rw-r-- 1 zk zk 67108880 Jan 9 20:11 log.300000042
-rw-rw-r-- 1 zk zk 67108880 Jan 30 10:45 log.400000024
-rw-rw-r-- 1 zk zk 67108880 Jan 30 12:09 log.500000001
-rw-rw-r-- 1 zk zk 67108880 Jan 30 12:11 log.5000000b4
-rw-rw-r-- 1 zk zk 69734 Jan 6 05:14 snapshot.300000041
-rw-rw-r-- 1 zk zk 73332 Jan 29 09:21 snapshot.400000023
-rw-rw-r-- 1 zk zk 73877 Jan 30 11:43 snapshot.40000003b
-rw-rw-r-- 1 zk zk 84116 Jan 30 12:09 snapshot.5000000b3 ---> HERE, you see it
ubuntu@em-1:/var/lib/zookeeper/data/version-2$

Passaggio 4. Operazioni di ripristino.

1. Abilitare la modalità di debug in modo che EM interrompa il riavvio. 

 ubuntu@em-1:~$ sudo /opt/cisco/em-scripts/enable_debug_mode.sh                                                   

Potrebbe essere necessario riavviare nuovamente la VM (in questo caso, non è necessario eseguire alcuna operazione)

2. Spostare i dati dell'amministratore delle cassette postali.

In /var/lib/zookeeper/data è presente la cartella denominata versione-2 che contiene lo snapshot del database. L'errore sopra riportato indica che il caricamento non è riuscito in modo da essere rimosso.

ubuntu@em-1:/var/lib/zookeeper/data$ sudo mv version-2 old                      
 ubuntu@em-1:/var/lib/zookeeper/data$ ls -la
total 20
....
-rw-r--r-- 1 zk   zk      2 Feb  1 10:33 myid
drwxrwxr-x 2 zk   zk   4096 Jan 30 12:12  old  -->  so you see now old folder and you do not see version-2
-rw-rw-r-- 1 zk   zk      4 Feb  1 10:33 zookeeper_server.pid
..

3. Riavviare il nodo.

sudo reboot

4. Disabilitare nuovamente la modalità di debug.

 ubuntu@em-1:~$ sudo /opt/cisco/em-scripts/disable_debug_mode.sh                                                   

Tali procedure consentiranno al servizio di riesaminare il problema EM.