Verfahren zur Wiederherstellung von Subversion Sync in CPS

Einleitung

In diesem Dokument wird das Verfahren zur Wiederherstellung der Subversion (SVN)-Synchronisierung in Cisco Policy Suite (CPS) beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Linux 
• CPS

Anmerkung: Cisco empfiehlt, dass Sie über Berechtigungen für den Root-Zugriff auf die CPS CLI verfügen müssen.

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• CPS 20.2
• Unified Computing System (UCS)-B

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Hintergrundinformationen

Apache SVN ist das Versionsverwaltungssystem, das in CPS verwendet wird. Es verwaltet alle CPS-Richtlinienkonfigurationen und verfügt über Repositorys, in denen Dateien erstellt, aktualisiert und gelöscht werden können. SVN behält den Dateiunterschied bei, wenn eine Datei auf dem Server geändert wird und generiert für jede Änderung eine Versionsnummer.

Generell werden die meisten Interaktionen mit SVN über Policy Builder (PB) durchgeführt.

Mit anderen Worten: CPS speichert die Richtlinienkonfigurationsdaten unter Verwendung von SVN oder Subversion in einer SVN-Datenbank. Diese bietet eine grafische Benutzeroberfläche (GUI) zum Anzeigen und Bearbeiten der SVN-Datenbank (DB) mit dem Namen Policy Builder (PB), die über eine externe Schnittstelle, die virtuelle IP (VIP) und den Policy Director (PD) mit dem virtuellen pcrfclient/Operations and Maintenance (OAM)-System verbunden ist.

Die Konfigurationsdaten in der SVN-DB der pcrfclients müssen zu jedem beliebigen Zeitpunkt synchronisiert sein.

CPS besteht aus der Bereitstellung von pcrfclient-Knoten im aktiven und Standby-HA-Modell, wobei ein Knoten als aktiver und der andere Knoten als Standby-Knoten ausgeführt wird.

Problem

Es ist möglich, dass in einigen Situationen die SVN zwischen pcrfclient-Knoten in einem CPS nicht synchron ist und dann synchronisiert werden muss.

In einigen Fällen, meist post-policy veröffentlichen, zum Zeitpunkt des Arbitervip Switchover oder auch wenn der SVN-Server nicht erreichbar ist, dann SVN-Sperren auf dem Ziel-Repository erstellt.

Dann ist die SVN-Synchronisierung veraltet, und diese werden in /var/log/httpd/svnsync.log in betroffenem pcrfclient. Wenn diese Sperren erstellt werden, zeigt die CPS-Diagnoseausgabe den SVN-Synchronisierungsfehler an. Führen Sie diesen Befehl im Cluster-Manager oder im pcrfclient aus, um den SVN-Synchronisierungsstatus zu überprüfen.

[root@installer ~]# diagnostics.sh --svn
CPS Diagnostics HA Multi-Node Environment
----------------------------
Checking svn sync status between pcrfclient01 & 02...
svn is not sync between pcrfclient01 & pcrfclient02...[FAIL]
Corrective Action(s): Run ssh pcrfclient01 /var/qps/bin/support/recover_svn_sync.sh

Verfahren zur Wiederherstellung der SVN-Synchronisierung zwischen pcrfclient-Knoten

Ansatz 1

Dieser Ansatz wird verwendet, wenn keine SVN-Sperre erstellt wurde.

Schritt 1: Melden Sie sich wie in der Diagnose gezeigt am entsprechenden pcrfclient-Knoten an, und führen Sie diesen Befehl aus, um SVN zwischen aktiven und Standby-pcrfclient-Knoten zu synchronisieren.

/var/qps/bin/support/recover_svn_sync.sh

Befehlsausgabe bei erfolgreicher SVN-Synchronisierung:

[root@dc1-pcrfclient01 ~]# /var/qps/bin/support/recover_svn_sync.sh
=================================================================
[Thu Aug 25 09:10:44 UTC 2022] [INFO] /var/qps/bin/support/recover_svn_sync.sh script is running from console
-----sync betweeen pcrfclient01 & pcrfclient02 --------------------
[Thu Aug 25 09:10:47 UTC 2022] [INFO] Doing SVN sync between pcrfclient01 and pcrfclient02...
[Thu Aug 25 09:11:06 UTC 2022] [INFO] SVN are already in sync between pcrfclient01 and pcrfclient02
[Thu Aug 25 09:11:07 UTC 2022] [INFO] SVN UUID are matched between pcrfclient01 and pcrfclient02
[Thu Aug 25 09:11:07 UTC 2022] [INFO] SVN sync completed successfully for pcrfclient01 & pcrfclient02
[root@dc1-pcrfclient01 ~]#

