Policy Types
There are many types of policies and many ways to implement them. Some of the main classifications are explained below. A recent draft standard defines the terminology of each kind of policy. That terminology has been adopted in this book, and the standard is summarized in this section.
Limits and Error Event Rules
One of the simplest policies is to define limits on a measurement and associate it with an action. This is often implemented as an “if measure passes threshold then action” rule. Products such as the Sun Enterprise SyMON 2.0 software (referred to hereafter as SyMON) predefine many simple limit rules and allow new rules to be set on any measurement. A limit can be defined as a simple rule with a single input measurement. It is also common to have several thresholds with a warning level action and a critical problem level action for the same measure.
An error event is different because it is treated as a discrete on/off event rather than a continuous variable to be compared against a limit.
In either case, an alert is generated and logged. The alert can be transitory and go away when the rule is re-evaluated, or it can be persistent and require a user to acknowledge that it has been seen.
Complex Rules and Hierarchies
More complex rules take several inputs and can maintain historical information such as previous state and running averages. They can also be built out of several simple limit rules. A complex rule is used to establish the state of a component or a subsystem. When rules are combined, they are ranked so that critical problems take precedence over warnings. A hierarchy of rules can be built for a network of systems so that the overall state of the network is indicated by the state of the system that has the worst problem. In turn, that state is based on the state of the subsystem that has the worst problem. A rule state propagation hierarchy is provided as part of the Sun Enterprise SyMON 2.0 product, and many other commercial tools implement this mechanism.
The policy is inherent in the set of rules that are implemented, the thresholds that the rules use, and the actions that occur when a rule becomes active.
Priority
A relative importance level can be given to the work done by a system as part of a policy that prioritizes some activities over others. The Solaris Resource Manager product and others like it assign shares to each user according to a policy decided by the administrator, then accumulate the CPU usage at a per-user level and implement a control based on the number of shares held by each user and the user's place in the hierarchy.
An alternative approach is to specify percentages directly. The Solaris Bandwidth Manager software uses this mechanism to provide a way to specify policies on a per- network packet basis. Each packet is classified by address or protocol and each class is given a priority and a percentage of the total bandwidth that it can use.
Goals
Goal-based policies are prescriptitive rather than reactive. They operate at a higher level. A goal can be translated into a mixture of limits, priorities, and relative importance levels. Goals can include actions for when the goal cannot be met.
A goal can also be thought of as a control loop, where the policy manipulates controls when a measurement deviates from its desired range. As described in Chapter 3, a control loop is a complex thing to manage because its stability characteristics, time constant, and damping factor must be set correctly. The interaction of multiple inter-linked control loops can be problematic.
Goals can be expressed in several ways:
Response time goals try to monitor the end user response time of a system and control resources so that high priority work maintains its response time goal by taking resources from lower priority work.
Throughput goals monitor the rate of consumption of a resource for long running jobs and control the relative priority to maintain the desired balance.
Deadline goals have a way of telling how far a repetitive batch job has gone through its work, and control resources to ensure that the entire job completes by a deadline. For example, a payroll application must complete on time and generate the correct number of pay slips. A goal-based workload manager could monitor the running total.
At present, automated goal-based workload management is a feature found only on mainframes running OS/390 software.
Operational Policies
Some policies are implemented manually as part of operations management. For example, an availability policy can include a goal for uptime and an automatic way to measure and report the uptime over a period. There is no direct control in the system that affects uptime. It is handled by operations staff, who will reconfigure software to work around problems, swap out unreliable hardware, or reconfigure the system into a more resilient configuration if the availability goal is not being met.
In most cases, goal-based policies require manual intervention to complete the control loop. A measure of response time is monitored, and if its goal is not being met, the administrator manually varies the CPU shares, moves work from an overloaded system to another system, or performs a hardware upgrade.
Networked Security Policies
Access to a system varies according to the role of the user. A security policy can prevent access to certain resources or allow designated users to manage subsystems. For example, the SyMON software includes access control lists for operations that change the state of a system, and multiple network domain views to give different administrative roles their own view of the resources being managed. Security and network-based policies can be stored in an LDAP based name service. When users dial into an Internet service provider, they are looked up in a RADIUS authentication database, which can extract a profile from an LDAP server to configure the systems each user is allowed to access and the Solaris Bandwidth Manager configuration is updated to take into account that user's network address.