In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
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.
Cisco empfiehlt, dass Sie über Kenntnisse zu folgenden Themen verfügen:
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.
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.
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.
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:
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
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 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:
ps –aef | grep mongo
monit summary