Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Fehlerbehebung

Einschalten des Schiedsrichters aus dem SHUTOFF-Staat

Stellen Sie alle Instanzen aus dem FEHLERzustand wieder her.

Rückgewinnung von Schiedsrichtern/Schiedsgerichtsbarkeit

Überprüfen

Einführung

In diesem Dokument wird beschrieben, wie Instanzen von Cisco Virtual Policy and Charging Rules Function (vPCRF) wiederhergestellt werden, die in einer Ultra-M/OpenStack-Bereitstellung bereitgestellt werden.

Verfasst von Nitesh Bansal, Cisco Advance Services.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse zu folgenden Themen verfügen:

- OpenStack

- CPS

- Die Compute für die betroffenen Instanzen ist jetzt verfügbar.

- Rechenressourcen sind in derselben Verfügbarkeitszone verfügbar wie die betroffene Instanz.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf CPS und gelten für alle Versionen.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Fehlerbehebung

Einschalten des Schiedsrichters aus dem SHUTOFF-Staat

Wenn sich eine Instanz aufgrund eines geplanten Abschaltvorgangs oder aus anderen Gründen im SHUTOFF-Zustand befindet, starten Sie die Instanz mit dem folgenden Verfahren und aktivieren Sie die Überwachung in Elastic Service Controller (ESC).

Schritt 1: Überprüfen Sie den Status der Instanz über OpenStack.

source /home/stack/destackovsrc-Pcrf

nova list --fields name,host,status | grep arbiter

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | destackovs-compute-2  | SHUTOFF|

Schritt 2: Überprüfen Sie, ob der Computer verfügbar ist, und stellen Sie sicher, dass der Status aktiv ist.

source /home/stack/destackovsrc

nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’

| state                     | up                                       |

| status                    | enabled                                  |

Schritt 3: Melden Sie sich als Admin-Benutzer beim ESC Master an, und überprüfen Sie den Zustand der Instanz in opdata.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep arbiter

r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 VM_ERROR_STATE

Schritt 4: Schalten Sie die Instanz von OpenStack ein.

source /home/stack/destackovsrc-Pcrf

nova start r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

Schritt 5: Warten Sie fünf Minuten, bis die Instanz gestartet ist, und gehen Sie in den aktiven Zustand über.

source /home/stack/destackovsrc-Pcrf

nova list –fields name,status | grep cm

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | ACTIVE |

Schritt 6: Aktivieren Sie VM Monitor im ESC, nachdem die Instanz im aktiven Zustand ist.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

Weitere Informationen zur Wiederherstellung von Instanzkonfigurationen finden Sie in den nachfolgend angegebenen Instanztypspezifischen Verfahren.

Stellen Sie alle Instanzen aus dem FEHLERzustand wieder her.

Wenn sich der Status der CPS-Instanz in der OpenStack-Instanz im FEHLER-Status befindet, starten Sie die Instanz wie folgt:

Schritt 1: Setzen Sie den Status der Instanz zurück, um die Instanz wieder in einen aktiven Zustand zu versetzen, anstatt einen Fehlerzustand. Starten Sie anschließend die Instanz neu.

source /home/stack/destackovsrc-Pcrf

nova reset-state –active r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

nova reboot –-hard  r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

Schritt 2: Melden Sie sich als Admin-Benutzer beim ESC Master an, und überprüfen Sie den Zustand der Instanz in opdata.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep arbiter

r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 VM_ERROR_STATE

Schritt 3: Überprüfen Sie, ob der Computer verfügbar ist und fehlerfrei ausgeführt wird.

source /home/stack/destackovsrc

nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’

| state                     | up                                       |

| status                    | enabled                                  |

Schritt 4: Überprüfen Sie den Status der Instanz in OpenStack.

source /home/stack/destackovsrc-Pcrf

nova list --fields name,host,status | grep arbiter

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | destackovs-compute-2  | ERROR|

Schritt 5: Warten Sie fünf Minuten, bis die Instanz gestartet ist, und gehen Sie in den aktiven Zustand über.

source /home/stack/destackovsrc-Pcrf

nova list –fields name,status | grep arbiter

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957 | ACTIVE |

Schritt 6: Wenn Cluster Manager ändert den Status nach dem Neustart auf AKTIV, aktiviert VM Monitor im ESC, nachdem die Cluster Manager-Instanz im aktiven Zustand ist.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR r5-arbiter_arb_0_2eb86cbf-07e5-4e14-9002-8990588b8957

Schritt 7: Verwenden Sie nach der Wiederherstellung in den aktiven Status bzw. in den Ausführungsstatus die Prozedur für den Instanztyp, um Konfigurationen/Daten aus der Sicherung wiederherzustellen.

Rückgewinnung von Schiedsrichtern/Schiedsgerichtsbarkeit

Wenn vor kurzem eine Schiedsinstanz/ein Schiedsrichter wiederhergestellt wurde und der Schiedsrichter sich nicht in diagnostics.sh get_replica_status befindet, folgen Sie diesem Verfahren.

Wenn für die Bereitstellung eine dedizierte Arbiter-VM verwendet wird, führen Sie für Arbitervip zusätzlich Schritt 4 aus, und führen Sie dann die folgenden Schritte aus:

1. Führen Sie im Cluster-Manager diesen Befehl aus, um die mongodb start/stop-Skripts auf Basis der Systemkonfiguration zu erstellen:

cd /var/qps/bin/support/mongo

build_set.sh --all --create-scripts

2.  Führen Sie auf PCRFCLIENTXX oder (und) Arbiter diesen Befehl aus, um alle Prozesse aufzulisten, die Sie starten müssen.

cd etc/init.d/

ll | grep sessionmgr

3.  Führen Sie auf PCRFCLIENTXX oder (und) Arbiter für jede Datei, die in der letzten Ausgabe aufgeführt ist, diesen Befehl aus, ersetzen Sie xxxxx durch Portnummern, Beispiel für 27717 hier:

/etc/init.d/sessionmgr-xxxxx start

Example:

/etc/init.d/sessionmgr-27717 start

4. Wenn Arbiter-VIP verwendet wird, überprüfen Sie, ob eine der PC-Ressourcen auf pcrfclient01 mithilfe dieser Befehle bereinigt werden muss:

pcs resource show | grep –v started

Wenn eine Ausgabe durch den Befehl in Schritt 4 zurückgegeben wird, bereinigen Sie die PC-Ressource mit dem folgenden Befehl. Wiederholen Sie für mehrere PC-Ressourcen, die nicht gestartet wurden, den Befehl für jede Ressource:

pcs resource cleanup

Überprüfen

Überprüfen Sie die Integrität des Replikationsstatus:

Run diagnostics.sh on pcrfclient01

Wenn der Schiedsrichter als Schiedsrichter und nicht als Schiedsrichter/Kreditgeber fungiert, können Sie folgende Schritte ausführen, um zu überprüfen, ob die VM vollständig wiederhergestellt ist oder nicht:

1. Auf dem primären Schiedsrichter sollten alle Mongo-Prozesse ausgeführt werden, und dieser Schiedsspruch kann auf folgende Weise überprüft werden:

ps –aef | grep mongo

2. Stellen Sie sicher, dass alle Prozesse unter Überwachung der Monit für einen Schiedsrichter in einem guten Zustand (Laufen/Überwacht) sind.

monit summary