BW ApplicationDeliveryPlatformConfigGuide
BW ApplicationDeliveryPlatformConfigGuide
Document Version 1
Copyright Notice
Copyright© 2020 Cisco Systems, Inc. All rights reserved.
Trademarks
Any product names mentioned in this document may be trademarks or registered
trademarks of Cisco or their respective companies and are hereby acknowledged.
This section describes the changes to this document for each release and document
version.
ADP Farm
NS
AS Cluster
ADP
Application Application
...
BroadWorks BroadWorks
Container Container
BroadWorks Platform
Tomcat (v8.0)
BW
Communication OCI-P
Web Utility
Application AS- PS
OCI-C
...
httpnio
http (blocking
http (async)
Web
Application
LocationAPI NS
XML
CTI
This guide provides general Application Delivery Platform product description and
deployment information. It explains the Cisco BroadWorks and web applications
management features of the Application Delivery Platform and provides some guidelines
on web application development.
Backend A
[WebContainer]
App-A
Bindings App-C
Backend C
ADP [WebContainer]
[LoadBalancer] App-B
App-C
Backend B
ProxyServer X
[WebContainer]
App-B
App-C
ProxyServer Y
Backend D
[WebContainer]
App-D
For more information about the Load Balancer application, see the Load Balancing
Feature Description [4].
The following steps should be executed to start an Application Delivery Platform Server.
1) Obtain a license from Cisco. For more information, see section 5 Licensing.
2) Install the Application Delivery Platform from the binary image. For more information,
see the Cisco BroadWorks Software Management Guide [1].
3) Configure the BWCommunicationUtility on the Application Delivery Platform. For
more information, see section 8.4 Configuration of BWCommunicationUtility.
4) Configure the Application Server cluster to allow Application Delivery Platform
connectivity.
5) Start the Application Delivery Platform.
The Application Delivery Platform is distributed using binary images for Linux. The image
files are named using the usual format:
ADP_Rel_2020.07_1.yyy.Linux-x86_64.bin
Where yyy is a unique identifier for the Application Delivery Platform Release 2020.07.
The Application Delivery Platform has its own license. This license is such that it can
contain multiple licenses to allow the running of Cisco BroadWorks applications.
The Application Delivery Platform does not start if it is not properly licensed.
The installation procedure for the Application Delivery Platform is similar to the one used
for existing Cisco BroadWorks servers. For detailed information and procedures on
installing the Application Delivery Platform, see the Cisco BroadWorks Software
Management Guide [1].
The upgrade process for the Application Delivery Platform works the same way as for
other Cisco BroadWorks servers. However, the Cisco BroadWorks and web applications
hosted by the Application Delivery Platform are handled differently from the Application
Delivery Platform itself. The following subsection provides more information.
Parameters description:
forceOption : This parameter determines the force option. Use the
"force" option to apply the change immediately.
Otherwise, a restart of the application is required for
the changes to apply.
option : This parameter determines the options.
activeSoftwareVersion: This parameter specifies the active software version.
type : This parameter determines whether the activation type is
the server or a specific application. The software
automatically determines whether it needs to upgrade or
rollback.
server : This parameter controls the activation of the server.
identity : This nested parameter specifies the name of the server
identity to set to "active". It is usually the short
name of a BroadWorks server (for example, Profile
Server, Network Server, and so on).
version : This nested parameter specifies the version of the
software to activate.
revert : This parameter provides the ability to revert to a
previous release. Use the "revert" option to perform a
revert to the specified previous release. Otherwise, a
rollback to the specified previous release is performed.
backupLocation : This nested parameter specifies the full path of the
database backup file to use when performing a revert.
application : This parameter controls the activation of an application.
name : This parameter specifies the name of the application to
set to "active".
======================================================================
set
[<forceOption>, Choice = {force}]
<option>, Choice = {activeSoftwareVersion}
activeSoftwareVersion:
<type>, Choice = {server, application}
server:
<identity>, String {1 to 80 characters}
<version>, String {1 to 80 characters}
[<revert>, Choice = {revert}]
revert:
Reverting to a previous version is executed the same way, that is, through the CLI. Note
that since the Application Delivery Platform is release independent, rollback is not
supported. However, for the revert operation to be allowed, the list of applications installed
on the Application Delivery Platform, including their versions, must be the same as it was
before the upgrade.
Since these applications are delivered as release independent, the build format is date
based, as follows:
APP_YYYY.MM_1.XXX
Where:
APP represents the application name (for example, LoadBalancer).
YYYY represents the year (for example, 2020).
MM represents the month (for example, 07).
XXX represents the incremented build number.
Since these applications are delivered as release anchored, the build format is release
based, as follows:
APP_MAJOR.MINOR_1.XXXX
Where:
APP represents the application name (for example, CommPilot).
MAJOR represents the major version (for example 24, corresponding to the
Application Server version).
MINOR represents the minor version (for example, 0).
XXXX represents the incremented build number.
The Application Delivery Platform hosts several active components that provide internal
and external services.
7.1.1.2 Logs
The Software Manager logs are located in directory /var/broadworks/logs/swmanager.
NOTE: The statistics collected by the SNMP Agent are lost when the SNMP Agent is stopped.
7.1.2.2 Logs
The SNMP Agent logs are located in the /var/broadworks/logs/snmp directory.
7.1.3.2 Logs
The License Manager logs are located in the /var/broadworks/logs/lmd directory.
7.1.4.2 Logs
The Configuration Agent issues logs to the /var/broadworks/logs/config directory.
The platform processes must always be running for the Cisco BroadWorks applications to
run properly. The healthmon command monitors these processes and reports any
missing platform processes.
7.2.1 WebContainer
The Application Delivery Platform deploys a WebContainer application to host the web
applications. The WebContainer is built around the Tomcat application server.
The WebContainer application is like any other automatic Cisco BroadWorks applications,
that is, it can be activated, deployed, undeployed, and deactivated.
WebContainer Components
Mgr
HTTPNIO
Executor
STATS #B
STATS #B
HTTP
HTTP-Nio
Connector
STATS #C
CTI OCIC
Executor Executor BCCT
(OCIP,
Proprietary, XML-based BwCommunicationUtility
OCIC,
OCIP SMAP)
CTI Connector Executor
Config
STATS #E
STATS #E
7.2.1.3 Logs
The Tomcat application container used by the Application Delivery Platform issues logs to
the /var/broadworks/logs/tomcat directory. This log contains the container internal logs
and possibly the exceptions it encounters while executing the various web applications.
The general settings for Tomcat allow configuring the log level.
Parameters description:
profileTuningName: This parameter specifies the name of the selected
profile tuning.
ADP_CLI/System/ProfileTuning/GeneralSettings>
======================================================================
set
<attribute>, Multiple Choice = {capacity}
<capacity>, Integer {1 to 2147483647}
ADP_CLI/System/CommunicationUtility/DefaultSettings/Executors/OCIC/Queue> set
capacity 25000
*** Warning: Broadworks needs to be restarted for the changes to take effect
***
ADP_CLI/System/CommunicationUtility/DefaultSettings/Executors/OCIC/Queue> get
capacity = 25000
ADP_CLI/System/CommunicationUtility/DefaultSettings/Executors/OCIC/Queue>
ADP_CLI/System/CommunicationUtility/DefaultSettings/Executors/OCIC/ThreadPool>
help set
This command is used to modify the thread pool settings.
Parameters description:
attribute : The name of an attribute to modify.
min : This parameter specifies the minimum number of threads to keep
in steady state. Lower thread counts are possible during
initialization.
max : This parameter specifies the maximum number of threads this
pool
can contain.
keepALiveTime: This parameter specifies the amount of idle time before an
excess thread is terminated.
======================================================================
set
<attribute>, Multiple Choice = {min, max, keepALiveTime}
<min>, Integer {1 to 10000}
<max>, Integer {1 to 10000}
<keepALiveTime>, Integer {1 to 3600}
ADP_CLI/System/CommunicationUtility/DefaultSettings/Executors/OCIC/ThreadPool> set
min 5 max 5 keepALiveTime 30
*** Warning: Broadworks needs to be restarted for the changes to take effect
***
ADP_CLI/System/CommunicationUtility/DefaultSettings/Executors/OCIC/ThreadPool> get
min = 5
max = 5
keepALiveTime = 30
ADP_CLI/System/CommunicationUtility/DefaultSettings/Executors/OCIC/ThreadPool>
8.4.5 Executors
Individual executors are available for OCI-C and OCI-P processing. Each Web App that
requires an executor gets a distinct instance. However, all instances are configured using
the same settings.
The recommended operating model for these executors is the fixed threading
configuration: minPoolSize=maxPoolSize, with queueCapacity > 1.
These executors are configurable from the
ADP_CLI/System/CommunicationUtility/DefaultSettings/Executors level.
When the NS location URL specifies HTTPS as the scheme, the Application Delivery
Platform initiates a secured HTTP connection (using Transport Layer Security
[TLS]/Secure Sockets Layer [SSL]) to the server. Otherwise, the Application Delivery
Platform initiates an unsecured HTTP connection.
SRV lookup for the nslocation service is performed when the port is omitted from the
configured locationServiceURL. When using this option, the locationServiceURL’s
hostname is taken as the domain name for an SRV lookup on the following service. The
result from the lookup considers the weight and cost associated with the service.
_nslocation._tcp.<domain>
If the port is omitted from the configured locationServiceURL but no SRV records are
found, the URL is used as-is with the default HTTP port (80) or HTTPS port (443), as
determined by the URL scheme to perform an A/AAAA lookup.
Alternatively, to immediately perform an A/AAAA lookup and, consequently, prevent a
Service Locator (SRV) lookup, the port needs to be specified explicitly in the URL.
The following example shows a URL that is resolved using SRV lookups.
When using this syntax, a lookup on the following SRV record occurs.
_nslocation._tcp.nsdomain.com SRV 1 10 1234 nsdomain1.broadsoft.com
_nslocation._tcp. nsdomain.com SRV 2 10 567 nsdomain2.broadsoft.com
These records result in the following URLs that reflect the weight and cost associated with
the service.
https://nsdomain1.broadsoft.com:1234
https://nsdomain2.broadsoft.com:567
If no SRV records are found, the following URL is used instead to perform an A/AAAA
lookup.
https://nsdomain.com:443
8.5.2 Logging
The log settings for the Tomcat Application container are configurable through the CLI
under the ADP_CLI/Applications/WebContainer/Tomcat/Logging level. It uses the
common Cisco BroadWorks logging mechanism for input and output channels.
The Tomcat input channel includes the following names:
Generic
NameService
TomcatCore
CtiConnector
GcLog
SMAP
ExternalAuthenticator
By default, the Tomcat application container used by the Application Delivery Platform
issues logs in the /var/broadworks/logs/tomcat directory. This log contains the container
internal logs and possibly the exceptions it encounters while executing the various web
applications.
The Tomcat output channel follows the typical Cisco BroadWorks output channel pattern.
Following is an example of setting the TomcatCore log level to “FieldDebug”.
ADP_CLI/Applications/WebContainer/Tomcat/Logging/InputChannels> h set
This command is used to modify input channels-related attributes.
Parameters description:
name : This parameter specifies the name of the logging input channel.
attribute: The name of an attribute to modify.
enabled : This parameter turns the logging to the logging input channel on
and
off.
severity : This parameter specifies the severity level of the logging input
channel.
======================================================================
set
<name>, Choice = {Generic, NameService, TomcatCore,
ExternalAuthenticator, CtiConnector, GcLog, SMAP}
ADP_CLI/Applications/WebContainer/Tomcat/Logging/InputChannels> set
TomcatCore enabled true severity FieldDebug
*** Warning: BroadWorks needs to be restarted for the changes to take
effect ***
ADP_CLI/Applications/WebContainer/Tomcat/Logging/InputChannels> get
Name Enabled Severity
============================================
Generic true
NameService true Info
TomcatCore true FieldDebug
ExternalAuthenticator true Info
CtiConnector true Info
GcLog true Info
SMAP false
7 entries found.
ADP_CLI/Applications/WebContainer/Tomcat/Logging/InputChannels>
8.5.3 Executors
Individual executors are available for each access point:
HTTPNIO: Blocking HTTP requests and NonBlocking HTTP requests used for
streaming.
CTI: CTI interface.
The recommended operating model for the CTI executors is the fixed threading
configuration described in section 8.3.2 Typical Configurations.
(minPoolSize=maxPoolSize, with queueCapacity > 1).
The recommended operating model for the HTTPNIO executors is the on-demand
threading configuration described in section 8.3.2 Typical Configurations.
(minPoolSize<maxPoolSize, with queueCapacity > 1).
These executors are configurable from the
ADP_CLI/Applications/WebContainer/Tomcat/Executors level.
Parameters description:
attribute : The name of an attribute to modify.
enabled : This parameter enables or disables data collection
for
JVM statistics
statisticsRefreshPeriod: This parameter specifies the frequency at which
BroadWorks fetches PMs from JVM Mbeans
======================================================================
set
<attribute>, Multiple Choice = {enabled, statisticsRefreshPeriod}
<enabled>, Choice = {false, true}
<statisticsRefreshPeriod>, Integer {1 to 86400}
ADP_CLI/Applications/WebContainer/Tomcat/JVMStatsCollector/GeneralSettings>
ADP_CLI/Applications/WebContainer/Tomcat/JVMStatsCollector/GeneralSettings>
set enabled true statisticsRefreshPeriod 10
*** Warning: Broadworks needs to be restarted for the changes to take effect
***
ADP_CLI/Applications/WebContainer/Tomcat/JVMStatsCollector/GeneralSettings>
get
enabled = true
statisticsRefreshPeriod = 10
ADP_CLI/Applications/WebContainer/Tomcat/JVMStatsCollector/GeneralSettings>
ADP_CLI/Applications/WebContainer/Tomcat/OverloadProtection/Webapps> help
add
This command is used to add the web application overload protection
entry.
Parameters description:
name : This parameter specifies the name of the web application.
period: This parameter specifies the duration expressed in seconds during
which
the total number of transactions is limited for the overall
server.
limit : This parameter specifies the maximum number of requests to be
allowed
during the specified period duration.
======================================================================
add
<name>, Choice = {<list of installed applications>}
<period>, Integer {1 to 300}
<limit>, Integer {1 to 65535}
ADP_CLI/Applications/WebContainer/Tomcat/OverloadProtection/Webapps> add
Xsi-Events 1 50
Parameters description:
name : This parameter specifies the name of the web application.
attribute: The name of an attribute to modify.
period : This parameter specifies the duration expressed in seconds during
which the total number of transactions is limited for the overall
server.
limit : This parameter specifies the maximum number of requests to be
allowed during the specified period duration.
======================================================================
set
<name>, Choice = {{<list of installed applications>}
ADP_CLI/Applications/WebContainer/Tomcat/OverloadProtection/Webapps>
ADP_CLI/Applications/WebContainer/Tomcat/OverloadProtection/Webapps> set Xsi-
Events period 1 limit 50
*** Warning: Broadworks needs to be restarted for the changes to take effect
***
ADP_CLI/Applications/WebContainer/Tomcat/OverloadProtection/Webapps> get
Name Period Limit
========================================
Xsi-Actions 1 100
Xsi-Events 1 50
Xsi-MMTel 1 100
3 entries found.
Parameters description:
name : This parameter specifies the name of the web application.
attribute : Name of the webapp.
sessionTimeout: This parameter specifies a web application specific duration
expressed in seconds after which an inactive session times
out.
======================================================================
add
<name>, Choice = {{<list of installed applications>}
Parameters description:
name : This parameter specifies the name of the web application.
attribute : The name of an attribute to modify.
sessionTimeout: This parameter specifies a web application specific duration
expressed in seconds after which an inactive session times
out.
======================================================================
set
<name>, Choice = {<list of installed applications>}
<attribute>, Multiple Choice = {sessionTimeout}
<sessionTimeout>, Integer {1 to 86400}
ADP_CLI/Applications/WebContainer/Tomcat/SessionManagement/Webapps> get
Name Session Timeout
==============================
Xsi-Actions 1200
1 entry found.
8.5.7 Thresholds
This section describes the list of configurable thresholds. For the list of SNMP traps
generated upon a threshold crossing, see section 8.6.4 Thresholds.
8.5.7.1 Executors
For each of the executor name (CTI and HTTPNIO), the Application Delivery Platform
provides the ability to set the following thresholds.
Executor Queue Usage Ratio
The executor queue usage ratio is defined as a percentage using the following formula:
EventQueueCount / queueCapacity * 100. By default, this threshold defines the arm level
to be 90 and the clear level to be 81. This threshold is enabled.
The Application Delivery Platform renders a CLI level for this threshold under the
ADP_CLI/Applications/WebContainer/Tomcat/Executors/<executorName>/Queue/SizeTh
reshold level.
The following is an example of setting the arm value to “88” and the reset value to “78” for
the HTTPNio executor.
ADP_CLI/Applications/WebContainer/Tomcat/Executors/HTTPNio/Queue/SizeThreshold>
help set
Parameters description:
attribute : The name of an attribute to modify.
enabled : This parameter determines whether a threshold is active.
armValue : This parameter specifies a value for enabling a threshold crossing.
resetValue: This parameter specifies a value for clearing a threshold crossing.
======================================================================
set
<attribute>, Multiple Choice = {enabled, armValue, resetValue}
<enabled>, Choice = {false, true}
<armValue>, Integer {0 to 100}
<resetValue>, Integer {0 to 100}
ADP_CLI/Applications/WebContainer/Tomcat/Executors/HTTPNio/Queue/SizeThreshold> set
armValue 88 resetValue 78
*** Warning: BroadWorks needs to be restarted for the changes to take effect ***
ADP_CLI/Applications/WebContainer/Tomcat/Executors/HTTPNio/Queue/SizeThreshold> get
enabled = true
armValue = 88
resetValue = 78
ADP_CLI/Applications/WebContainer/Tomcat/Executors/HTTPNio/Queue/SizeThreshold>
Parameters description:
attribute : The name of an attribute to modify.
enabled : This parameter determines whether a threshold is active.
armValue : This parameter specifies a value for enabling a threshold crossing.
resetValue: This parameter specifies a value for clearing a threshold crossing.
======================================================================
set
<attribute>, Multiple Choice = {enabled, armValue, resetValue}
<enabled>, Choice = {false, true}
<armValue>, Integer {0 to 100}
<resetValue>, Integer {0 to 100}
ADP_CLI/Applications/WebContainer/Tomcat/JVMStatsCollector/HeapUsageThreshold> set
armValue 88 resetValue 78
*** Warning: Broadworks needs to be restarted for the changes to take effect ***
ADP_CLI/Applications/WebContainer/Tomcat/JVMStatsCollector/HeapUsageThreshold> get
enabled = true
armValue = 88
resetValue = 78
ADP_CLI/Applications/WebContainer/Tomcat/JVMStatsCollector/HeapUsageThreshold>
Tomcat Core
occurs here
Comet
Events
request
queue
Waiting
Time
HTTP
OCIP
Request
Other BW
Servers
Connector
processing
Time
Task
Processing OCIP
Time application
processing Responses Response
time i/o
queue
Waiting
Responses Time
i/o Task
Processing
Time
response
Comet
Events
request
queue
Waiting
Time
HTTP
Task
Processing OCIC
Time Request
Other BW
queue
Servers
Task Waiting OCIC
Connector Processing Time Responses
processing Time
Time Responses
i/o
application
processing
time
end
response
Tomcat Core
occurs here
Comet
Events
Proprierary,
XML-based request
queue
Waiting
Time
Task
Processing OCIC
Time Request
Other BW
queue
Servers
response end
(1) bwConnectorIndex
(2) bwConnectorName
(3) bwConnectorExecutorName
(4) bwConnectorRequestCount
(5) bwConnectorBytesRx
(6) bwConnectorBytesTx
(7) bwConnectorTotalProcessingTime
(8) bwConnectorMaxProcessingTime
ADP_CLI/Monitoring/PM/WebContainer>
8.6.2.2 Executors
The Queue Waiting Time and Task Processing Time are part of the executor metrics.
The Queue Waiting Time statistic reports the time spent waiting in the executor queue. A
delay occurs when the executor threads are all busy processing other events. This metric
is reported in a MIB table identified by the executor type. The BW-WebContainer MIB
reports this statistic with the following OID:
bwWebContainer.executors.executorTable.bwExecutorQueueWaitingTime
The Task Processing time statistic reports the processing time spent in the executor
thread. This metric is reported in a MIB table identified by the executor type. The system
does not report an instant value. Instead, it tracks the minimum, average, and maximum
values. The BW-WebContainer MIB reports this statistic with the following OIDs:
bwWebContainer.executors.executorTable.bwExecutorTaskProcessingTimeMin
bwWebContainer.executors.executorTable.bwExecutorTaskProcessingTimeAvg
bwWebContainer.executors.executorTable.bwExecutorTaskProcessingTimeMax
(1) bwExecutorIndex
(2) bwExecutorName
(3) bwExecutorQueueCapacity
(4) bwExecutorQueueSize
(5) bwExecutorQueueWaitingTimeAvg
(6) bwExecutorQueueWaitingTimeMin
(7) bwExecutorQueueWaitingTimeMax
(8) bwExecutorQueueWaitingTimeMaxTimestampMSB
(9) bwExecutorQueueWaitingTimeMaxTimestampLSB
(10) bwExecutorMinPoolSize
(11) bwExecutorMaxPoolSize
(12) bwExecutorThreadsBusy
(13) bwExecutorCompletedTaskCount
(14) bwExecutorThreadsAlive
(15) bwExecutorThreadsAliveMax
(16) bwExecutorTaskProcessingTimeAvg
(17) bwExecutorTaskProcessingTimeMin
(18) bwExecutorTaskProcessingTimeMax
(19) bwExecutorTaskProcessingTimeMaxTimestampMSB
(20) bwExecutorTaskProcessingTimeMaxTimestampLSB
(21) bwExecutorQueueWaitingTimeMaxTimestamp
(22) bwExecutorTaskProcessingTimeMaxTimestamp
(23) bwExecutorQueueWaitingTimeResetTS
(24) bwExecutorQueueWaitingTimeAvgCurrInt
(25) bwExecutorQueueWaitingTimeAvgLastInt
(26) bwExecutorQueueWaitingTimeMinCurrInt
(27) bwExecutorQueueWaitingTimeMinLastInt
(28) bwExecutorQueueWaitingTimeMinCurrIntTS
(29) bwExecutorQueueWaitingTimeMinLastIntTS
(30) bwExecutorQueueWaitingTimeMaxCurrInt
(31) bwExecutorQueueWaitingTimeMaxLastInt
(32) bwExecutorQueueWaitingTimeMaxCurrIntTS
(33) bwExecutorQueueWaitingTimeMaxLastIntTS
(34) bwExecutorTaskProcessingTimeResetTS
(35) bwExecutorTaskProcessingTimeAvgCurrInt
(36) bwExecutorTaskProcessingTimeAvgLastInt
(37) bwExecutorTaskProcessingTimeMinCurrInt
(38) bwExecutorTaskProcessingTimeMinLastInt
(39) bwExecutorTaskProcessingTimeMinCurrIntTS
(40) bwExecutorTaskProcessingTimeMinLastIntTS
(41) bwExecutorTaskProcessingTimeMaxCurrInt
(42) bwExecutorTaskProcessingTimeMaxLastInt
(43) bwExecutorTaskProcessingTimeMaxCurrIntTS
(44) bwExecutorTaskProcessingTimeMaxLastIntTS
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10)
(11) (12) (13) (14) (15) (16) (17) (18) (19) (20)
(21) (22) (23) (24) (25)
(26) (27) (28) (29) (30)
(31) (32) (33)
(34) (35) (36) (37) (38) (39)
(40) (41) (42) (43) (44)
1 httpnio 20000 0 0 0 0 370 2681315361 166
1666 0 0 0 0 0 0 0 370 2681315361 Wed Jun
10 16:00:14 EDT 2020 Wed Jun 10 16:00:14 EDT 2020 Thu Jun 11 08:00:00 EDT 2020
0 0 0 0 Thu Jun 11 08:00:00 EDT 2020 Thu Jun 11 07:55:00 EDT 2020
0 0 Thu Jun 11 08:00:00 EDT 2020 Thu Jun 11 07:55:00 EDT 2020 Thu Jun 11
08:00:00 EDT 2020 0 0 0 0 Thu Jun 11 08:00:00 EDT 2020 Thu
Jun 11 07:55:00 EDT 2020 0 0 Thu Jun 11 08:00:00 EDT 2020 Thu Jun 11
07:55:00 EDT 2020
(1) bwApplicationResourceIndex
(2) bwApplicationResourceWebAppName
(3) bwApplicationResourceRequestCount
(4) bwApplicationResourceTotalProcessingTime
ADP_CLI/Monitoring/PM/WebContainer> >
8.6.3.1 Memory
The OIDs for heap and nonheap memories are available from the following CLI levels.
ADP_CLI/Monitoring/PM/WebContainer> cd processMetrics/memory/heap;get
bwWebContainer/processMetrics/memory/heap/
------------------------------------------------------------------------------
bwWebContainer/processMetrics/memory/heap/
------------------------------------------------------------------------------
bwProcessMetricsHeapInitSize 226492416
bwProcessMetricsHeapMaxSize 226492416
bwProcessMetricsHeapUsed 60406032
bwProcessMetricsHeapUsedMax 92134800
bwProcessMetricsHeapCommitted 226492416
bwProcessMetricsHeapLastPostCollectionSize 60496664
ADP_CLI/Monitoring/PM/WebContainer>
ADP_CLI/Monitoring/PM/WebContainer> cd memory/nonheap;get
bwWebContainer/processMetrics/memory/nonheap/
------------------------------------------------------------------------------
bwWebContainer/processMetrics/memory/nonheap/
------------------------------------------------------------------------------
ADP_CLI/Monitoring/PM/WebContainer>
8.6.3.2 Thread
The OIDs for threads are available from the following CLI level.
ADP_CLI/Monitoring/PM/WebContainer> cd processMetrics/threads;get
bwWebContainer/processMetrics/threads/
------------------------------------------------------------------------------
bwWebContainer/processMetrics/threads/
------------------------------------------------------------------------------
bwProcessMetricsThreadsAlive 33
bwProcessMetricsThreadsAliveMax 34
bwProcessMetricsThreadsStarted 37911
ADP_CLI/Monitoring/PM/WebContainer>
8.6.4 Thresholds
This section describes the list of SNMP traps generated upon a threshold crossing. For
the list of thresholds whose default values are configurable, see section 8.5.7 Thresholds.
8.6.4.1 Executors
For each of the executor name (CTI, and HTTPNIO), the Application Delivery Platform
provides the ability to generate the following traps:
Executor Queue Usage Ratio
The executor queue usage ratio is defined as a percentage using the following formula:
EventQueueCount / queueCapacity * 100. Upon threshold crossing, the system
generates the following trap:
Trap bwExecutorQueueUsageExceeded (of severity high): The usage ratio of the
executor queue exceeded the threshold level.
Executor Queue Latency
The executor queue latency is defined as an absolute value and represents the number of
requests that are currently queued while waiting for other tasks to complete during
execution. Upon threshold crossing, the system generates the following trap:
Trap bwExecutorQueueLatencyExceeded (of severity high): The executor queue
latency exceeded the threshold level.
Executor Thread Pool Processing Time
The executor thread pool processing time is defined as an absolute value and represents
the execution time taken by a task to complete. Upon threshold crossing, the system
generates the following trap:
Trap bwExecutorThreadPoolProcessingTimeExceeded (of severity high): The
executor thread pool processing time exceeded the threshold level.
8.7.1 Installation
The first step in the application life cycle is the installation. For the installation of
applications that are not pre-packaged with the Application Delivery Platform, the
application file (.war or .bwar) must be copied to a local temporary directory on the server,
for example, /tmp. Using the CLI, in the Maintenance/ManagedObjects level, invoke the
install command, providing the full path name of the application file. Note that the name of
the file is irrelevant to the Application Delivery Platform. All the descriptive and operational
data used by the Application Delivery Platform are inside the file. By default,
pre-packaged applications are located in the /usr/local/broadworks/apps directory.
An application is made unique by its name and its version, both of which are defined in the
internal deployment descriptor (in the .war/.bwar). For web application, the deployment
descriptor is the web.xml file. On the other hand, the Cisco BroadWorks application
deployment descriptor is in the broadworks.xml file. The Application Delivery Platform
enforces uniqueness of applications and does not allow installation of two applications with
the same name/version.
Following is an example of an installation of an application.
ADP_CLI/Maintenance/ManagedObjects> install application /tmp/Example-
_1.0.war
Broadworks SW Manager installing Example_1.0.war...
- Performing basic validation
. Valid application structure
. Name : Example
. Description: This is an example Web Application
. Version : 1.0
...Done
ADP_CLI/Maintenance/ManagedObjects>
During the installation process, the application file is validated and, if valid, it is internally
copied and installed. Once the application is installed, the file used to install the
application is no longer required and can be deleted.
After being installed, the application can either be activated to make it configurable or it
can be uninstalled.
NOTE: Applications with an automatic upgrade mode are installed by default when the
Application Delivery Platform is installed. Such applications cannot be uninstalled.
ADP_CLI/Maintenance/ManagedObjects>
When activating an application, the name and version are mandatory. The contextPath
parameter is only required when activating a web application. It must not be specified
when activating a Cisco BroadWorks application.
Multiple instances of the same web application can be activated using different context
paths. However, a single activation of a Cisco BroadWorks application is allowed.
Once activated, applications can be configured. Configuration is done through the CLI
from the application specific context. This context can be found under the application level
as illustrated in the following example.
ADP_CLI/Applications> ?
0) OpenClientServer: go to level OpenClientServer
1) Example : go to level Example_1.0
ADP_CLI/Applications> 1
ADP_CLI/Applications/Example> ?
Configure the Example_1.0 web application.
Commands:
0) get : show webapp-related attributes
1) set : modify webapp-related attributes
2) clear : clear webapp-related attributes
ADP_CLI/Applications/Example>
8.7.3 Deployment
Applications activated on the Application Delivery Platform can be selectively deployed
using the CLI deploy command. Following are examples of application deployments.
ADP_CLI/Maintenance/ManagedObjects> deploy ?
<type>, Choice = {application}
application:
<nameOrContextPath>, String {1 to 255 characters}
ADP_CLI/Maintenance/ManagedObjects>
As shown in the previous example, deploying a web application and a Cisco BroadWorks
application require different parameters. A web application is deployed using the context
path specified during the activation command. On the other hand, deploying a Cisco
BroadWorks application is done using the application name.
The following subsections present the deployment differences between web and Cisco
BroadWorks application.
ADP_CLI/Maintenance/ManagedObjects>
bwadmin@mtl64lin12 $ showrun
Active alarms
--------------------------------
Recommendations
---------------
ADP_CLI/Maintenance/ManagedObjects>
In cases where the amount of physical memory is changed on the server, the application’s
memory configuration is automatically recalculated by the Software Manager at boot time.
8.7.3.2.2 State Management
Each Cisco BroadWorks application implements its own state. The application state is
presented as an administrative state and an effective state. Both states can be viewed
from the CLI Maintenance/ManagedObjects level using the command get broadworks full.
Only the administrative state can be controlled by an operator; the effective state simply
reflects the actual state of the application. The administrative state is controlled through
the CLI Maintenance/ManagedObjects level using the lock and unlock commands. As the
commands suggests, the possible administrative states are:
Locked
Unlocked
When an application administrative state is set to one of these states, it means that the
application tries to transition to that state (assuming the application is running).
On the other hand, the effective state reflects the actual state of the application and can
have the following values.
Locked: The application is locked. Depending on the application’s implementation, it
may mean that it provides limited to no functionality at all.
Locking: The application is in the process of being locked. This is a transitional state.
Unlocked: The application is unlocked; all its functionality is available.
Unlocking: The application is in the process of being unlocked. This is a transitional
state.
Stopping: The application is in the process of being stopped. This is a transitional
state.
Stopped: The application is stopped; none of its functionality is available.
InTrouble: The application is not functional; one or more (but not all) of its containers
are dead. The application must be restarted. The application also enters this state
when one or more (but not all) of its containers is restarted by the process monitor.
* Server:
Identity..............: ADP
Version...............: Rel_2020.07_1.030
Administrative State..: Unlocked
* Applications:
Name Version Deployed Administrative State
Effective State
=========================================================================
=========
OpenClientServer 2020.07_1.030 true Unlocked
Unlocking
WebContainer 2020.07_1.030 true Unlocked
Unlocked
2 entries found.
* Hosted Applications:
Name Version Context Path Deployed Administrative State Effective
State
=========================================================================
=====
0 entry found.
ADP_CLI/Maintenance/ManagedObjects>
* Server:
Identity..............: ADP
Version...............: Rel_2020.07_1.030
Administrative State..: Unlocked
* Applications:
Name Version Deployed Administrative State
Effective State
=========================================================================
=========
OpenClientServer 2020.07_1.030 true Unlocked
Unlocking
WebContainer 2020.07_1.030 true Unlocked
Unlocked
2 entries found.
* Hosted Applications:
Name Version Context Path Deployed Administrative State Effective
State
=========================================================================
=====
0 entry found.
ADP_CLI/Maintenance/ManagedObjects>
* Server:
Identity..............: ADP
Version...............: Rel_2020.07_1.030
Administrative State..: Unlocked
* Applications:
Name Version Deployed Administrative State
Effective State
=========================================================================
=========
OpenClientServer 2020.07_1.030 false Unlocked
Stopped
WebContainer 2020.07_1.030 true Unlocked
Unlocked
2 entries found.
* Hosted Applications:
Name Version Context Path Deployed Administrative State Effective
State
=========================================================================
=====
0 entry found.
ADP_CLI/Maintenance/ManagedObjects>
NOTE: Undeploying the Cisco BroadWorks WebContainer application affects all web
applications. The web applications are no longer running.
8.7.5 Deactivation
Undeploy applications can be deactivated using the deactivate CLI command.
Deactivated applications can no longer be configured. As such, their associated CLI level
under the application context is removed. For web applications, the context path is
released and can be reused. Following are some examples of application deactivation.
Note that deactivating a Cisco BroadWorks application is done using the application
name, whereas deactivating a web application is done using the context path.
ADP_CLI/Maintenance/ManagedObjects> deactivate application
OpenClientServer
BroadWorks SW Manager deactivating...OpenClientServer version
2020.07_1.030
...Done
ADP_CLI/Maintenance/ManagedObjects>
8.7.6 Uninstallation
Installed applications that are no longer required can be uninstalled. This removes all files
related to this application from the Application Delivery Platform. Only applications in
Active state can be uninstalled. Furthermore, only applications having their upgrade mode
set to “Manual” can be uninstalled. Those with an Automatic upgrade mode cannot be
uninstalled as they are part of the Application Delivery Platform and they are upgraded
with the platform. An application is uninstalled using the uninstall command from the CLI,
Maintenance/ManagedObjects level. The uninstall command required an application and
a version. Following is an example of an uninstallation of a web application.
ADP_CLI/Maintenance/ManagedObjects> uninstall application Example 1.0
BroadWorks SW Manager un-installing Example version 1.0...
...Done
8.7.7 Upgrade
Applications that are using the Manual upgrade mode must be manually upgraded
through the CLI. Applications with an Automatic upgrade mode are automatically
upgraded when the Application Delivery Platform is upgraded. The upgrade procedure is
different whether the application is a Cisco BroadWorks application or a web application.
Once the application is installed, the upgrade process can be performed. First, the
application must be locked for the upgrade to proceed.
ADP_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion application
LoadBalancer 2020.09_1.090
Stopping [done]
As part of this process, the application is both locked and stopped. To make sure the
operator is aware that this will cause a downtime, a question is prompted before
performing the upgrade.
In some cases, the new application version requires a newer version of the Application
Delivery Platform. In this case, the Application Delivery Platform must be upgraded before
the application can be installed.
8.7.8 Revert
If, for some reason, the Cisco BroadWorks application must be reverted to a previous
version, the process is similar to an upgrade.
ADP_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion application
LoadBalancer 2020.04_1.030 revert
+++ WARNING +++ WARNING +++ WARNING +++
Upgrading an application will cause downtime for the targeted component.
Continue?
Stopping [done]
Again, the application is locked and stopped before the revert operation is executed.
One important thing to note is that some changes may be lost after the revert operation is
executed (for example, configuration changes) because the resulting active application is
in the state it was before the upgrade.
Installation of an application older than the one that is active is supported. However,
reverting to such an application will result in losing all the configuration made to the active
version.
Note that the revert operation is not supported for web applications.
In the example, web.broadsoft.com represents the FQDN used by all HTTP servers
(namely, ADP1 and ADP2), and ADP1.broadsoft.com represents the local name of the
server. Naming can be important for single SSL certificate generation.
The HTTP servers generate self-signed certificates by default and use the default
SSL/TLS protocol and cipher provided by Java. These defaults may be configured on a
per end-point basis using the following CLI levels.
ADP_CLI/Interface/Http/HttpServer/SSLSettings> h
This level is used to configure the Secure Sockets Layer (SSL)/Transport
Layer Security (TLS) parameters.
Commands:
0) Certificates : go to level Certificates
1) Ciphers : go to level Ciphers
2) Protocols : go to level Protocols
ADP_CLI/Interface/Http/HttpServer/SSLSettings>
The protocols and ciphers may also be configured at less specific contexts at the interface
and server level. These less specific contexts are referred to as SSLCommonSettings.
For more information, see the Cisco BroadWorks SSL Support Options Guide [3].
On ADP2:
ADP_CLI/Interface/Http/HttpServer> get
Interface Port Name Secure Client Auth Req Cluster FQDN
===============================================================================
192.168.8.9 443 ADP2.broadsoft.com true false ADP.broadsoft.com
192.168.8.9 80 ADP2.broadsoft.com false false ADP.broadsoft.com
Because the names of the HTTP servers follow a proper pattern for the server name, a
single certificate with a common name using wildcard characters, such as
ADP*.broadsoft.com or *.broadsoft.com, can be issued. One could decide to have two
distinct certificates here, for example, ADP1.broadsoft.com and ADP2.broadsoft.com,
although this would not be practical in an environment where both Application Delivery
Platforms serve the same software clients in a farm.
Note that software clients accessing the HTTP server using a different alias name, allowed
as defined under the ADP_CLI/Interface/Http/HttpAlias level, are still handled properly by
the same single certificate name. For more information, see section 8.8.6 HTTP Aliases.
On ADP2:
ADP_CLI/Interface/Http/HttpServer> get
Interface Port Name Secure Client Auth Req Cluster FQDN
==============================================================================
192.168.8.9 443 web2.bsft.com true false web.bsft.com
192.168.8.9 80 web2.bsft.com false false web.bsft.com
By creating a single certificate that includes the subjectAlternativeName extension with the
value “ADP1.broadsoft.com web2.bsft.com”, a single certificate may be shared between
the 2 servers.
It is important to understand that the presence of the subjectAlternativeName in a
certificate is mutually exclusive with the certificate common name. That is, when the
subjectAlternativeName is present, the SSL handshake does not use the common name.
As a result, the common name should be added to the subjectAlternativeName extension
when required.
Note that software clients accessing the HTTP server using a different alias name, allowed
as defined under the ADP_CLI/Interface/Http/HttpAlias level, are still handled properly by
the same single multi-domain (SAN) certificate name.
If the need for an additional server arises (for example, web3.bsft.com), a SAN certificate
must be signed again with the updated field subjectAlternativeName
(“ADP1.broadsoft.com web2.bsft.com web3.bsft.com”).
ADP_CLI/Interface/Http/HttpAlias> get
The URL companyB.com would appear in the HTTP header of a browser because it is
defined here as an alias. However, the certificate can only be issued against
companyA.com with the interface address 192.168.8.8 and port 443. A user accessing
the server with companyB.com and fetching information about the SSL certificate would
realize it was issued against companyA.com, which is undesirable. An alternative is to
define additional HTTP servers with the internet address 192.168.8.8 but with different
ports (for example, 442 and 444), and with some kind of a dummy and generic name
applicable to both companies. Although this is not necessarily desirable either.
If additional network cards are added to the platform, additional HTTP servers can be
defined, which can then have their own certificates, as illustrated by the following example.
ADP_CLI/Interface/Http/HttpServer> get
Interface Port Name Secure Client Auth Req Cluster FQDN
=========================================================================
192.168.8.8 443 companyA.com true false
192.168.8.8 80 companyA.com false false
192.168.8.9 443 companyB.com true false
192.168.8.9 80 companyB.com false false
When the need for an increasing number of distinct SSL certificates arises, it might not be
feasible to add as many network cards as required. Virtual IPs can be defined for such a
purpose.
On Linux, each physical interface is represented by a file corresponding to
/etc/sysconfig/network-scripts/ifcfg-eth<x> where <x> represents the unique interface
number for that card (for example, the first interface card is represented by ifcfg-eth0).
To create a virtual interface for that physical interface, a file, in the format of ifcfg-
eth0:<y> where <y>represents the alias number, must be created.
For example:
ifcfg-eth0
# Intel Corporation 82540EM Gigabit Ethernet Controller
DEVICE=eth0
IPADDR=192.168.8.8
NETMASK=255.255.255.0
ifcfg-eth0:0
# Intel Corporation 82540EM Gigabit Ethernet Controller
DEVICE=eth0:0
IPADDR=192.168.8.10
NETMASK=255.255.255.0
BOOTPROTO=none
ONPARENT=yes
BROADCAST=192.168.8.255
Note that the addition of Application Delivery Platform interface addresses must be
properly propagated through the entire network (DNS or /etc/hosts, Network Servers
configuration, and so on). All settings required on the network and in the Cisco
BroadWorks configuration for the primary IP address of the Application Delivery Platform
are also required for the added IP addresses.
The virtual interfaces act just as physical interfaces as far as certificates are concerned.
Requiring client authentication means that the server must validate the certificate received
from the client during the SSL handshake. The server uses a trust store that contains trust
anchors to validate these certificates. Therefore, this CLI level provides a sublevel named
trusts that defines a set of dedicated commands for handling trust anchors. This sublevel
is located as follows for the HttpServer level.
PS_CLI/Interface/Http/SSLCommonSettings/ClientAuthentication/Trusts>
These interactions allow the generation of a trust anchor that can be directly distributed to
the client software 2 or can be used as an issuer for generating client certificates.
Depending on the network requirement, a Cisco BroadWorks customer can require
multiple trust anchors. For example, certain device vendors demand the use of their own
certificates. The CLI commands require an administrator to specify an alias name to allow
for identifying the trust anchors individually.
8.9 Peering
The Application Delivery Platform supports being deployed in a cluster. Redundancy in
this case is used for file and configuration replication across the cluster members.
ADP_CLI/System/ConfigAgent/GeneralSettings> cd ../Replication/
ADP_CLI/System/ConfigAgent/Replication> start
ADP_CLI/System/ConfigAgent/GeneralSettings> cd ../Replication/
ADP_CLI/System/ConfigAgent/Replication> start
...Replication started
The list of replicated CLI levels depends on the applications deployed on the Application
Delivery Platform. The following applications support configuration replication:
BroadworksFileRepos
BroadworksFileReposExtdCapture
ECLReportingRepository
MessageArchive
==============================================
==== SSH CONFIGURATION TOOL version 2.2.22 ====
=> Setting default settings <=
Setting 'StrictHostKeyChecking no'
Setting 'ServerAliveInterval 250'
=> DNS Sanity test <=
[###############]
[...............]
Configured: y, Reachable: y, Resolved: n, Required: n.
Using [email protected] as local peer name for
adp1.mtl.broadsoft.com.
=> DNS not OK, continuing... <=
=> Peer reachability test <=
[######]
[......]
=> Creating SSH keys <=
Creating keys for [email protected]...
10.1 Logs
Most Application Delivery Platform components issue logs. The following subsections
provide information on where logging information can be found on the Application Delivery
Platform.
10.2.1.1 User Login without Domain Name when Network Server Mode is Used
In “NS” mode, the BWCommunicationUtility performs LocationAPI lookups on the Network
Server to resolve the Application Server cluster that owns it. The full user name must be
user: user@domain because the Application Delivery Platform is not aware of the default
domain of the Application Server cluster.
The following log can usually be observed.
BwCommunicationMgr: Executing NS user lookup
BwCommunicationMgr: Servers={null,null}
BwCommunicationMgr: No usable OCI-P authenticator for <user>
10.2.2.1 Application Server Does Not Support OCI-C (For Release 14.sp5 or Later)
The following log can usually be observed.
Failed to register OCI-C protocol
The Application Delivery Platform allows installation and deployment of standard web
applications packaged as web application archive (war) files. This section defines the
expected structure of such web applications and provides guidelines for their
implementation.
These guidelines take into account the fact that some of the web applications produced by
Cisco BroadWorks can be deployed on third-party platforms.
This section is not a tutorial on how to build web applications. Rather, it focuses on the
compliancy with the Application Delivery Platform.
NOTE: This naming convention has no functional bearing on the web application and is
intended only as a convenience for users.
The Application Delivery Platform does not rely on any elements from the naming pattern
for management of the web application. It extracts name and version information from the
embedded web.xml, as described in the following subsections. The Application Delivery
Platform, therefore, does not expect or enforce this naming convention.
Note that manually changing the .war file name can be required on third-party platforms to
accommodate deployment and establishment of the context path for the application
(notably for Tomcat in some configurations). This is to be expected.
3 The standard for building the web application can be obtained from
http://tomcat.apache.org/tomcat-6.0-doc/appdev/deployment.html.
<env-entry>
<env-entry-name>webAppConigFile</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>bwXsiActionsConfig.properties</env-entry-value>
</env-entry>
…
</web-app>
[1] Cisco Systems, Inc. 2020. Cisco BroadWorks Software Management Guide.
Available from Cisco at cisco.com.
[2] Cisco Systems, Inc. 2020. Cisco BroadWorks Application Delivery Platform Fault
and Alarm Interface Specification. Available from Cisco at cisco.com.
[3] Cisco Systems, Inc. 2020. Cisco BroadWorks SSL Support Options Guide.
Available from Cisco at cisco.com.
[4] Cisco Systems, Inc. 2016. Load Balancing Feature Description, Release 22.0.
Available from Cisco at cisco.com.
[5] Cisco Systems, Inc. 2020. Cisco BroadWorks Configuration System Interface
Specification. Available from Cisco at cisco.com.