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 Sie eine Fehlerbehebung für die Wiederherstellung von Richtlinienservern (PS) durchführen.
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.
In diesem Abschnitt wird beschrieben:
Wenn sich eine Instanz aufgrund eines geplanten Herunterfahrens oder aus einem anderen Grund im SHUTOFF-Zustand befindet, starten Sie die Instanz mit diesem 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 oam-s1 | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed | 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.
echo "show esc_datamodel opdata tenants tenant Pcrf deployments * state_machine | tab" | /opt/cisco/esc/confd/bin/confd_cli -u admin –C | grep qns-s2 SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed VM_ERROR_STATE
Schritt 4: Schalten Sie die Instanz von OpenStack ein.
source /home/stack/destackovsrc-Pcrf nova start SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed
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 oam-s1 | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 |SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed | 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 SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed
Weitere Informationen zur Wiederherstellung von Instanzkonfigurationen finden Sie unter Instanztypspezifische Verfahren.
Dieses Verfahren kann verwendet werden, wenn der Zustand der CPS-Instanz in OpenStack FEHLER ist:
Schritt 1: Überprüfen Sie den Status der Instanz in OpenStack.
source /home/stack/destackovsrc-Pcrf nova list --fields name,host,status | grep oam-s1 | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed | ERROR|
Schritt 2: Ü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 3: Melden Sie sich als Admin-Benutzer beim ESC Master an, und überprüfen Sie den Zustand der Instanz in opdata.
echo "show esc_datamodel opdata tenants tenant Pcrf deployments * state_machine | tab" | /opt/cisco/esc/confd/bin/confd_cli -u admin -C | grep oam-s1 SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed VM_ERROR_STATE
Schritt 4: 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 oam-s1_0_170d9c14-0221-4609-87e3-d752e636f57f nova reboot --hard oam-s1_0_170d9c14-0221-4609-87e3-d752e636f57f
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 oam-s1 | c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 |SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed | ACTIVE |
Schritt 6: Wenn Cluster Manager den Status nach dem Neustart in AKTIV ändert, aktivieren Sie 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 SVS1-tmo_oam-s1_0_fd8b0bb8-a2d7-4dae-8048-0c3d86c5d8ed
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.
Policy SVN Recovery:
Meist um Policy SVN in einem anderen, auf PCRFCLIENTXX gemounteten Volume unter /var/www/svn/repos/zu halten, so werden die Änderungen beim Verlust von Policy Svn reduziert, selbst wenn die Instanz verloren geht. Wenn Ihre Bereitstellung kein anderes Schlankheitsvolumen für Policy-SVN aufweist oder der Empfänger, in dem Policy-SVN gespeichert wurde, ebenfalls verloren ist, befolgen Sie die folgenden Schritte, um Policy SVN auf PCRFCLIENT01 wiederherzustellen.
Schritt 1: Melden Sie sich als Root-Benutzer beim Cluster Manager VM an.
Schritt 2: Beachten Sie die UUID des SVN-Repositorys mit diesem Befehl:
svn info http://pcrfclient02/repos | grep UUID
Der Befehl gibt die UUID des Repositorys aus:
For Example Repository UUID: ea50bbd2-5726-46b8-b807-10f4a7424f0e
Schritt 3: Überprüfen Sie, ob die SVN-Richtlinie synchronisiert ist, wenn der angegebene Befehl verwendet wird. Wenn ein Wert zurückgegeben wird, ist SVN bereits synchronisiert. Außerdem müssen Sie sie nicht über PCRFCLIENT02 synchronisieren, und Sie sollten Schritt 4 überspringen. Die Wiederherstellung nach der letzten Sicherung kann weiterhin für erforderlich verwendet werden, wie weiter unten in diesem Abschnitt beschrieben.
/usr/bin/svn propget svn:sync-from-url --revprop -r0 http://pcrfclient01/repos
Schritt 4: Wiederherstellung der SVN-Master/Slave-Synchronisierung zwischen dem pcrfclient01 und pcrfclient02 mit pcrfclient01 als Master durch Ausführung einer Reihe von Befehlen auf PCRFCLIENT01
/bin/rm -fr /var/www/svn/repos /usr/bin/svnadmin create /var/www/svn/repos /usr/bin/svn propset --revprop -r0 svn:sync-last-merged-rev 0 http://pcrfclient02/repos-proxy-sync /usr/bin/svnadmin setuuid /var/www/svn/repos/ "Enter the UUID captured in step 2" /etc/init.d/vm-init-client /var/qps/bin/support/recover_svn_sync.sh
Schritt 5: Wenn Policy SVN auf PCRFCLIENT01 mit PCRFCLEINT02 synchronisiert ist, das neueste svn jedoch nicht in Policy Builder wiedergibt, kann es mithilfe des Befehls auf Cluster Manager VM über die letzte Sicherung importiert werden.
config_br.py –a import --svn /mnt/backup/
Meist um Policy SVN in einem anderen, auf PCRFCLIENTXX gemounteten Volume unter /var/www/svn/repos/zu halten, so werden die Änderungen beim Verlust von Policy Svn reduziert, selbst wenn die Instanz verloren geht. Wenn Ihre Bereitstellung kein anderes Schlankheitsvolumen für Policy-SVN aufweist oder der Empfänger, in dem Policy-SVN gespeichert wurde, ebenfalls verloren ist, befolgen Sie die folgenden Schritte, um Policy SVN auf PCRFCLIENT02 wiederherzustellen.
Schritt 1: Secure Shell zum pcrfclient01
ssh pcrfclient01
Schritt 2: Führen Sie das Skript aus, um die SVN-Repos von pcrfclient01 auf pcrfclient02 zu synchronisieren.
/var/qps/bin/support/recover_svn_sync.sh
Überprüfen Sie den Systemstatus von pcrfclient:
run diagnostics.sh from pcrfrclient
Stellen Sie sicher, dass die Benutzeroberfläche PB, Control Center und Grafana zugänglich ist und ordnungsgemäß funktioniert.
/var/qps/bin/support/recover_svn_sync.sh
/var/qps/bin/support/recover_svn_sync.sh