Wiederherstellungsverfahren für Ultra-M AutoVNF Cluster Failure - vEPC

Einführung

In diesem Dokument werden die erforderlichen Schritte beschrieben, um den Ausfall des Ultra Automation Services (UAS) oder des AutoVNF-Clusters in einer Ultra-M-Konfiguration wiederherzustellen, die StarOS Virtual Network Functions (VNFs) hostet.

Hintergrundinformationen

Ultra-M ist eine vorkonfigurierte und validierte Kernlösung für virtualisierte mobile Pakete, die die Bereitstellung von VNFs vereinfacht.

Die Ultra-M-Lösung besteht aus den genannten VM-Typen:

• Auto-IT 
• Automatische Bereitstellung
• UAS oder AutoVNF
• Element Manager (EM)
• Elastic Services Controller (ESC)
• Kontrollfunktion (CF)
• Sitzungsfunktion (SF)

Die High-Level-Architektur von Ultra-M und die beteiligten Komponenten sind in diesem Bild dargestellt:

UltraM-Architektur

Dieses Dokument richtet sich an Mitarbeiter von Cisco, die mit der Cisco Ultra-M-Plattform vertraut sind.

Hinweis: Ultra M 5.1.x wird zur Definition der Verfahren in diesem Dokument berücksichtigt.

Abkürzungen

VNF	Virtuelle Netzwerkfunktion
CF	Kontrollfunktion
SF	Servicefunktion
WSA	Elastic Service Controller
MOP	Verfahrensweise
OSD	Objektspeicherdatenträger
HDD	Festplattenlaufwerk
SSD	Solid-State-Laufwerk
VIM	Virtueller Infrastrukturmanager
VM	Virtuelles System
EM	Element Manager
USA	Ultra-Automatisierungsservices
UUID	Universell eindeutige IDentifier

Workflow des MoP

Fall 1. Wiederherstellung eines einzelnen Ausfalls des UAS-Clusters

Statusprüfung

1. Der Ultra-M Manager führt die Statusprüfung des Ultra-M-Knotens durch. Navigieren Sie zum Verzeichnis reports/var/log/cisco/ultram-health/and grep für den UAS-Bericht.

• [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. Der erwartete Status des UAS-Clusters wird wie abgebildet angezeigt, wobei alle drei UAS am Leben sind. 

[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

Beim Versuch, eine Verbindung zu UAS herzustellen, wird keine Verbindung zum Confd Server hergestellt.

1. In einigen Fällen können Sie keine Verbindung zum konfigurierten Server herstellen.

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

 2. Überprüfen Sie den Status des uas-config-Prozesses.

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

3. Wenn der konfigurierte Server nicht ausgeführt wird, starten Sie den Dienst neu.

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

UAS aus Fehlerstatus wiederherstellen

 1. Falls ein AutoVNF im Cluster ausfällt, zeigt das UAS-Cluster einen der im Fehlerstatus befindlichen UAS an.

[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. Kopieren Sie die richtige Datei (RC-Datei Ihres VNF) vom /Home/Stack im OSPD-Server in AutoDeploy, und leiten Sie sie ab. 

3. Überprüfen Sie den Status Ihres UAS/AutoVNF mithilfe des Skripts uas-check.py . autovnf1 ist der AutoVNF-Name. 

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. Stellen Sie die UAS mithilfe des Skripts uas-check.py wieder her, und fügen Sie —fix Schlüsselwort hinzu.

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. Sie sehen, dass die neu erstellten UAS aktiv sind und Teil des Clusters sind.

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

Fall 2. Alle drei UAS (AutoVNF) sind im Fehlerstatus.

1. Der Ultra-M Manager führt die Statusprüfung des Ultra-M-Knotens durch.

[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. Wie in der Ausgabe festgestellt, meldet der Ultra-M-Manager, dass ein Fehler für AutoVNF vorliegt, und es zeigt, dass alle drei UAS des Clusters im Fehlerstatus sind. 

Überprüfen Sie das Skript UAS Health mit uas-check.py.

1. Melden Sie sich bei der automatischen Bereitstellung an, und prüfen Sie, ob Sie auf AutoVNF UAS zugreifen und den Status abrufen können.

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. Von Auto-Deploy, Secure Shell (SSH) bis AutoVNF-Knoten und Wechseln in den Konfigurationsmodus Überprüfen Sie den Status mit show uas.

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. Es wird empfohlen, den Status in allen drei UAS-Knoten zu überprüfen.

Überprüfen Sie den Status der VMs auf OpenStack-Ebene.

Überprüfen Sie den Status der AutoVNF VMs in der Nova-Liste. Führen Sie ggf. nova start aus, um die heruntergefahrene VM zu starten.

[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                                                     

Zookeeper-Ansicht überprüfen

1. Überprüfen Sie den Zustand des Zookeeper, um den Modus als Führer zu überprüfen.

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. Zookeeper sollte normalerweise aktiviert sein.

Fehlerbehebung bei AutoVNF - Prozesse und Aufgaben

1. Geben Sie den Grund für den Fehlerstatus der Knoten an. Damit AutoVNF ausgeführt werden kann, müssen eine Reihe von Prozessen wie folgt eingerichtet und ausgeführt werden:

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. Überprüfen Sie, ob diese Python-Prozesse ausgeführt werden:

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. Wenn sich einer der erwarteten Prozesse nicht im Start-/Ausführungszustand befindet, starten Sie den Prozess neu, und überprüfen Sie den Status. Wenn der Fehlerstatus weiterhin angezeigt wird, befolgen Sie zur Behebung dieses Problems die im nächsten Abschnitt beschriebenen Schritte.

Fehlerbehebung für mehrere UAS im Fehlerstatus

1. nova —hard reboot <Name des VM> von OSPD, geben Sie etwas Zeit für die Wiederherstellung dieser VM, bevor Sie mit den nächsten UAS fortfahren. Gehen Sie auf allen UAS VMs vor. 

oder

2. Melden Sie sich bei den einzelnen USA an, und verwenden Sie sudo reboot. Warten Sie auf die Wiederherstellung, und fahren Sie dann mit anderen UAS VMs fort.

Transaktionsprotokolle können Sie wie folgt überprüfen:

/var/log/upstart/autovnf.log

show logs xxx | display xml

Dadurch wird das Problem behoben und der Status "UAS from Error" (UAS nach Fehler) wiederhergestellt. 

1. Überprüfen Sie dies mit dem Bericht 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      | :-)      |

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