| Oracle® Communications Service Broker Policy Controller Implementation Guide Release 6.1 Part Number E29455-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Service Broker Policy Controller Implementation Guide Release 6.1 Part Number E29455-01 |
|
|
PDF · Mobi · ePub |
This chapter explains how to protect Oracle Communications Service Broker Policy Controller (Policy Controller) from system 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 Policy Controller can increase significantly. This can cause a situation known as system overload in which Policy Controller has insufficient resources to handle new sessions. If overload is not handled correctly, the system can fail and lose critical data.
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 too many active sessions or 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.
See the discussion on implementing overload protection in Oracle Communications Service Broker System Administrator's Guide, for more information.
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.
You can configure Service Broker overload protection at the system and module levels:
System counters and gauges: These two indicators provide system level overload protection. They can detect and trigger an overload condition that might occur across any number of clustered managed servers or when deploying any combination of Service Broker products.
SystemCountersRuntimeMBean.SessionGauge
SystemCountersRuntimeMBean.InitialRequestCount
These counters and gauges monitor sessions that occur per managed server and per product. The indicators are systemwide because they monitor all sessions across the domain for all managed servers. Note there is no global overload protection status.
Using JConsole in a live environment, the platform system indicators are located under this node: oracle.axia.platform.runtimembean.pn.
Module level counters and gauges:
Any of the indicators described in Table 4-1 and Table 4-2 can provide module-level protection based on overload conditions that might occur when using Policy Controller.
The Policy Controller GxThrottledSessions and RxThrottledSessions counters described in Table 4-1 and Table 4-2, are related to monitoring overload protection because they hold the number of initial requests that were throttled due to an overload condition. However, they should not be used to implement threshold-crossed overload protection.
Note: Policy Controller should primarily use the platform-level SessionGauge and InitialRequestCount indicators for overload protection described in Table 5-1.
Table 5-1 Counters and Gauges For Implementing System Overload Protection
| Attribute | Description | Type |
|---|---|---|
|
InitialRequestCount |
Incremented each time the SessionGauge is incremented within the current counter interval. |
System-level Counter |
|
SessionGauge |
In a co-deployed domain, other applications such as the Online Mediation Controller can also update this gauge. |
System-level Gauge |
These steps must be followed to configure overload protection.
By default, the following system level gauge and counter are defined as your key overload indicators:
SystemCountersRuntimeMBean.SessionGauge: A gauge that measures the number of active sessions currently handled by Service Broker.
SystemCountersRuntimeMBean.InitialRequestCount: A counter that measures the rate at which Service Broker receives new sessions.
You can configure certain parameters such as threshold crossed and threshold ceased values but usually these indicators work well with their default settings.
Identify the Policy Controller level counters and gauges you want to use as key overload indicators.
Configure Threshold Crossed Notifications details for your Policy Controller counters and gauges.
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 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.
Configure Key Overload Indicators.
After you have configured the Policy Controller counters and gauges you want to use for overload protection you must specify that they are to be used by Service Broker as Key Overload Indicators.
You do this in the Administration Console by selecting Tier Management, and then Overload Pane. In the Key Overload Indicators pane, you can set your key overload indicators.
Note:
Service Broker activates overload protection when any of your key overload indicator crosses its upper threshold during a sampling interval.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.
You can customize the overload protection error code by modifying the value of the result code. In the Administration Console select the PCRF tab, then OCSB, then System Parameters, then Global Parameters. Configure the Overload Rejection Result Code.
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 systemwide and module-level counters and gauges. There are only two systemwide overload indicators: sessionGauge and InitialRequestCount.
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 any 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 PCRF, then OCSB, then System Parameters, and then Statistics.
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 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 systemwide 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.
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 counter or gauge uses either sessionGauge or initialRequestCount as the threshold name value, you do not have to add these indicators to the Key Overload Indicators pane. However, the module-level settings (for example, crossed threshold value) will override the platform-level settings for that individual software bundle only.
Click Apply.
This section describes how to configure general attributes for overload protection notifications.
To configure general Policy Controller statistics settings:
Start the Policy Controller domain and managed server.
Start the Administration Console.
For details see Oracle Communications Service Broker Administrator's Guide.
Expand PCRF, then OCSB, then System Parameters, then Statistics, and then General.
Be sure you have selected Lock & Edit.
In the General pane, configure the desired parameters according to the descriptions in Table 5-2.
When you have finished, click Apply.
Table 5-2 General Overload Configuration Parameters for Policy Controller
| 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. |
|
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.
At the Policy Controller level you can configure an Overload Rejection Result Code.In the Administration Console: PCRF, then OCSB, then Execution Block, and then Global Parameters. You can change the value in this field: Overload Rejection Result Code.This Diameter result code is used in the answer of a rejected initial request and the default value is 5012 DIAMETER_UNABLE_TO_COMPLY.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
