Performance Improvement

Critical Resources Monitoring in CPS using KPIs

Feature Summary and Revision History

Table 1. Summary Data

Applicable Product(s) or Functional Area

CPS

Applicable Platform(s)

Not Applicable

Default Setting

Not Applicable

Related Changes in This Release

Not Applicable

Related Documentation

CPS SNMP, Alarms, and Clearing Procedures Guide

CPS Troubleshooting Guide

Table 2. Revision History

Revision Details

Release

First introduced

20.2.0

Feature Description

CPS now provides support to monitor whether SVN on pcrfclient VMs are in sync to ensure stable operations.

A new alarm is generated as alert when SVN is not in sync and a corresponding clear alarm is triggered when SVN is in sync.

You can use the following commands to get the SVN repos and revision number details:

/usr/bin/svn info http://pcrfclient01/repos
/usr/bin/svn info http://pcrfclient02/repos

The SVN KPI is captured using whisper .wsp in /var/lib/carbon/whisper/cisco/quantum/qps/pcrfclient01 location and Whisper provides details of CPU, memory, and other plugins which are defined in the collectd.conf file.

The following new alarms has been added:

  • SVNnotinsync

  • SVNinsync

For more information, see the following sections:

  • Application Notifications table in the CPS SNMP, Alarms, and Clearing Procedures Guide

  • Clearing Procedures chapter in the CPS SNMP, Alarms, and Clearing Procedures Guide

  • Testing Traps Generated by CPS in the CPS Troubleshooting Guide

The following new statistics has been added:

  • svn_status.records,1.0

  • svn_status.records,0.0

For more information on statistics, see Statistics/KPI Additions or Changes.

Enabling In-Service MongoDB Authentication

Table 3. Summary Data

Applicable Product(s) or Functional Area

CPS

Applicable Platform(s)

Not Applicable

Default Setting

Enabled -Configuration Required

Related Changes in This Release

Not Applicable

Related Documentation

CPS Installation Guide for OpenStack

CPS Installation Guide for VMware

Table 4. Revision History

Revision Details

Release

First introduced

20.2.0

Feature Description

CPS supports enabling in-service MongoDB authentication. In case of GR/multi-cluster setups, add:

  • remote_site_ip in the Configuration.csv file for VMware setups. This parameter needs to be added in both clusters.

  • remoteSiteIp in the YAML file for OpenStack setups. This parameter needs to be added in both clusters.

For more information, see the following sections:

  • General Configuration and MongoDB Authentication Process sections in the CPS Installation Guide for VMware

  • Configuration Parameters - HA System and MongoDB Authentication Process sections in the CPS Installation Guide for OpenStack.

Logs are available over the console and in the files:

  • /var/log/broadhop/scripts/mongo_auth_upgrade.log

  • /var/log/sessionmgr-XXXX.log in the respective VM

Configuration and Restrictions

  • Configurations need to be done in the Configuration.csv file.

  • Encrypted password only needs to be updated.

Troubleshooting

If MongoDB processes on arbitervip are not coming up when enabling/disabling the MongoDB authentication, see MongoDB Processes not Coming Up on Arbitervip section in the CPS Troubleshooting Guide.

KPI Support to Monitor MongoDB Fragmentation and Generate an SNMP Alarm

Feature Summary and Revision History

Table 5. Summary Data

Applicable Product(s) or Functional Area

CPS

Applicable Platform

Not Applicable

Default Setting

Enabled – Configuration Required

Related Changes in This Release

Not Applicable

Related Documentation

CPS Troubleshooting Guide

CPS SNMP, Alarms, and Cleaning Guide

CPS Operation Guide

Table 6. Revision History

Revision Details

Release

First introduced

20.2.0

Feature Description

CPS supports new KPIs to monitor MongoDB level fragmentation in bulkstats via Grafana and to generate an SNMP alarm when MongoDB fragment percentage exceeds a specified value.

The following new alarms are added:

  • MongoPrimaryDB fragmentation exceeded the threshold value

  • PrimaryDB fragmentation percent conforms to threshold

