This chapter is from the book
This chapter is from the book
This chapter is from the book
1.2 Policy-Based Self-Configuration
One of the most time-consuming operations in the management of any system is the initial configuration of a new installation, or the reconfiguration that needs to be performed when new requirements are received. The basic approach in self-configuration is to offer a simplified set of abstractions that the administrator needs to manipulate, while the detailed configuration of a myriad of parameters in the system are hidden to a large extent. Although there are several instances in which policy-based self-configuration mechanisms can be used, we will use the example of a hosting service provider for illustration purposes.
For the sake of simplicity of illustration, let us assume that all the customers of this service provider run their Web sites only within the premises of the service provider, and each Web site is supported by one or more instances of a Web server such as Apache or IIS. The service provider has a pool of stand-by servers that can be deployed for any customers after a proper installation of applications. Some of the customers whose Web sites draw heavy traffic may need multiple servers at the site with a load-balancer in front of them, whereas customers whose sites are not as popular may be sharing a single server with other customers. The service provider can set up a hosting Web site with a set of routers, virtual LAN switches, load-balancers, and server blades that can enable this service. All of these devices make up the target system of the policies. Because most hosting service providers will have system administrators who can write scripts to automate common processes, we further assume that they will have developed a series of scripts so that they can automatically allocate a server from a shared pool to a specific customer, and conversely return a server back to the pool once the busy period is over or the contract with a corresponding customer expires. A similar script can be developed for automating the addition or removal of a new virtual server for smaller customers. A more detailed discussion about how such a system can be developed can be found in [APPL].
When a new customer is added or an existing customer removed, the configuration of the site needs to be changed according to the change in the set of customers being supported. If there are mechanisms available for servers to be assigned in an automated manner to different customers from a shared pool, then the number of servers or processors assigned to a specific customer may change depending on the intensity of traffic to that site. Sometimes the hosting site may want to enforce limits on how much bandwidth a customer’s site can use in a month, and may want to reconfigure the site to restrict the throughput available to a hosted site if the traffic to that site exceeds predetermined thresholds. Let us assume that the service provider characterizes its customers into two groups: large and small. It may instantiate policies for self-configuration of its site, which may look like the following:
If a large customer has 75% or more utilization of all its servers, and has less than its maximum allowed number of servers, then allocate an additional server from the free pool to it. If a large customer has 30% utilization or less on all its servers, and has more than its minimum allowed number of servers, then remove a server from it to the free pool. If a small customer has reached 125% of the monthly bandwidth allowed to its site, then disallow further access to the site for the rest of the month. If the addition of a new small customer causes the number of small customers at a server to exceed a threshold, allocate a new server from the free pool and migrate half of the existing small customers to that new server.
In the preceding example, we can identify several attributes: utilization rate, number of servers, numbers of free servers, monthly bandwidth, and so on. Each of the policies provides a constraint on the new configuration of the system. The behavior of the system (allocation of servers between customers and the free pool) is constrained to conform to the guidelines set earlier. The guidelines may change based on the experience of the service provider—instead of using server utilization, it may opt to use the bandwidth consumed as a trigger for reallocation of servers, or it may use a combination of both. Also it may choose to not block small customers that exceed their throughput limits, opting instead to charge them an additional amount of money. Looking back at the discussion of policy types, we can recognize all of these policies as instances of action policies.
These sets of policies allow the administrator to manage the customers using attributes (utilization, number of servers, bandwidth rate, and so on) that are decoupled from the details of actual server configuration (their IP addresses, commands to control bandwidth, their operating system version, and so forth). Thus, the goal is to allow administrators to view system management in terms of the abstracted attributes that lets them specify what needs to be done, leaving the details of how it can be done to the underlying mechanisms that support a policy-based management system. Policies do not describe the mechanisms for the reallocation of the servers, the migration of customers to the new server, or disabling access to any site. However, assuming that appropriate scripts to do these tasks exist, the ability to specify the policies and invoke the right scripts for the required actions would enable the system to self-configure itself in accordance with the wishes of the service provider.
Building a policy enabled management system for this scenario would involve three steps:
- Determining a way to specify the policies.
- Enabling support within the system to interpret and enforce the policies.
- Invoking a mechanism to distribute policies from the entity specifying them to the entities interpreting and enforcing them.
To specify policies, a language that can capture the semantics of policies needs to be selected and a tool to specify the policies needs to be developed. Later we will discuss that having an information model is also an important aspect of the specification process in addition to selecting a policy language. The system management software that allocates and reallocates servers needs to understand policies specified in this language so that it can enforce the policies by transferring the servers under various operation conditions. Finally, it is important that the policy specification from a system administrator is distributed to a system that can enforce the policies. In this particular case, if there is only one instance of the system management software, the third problem of distribution is trivial because there is no need for synchronizing among multiple copies of the policy.