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