For more information on alarms, see the following guides:

  • Application Notifications table and Clearing Procedures chapter in the CPS SNMP, Alarms, and Cleaning Guide

  • Testing Traps Generated by CPS in the CPS Troubleshooting Guide

  • DB Fragmentation Monitoring KPIs and Resync Member of a Replica Set sections in the CPS Operation Guide

Optimized Secondary Binding Lookup

Feature Summary and Revision History

Table 7. Summary Data

Applicable Product(s) or Functional Area

CPS

Applicable Platform

Not Applicable

Default Setting

Enabled – Configuration Required

Related Changes in This Release

Not Applicable

Related Documentation

Contact your Cisco Account representative

Table 8. Revision History

Revision Details

Release

First introduced

20.2.0

Feature Description

CPS is enhanced to provide support to query on available secondary member of the local site replica-set and remote site replica-set available in local site simultaneously to get the secondary key record from SK DB.


Note

  • This feature provides improvement for secondary key lookups happening on secondary sessions initiate requests in the current site and their primary sessions present in the remote site.

  • In case there is any latency between the primary and secondary sites, the latency time is reduced while finding the secondary key records for secondary session initiate call processing.

  • There are two parts of this feature. Both of them are optimized to reduce the processing time to match the latency between the sites.

    The current feature implementation covers the following to reduce the processing time to match the latency between the sites:

    • Optimization in existing serial or sequential query for secondary key lookup.

    • Introduction of parallel query for secondary key lookup.


The following is the list of new qns.conf file parameters added:

  • enable.primary.parallel.queries

  • mongo.skdb.query.pool.size

  • mongo.skdb.query.thread.pool.queue.size

For more information on qns.conf file parameters, contact your Cisco Account representative.

The following new statistics are added:

  • skdb_cache_get_total.qns_stat.success

  • skdb_cache_get_total.qns_stat.error

  • skdb_cache_get_total.qns_stat.total_time_in_ms

  • skdb_cache_get_total.qns_stat.avg

  • skdb_cache_get.qns_stat.success

  • skdb_cache_get.qns_stat.error

  • skdb_cache_get.qns_stat.total_time_in_ms

  • skdb_cache_get.qns_stat.avg

  • skdb_cache_get_remote.qns_stat.success

  • skdb_cache_get_remote.qns_stat.error

  • skdb_cache_get_remote.qns_stat.total_time_in_ms

  • skdb_cache_get_pri.qns_stat.avg

  • skdb_cache_get_pri.qns_stat.success

  • skdb_cache_get_pri.qns_stat.error

  • skdb_cache_get_pri.qns_stat.total_time_in_ms

  • skdb_cache_get_pri.qns_stat.avg

  • skdb_cache_get_pri_remote.qns_stat.success

  • skdb_cache_get_pri_remote.qns_stat.error

  • skdb_cache_get_pri_remote.qns_stat.total_time_in_ms

  • skdb_cache_get_pri_remote.qns_stat.avg

  • parallel_query_skdb_fail

For more information on statistics, see Statistics/KPI Additions or Changes.

Memory and Performance Impact

When the feature is enabled, additional threads are invoked to process the parallel operation to fetch the Secondary Key records from SK DB which increases the CPU consumption by 3-4 %.

Support CPS on ESXi 6.7

Feature Summary and Revision History

Table 9. Summary Data

Applicable Product(s) or Functional Area

CPS

Applicable Platform(s)

Not Applicable

Default Setting

Enabled - Always-on

Related Changes in This Release

Not Applicable

Related Documentation

CPS Installation Guide for VMware

Table 10. Revision History

Revision Details

Release

First introduced

20.2.0

Feature Description

CPS is now supported on ESXi 6.7. To support CPS on ESXi 6.7, you need to install OVF tool 4.3.0 version.

Version 4.3.0 for VMware 6.5/6.7: VMware-ovftool-4.3.0-13981069-lin.x86_64.bundle

You can download the OVF tool from https://code.vmware.com/web/tool/4.3.0/ovf.

Upgrade CentOS to 8.1

Feature Summary and Revision History

Table 11. Summary Data

Applicable Product(s) or Functional Area

CPS

Applicable Platform(s)

Not Applicable

Default Setting

Enabled - Always-on

Related Changes in This Release

Not Applicable

Related Documentation

Not Applicable

