Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Informações de Apoio

Abreviaturas

Problema: A EM pode acabar nesse estado, como parece do Ultra M Health Manager

Etapas de solução de problemas e recuperação

Etapa 1. Verifique o estado dos EMs.

Etapa 2. Verifique os registros em /var/log/em no nó que não se junta ao cluster.

Etapa 3. Verifique se existe um instantâneo em questão.

Etapa 4. Etapas de recuperação.

Introduction

Este documento fornece um resumo de como solucionar problemas quando o Element Manager é executado em um modo autônomo.

Prerequisites

Requirements

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

- StarOs

- Arquitetura básica Ultra-M

Componentes Utilizados

As informações neste documento são baseadas na versão Ultra 5.1.x.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

O Ultra-M é uma solução de núcleo de pacotes móveis virtualizados, pré-embalada e validada, projetada para simplificar a implantação de VNFs. O OpenStack é o Virtualized Infrastructure Manager (VIM) para Ultra-M e consiste nos seguintes tipos de nó:

- Computação

- Disco de Armazenamento de Objeto - Computação (OSD - Compute)

- Controlador

- Plataforma OpenStack - Diretor (OSPD)

A arquitetura de alto nível da Ultra-M e os componentes envolvidos estão descritos nesta imagem:

Arquitetura UltraM

Este documento destina-se ao pessoal da Cisco familiarizado com a plataforma Cisco Ultra-M e detalha as etapas necessárias para serem executadas no nível de VNF do OpenStack e do StarOS no momento da substituição do servidor controlador.

Abreviaturas

Essas abreviações são usadas neste artigo:

VNF

Função de rede virtual

EM

Gestor de Elementos

VIP

Endereço IP virtual:

CLI

Linha de comando

Problema: A EM pode acabar nesse estado, como parece do Ultra M Health Manager

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

Depende da versão, pode haver 2 ou 3 EM em execução no sistema.

No caso em que você tem 3 EM implantado, dois deles seriam funcionais e o terceiro apenas para poder ter o cluster Zookeeper. No entanto, não é usado.

Se um dos 2 EMs funcionais não funcionasse ou não estivesse acessível, o EM em funcionamento estaria no modo autônomo.

Caso você tenha implantado o 2 EM, caso um deles não esteja funcionando ou acessível, o EM restante poderá estar no modo autônomo.

Este documento explica o que procurar se isso acontecer e como se recuperar.

Etapas de solução de problemas e recuperação

Etapa 1. Verifique o estado dos EMs.

Conecte-se ao VIP EM e verifique se o nó está nesse 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#

Portanto, a partir daqui, você pode ver que há apenas uma entrada no SCM - e essa é a entrada para nosso nó.

Se você conseguir se conectar ao outro EM, poderá 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.

Dependendo do problema no EM, o NCS CLI não pode ser acessível ou o nó pode ser reinicializado.

Etapa 2. Verifique os registros em /var/log/em no nó que não se junta ao cluster.

Verifique os logs no nó no estado do problema. Assim, para a amostra mencionada, você navegaria em-1 /var/log/em/zookeeper 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)

Etapa 3. Verifique se existe um instantâneo em questão.

Navegue até /var/lib/zookeeper/data/version-2 e verifique se o snapshot vermelho na etapa 2 está 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. Etapas de recuperação.

1. Ative o modo de depuração para que EM interrompa a reinicialização.

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

A reinicialização da VM pode ser necessária novamente (será automaticamente, você não precisa fazer nada)

2. Mova os dados do detentor da zootecnia.

No /var/lib/zookeeper/data há a pasta chamada version-2 que tem o instantâneo do DB. O erro acima indica a falha de carregamento para 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. Reinicialize o nó.

sudo reboot

4. Desative novamente o modo de depuração.

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

Estas etapas devem trazer o serviço de volta ao problema EM.