Procedimento de recuperação para a falha do conjunto de Ultra-M AutoVNF - vEPC

Introdução

Este original descreve as etapas exigidas para recuperar ultra os serviços da automatização (UA) ou a falha do conjunto de AutoVNF em um Ultra-M setup que a rede virtual de StarOS dos anfitriões funciona (VNFs).

Informações de Apoio

Ultra-M é uma solução móvel virtualizada pré-embalada e validada do núcleo do pacote que seja projetada a fim simplificar o desenvolvimento de VNFs.

A solução de Ultra-M consiste nos tipos mentoned da máquina virtual (VM):

• A Auto-TI 
• Auto-distribua
• UA ou AutoVNF
• Element Manager (EM)
• O elástico presta serviços de manutenção ao controlador (o ESC)
• Função de controle (CF)
• Função da sessão (SF)

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

Arquitetura de UltraM

Este original é pretendido para os Ciscos personnel que são familiares com a plataforma de Cisco Ultra-M.

Nota: A liberação M 5.1.x é considerada ultra a fim definir os procedimentos neste original.

Abreviaturas

VNF	Função da rede virtual
CF	Função de controle
SF	Função de serviço
ESC	Controlador elástico do serviço
ESPANADOR	Método do procedimento
OSD	Discos do armazenamento do objeto
HDD	Unidade de disco rígido
SSD	Movimentação de circuito integrado
VIM	Gerente virtual da infraestrutura
VM	Máquina virtual
EM	Element Manager
UA	Ultra Automation Services
UUID	Universalmente identificador exclusivo

Trabalhos do espanador

Recuperação do caso 1. da única falha do conjunto UA

Verificação de status

1. O gerente de Ultra-M executa o exame médico completo do nó de Ultra-M. Navegue ao diretório de /var/log/cisco/ultram-health/ dos relatórios e o grep para os UA relata.

• [stack@pod1-ospd ultram-health]$ more ultram_health_uas.report
  
  ---------------------------------------------------------------------------------------------------------
   VNF ID           | UAS Node | Status   | Error Info, if any        
  ---------------------------------------------------------------------------------------------------------
   172.21.201.122   | autovnf  | XXX      | AutoVNF Cluster FAILED : Node: 172.16.180.12, Status: error, Role: NA
   172.21.201.122   | vnf-em   | :-)      |
   172.21.201.122   | esc      | :-)      |
  --------------------------------------------------------------------------------------------------------- 

2. O estado previsto do conjunto UA será como descrito, onde todos os três UA estão vivos. 

[stack@pod1-ospd ~]# ssh ubuntu@10.1.1.1
password:

ubuntu@autovnf1-uas:~$ ncs_cli -u admin -C

autovnf1-uas-0#show uas 
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.16.181.101
INSTANCE IP STATE ROLE 
------------------------------------
172.16.180.3 alive CONFD-MASTER 
172.16.180.7 alive CONFD-SLAVE 
172.16.180.12 alive NA

Falha conectar ao server de Confd quando você tentar conectar aos UA

1. Em alguns casos, você não poderá conectar ao server do confd.

ubuntu@autovnf1-uas-0:/opt/cisco/usp/uas/manager$ confd_cli -u admin -C
Failed to connect to server

 2. Verifique o estado do processo UA-confd.

ubuntu@autovnf1-uas-0:/opt/cisco/usp/uas/manager$ sudo initctl status uas-confd
uas-confd stop/waiting

3. Se o server do confd não é executado, reinicie o serviço.

ubuntu@autovnf1-uas-0:/opt/cisco/usp/uas/manager$ sudo initctl start uas-confd
uas-confd start/running, process 7970
ubuntu@autovnf1-uas-0:/opt/cisco/usp/uas/manager$ confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 172.16.180.9 using ssh on autovnf1-uas-0

Recupere UA do estado de erro

 1. Em caso de uma falha de um AutoVNF entre o conjunto, os UA aglomeram as mostras uma dos UA no estado de erro.

[stack@pod1-ospd ~]# ssh ubuntu@10.1.1.1
password:

ubuntu@autovnf1-uas:~$ ncs_cli -u admin -C

autovnf1-uas-0#show uas 
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.16.181.101
INSTANCE IP STATE ROLE 
------------------------------------
172.16.180.3 alive CONFD-MASTER 
172.16.180.7 alive CONFD-SLAVE 
172.16.180.12 alive error