Table 12. Revision History

Revision Details

Release

First introduced

20.2.0

Feature Description

In CPS 20.2.0 release, CentOS is upgraded to 8.1 version. With CentOS 8.1, kernel is upgraded to 4.18.0-147.5.1.el8_1.x86_64. Also, all the packages are upgraded to be compatible with CentOS 8.1.

  • Network Time Protocol (NTP) is implemented using Chronyd daemon in Centos 8.1. Chronyd daemon replaces NTPD daemon. To check if the system time is synchronized, use the following commands:

    • chronyc sources: Displays information about the current time sources that chronyd is accessing.

    • chronyc tracking: Provides information about time sync status.

    • chronyc sourcestats: Displays information about the drift rate and offset estimation process for each of the sources currently being examined by chronyd.

    For more information on Chrony, see Red Hat documentation.


    Note

    In this release, automatic installation and configuration of NTP is added for Cluster Manager.


  • Corosync package has been upgraded. Current corosync version isn’t compatible with previous release corosync version. Due to corosync version incompatibility, during in-service migration (ISSM) Set1 and Set 2 VMs won't be able to form the cluster. This leads to split brain scenario during ISSM. This is transient and system recovers automatically once both Set 1 and Set 2 VMs are upgraded to new corosync version. In-service migration has been designed to migrate customer system with minimal disruption of traffic.

    Transport protocol is changed for Corosync from udpu to knit

  • Puppet is upgraded from 3.6.2-3 to 5.5.19 version. Puppet code has been modified to adapt to this change. Customers are also required to test and adapt custom puppet code before applying same to CPS.

  • Grafana package is upgraded from 6.2.2-1 to 6.7.1-1.

  • MongoDB is upgraded to 3.6.17.

  • Memcache is upgraded to 1.5.9-2.

Memory and Performance Impact

The boot time for VM has marginally increased. Also, there’s a moderate increase in puppet run time during fresh installation and ISSM. For subsequent puppet runs there’s no change in execution time.

Deployment Considerations

It’s required to have ESXi Hosts upgraded to minimum 6.5. Controller location should be set to IDE or SCSI. For SCSI, select the SCSI Controller to VMware Paravirtual.


Note

It is recommended to use SCSI controller.


The following is a sample configuration:

Upgrade/Migration/Backward Compatibility Considerations

CPS 20.2.0 is built on a newer version of CentOS. Previous versions of the CPS platform used CentOS 7; however CPS 20.2.0 uses CentOS 8.1. Because of this change, an in-service software upgrade (ISSU) is not possible. If customers want to move to CPS 20.2.0, they must perform an in-service migration which has been designed to migrate their system with minimal disruption of traffic.

In CPS 20.2.0, puppet is upgraded from 3.6.2-3 to 5.5.19 version. Puppet code has been modified to adapt to this change. Previous release puppet code is not compatible with the current puppet version (5.5.19). Customer specific puppet code must be adapted to current release puppet version (5.5.19) before applying it to CPS 20.2.0.

VMware ESXI server must be updated to 6.5 or more.

Backup/Restore Considerations

config_br.py script isn’t supported for backup and restoring users.

Geo-Redundancy/HA Consideration

As Corosync version is incompatible with previous release, there is traffic loss during ISSM.

guestNic value must be configured for standalone arbiter. For more information, refer to the CPS Geographic Redundancy Guide.

Upgrade MongoDB from 3.6.9 to 3.6.17

In CPS 20.2.0, MongoDB has been upgraded from 3.6.9 to 3.6.17. To verify mongod is running the latest RPMs, execute the command:

runonall.sh 'grep "db version" /var/log/mongo* | tail -1' 2>&1 | grep 'CONTROL'
[pcrfclient02] out: /var/log/mongodb-27727.log:2018-04-09T06:28:28.207+0000 I CONTROL [initandlisten] db version v3.6.17
[sessionmgr01] out: /var/log/mongodb-27727.log:2018-04-09T06:30:57.810+0000 I CONTROL [initandlisten] db version v3.6.17
[sessionmgr02] out: /var/log/mongodb-27727.log:2018-04-09T06:31:43.853+0000 I CONTROL [initandlisten] db version v3.6.17