Pesquise defeitos edições quando o Element Manager é executado em um modo independente

Introdução

Este documento fornece um sumário em como pesquisar defeitos edições quando o Element Manager é executado em um modo independente.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• StarOs
• Arquitetura da base de Ultra-M

Componentes Utilizados

A informação neste documento é baseada ultra na liberação 5.1.x.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Ultra-M é uma solução móvel virtualizada pré-embalada e validada do núcleo do pacote projetada simplificar o desenvolvimento de VNFs. OpenStack é o gerente virtualizado da infraestrutura (VIM) para Ultra-M e consiste nestes tipos de nó:

• Cálculo
• Disco do armazenamento do objeto - Cálculo (OSD - Cálculo)
• Controlador
• Plataforma de OpenStack - Diretor (OSPD)

A arquitetura de nível elevado de Ultra-M e os componentes envolvidos são descritos nesta imagem:

Arquitetura de UltraM

Este documento é pretendido para o familiar dos Ciscos personnel com plataforma de Cisco Ultra-M e detalha as etapas exigidas ser realizado a nível de OpenStack e de StarOS VNF na altura da substituição do server do controlador.

Abreviaturas

Estas abreviaturas são usadas neste artigo:

VNF	Função da rede virtual
EM	Element Manager
VIP	Endereço IP de Um ou Mais Servidores Cisco ICM NT virtual
CLI	Linha de comando

Problema: O EM pode terminar acima neste estado enquanto parece do gerente da saúde de Ultra-M

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

Depende em cima da versão, pode haver 2 ou 3 EM que são executado no sistema.

No caso onde você tem 3 EM distribuído, dois deles seriam o funcional e terceiro apenas a poder ter o conjunto do Zookeeper. Contudo, não é usado. 
Caso que esse dos 2 EM funcionais não trabalharia nem não é alcançável, o EM de trabalho reagiria do modo independente. 

Caso que você distribuiu 2 EM, caso que esse deles é não trabalhando ou alcançável, o EM permanecendo pode reagir do modo independente. 

Este documento explica o que olhar se este acontece e como recuperar.

  

Pesquise defeitos e passos de recuperação

Etapa 1. Verifique o estado dos EM.

Conecte ao EM VIP e verifique que certamente o nó está neste estado:

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#

Assim, de aqui, você pode ver que há apenas uma entrada no SCM - e aquela é a entrada para nosso nó. 

Se você controla conectar ao outro EM você pode ver algo como:

  
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. 

Segundo o que é a edição no EM, os NC CLI não podem ser acessíveis, ou o nó pode recarregar. 

Etapa 2. Verifique entra /var/log/em no nó que não se junta ao conjunto.

Verifique entra o nó no estado de problema. Assim, porque a amostra mencionada, você navegaria logs em-1 /var/log/em/zookeeper:

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

 Etapa 3. Verifique que o instantâneo na pergunta existe.

Navegue a /var/lib/zookeeper/data/version-2 e verifique que esse instantâneo que está sendo vermelho em etapa 2 esta presente.

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$

Etapa 4. Passos de recuperação.

1. Enable debuga o modo assim que o EM para a repartição. 

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

A repartição VM pôde ser exigida mais uma vez (seja automaticamente, você não precisam de fazer qualquer coisa)

2. Mova os dados do zookeeper.

Em /var/lib/zookeeper/data há o dobrador chamado a versão 2 que tem o instantâneo do DB. Os pontos acima do erro a falha carregar de modo que você a remova.

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. Recarregue o nó.

sudo reboot

4. Desabilitação para trás o modo debugar.

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

Estas etapas trarão o apoio do serviço no problema EM.