|
|
The following section explains configuring budgets and describes their relationship to SLA settings.
In Network Gatekeeper, SLA enforcement is based on budgets maintained by the Budget service. The budget reflects the current traffic request rate based on traffic history. Each Network Gatekeeper server updates both its own local traffic count and the cluster-wide count maintained in one Network Gatekeeper server, the cluster master, based on load and time intervals. The cluster master is, from a cluster-perspective, a singleton service that is highly available and is guaranteed to be available by the WebLogic Server infrastructure. The cluster master is also guaranteed to be active on only one server in the cluster. This ensures accurate SLA enforcement with regards to request counters.
By default, budget quotas are enforced within the cluster. The Budget service is also capable of maintaining budget quotas across domains spread across geographic locations.
Budget values for SLAs that span longer periods of time are persisted in the persistent store to minimize the state loss if a cluster master fails.
There are two types of budget caches:
When a cluster master is restarted it revives the state from the persistent store. If a cluster master fails, each Network Gatekeeper server continues to independently enforce the SLA accurately to the extent possible, until the role of cluster master has been transferred to an operational server. In such a situation, a subset of the budget cache is lost: the in-memory only budget cache and the parts of the in-memory cache backed by persistent storage that have not been flushed to persistent storage. The flush intervals are configurable, see Attribute: PersistentBudgetFlushInterval and Attribute: PersistentBudgetTimeThreshold.
A desired accuracy factor for synchronizations can also be configured, see Attribute: AccuracyFactor.
The configuration settings for these affect accuracy and performance:
Budgets are synchronized between all servers in a cluster according to the following algorithm:
The request count is the amount of the budget that has been allocated since the last synchronization with the master. The following scenarios are possible:
Synchronization happens as a result of (1) or (2), whichever comes first.
If the request count reaches the threshold value, there will be no explicit synchronization when the timer reaches Tt.
If r = 100, n = 2 and T = 1000 milliseconds and a = 2
rt = 100 / (2 * 2) = 25 requests Tt = 1000 / (2 *2) = 250 milliseconds
The slave synchronizes with the master if the request count reaches 25 or if the time since the last synchronization is 250 ms, whichever comes first, at which point the timer is reset.
The master is responsible for enforcing the budget limits across the cluster by keeping track of the request count across all the servers in the cluster.
If there is budget available, the master updates the slaves with the remaining budget whenever the slaves synchronize with the master.
In the absence of the master, each slave individually enforces the budget limit but caps the requests at r/n, thereby guaranteeing that the budget count never reaches the limit.
If the slave fails before it can update the master, the master is not able to account for that server’s budget allocation, and can be rt requests out-of-sync.
Under certain circumstances, if the master allocates more than the configured budget limit, the budget will be adjusted over time.
For budgets that span longer period of time, the budget count is persisted in the database to avoid losing all state during master failures. See Attribute: PersistentBudgetTimeThreshold.
Budgets can have overrides defined in the SLAs. When a budget is configured with an override, the budget master determines if a given budget is active. If active, it enforces budget limits based on the active override configuration. If overrides are overlapping, no guarantees are provided on which override will be enforced.
| Note: | For an override to be active all of the following must be true: |
startDateendDate (must not be the same date)startTime and endTime. If endTime is earlier than startTime the limit spans midnight.startDow and endDow or equal to startDow or endDow. If endDow is less than startDow the limit spans the week end.Overrides are not enforced across geographically redundant sites.
Configure the following attributes:
No management operations are available.
Managed object: Container Services
BudgetService
MBean: com.bea.wlcp.wlng.core.budget.management.configuration.BudgetServiceMBean
Below is a list of attributes for configuration and maintenance.
Specifies the time interval between flushes of budgets to persistent storage. See Introduction.
Specifies threshold value for budgets. Budgets for all time intervals defined in the SLA larger than this value are persisted. See Introduction.
Specifies the accuracy factor. See Introduction.
Configuration synchronization interval between the slave nodes and the master node.
Under normal operating conditions, Network Gatekeeper, including the Budget service, and the WebLogic Server automatic migration framework share the common transactional (XA) datasource (wlng.datasource) that has been set up for the Network Gatekeeper at large. A datasource is an abstraction that handles connections with the persistent store. Under very heavy traffic it is possible for the Budget singleton service to be deactivated on all servers. This can happen if the automatic migration mechanism that supports the service becomes starved for connections. In this case, a major severity alarm is thrown: Alarm ID 111002, “Budget master unreachable”.
| Note: | Datasource issues are not the only reason this alarm might be thrown. |
If you encounter this problem, you can set up a separate singleton datasource for the migration mechanism that will assure that the singleton service always has access to the persistent store. This datasource should be configured to use the same database as the common transactional (XA) datasource (wlng.datasource). For more information on singleton service migration in, see the section Automatic Migration of User-Defined Singleton Services in http://download.oracle.com/docs/cd/E13222_01/wls/docs100/cluster/service_migration.html. Also see the section High-availability Database Leasing in http://download.oracle.com/docs/cd/E13222_01/wls/docs100/cluster/migration.html for information on the mechanism underlying migration.
For information on setting up a separate datasource to support migration of singleton services, like the Budget service, in WLS, see the section Configuring JDBC Data Sources in http://download.oracle.com/docs/cd/E13222_01/wls/docs100/jdbc_admin/jdbc_datasources.html.
|