Wenn dieser Befehl SVN nicht synchronisieren kann und diesen Fehler im Zusammenhang mit der SVN-Sperre im Ziel- oder Spiegelrepository auslöst, gehen Sie zu Ansatz 2., der die SVN-Diebstahlsperre beinhaltet.

Schritt 2: Führen Sie diesen Befehl im Cluster Manager oder im pcrfclient aus, um den SVN-Synchronisierungsstatus zu überprüfen.

[root@installer ~]# diagnostics.sh --svn
CPS Diagnostics HA Multi-Node Environment
---------------------------
Checking svn sync status between pcrfclient01 & pcrfclient02...[PASS]
[root@installer ~]#

Ansatz 2

Sie können diesen Ansatz verwenden, wenn die SVN-Sperre im Ziel- oder Spiegelungs-Repository erstellt wird.

Schritt 1: Melden Sie sich wie in Diagnose dargestellt beim entsprechenden pcrfclient-Knoten an, und führen Sie diesen Befehl aus.

Command syntax:
svnsync synchronize file:///var/svn/repos-mirror http://svn.example.com/repos

Sample command:
/usr/bin/ssh -k qns@pcrfclient01 -t '' '/usr/bin/svnsync info http://pcrfclient02/repos-proxy-sync'

[root@dc1-pcrfclient01 ~]# /usr/bin/ssh -k qns@pcrfclient01 -t '' '/usr/bin/svnsync info http://pcrfclient02/repos-proxy-sync'
Source URL: http://pcrfclient01/repos-proxy-sync
Source Repository UUID: f1937c9d-1688-463a-9d4e-db944d9aafb1
Last Merged Revision: 170
[root@dc1-pcrfclient01 ~]#

2. Führen Sie diesen Befehl aus, um die SVN-Sperre im Ziel- oder Spiegelrepository zu entwenden.

/usr/bin/ssh -k qns@pcrfclient01 -t '' '/usr/bin/svnsync sync --steal-lock http://pcrfclient02/repos-proxy-sync'

Anmerkung: Dieser Befehl veranlasst svnsync dazu, bei Bedarf die Sperre zu stehlen, die es auf dem Ziel- oder Mirror-Repository verwendet, um den exklusiven Zugriff auf das Repository sicherzustellen. Diese Option darf nur verwendet werden, wenn eine Sperre im Ziel- oder Mirror-Repository vorhanden und als veraltet bekannt ist, d. h. wenn Sie sicher sind, dass es keine anderen svnsync-Prozesse gibt, die auf das Repository zugreifen.

3. Führen Sie diesen Befehl aus, um SVN zwischen aktiven und Standby-pcrfclient-Knoten zu synchronisieren.

[root@dc1-pcrfclient01 ~]# /var/qps/bin/support/recover_svn_sync.sh
=================================================================
[Thu Aug 25 09:10:44 UTC 2022] [INFO] /var/qps/bin/support/recover_svn_sync.sh script is running from console
-----sync betweeen pcrfclient01 & pcrfclient02 --------------------
[Thu Aug 25 09:10:47 UTC 2022] [INFO] Doing SVN sync between pcrfclient01 and pcrfclient02...
[Thu Aug 25 09:11:06 UTC 2022] [INFO] SVN are already in sync between pcrfclient01 and pcrfclient02
[Thu Aug 25 09:11:07 UTC 2022] [INFO] SVN UUID are matched between pcrfclient01 and pcrfclient02
[Thu Aug 25 09:11:07 UTC 2022] [INFO] SVN sync completed successfully for pcrfclient01 & pcrfclient02
[root@dc1-pcrfclient01 ~]#

2. Führen Sie diesen Befehl im Cluster Manager oder im pcrfclient aus, um den SVN-Synchronisierungsstatus zu überprüfen.

[root@installer ~]# diagnostics.sh --svn
CPS Diagnostics HA Multi-Node Environment
---------------------------
Checking svn sync status between pcrfclient01 & pcrfclient02...[PASS]
[root@installer ~]#