Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Informations générales

Problème

Procédure pour récupérer la synchronisation SVN entre les noeuds pcrfclient

Approche 1

Approche 2

Introduction

Ce document décrit la procédure pour récupérer la synchronisation de subversion (SVN) dans Cisco Policy Suite (CPS).

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

- Linux

- CPS

Note: Cisco recommande que vous ayez un accès racine privilégié à l'interface de ligne de commande CPS.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

- CPS 20.2

- UCS (Unified Computing System)-B

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Apache SVN est le système de création de version et de contrôle de révision utilisé dans CPS. Il gère toutes les configurations de stratégie CPS et dispose de référentiels dans lesquels les fichiers peuvent être créés, mis à jour et supprimés. SVN conserve la différence de fichier chaque fois qu'une modification est apportée à un fichier sur le serveur et génère un numéro de révision pour chaque modification.

En général, la plupart des interactions avec SVN sont effectuées via Policy Builder (PB).

En d'autres termes, CPS stocke les données de configuration de stratégie par l'utilisation de SVN, ou subversion, dans une base de données SVN. Il fournit une interface utilisateur graphique (GUI) pour afficher et modifier la base de données SVN appelée Policy Builder (PB) qui se connecte à la machine virtuelle pcrfclient/OAM (Operation and Maintenance) via une interface externe, l'IP virtuelle (VIP) et le Policy Director (PD).

Les données de configuration de la base de données SVN des deux pcrfclients doivent être synchronisées à tout moment.

CPS consiste en un déploiement de modèles haute disponibilité (HA) actifs et en veille de noeuds pcrfclient, où un noeud est actif et l'autre en veille.

Problème

Il est possible que dans certaines situations, le SVN entre les noeuds pcrfclient dans un CPS ne soit pas synchronisé et qu'il soit alors nécessaire de les rendre synchronisés.

Dans certains cas, la plupart du temps après la publication de la politique, au moment de la commutation arbitervip ou même si le serveur SVN n'est pas accessible, alors des verrous SVN sont créés sur le référentiel de destination.

Ensuite, la synchronisation SVN devient obsolète et celles-ci sont visibles dans /var/log/httpd/svnsync.log dans pcrfclient concerné. Lorsque ces verrous sont créés, le résultat du diagnostic CPS vous indique l'erreur de synchronisation SVN. Exécutez cette commande à partir de Cluster Manager ou de pcrfclient afin de vérifier l'état de synchronisation SVN.

[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

Procédure pour récupérer la synchronisation SVN entre les noeuds pcrfclient

Approche 1

Cette approche est utilisée lorsqu'aucun verrou SVN n'est créé.

Étape 1. Connectez-vous au noeud pcrfclient respectif comme indiqué dans les diagnostics et exécutez cette commande pour synchroniser SVN entre les noeuds pcrfclient actifs et en veille.

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

Sortie de commande si la synchronisation SVN réussit :

[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 ~]#

Si cette commande ne peut pas synchroniser SVN et renvoie cette erreur liée au verrou SVN dans le référentiel de destination ou miroir, alors allez à Approche 2. qui implique le verrou de vol SVN.

Étape 2. Exécutez cette commande à partir de Cluster Manager ou pcrfclient, afin de vérifier l'état de synchronisation SVN.

[root@installer ~]# diagnostics.sh --svn

CPS Diagnostics HA Multi-Node Environment

---------------------------

Checking svn sync status between pcrfclient01 & pcrfclient02...[PASS]

[root@installer ~]#

Approche 2

Vous pouvez utiliser cette approche si le verrou SVN est créé dans le référentiel de destination ou miroir.

Étape 1. Connectez-vous au noeud pcrfclient correspondant comme indiqué dans les diagnostics et exécutez cette commande.

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. Exécutez cette commande pour voler le verrou SVN sur le référentiel de destination ou miroir.

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

Note: Cette commande force svnsync à voler, si nécessaire, le verrou qu'il utilise sur le référentiel de destination ou miroir pour assurer un accès exclusif au référentiel. Cette option ne doit être utilisée que lorsqu'un verrou existe dans le référentiel de destination ou miroir et est connu pour être périmé, c'est-à-dire lorsque vous êtes certain qu'aucun autre processus svnsync n'accède au référentiel.

3. Exécutez cette commande pour synchroniser SVN entre les noeuds pcrfclient actifs et en veille.

[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. Exécutez cette commande à partir de Cluster Manager ou de pcrfclient, pour vérifier l'état de synchronisation SVN.

[root@installer ~]# diagnostics.sh --svn

CPS Diagnostics HA Multi-Node Environment

---------------------------

Checking svn sync status between pcrfclient01 & pcrfclient02...[PASS]

[root@installer ~]#