A Policy Architecture


This section covers the basic components comprising a policy management system. The components include policy enforcers, repositories, and policy managers (after all, something has to manage the management policies). Specific products might have different combinations of components.

Policy Management Tools

Administrators use policy management tools to construct and modify their management policies. Policies today are often generic in that they are applied across the entire base of customers being served; however, policy systems must scale in sophistication to accommodate a tailored set of policies for each customer. For example, each customer organization could have policies that apply to each service used by the organization and could also have policies that apply to specific individuals within the customer organization.

Increased granularity stresses the policy system because there is more information to manage and access when policies are applied. As such, appropriate storage, information management, and processing resources are needed for scaling the policy system.

Clear presentation and ease of use are critical here because introducing a mistake into a policy can be burdensome to find and rectify. Administrators need to enter as much information as possible with simple forms. Importing customer profiles and other policy information saves a significant amount of staff time. Automated entry also speeds and simplifies the process while reducing the chance of introducing errors.

Archiving and version control are also essential features to consider. The original policies are modified as administrators use feedback to improve them or add more precise actions. Administrators must be able to track each generation of a policy so that they can roll back to an earlier version quickly.

Security features control access to the policy management tools. Only selected administrators can create or modify the policies. The same restrictions are applied to the policies for each customer; only those administrators responsible for a customer can set or modify the appropriate policies.

Repository

The policy repository contains the policy information used by the other elements in the policy system. The repository can be implemented in many waysas a set of flat files, a database, and more commonly, as a directory. Directories are winning favor because they offer advantages, including the following:

  • Directories are already widely used for other functions, including configuration, access control, and resource allocation. This offers the advantage of using existing mechanisms rather than inventing something equivalent.

  • Directory technology is maturing with high reliability and scalability.

  • Distributed directories offer higher performance and resilience to failures.

Repositories are structured to provide independent policy domains for each customer organization, their business units, and specific individuals within the organization.

The policy management tools aid administrators in creating and modifying the information held in the policy repository. After the information is safely in the repository, it must be available to the elements that actually act on it.

Policy Distribution

After they are in the repository, policies can be distributed to the appropriate elements. There are three types of distribution models: pull, or component-centric; push, or repository-centric; and a hybrid that combines elements of each. These approaches are discussed in the following subsections.

The Pull (Component-Centric) Model

The pull model is component-centric because it allows a policy-management component to gather the information it needs through a direct request to the repository. This saves large amounts of staff time that otherwise would be required to load every component with all the information it might ever need. Instead, a component queries for missing information and proceeds when the policy repository makes it available.

Adding more intelligence to the repository enables finer tuning and control. For example, distinctions between a customer accessing services from high-speed or low-speed connections can be made and the appropriate policies can be applied to each case.

Consider further that time of day might be considered as a criterion for blocking or permitting access to specific services in different time periods. Such a policy would be one method of preventing undesired activities, such as bulk transfers or database mirroring, from taking place when they would interfere with other activities.

A pull model evolves through on-demand delivery to the components. Over a period of time, each component pulls together the unique information it needs for its specific functions.

The drawback of this approach is that policies must remain fresh; policy information in a component can become stale and of no value. In fact, it has negative value because an old policy is in effect rather than its successor. As usual, there's a compromise to be made between frequent update requests and using local caching to reduce traffic and delays.

The Push (Repository-Centric) Model

The push model is called repository-centric because the repository drives new policy information to the components without waiting for their requests. The significant advantage is that policies can be quickly changed across large numbers of components. This ensures all components have current information and there are no errors introduced by having stale information in some parts of the environment. The pull model cannot make the same guarantee until aging times have elapsed.

The push model also entails the overhead of establishing and maintaining connections to the components for the fastest push. This can be a substantial demand on resources, and it must be balanced against the start-up times of establishing connections each time a new piece of information is pushed.

Hybrid Distribution

Using both models takes advantage of the strengths of each. The pull model obtains the latest information and can reduce traffic with local caching and aging. The push model is used when large-scale rapid policy changes are necessary (for example, when a security breach is detected). The policy system would use a push operation to change operations very quickly and minimize the damage from an intrusion.

Enforcers

This is where the rubber meets the roadenforcers ensure that policies are properly carried out. Enforcers are distributed throughout each infrastructure and carry out specific functions. Some enforcers are part of management agents embedded in another element while others, such as those in load-balancing switches, are major parts of the element's core function. Examples of enforcers include the following:

  • Access devices at the network edge apply access policies that determine access to services. These policies must be very granular, with policies that can be applied to individuals and services.

  • Routers in the network core switch and forward traffic according to policies for reserving bandwidth and forwarding traffic. This must also be granular for each customer and each service.

  • Servers apply priority policies for scheduling their tasks. These policies can also vary with activities. For example, a customer browsing a catalog might receive a lower priority than one who is completing a purchase.

  • Load-balancing solutions apply policies to distribute flows among a set of attached servers.

  • The geographic distribution system applies policies to select a site based on distance, relative loads, or customer profiles.




Practical Service Level Management. Delivering High-Quality Web-Based Services
Practical Service Level Management: Delivering High-Quality Web-Based Services
ISBN: 158705079X
EAN: 2147483647
Year: 2003
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net