Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Abkürzungen

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

Fehlerbehebung und Wiederherstellungsschritte

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

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

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

Schritt 4: Wiederherstellungsschritte

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.