2. Copie o arquivo do corerc (arquivo do rc de seu VNF) de /home/stack no server OSPD a AutoDeploy e a fonte ele. 

3. Verifique o estado de seu UAS/AutoVNF com o uso do script uas-check.py. autovnf1is o nome de AutoVNF. 

ubuntu@auto-deploy-iso-590-uas-0:~$ /opt/cisco/usp/apps/auto-it/scripts/uas-check.py auto-vnf autovnf1
2017-11-17 14:52:20,186 - INFO: Check of AutoVNF cluster started
2017-11-17 14:52:22,172 - INFO: Found 2 AutoVNF instance(s), 3 expected
2017-11-17 14:52:22,172 - INFO: Instance 'autovnf1-uas-2' is missing
2017-11-17 14:52:22,172 - INFO: Check completed, AutoVNF cluster has recoverable errors

4. Recupere os UA com o uso do script uas-check.py e adicionar-los --fixe a palavra-chave.

ubuntu@auto-deploy-iso-590-uas-0:~$ /opt/cisco/usp/apps/auto-it/scripts/uas-check.py auto-vnf autovnf1 --fix
2017-11-17 14:52:27,493 - INFO: Check of AutoVNF cluster started
2017-11-17 14:52:29,215 - INFO: Found 2 AutoVNF instance(s), 3 expected
2017-11-17 14:52:29,215 - INFO: Instance 'autovnf1-uas-2' is missing
2017-11-17 14:52:29,215 - INFO: Check completed, AutoVNF cluster has recoverable errors
2017-11-17 14:52:29,386 - INFO: Creating instance 'autovnf1-uas-2' and attaching volume 'autovnf1-uas-vol-2'
2017-11-17 14:52:47,600 - INFO: Created instance 'autovnf1-uas-2'

5. Você verá que os UA recém-criados são vivos e parte do conjunto.

autovnf1-uas-0#show uas 
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.16.181.101
INSTANCE IP STATE ROLE 
------------------------------------
172.16.180.3 alive CONFD-MASTER 
172.16.180.7 alive CONFD-SLAVE 
172.16.180.13 alive NA

Caso 2. Todos os três UA (AutoVNF) estão no estado de erro

1. O gerente de Ultra-M executa o exame médico completo do nó de Ultra-M.

[stack@pod1-ospd ultram-health]$ more ultram_health_uas.report

---------------------------------------------------------------------------------------------------------

 VNF ID           | UAS Node | Status   | Error Info, if any        

---------------------------------------------------------------------------------------------------------

 172.21.201.122   | autovnf  | XXX      | AutoVNF Cluster FAILED : Node: 172.16.180.12, Status: error, Role: NA,Node: 172.16.180.9, Status: error, Role: NA,Node: 172.16.180.10, Status: error, Role: NA

 172.21.201.122   | vnf-em   | :-)      |

 172.21.201.122   | esc      | :-)      |

---------------------------------------------------------------------------------------------------------

2. Como observado na saída, o gerente de Ultra-M relata que há uma falha para AutoVNF e mostra que todos os três UA do conjunto estão no estado de erro. 

Verifique a saúde UA com o script uas-check.py

1. Início de uma sessão à Auto-distribuição e à verificação se você pode alcançar o AutoVNF UA e obter o estado.

ubuntu@auto-deploy-iso-590-uas-0:~$ /opt/cisco/usp/apps/auto-it/scripts$ ./uas-check.py auto-vnf autovnf1 --os-tenant-name core

2017-12-05 11:41:09,834 - INFO: Check of AutoVNF cluster started
2017-12-05 11:41:11,342 - INFO: Found 3 ACTIVE AutoVNF instances
2017-12-05 11:41:11,343 - INFO: Check completed, AutoVNF cluster is fine

2. De Auto-distribua, Shell Seguro (ssh) ao nó de AutoVNF e participe no modo do confd. Verifique o estado com os uas da mostra.

ubuntu@auto-deploy-iso-590-uas-0:~$ ssh ubuntu@172.16.180.9
password:
autovnf1-uas-1#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.16.181.101
INSTANCE IP    STATE  ROLE 

----------------------------

172.16.180.9   error  NA   
172.16.180.10  error  NA   
172.16.180.12  error  NA   

