| Oracle® Communications Service Broker Service Controller Implementation Guide Release 6.1 Part Number E29460-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Service Broker Service Controller Implementation Guide Release 6.1 Part Number E29460-01 |
|
|
PDF · Mobi · ePub |
This chapter explains how to protect Oracle Communications Service Broker from overload. For more information, see the Oracle Communications Service Broker System Administrator's Guide.
In some cases, such as unanticipated traffic peaks or failure of a network hardware or software component, the load on Service Broker modules can increase significantly. This can cause a situation known as system overload in which Service Broker modules have insufficient resources to handle new sessions. If overload is not handled correctly, the system can crash and critical data can be lost.
To handle increased amounts of traffic without damaging operations of the entire system, Service Broker provides an overload protection mechanism. This mechanism operates in Processing Domains where you can define criteria for overload detection.
By default, an overload condition is triggered by an excessive number of 1) active sessions or 2) initial requests. The system rejects initial requests while the overload lasts. In addition to rejecting initial requests, Service Broker provides the capability to customize how the system behaves if overload occurs.
When you configure gauges and counters as key overload indicators, Service Broker triggers overload protection if threshold values are crossed as measured by those indicators. You can select any of the counters and gauges provided by Service Broker to serve as key overload indicators.
Note:
Consult with Oracle Technical Support if you have questions about which runtime MBeans are best suited to implement overload protection in your network environment.When you configure overload protection, your settings are applied uniformly across all managed servers in the domain. Usually, server load balancing allocates traffic "fairly" across servers. However, it is possible for a single managed server in a domain to enter an overload condition while the other servers are functioning normally.
Service Broker overload protection can be configured at the system and module levels:
System counters and gauges: These two indicators can detect and trigger an overload condition that might occur across any number of clustered managed servers:
SystemCountersRuntimeMBean.SessionGauge
SystemCountersRuntimeMBean.InitialRequestCount
The SessionGauge gauge represents the total number of active sessions on a single managed server (JVM).
The InitialRequestCount counter represents the session creation rate. For example, the number of new sessions created per second on a single managed server.
You configure the SessionGauge and InitialRequestCount indicators for the managed servers in the Administration Console. All managed servers share those configuration settings.
There is no global overload protection status. However, if any managed server goes into an overload state, as defined by the shared configuration, the system stops accepting new sessions until the overload condition ceases.
Module-level counters and gauges: These indicators are for specific modules. Using the Administration Console, you can configure these indicators for overload protection under the monitoring tabs. Expand Platform, then OCSB, then Processing Tier, and then Interworking and Supplementary Modules.
These steps must be followed to configure overload protection.
By default, the following gauge and counter are defined as your key overload indicators:
SystemCountersRuntimeMBean.SessionGauge: A gauge that measures the number of active sessions handled by a single managed server. The number of active sessions includes Service Controller sessions, and if installed, sessions from other installed products: Online Mediation Controller, and Policy Controller.
SystemCountersRuntimeMBean.InitialRequestCount: A counter that measures the rate at which a managed server receives new sessions.
The SessionGauge and InitialRequestCount measurements are per managed server but all of the managed servers share a common configuration. If any managed server goes into an overload condition, the system stops accepting new sessions until the overload condition ceases.
Identify module-level counters and gauges you want to use as key overload indicators.
Configure Threshold Crossed Notifications details for your module-level counters and gauges.
For each counter and gauge you want to use as a key overload indicator, define an upper threshold and ceased value threshold. For example, if the upper threshold value is 100 and the ceased value is 90 then if 100 is crossed the system remains overloaded until the value goes below 90.
Specify a threshold name for each module-level counter or gauge. If you use either sessionGauge or initialRequestCount as the threshold name value you do not have to add these indicators to the Key Overload Indicators pane.
See the System Administrator's Guide for more information about configuring runtime MBeans thresholds.
Configure Key Overload Indicators.
After you have configured the module-level counters and gauges you want to use for overload protection you need to specify that they are to be used by Service Broker as Key Overload Indicators.
You do this by using the Administration Console. Expand Tier Management, then use the Key Overload pane to configure your key overload indicators.
Important: Service Broker activates overload protection when any of your key overload indicator crosses its upper threshold.
Customize overload protection behavior.
The behavior of Service Broker is that if an overload condition occurs, the system continues to handle all active sessions but rejects initial requests until the overload condition ceases.
In addition to the default protection behavior, you can customize how Service Broker responds to SIP and Diameter network entities that attempt to establish sessions during a system overload.
Example: You can define the type of error and value of the SIP Retry-After header field that Service Broker uses to respond to newly established SIP sessions.
You can customize overload protection behavior by using the Administration Console. Expand Tier Management, then Overload and Tracing, and then the Overload Protection Methods pane.
The following sections describe in detail how to configure Key Overload Indicators.
This section describes how to create Threshold Crossed Notifications rules for overload protection. The components of these rules specify MBean type, threshold name, crossed and ceased threshold values, and other fields.The following steps are applicable to both system-wide and module-level counters and gauges. There are only two system-wide overload indicators: sessionGauge and InitialRequestCount. The default settings for these indicators should usually not be changed.
To transform the counter or gauge you configure in this section to be a key overload indicator you must match the threshold name value you set under the Monitoring tab with the threshold name value in the Key Overload indicators pane.
For example, the default key overload indicator threshold name sessionGauge matches the threshold name value in the default threshold crossed notifications rule also sessionGauge.
To configure Threshold Crossed Notification Rules do the following:
In the navigation tree, expand the OCSB node.
Expand Processing Tier.
Do either of the following:
To configure System-level Counters and Gauges: Expand Tier Management, then Monitoring, and then Monitoring. Note: You cannot add more counters and gauges in addition to the default sessionGauge and InitialRequestCount indicators. However, if required you can modify details such as crossed and ceased threshold values.
To configure Module-level Counters and Gauges: Expand Interworking or Supplementary Modules, then Expand the module for which you want to configure a counter or gauge as an overload indicator.
In the Monitoring tab, select Threshold Crossed Notifications.
Be sure you have selected Lock & Edit and then click New.
In the Threshold Name field, enter a string that names the threshold. This value is referenced by the key overload indicators.
For the Enable threshold field, select True or False. Only enabled thresholds are considered for overload protection.
In the MBean Type field, enter the type of MBean.
For the Counting Type field, select the Counting method. For gauges use CurrentGeneralValue and for counters use CurrentIntervalDeltaValue.
In the MBean Attribute field, enter an MBean attribute. For SystemGaugeRuntime use SessionGauge and for SystemCountRuntime use InitialRequestCount.
In the Threshold class field, enter High. Crossing a low threshold does not cause an overload state.
In the Threshold Value field, enter an integer value which when crossed triggers an overload state.
In the Threshold ceased value field, enter an integer value which when crossed the triggered threshold ceases. This value is applicable only to gauges.
In the Threshold crossed message field, enter a message included in the threshold notification.
In the Threshold ceased message field, enter a message included in the threshold ceased notification.
In the Server filter field, leave it empty or use a regular expression to filter on a managed server. For example "managed_1" or "server."
In the Resource filter field, enter a unique name for the indicator.
Click Apply.
Identify the module-level counters and gauges you want to use for overload protection. Use the Administration Console to list the names and threshold names for these indicators.
The Overload Protection pane is pre-populated with these two system-wide indicators:
SystemCountersRuntimeMBean.SessionGauge
SystemCountersRuntimeMBean.InitialRequestCount
To specify module-level Key Overload Indicators do the following:
In the navigation tree, expand the OCSB node.
Expand Processing Tier.
Expand Tier Management.
Select Overload Protection. The Key Overload Indicators pane appears.
Be sure you have selected Lock & Edit and then click New.
In the Name field, enter a unique name for the indicator.
In the Threshold Name field, enter a unique string that references the threshold.
Multiple indicators at the system or module-level can use the same Threshold Name. In this situation, all matching crossed thresholds will be considered to indicate an overload state.
Example: If any module-level counter or gauge use either sessionGauge or initialRequestCount as the threshold name value, you do not have to add these module-level indicators to the Key Overload Indicators pane. However, the module-level settings (e.g. crossed threshold value) will override the platform-level settings for that individual module only.
Click Apply.
This section describes how to configure general attributes for overload protection notifications.
These attributes can be configured both at the system and module levels. Expand Tier Management, then Monitoring, and then the General tab. To configure IMs, expand Interworking Modules, then the IM you want to configure, then Monitoring, and then the General tab.
Table 9-1 describes the configuration parameters on the Monitoring General tab. At the Tier level these parameters affect only SessionGauge and InitialRequestCount. At the module level the parameters affect all runtime MBeans in the module.
Table 9-1 General Overload Configuration Parameters
| Name | Description |
|---|---|
|
Enable runtime MBeans |
Disables the runtime MBeans so you can neither poll them for values or get notifications. |
|
Enable Notifications |
Disables only notifications, so you can still poll values from the MBean. |
|
Counter Interval (sec) |
This parameter specifies the length of the interval in seconds. Note: This parameter is not configurative at the module level. |
|
Notification trigger interval (sec) |
Sampling interval in seconds for checking notifications. For example, if the Counter Interval is set to 10 seconds and the Notification trigger interval is set to 2 seconds for each counter interval the system will determine 5 times whether the threshold value has been crossed. |
When system overload occurs, Service Broker rejects new sessions and sends response messages to the network entities that attempted to establish the new sessions.
In the Overload Protection Methods pane you can configure how Service Broker responds to attempts by SIP and Diameter network entities to establish new sessions.
Table 9-2 describes configuration parameters on the Overload Protection Methods subtab. Expand Platform, then Processing Tier, then Overload and Tracing, and then the Overload Protection Methods subtab.
Table 9-2 Overload Protection Methods
| Name | Type | Description |
|---|---|---|
|
Enabled |
BOOL |
Specifies whether or not the overload protection methods in this table are enabled. Possible values:
|
|
SIP Response Status Code |
STRING |
Specifies a SIP error that Service Broker returns to a SIP network entity when Service Broker declines an attempt to establish a session. Default value: 503 |
|
SIP Retry-After |
STRING |
Specifies the value that Service Broker sets in the Retry-After header of the error response sent to the network entity. This value defines how long the network entity waits before it retries to establish a session. Default value: 300 |
|
Diameter Response Result Code |
STRING |
Specifies a response Result Code AVP that Service Broker returns to a Diameter network entity when Service Broker declines the attempt to establish a session. Default value: 5012 |
|
Web Service Response Status Code |
INT |
Specifies an error code that Service Broker returns to a Web service network entity when Service Broker declines the attempt to establish a session. Default value: 503 |
|
SAL Response Status Code |
INT |
Specifies an error code that Service Broker returns to a SAL application when Service Broker declines the attempt to establish a session. Default value: 503 |
|
 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
