Recently, resource sharing has been addressed by the virtualization
of resources in off-the-shelf OS's (e.g., virtual Web hosting and
virtual
servers) [2,3,6,7,8,14,21]. The essence of these concepts is that one
physical server is split into several virtual hosts (VHs). Ideally, neither
the client nor the server application is aware of the fact that it is executing
on a VH and not on a real host. Initial implementations of this idea were
content-based VHs. Here, a server would serve different content, depending
on the IP address that was used to contact it, e.g., Apache's VirtualHost
directive [14]. The performance interference that occurs between co-located
VHs was not considered. To solve this problem, resource bindings for VHs
were introduced [2,4,7,20,21]. With resource bindings, demand surges on
one VH will no longer impact the performance of other co-hosted VHs. A
service that is executed on one VH behaves as if it were executed on its
own physical server. This still does not address the performance interference
between services that may result from accessing the same backend service.
Looking at the services that are hosted on a VH, we found that they vary between monolithic, which implement all service functionality themselves, and light-weight, which relay most of their work to other services. Therefore, the abstraction of a service does not directly coincide with the process boundaries imposed by the OS. Nevertheless, we define a service as the set of processes, sockets, and file descriptors that implement the service interface and share one address space. All other service activities (henceforth called just activities) that a service may trigger outside its own address space are referred to as sub-services. Since service providers often host similar services for different business clients, sub-services often shared among them.
When services are shared among different business clients, VH-based insulation approaches fail (see Figure 1). Shared services like DNS, proxy cache services, time services, distributed file systems, and shared databases, are quite common. With shared services, an obvious question arises as to which VH should host these shared services. Since these services work on behalf of many other services, their resource bindings should be dynamic to reflect the works-for relation. The problem could be fixed by replicating shared services on each VH. However, in this case the consistency of individual shared services becomes a major concern, as does the inefficiency that results when hosting two identical services to maximize performance insulation.
To eliminate the performance interference caused by shared services, we introduce the notion of a Virtual Service (VS). VSs are an OS abstraction that provides per-service resource partitioning and management by dynamically binding service activities in a manner that is completely transparent to applications. Once an activity is classified as belonging to some VS, this VS association is maintained, regardless of the process context in which the activity continues. This means that the resource bindings for shared services are delayed until it is known who they work for. This automatic and delayed resource binding makes insulation between services possible, in spite of shared sub-services.
In the VS architecture, the dynamic binding of activities to VSs is inferred by intercepting system calls within the OS using classification gates and analyzing the information that is passed to the call (see Figure 2). Gates track work that propagates from one service to another and are configured by the system administrator via simple rules. They automate the binding of resources (e.g., newly-created processes and sockets) to VSs, and keep track of any work done on behalf of a VS. Administrators can specify which system calls should be intercepted. Furthermore, they set up the rules that specify how the association between resources (e.g., processes, sockets, etc.) and VSs is affected by the intercepted calls. For example, a rule like: ``If process P1 accepts a service request from VSx, the resulting P1 activity should be charged to VSx'' can be configured easily. Our design also includes a VS-aware scheduler and packet dispatcher that enforce per-VS CPU and network shares.
The combination of VSs and gates permits resource management for dynamic communicating services without requiring any changes to the hosted services. While being transparent to the application, the system administrator must know the mechanisms by which work is relayed among VSs. Fortunately, this information can be inferred without application modification by system-call-tracing utilities or packet sniffers.
Other approaches that permit changing the resource bindings [2,4] do
not consider the problem of shared sub-services that do not readjust resource
bindings on their own. Since the applications that the ASP hosts are usually
developed for standard OS's, they are not resource-binding-aware. As Figure
2
shows, our transparent VS architecture brings resource management to such
applications.
The following points summarize the key features of our VS architecture:
We summarize related work in Section 2. Section 3 details the design of VS and the dynamic management of VS associations. Section 4 describes our Linux-based implementation. Section 5 presents experimental results and quantitatively shows that the VS abstraction solves the problems faced by ASPs that co-host services. Section 6 summarizes our findings and future research directions.