3. Recomenda-se verificar o estado em todos os três Nós UA.

Verifique o estado dos VMs no nível de OpenStack

Verifique o estado do AutoVNF VMs na lista da nova. Se for necessário, execute o começo da nova a fim começar o desligamento VM.

[stack@pod1-ospd ultram-health]$ nova list | grep autovnf

| 83870eed-b4e9-47b3-976d-cc3eddecf866 | autovnf1-uas-0                                                 | ACTIVE | -          | Running     | orchestr=172.16.180.12; mgmt=172.16.181.6                                                                                                                  
| 201d9ce5-538c-42f7-a46c-fc8cdef1eabf | autovnf1-uas-1                                                 | ACTIVE | -          | Running     | orchestr=172.16.180.10; mgmt=172.16.181.5                                                                                                                    
| 6c6d25cd-21b6-42b9-87ff-286220faa2ff | autovnf1-uas-2                                                 | ACTIVE | -          | Running     | orchestr=172.16.180.9; mgmt=172.16.181.13                                                     

Verifique a opinião do Zookeeper

1. Verifique o estado do zookeeper a fim verificar o modo como o líder.

ubuntu@autovnf1-uas-0:/var/log/upstart$ /opt/cisco/usp/packages/zookeeper/current/bin/zkServer.sh status
ZooKeeper JMX enabled by default
Using config: /opt/cisco/usp/packages/zookeeper/current/bin/../conf/zoo.cfg
Mode: leader

2. O Zookeeper normalmente deve estar acima.

Pesquise defeitos o AutoVNF - Processos e tarefas

1. Identifique a razão para o estado de erro dos Nós. Para que AutoVNF seja executado, há um conjunto de processo que deva ser em serviço como mostrado:

AutoVNF

uws-ae

uas-confd

cluster_manager

uas_manager

ubuntu@autovnf1-uas-0:~$ sudo initctl list  | grep uas 

uas-confd stop/waiting ====> this is not good, the uas-confd process is not running

uas_manager start/running, process 2143

root@autovnf1-uas-1:/home/ubuntu# sudo initctl list 
....
uas-confd start/running, process 1780
....
autovnf start/running, process 1908
....
....
uws-ae start/running, process 1909
....
....
cluster_manager start/running, process 1827
....
.....
uas_manager start/running, process 1697
......
......

2. Verifique que estes processos do pitão estão sendo executado:

uas_manager.py

cluster_manager.py

usp_autovnf.py

  

root@autovnf1-uas-1:/home/ubuntu# ps -aef | grep pyth
root      1819  1697  0 Jun13 ?        00:00:50 python /opt/cisco/usp/uas/manager/uas_manager.py
root      1858  1827  0 Jun13 ?        00:09:21 python /opt/cisco/usp/uas/manager/cluster_manager.py
root      1908     1  0 Jun13 ?        00:01:00 python /opt/cisco/usp/uas/autovnf/usp_autovnf.py
root     25662 24750  0 13:16 pts/7    00:00:00 grep --color=auto pyth

3. Se alguns dos processos previstos não são dentro começo/estado de execução, reinicie o processo e verifique o estado. Se ainda mostra no estado de erro a seguir segue o procedimento mencionado na próxima seção a fim fixar esta edição.

Reparo para UA múltiplos no estado de erro

1. nova --o <name duro da repartição do VM> de OSPD, dá algum tempo para a recuperação deste VM antes que você continue aos UA seguintes. Faça-o em todos os UA VMs. 

ou

2.Log dentro a cada um dos UA e da repartição do sudo do uso. Espere a recuperação e continue então a outros UA VMs.

Para log de transação, verifique:

/var/log/upstart/autovnf.log

show logs xxx | display xml

Isto fixará a edição e recuperará os UA do estado de erro. 

1. Verifique o mesmos com o uso do relatório do ultram_health_check.

[stack@pod1-ospd ultram-health]$ more ultram_health_uas.report

---------------------------------------------------------------------------------------------------------

 VNF ID           | UAS Node | Status   | Error Info, if any        

---------------------------------------------------------------------------------------------------------

 172.21.201.122   | autovnf  | :-)      | 

 172.21.201.122   | vnf-em   | :-)      |

 172.21.201.122   | esc      | :-)      |

---------------------------------------------------------------------------------------------------------