|
Operational policy
With WebSphere XD, you can differentiate application service levels according to your business requirements. The goals-directed infrastructure capabilities of WebSphere XD mean that user requests are classified, prioritized, queued, and routed to servers based on application operational policies that are tied to business goals. Application performance is optimized according to these policies that reflect service level goals and relative importance to the organization.
Simply put, you can state what applications are important to you, and these applications will get the highest priority access to your WebSphere resources at the right time. This can help you ensure, for example, that your business-critical transactions get the best quality of service.
WebSphere XD offers two types of operational policies:
| Service policy
|
Service policies definitions are made up of two key items, namely goals and importance. The goal portion of the service policy defines how incoming work is evaluated and managed in order to ensure and detect if work is meeting its assigned service policy levels. The importance is used in times of resource contention in order to identify the most important work in the system, and give it the priority.
|
| Health policy
|
WebSphere XD provides a health monitoring and management subsystem. This subsystem continuously monitors the operation of servers to detect functional degradation that is related to user application malfunctions. The health management subsystem consists of two main elements, namely health policies and the health controller.
WebSphere XD supports the following health policies:
Age-based condition: Monitors for servers running longer than a configured time period.
|
|
Excessive request time-out condition: This health policy will detect, for each server that is a member of the policy, the percentage of requests directed at that server which have timed out (over an interval of time) after being routed from the ODR.
|
|
Excessive response time-out condition: Monitors for servers that appear to be hung due to requests taking an excessively long time period to complete.
|
|
Workload condition: Monitors for servers that have executed more than a configured number of requests.
|
|
Memory condition, excessive memory usage: Monitors for servers that appear to be consuming more memory than what the server has available.
|
|
Memory condition, memory leak: Profiles the Java Virtual Machine (JVM) heap size after a garbage collection has occurred, and looks for trends of increased consumption. When an increasing trend is detected, the condition is triggered.
|
|
Storm drain condition: Applies only to dynamic clusters and will detect, for each cluster member, a significant drop in the average response time for a member of the cluster coupled with changes to the dynamic workload manager (DWLM) weights for the cluster members.
|
|