Introduzione
In questo documento viene descritto come configurare le percentuali di soglia della frammentazione del database personalizzata in Cisco Policy Suite (CPS).
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
Nota: Cisco consiglia di disporre dell'accesso utente root con privilegi alla CLI di CPS.
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
- CPS 20.2
- Unified Computing System (UCS)-B
- MongoDB v3.6.17
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
CPS utilizza MongoDB per costituire la struttura di base del database (DB).
La frammentazione è una caratteristica di MongoDB. Questo avviso consente di monitorare in modo proattivo la frammentazione del database MongoDB, evitando così un eventuale maggiore utilizzo delle risorse (disco e memoria) dovuto a tale frammentazione.
CPS genera un allarme SNMP (Simple Network Management Protocol) quando la percentuale di frammentazione del database MongoDB supera un valore specificato.
OSPF (Open Shortest Path First) /etc/collectd.d/dbMonitorList.cfg Il file presente nelle macchine virtuali (VM) di sessionmgr contiene l'elenco dei database e i rispettivi valori percentuali di soglia di frammentazione.
Configurazione
Configurazioni
Approccio per CPS ospitato in OpenStack
Passaggio 1. Dalla macchina virtuale di Cluster Manager, eseguire questo comando per creare un backup del file di configurazione corrente.
#cp /etc/puppet/modules/qps/templates/collectd_worker/collectd.d/dbMonitorList.cfg /etc/puppet/modules/qps/templates/collectd_worker/collectd.d/dbMonitorList.cfg.bkp
Passaggio 2. Eseguire questo comando da Gestione cluster per ottenere la configurazione corrente dalle macchine virtuali sessionmgr (per confrontare e convalidare le modifiche successive).
#for host in $(hosts-all.sh | grep 'sessionmgr'); do echo checking in $host; ssh $host "cat /etc/collectd.d/dbMonitorList.cfg"; done
Output di esempio:
checking in sessionmgr01
session_cache|session|40
sk_cache|secondary_key|40
diameter|endpoints|40
spr|subscriber|40
balance_mgmt|account|40
checking in sessionmgr02
session_cache|session|40
sk_cache|secondary_key|40
diameter|endpoints|40
spr|subscriber|40
balance_mgmt|account|40
Passaggio 3. Modificare la soglia predefinita (40) sul valore consigliato (ad esempio, 60). Eseguire questo comando da Gestione cluster.
Nota: questo comando modifica la soglia per tutti i database. Se è necessario aggiornare la soglia per un database specifico, aggiornare il file manualmente.
#sed -i 's/40/60/g' /etc/puppet/modules/qps/templates/collectd_worker/collectd.d/dbMonitorList.cfg
Passaggio 4. Eseguire questo comando per confrontare i file in Gestione cluster per convalidare la modifica.
#diff /etc/puppet/modules/qps/templates/collectd_worker/collectd.d/dbMonitorList.cfg /etc/puppet/modules/qps/templates/collectd_worker/collectd.d/dbMonitorList.cfg.bkp
Output di esempio:
4c4
< session_cache|session|60
---
> session_cache|session|40
9c9
< sk_cache|secondary_key|60
---
> sk_cache|secondary_key|40
14c14
< diameter|endpoints|60
---
> diameter|endpoints|40
19c19
< spr|subscriber|60
---
> spr|subscriber|40
24c24
< balance_mgmt|account|60
---
> balance_mgmt|account|40
Passaggio 5. Eseguire questo comando per compilare la modifica in Gestione cluster.
[root@installer ~]# /var/qps/bin/build/build_puppet.sh
Copying /etc/puppet to /var/qps/images/puppet.tar.gz...
Creating MD5 Checksum...
[root@installer ~]#
Passaggio 6. Eseguire questo comando da Gestione cluster per applicare la modifica nelle macchine virtuali sessionmgr.
[root@installer ~]# for host in $(hosts-all.sh | grep 'sessionmgr'); do echo starting vm-init in $host; ssh $host "/etc/init.d/vm-init > /dev/null 2>&1 &"; done
starting vm-init in sessionmgr01
starting vm-init in sessionmgr02
[root@installer ~]#
Passaggio 7. Aspettate che la marionetta sia completata. Eseguire questo comando da Gestione cluster per visualizzare lo stato della configurazione del Marionetta.
#for host in $(hosts-all.sh | grep 'sessionmgr' | tail -1); do echo checking in $host; ssh $host "tail -f /var/log/puppet.log"; done
2022-11-08 06:32:23 +0000 Service[whisper](provider=cps) (info): whisper will be managed using monit.
2022-11-08 06:32:23 +0000 Service[whisper](provider=cps) (info): whisper will be managed using monit.
2022-11-08 06:32:23 +0000 /Stage[main]/Whisper/Service[whisper] (notice): Triggered 'refresh' from 1 event
2022-11-08 06:32:27 +0000 Stage[main] (info): Unscheduling all events on Stage[main]
2022-11-08 06:32:28 +0000 Puppet (notice): Applied catalog in 83.52 seconds
[Tue Nov 08 06:32:30 +0000 2022] * Completed puppet configuration for dc1-sessionmgr02...
[Tue Nov 08 06:32:30 +0000 2022] - NTP sync started, check the logs in vm-init.log
Approccio per CPS ospitato in VMWare
Passaggio 1. Aggiornare il /var/qps/config/deploy/csv/Configuration.csv file in Gestione cluster con il nome del database richiesto e il rispettivo valore percentuale di soglia. Il formato per fornire il valore percentuale di soglia personalizzato è il seguente (dove XX è il valore numerico di percentuale...ad esempio; 60).
session_cache,XX,
sk_cache,XX,
diameter,XX,
spr,XX,
balance_mgmt,XX,
Esempio di configurazione:
session_cache,60,
sk_cache,60,
diameter,60,
spr,60,
balance_mgmt,60,
Passaggio 2. Per aggiornare il /etc/collectd.d/dbMonitorList.cfg in modo che abbia i nuovi valori di soglia dal file Configuration.csv:
[root@installer ~]# /var/qps/install/current/scripts/import/import_deploy.sh
Filenames that will be processed
AdditionalHosts.csv Configuration.csv DBConfigServer.csv Definitions.csv Hosts.csv ReplicationSets.csv SessionCache.csv VLANs.csv VMSpecification.csv SecureConfig.csv VipProxyConfiguration.csv DSCPConfig.csv CriticalFiles.csv
The CSV files in /var/qps/config/deploy/csv are converted to json files in /var/qps/config/deploy/json..
build the hosts file to /var/www/html/hosts...
build the /etc/hosts file from the json configuation... /etc/hosts is backed to /etc/hosts.back
Skipping backup of '/etc/hosts' -- no changes detected.
Redis by default disabled -DenableQueueSystem=false in /etc/broadhop/qns.conf
Removing feature configs moved to core
Removing ws feature from pb and pcrf feature file
Building /etc/broadhop...
Copying to /var/qps/images/etc.tar.gz...
Creating MD5 Checksum...
Generating /etc/broadhop/servers.all
Rebuilding facts for: 'installer' (aka 'installer')
Creating md5sum for hosts file to validate later
Rebuilding facts for: 'dc1-lb01' (aka 'lb01')
Rebuilding facts for: 'dc1-sessionmgr01' (aka 'sessionmgr01')
Rebuilding facts for: 'dc1-lb02' (aka 'lb02')
Rebuilding facts for: 'dc1-qns01' (aka 'qns01')
Rebuilding facts for: 'dc1-qns02' (aka 'qns02')
Rebuilding facts for: 'dc1-pcrfclient01' (aka 'pcrfclient01')
Rebuilding facts for: 'dc1-sessionmgr02' (aka 'sessionmgr02')
Rebuilding facts for: 'dc1-pcrfclient02' (aka 'pcrfclient02')
No file for VipProxyConfiguration found
Copying /etc/puppet to /var/qps/images/puppet.tar.gz...
Creating MD5 Checksum...
[root@installer ~]#
Passaggio 3. Eseguire questo comando da Gestione cluster per applicare la modifica nelle macchine virtuali sessionmgr.
[root@installer ~]# for host in $(hosts-all.sh | grep 'sessionmgr'); do echo starting vm-init in $host; ssh $host "/etc/init.d/vm-init > /dev/null 2>&1 &"; done
starting vm-init in sessionmgr01
starting vm-init in sessionmgr02
[root@installer ~]#
Passaggio 4. Aspettate che la marionetta sia completata. Eseguire questo comando da Gestione cluster per visualizzare lo stato della configurazione del Marionetta.
#for host in $(hosts-all.sh | grep 'sessionmgr' | tail -1); do echo checking in $host; ssh $host "tail -f /var/log/puppet.log"; done
2022-11-08 06:48:34 +0000 Service[whisper](provider=cps) (info): whisper will be managed using monit.
2022-11-08 06:48:34 +0000 Service[whisper](provider=cps) (info): whisper will be managed using monit.
2022-11-08 06:48:34 +0000 /Stage[main]/Whisper/Service[whisper] (notice): Triggered 'refresh' from 1 event
2022-11-08 06:48:39 +0000 Stage[main] (info): Unscheduling all events on Stage[main]
2022-11-08 06:48:40 +0000 Puppet (notice): Applied catalog in 93.27 seconds
[Tue Nov 08 06:48:42 +0000 2022] * Completed puppet configuration for dc1-sessionmgr02...
[Tue Nov 08 06:48:42 +0000 2022] - NTP sync started, check the logs in vm-init.log
Verifica
Fare riferimento a questa sezione per verificare che la configurazione funzioni correttamente.
Convalidare la configurazione più recente nelle macchine virtuali di session mgr e confrontarla con l'output del passo 2. Eseguire questo comando da Gestione cluster.
[root@installer ~]# for host in $(hosts-all.sh | grep 'sessionmgr'); do echo checking in $host; ssh $host "cat /etc/collectd.d/dbMonitorList.cfg"; done
checking in sessionmgr01
session_cache|session|60
sk_cache|secondary_key|60
diameter|endpoints|60
spr|subscriber|60
balance_mgmt|account|60
checking in sessionmgr02
session_cache|session|60
sk_cache|secondary_key|60
diameter|endpoints|60
spr|subscriber|60
balance_mgmt|account|60
[root@installer ~]#
Risoluzione dei problemi
Le informazioni contenute in questa sezione permettono di risolvere i problemi relativi alla configurazione.
Questo avviso di frammentazione MongoDB è stato introdotto nella versione 20.1 e non è stato misurato nelle versioni precedenti. Per impostazione predefinita, il valore di soglia della frammentazione è 40%. Questo valore di soglia deve essere modificato in base alle dimensioni della distribuzione, ai modelli di traffico (modelli di chiamata) e ad altri fattori relativi ai modelli di traffico. In caso contrario, CPS genera avvisi di superamento della soglia di frammentazione del database non desiderati/indesiderati.
Feedback