Inhalt

Einführung

Hintergrundinformationen

Abkürzungen

Workflow des MoP

Fall 1. Wiederherstellung eines einzelnen Ausfalls des UAS-Clusters

Statusprüfung

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

UAS aus Fehlerstatus wiederherstellen

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

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

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

Zookeeper-Ansicht überprüfen

Fehlerbehebung bei AutoVNF - Prozesse und Aufgaben

Fehlerbehebung für mehrere UAS im Fehlerstatus

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

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