Table 1: Related Work
Resource Containers (RC) is the most recent representative of resource-oriented server management. Any OS or application activity executes in the context of an RC. The RC may contain basic CPU and network shares and various count limits on the number of resource consumers that can be bound to it. To control application performance, processes must explicitly bind to an RC. Subsequent activities are charged to the associated RC, and resource limits specified therein are enforced. Unlike VS, the RC abstraction does not automate the binding of resource consumers to RC's.
The Solaris Resource Manager [20] is based on a resource reservation concept (called lnodes) which is equivalent to RC. In addition to the resource-reservation abstraction, lnodes are tagged with Unix user-group affiliations so that the resource context can be inferred from the user-group setting of current application activity. This mechanism reduces the need for manual resource bindings. The idea is to give each user-ID its own machine. Unfortunately, this concept fails if shared services do not change their user-ID when they work on behalf of different users. For example, the system's DNS server does not change its user-ID to that of the process requesting address resolution.
In the context of Eclipse's hierarchical reservation domains [4] Bruno et al. discuss in a recent paper [3] how Eclipse tackles the problem of sharing specific OS entities such as sockets among concurrent applications. Interference can be reduced by tagging each request that utilizes a shared resource with the appropriate reservation domain, thus delaying the resource binding of the shared OS abstraction. Request tagging is also used by VS. Unlike VS, Eclipse does not infer the tag for a request in the absence of application support and does not exploit these for the scheduling of an application that picks up a tagged request. Precursors of this work are the Hierarchical Scheduler (HS) [9] with configurable CPU scheduling policies and the Nemesis OS [10]. Nemesis provides comprehensive inter-application isolation for memory and file system. Both HS and Nemesis require applications to manage their own resource bindings.
Workload Manager's (WLM's) [1] notion of a service class is similar to the notion of a VS. Since WLM manages requests separately according to their service class, service sharing does not necessarily cause interference. Nevertheless, classifying requests into service classes is the hard part. For this purpose, IBM modified OS/390's services to classify all requests into service classes. This approach does not work for ASPs since they cannot modify hosted applications. Therefore, VSs provide a transparent work classification mechanism.
Scout [18] takes a somewhat different route since it is primarily designed to be used in embedded multimedia server designs. Scout's path abstraction tracks the flow of work across different OS layers. Resources are reserved on a per-path basis. Since paths are compiled into the kernel, resource consumption scenarios cannot change dynamically. For every new resource consumption scenario (i.e., new applications) the Scout kernel must be recompiled. In contrast, VSs can be configured dynamically to handle new scenarios of resource consumption and service interaction.
Sun's Dynamic Enterprise 1000 [21], Solaris Resource Manager [20], and Ensim's recent VH product ServerXchange [7] are noteworthy commercial VH implementations resembling Eclipse. Other popular commercial solutions, such as Cisco's LocalDirector [6], HydraWeb [11], and F5's BigIP [8] are geared towards increasing the capacity available to ASPs through load-sharing in server clusters. These solutions also provide some coarse insulation between co-hosted services by shaping request flows. This mechanism applies only to well-known services (e.g. Web servers) since requests must be parsed by a load-managing frontend. Hence, insulation fails when ASPs co-host proprietary services and when the workload created by individual requests differs significantly among co-hosted sites.