Probleemoplossing bij problemen als Element Manager in een standalone modus draait

Inleiding

Dit document geeft een samenvatting van de manier waarop u problemen kunt oplossen bij het uitvoeren van Element-beheerder in een standalone modus.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• StarOs
• Ultra-M basisarchitectuur

Gebruikte componenten

De informatie in dit document is gebaseerd op de Ultra 5.1.x release.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.

Achtergrondinformatie

Ultra-M is een voorverpakte en gevalideerde gevirtualiseerde mobiele pakketoplossing die is ontworpen om de plaatsing van VPN’s te vereenvoudigen. OpenStack is de Gevirtualiseerde Infrastructuur Manager (VIM) voor Ultra-M en bestaat uit deze knooppunten:

• berekenen
• Object Storage Disk - computing (OSD)
• Controller
• OpenStack Platform - Director (OSPF)

De hoge architectuur van Ultra-M en de betrokken onderdelen zijn in deze afbeelding weergegeven:

UltraM-architectuur

Dit document is bedoeld voor het Cisco-personeel dat bekend is met het Cisco Ultra-M-platform en bevat informatie over de stappen die moeten worden uitgevoerd op niveau van OpenStack en StarOS VPN op het moment dat de vervanging van de controller Server wordt uitgevoerd.

Afkortingen

Deze afkortingen worden in dit artikel gebruikt:

VNF	Virtuele netwerkfunctie
EM	Element Manager
VIP	Virtueel IP-adres
CLI	opdrachtregel

Probleem: EM kan in deze toestand eindigen zoals het lijkt op Ultra-M Health Manager

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

Afhankelijk van de versie kan er 2 of 3 EM op het systeem draaien.

In het geval dat je 3 EM hebt ingezet, zouden er twee functioneel zijn en de derde slechts om de Zookeeper cluster te hebben. Het wordt echter niet gebruikt. 
Indien een van de 2 functionele EM's niet zou werken of niet bereikbaar is, zou het werkende EM in de standalone modus staan. 

Indien u 2 EM hebt ingezet, voor het geval dat één van deze niet werkt of bereikbaar is, kan het resterende EM in de standalone modus zijn. 

In dit document wordt uitgelegd hoe u dit kunt zien en hoe u het kunt herstellen.

  

Stappen voor probleemoplossing en herstel

Stap 1. Controleer de staat van de EM's.

Sluit aan op de EM VIP en controleer of het knooppunt zich in deze toestand bevindt:

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#

Vanaf hier kun je dus zien dat er slechts één punt in SCM is - en dat is de ingang voor ons knooppunt. 

Als het u lukt om verbinding te maken met de andere EM dan zie je zoiets als:

  
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. 

Afhankelijk van wat het probleem op de EM is, kan NCS CLI niet toegankelijk zijn of kan het knooppunt worden herstart. 

Stap 2. Controleer de logbestanden in /var/log/em op het knooppunt dat niet in het cluster geïntegreerd is.

Controleer de logbestanden op het knooppunt in de probleemstatus. Voor het monster dat we noemden, bevestig je em-1/var/log/em/zoökeeper-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)

 Stap 3. Controleer of de Snapshot in kwestie bestaat.

Navigeren naar /var/lib/zoökeeper/data/versie-2 en controleren of er een foto aanwezig is die in stap 2 rood is.

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$

Stap 4. Herstelstappen.

1. Schakel de debug-modus in zodat EM de herstart stopt. 

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

Mogelijk moet de VM opnieuw worden opgestart (dit zou automatisch gebeuren, u hoeft niets te doen)

2. Verplaats de gegevens van de fokker.

In de /var/lib/zoökeeper/data is er de map versie-2 die de snapshot van de DB heeft. De fout hierboven wijst op het niet laden zodat u het verwijdert.

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. Start het knooppunt opnieuw op.

sudo reboot

4. Schakel de debug-modus terug.

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

Met deze stappen zal de dienst het probleem EM opnieuw aanpakken.