 |
Each VS is uniquely identified by its descriptor (Figure 4). To allow the system administrator to manage VSs, each service has an integer virtual service identifier (VSID). The VSID is guaranteed to be unique on each machine. For VSs that use resources on multiple machines, we leave it up to user-space software to guarantee the uniqueness of identifiers. When setting up the distributed service, external administration software can force a specific VSID onto the newly-created VS. Such global VSID's are taken from their own number range and will never conflict with local VSID's. Like RC's [2] we advocate hierarchically-nested resource contexts. Hierarchy is necessary because an ASP's clients should be able to decide themselves whether they want all of their services to share resources or whether they want to insulate them from each other.
The parent field of the VS structure points to the parent VS. Oftentimes parent VSs will be used to implement abstract VSs, i.e., placeholder services to which all services of an ASP's business client belong. The highest-level service is the root_service with VSID 0, which accounts for all unclassified work.
Hierarchy is again reflected in VS attributes such as resource usage statistics and resource limits. By default, newly-created VSs share the attributes, i.e., resource control settings and statistics (CPU time used, packets sent, etc.) of their parents. This means that the fields in the child refer to its parent's pendants (Figure 4). To manage the child service directly, attributes of interest need to be detached from the parent. For example, to control the number of processes for a sub-service, one detaches the sub-service's process count limit via the servctl(DETACH_PROCESS_LIMIT) call.
To instantiate a cluster-wide VS, the administration software must create VS descriptors with one global VSID on all cluster nodes. On each of those nodes, local resources may be reserved using the VS descriptor's resource context. Before reserving VS resources, the administration software will monitor the VS's resource consumption via the statistical VS attributes. Once enough statistics are available, resource reservations will be calculated to stabilize VS performance. This calculation is difficult and requires a full-fledged monitoring-feedback algorithm, which is outside the scope of this paper. We experienced that cluster-wide VS management using a unified VSID name space simplifies the implementation of such an algorithm.
Most of the VS state discussed so far could potentially be realized using RC's [2] or Reservation Domains [4]. However, they do not provide configurable classification rules. Classification rules indicate how VS-membership is to be updated when certain system calls are invoked by specific VSs. For instance, if a process member of the VS in Figure 4 calls fork, the OS knows exactly that this is a way of relaying work and that the created process should inherit the parent's VS affiliation.