Fehlerbehebung, wenn Element Manager im Standalone-Modus ausgeführt wird

Einführung

Dieses Dokument bietet eine Zusammenfassung zur Fehlerbehebung, wenn Element Manager im Standalone-Modus ausgeführt wird.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• StarOS
• Ultra-M-Basisarchitektur

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf der Ultra 5.1.x-Version.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrundinformationen

Ultra-M ist eine vorkonfigurierte und validierte Kernlösung für virtualisierte mobile Pakete, die die Bereitstellung von VNFs vereinfacht. OpenStack ist der Virtualized Infrastructure Manager (VIM) für Ultra-M und besteht aus den folgenden Knotentypen:

• Computing
• Object Storage Disk - Computing (OSD - Computing)
• Controller
• OpenStack-Plattform - Director (OSPD)

Die High-Level-Architektur von Ultra-M und die beteiligten Komponenten sind in diesem Bild dargestellt:

UltraM-Architektur

Dieses Dokument richtet sich an Mitarbeiter von Cisco, die mit der Cisco Ultra-M-Plattform vertraut sind. Es beschreibt die Schritte, die auf der Ebene von OpenStack und StarOS VNF zum Zeitpunkt des Ersatzes des Controller-Servers erforderlich sind.

Abkürzungen

Diese Abkürzungen werden in diesem Artikel verwendet:

VNF	Virtuelle Netzwerkfunktion
EM	Element Manager
VIP	Virtuelle IP-Adresse
CLI	Befehlszeile

Problem: EM kann in diesem Zustand enden, wie es vom Ultra-M Health Manager zu sehen ist.

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

Je nach Version kann 2 oder 3 EM auf dem System ausgeführt werden.

Wenn 3 EM bereitgestellt ist, sind zwei davon funktionsfähig und die dritte nur in der Lage, den Zookeeper-Cluster bereitzustellen. Es wird jedoch nicht verwendet. 
Falls eines der beiden funktionellen EMs nicht funktioniert oder nicht erreichbar ist, befindet sich das funktionierende EM im Standalone-Modus. 

Wenn Sie 2 EM bereitgestellt haben, kann sich das verbleibende EM im Standalone-Modus befinden, falls eines davon nicht funktioniert oder nicht erreichbar ist. 

In diesem Dokument wird erläutert, wie Sie sehen, ob dies geschieht, und wie Sie wiederherstellen können.

  

Fehlerbehebung und Wiederherstellungsschritte

Schritt 1: Überprüfen Sie den Status der EMs.

Stellen Sie eine Verbindung zum EM VIP her, und überprüfen Sie, ob sich der Knoten in diesem Zustand befindet:

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#

Von hier aus können Sie sehen, dass es nur einen Eintrag in SCM gibt - und das ist der Eintrag für unseren Knoten. 

Wenn Sie eine Verbindung mit dem anderen EM herstellen können, sehen Sie z. B.:

  
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. 

Je nachdem, um welches Problem es sich beim EM handelt, kann auf die NCS CLI nicht zugegriffen oder ein Knoten kann neu gestartet werden. 

Schritt 2: Überprüfen Sie die Anmeldungen in /var/log/em am Knoten, der dem Cluster nicht beitritt.

Überprüfen Sie die Protokolle am Knoten im Problemstatus. Für das oben erwähnte Beispiel navigieren Sie zu em-1/var/log/em/zookeeper-Protokollen:

...
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)

 Schritt 3: Überprüfen Sie die Kurzreferenz in Frage.

Navigieren Sie zu /var/lib/zookeeper/data/version-2, und überprüfen Sie, ob der in Schritt 2 rot dargestellte Snapshot vorhanden ist.

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$

Schritt 4: Wiederherstellungsschritte

1. Aktivieren Sie den Debug-Modus, damit EM den Neustart beendet. 

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

Ein Neustart des virtuellen Systems ist möglicherweise noch einmal erforderlich (wird automatisch durchgeführt, Sie müssen keine weiteren Schritte ausführen)

2. Verschieben Sie die Zookeeper-Daten.

Im /var/lib/zookeeper/data befindet sich der Ordner Version-2, der den Snapshot der DB enthält. Der obige Fehler zeigt an, dass das Laden fehlgeschlagen ist, sodass Sie es entfernen.

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. Starten Sie den Knoten neu.

sudo reboot

4. Deaktivieren Sie den Debugmodus wieder.

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

Durch diese Schritte wird die Service-Datensicherung für das Problem-EM aktiviert.