Richtlinie und Charging Rules Function Stopp and Start Computing Node

Einführung

Dieses Dokument beschreibt die Schritte, die erforderlich sind, um einen fehlerhaften Computing-Server in einer Ultra-M-Konfiguration anzuhalten, die Cisco Policy Suite (CPS) Virtual Network Functions (VNFs) hostet.

Hinweis: Ultra M 5.1.x wird zur Definition der Verfahren in diesem Dokument berücksichtigt. Dieses Dokument richtet sich an Mitarbeiter von Cisco, die mit der Cisco Ultra-M-Plattform vertraut sind. Es enthält eine Beschreibung der Schritte, die auf der Ebene von OpenStack und CPS VNF zum Zeitpunkt des Stoppstarts des Compute-Servers ausgeführt werden müssen.

Voraussetzungen

Sicherung

Bevor Sie einen Compute-Knoten starten, ist es wichtig, den aktuellen Zustand Ihrer Red Hat OpenStack Platform-Umgebung zu überprüfen. Es wird empfohlen, den aktuellen Zustand zu überprüfen, um Komplikationen zu vermeiden.

Im Falle einer Wiederherstellung empfiehlt Cisco, eine Sicherung der OSPD-Datenbank mit diesen Schritten durchzuführen.

<[root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql
[root@director ~]# tar --xattrs -czf undercloud-backup-`date +%F`.tar.gz /root/undercloud-all-databases.sql 
/etc/my.cnf.d/server.cnf /var/lib/glance/images /srv/node /home/stack
tar: Removing leading `/' from member names

Dieser Prozess stellt sicher, dass ein Knoten ausgetauscht werden kann, ohne dass die Verfügbarkeit von Instanzen beeinträchtigt wird. Außerdem wird empfohlen, die CPS-Konfiguration zu sichern.

[root@CM ~]# config_br.py -a export --all /mnt/backup/CPS_backup_28092016.tar.gz

Identifizieren der im Compute-Knoten gehosteten VMs

Identifizieren Sie die VMs, die auf dem Compute-Server gehostet werden.

[stack@director ~]$ nova list --field name,host,networks | grep compute-10
| 49ac5f22-469e-4b84-badc-031083db0533 |  VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     |  pod1-compute-10.localdomain    | Replication=10.160.137.161; Internal=192.168.1.131; Management=10.225.247.229; tb1-orch=172.16.180.129

Hinweis: In der hier gezeigten Ausgabe entspricht die erste Spalte dem Universally Unique IDentifier (UUID), die zweite Spalte dem VM-Namen und die dritte Spalte dem Hostnamen, in dem das virtuelle System vorhanden ist. Die Parameter aus dieser Ausgabe werden in den nachfolgenden Abschnitten verwendet.

Deaktivieren Sie das Herunterfahren der PCRF-Services für das virtuelle System.

1. Melden Sie sich bei der Management-IP des virtuellen Systems an.

[stack@XX-ospd ~]$ ssh root@<Management IP>
[root@XXXSM03 ~]# monit stop all

2. Wenn die VM einSM, OAModerArbiter ist, beenden Sie zusätzlich die sessionmgr-Dienste.

[root@XXXSM03 ~]# cd /etc/init.d
[root@XXXSM03 init.d]# ls -l sessionmgr*
-rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27717
-rwxr-xr-x 1 root root 4399 Nov 28 22:45 sessionmgr-27721
-rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27727

3. Forevery-Datei mit dem Titel sessionmgr-xxxxxxx führen Sie den Dienst sessionmgr-xxxxx stop aus.

[root@XXXSM03 init.d]# service sessionmgr-27717 stop

Graceful Power Aus

Herunterfahren der VM von ESC

1. Melden Sie sich beim ESC-Knoten an, der der VNF entspricht, und überprüfen Sie den Status des virtuellen Systems.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name> VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>
                    <state>VM_ALIVE_STATE</state>
<snip>

2. Beenden Sie die VM mit dem VM-Namen. (VM-Name siehe Abschnitt " Identifizieren der im Compute-Knoten gehosteten VMs").

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d

 3. Nach dem Beenden muss die VM in den SHUTOFF-Status wechseln.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>
                    <state>VM_SHUTOFF_STATE</state>
<snip> 

Stopp-Start des Computing-Knotens

Die in diesem Abschnitt beschriebenen Schritte sind unabhängig von den im Computing-Knoten gehosteten VMs häufig.

Stopp-Start-Computing-Knoten aus dem OSPD

1. Überprüfen Sie den Status, und starten Sie den Knoten anschließend.

[stack@director ~]$ nova list | grep compute-10 
| 03f15071-21aa-4bcf-8fdd-acdbde305168 | pod1-stack-compute-10 | ACTIVE | - | Running | ctlplane=192.200.0.106 |

[stack@director ~]$ nova stop pod1-stack-compute-10

2. Warten Sie, bis sich die Compute im "Shutoff"-Status befindet, und starten Sie sie dann erneut.

[stack@director ~]$ nova start pod1-stack-compute-10

3. Überprüfen Sie, ob sich der neue Rechenknoten im aktiven Zustand befindet.

[stack@director ~]$ source stackrc
[stack@director ~]$ nova list |grep compute-10
| 03f15071-21aa-4bcf-8fdd-acdbde305168 | pod1-stack-compute-10 | ACTIVE | - | Running | ctlplane=192.200.0.106 |

[stack@director ~]$ source pod1-stackrc-Core
[stack@director ~]$ openstack hypervisor list |grep compute-10
| 6 | pod1-compute-10.localdomain    |

Stellen Sie die VMs wieder her

VM-Wiederherstellung vom ESC

1. Im Idealfall sollten die VMs in OSPD, wenn Sie die Nova-Liste überprüfen, im Shut-Zustand sein. In diesem Fall müssen Sie die VMs von ESC aus starten.

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action START VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
[sudo] password for admin: 

2. Wenn sich die VM in der nova-Liste im Fehlerzustand befindet, führen Sie diese Konfiguration aus.

[stack@director  ~]$ nova list |grep VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
| 49ac5f22-469e-4b84-badc-031083db0533 | VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     | ERROR  | -          | NOSTATE     | 

3. Stellen Sie jetzt das virtuelle System vom ESC wieder her.

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
[sudo] password for admin: 

Recovery VM Action
/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

4. Überwachen Sie yangesc.log.

admin@VNF2-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log
…
14:59:50,112 07-Nov-2017 WARN  Type: VM_RECOVERY_COMPLETE
14:59:50,112 07-Nov-2017 WARN  Status: SUCCESS
14:59:50,112 07-Nov-2017 WARN  Status Code: 200
14:59:50,112 07-Nov-2017 WARN  Status Msg: Recovery: Successfully recovered VM [VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d].

Überprüfen Sie die PCRF-Services auf dem VM.

Hinweis: Wenn sich die VM im SHUTOFF-Zustand befindet, aktivieren Sie sie mithilfe von esc_nc_cli aus ESC. Überprüfen Sie die diagnostics.sh-Datei von Cluster Manager VM, und falls bei den wiedergewonnenen VMs ein Fehler auftritt.

1. Melden Sie sich bei der entsprechenden VM an.

[stack@XX-ospd ~]$ ssh root@<Management IP>
[root@XXXSM03 ~]# monit start all

2. Wenn die VM einSM, OAModerArbiter ist, starten Sie zusätzlich die sessionmgr-Dienste, die zuvor gestoppt wurden. Forevery-Datei mit dem Titel sessionmgr-xxxxx, führen Sie den Dienst sessionmgr-xxxxx start aus.

[root@XXXSM03 init.d]# service sessionmgr-27717 start

 3. Wenn die Diagnose immer noch nicht klar ist, führen Sie build_all.sh von Cluster Manager VM aus und führen Sie VM-init auf der entsprechenden VM aus.

/var/qps/install/current/scripts/build_all.sh

ssh VM   e.g. ssh pcrfclient01 
/etc/init.d/vm-init