Introduction

It is becoming increasingly common and desirable for companies to outsource applications and services to Internet or Application Service Providers (ASPs) to reduce hardware and administration costs. ASPs save cost by sharing hardware, software licenses, and personnel among business clients. To minimize the number of system administrators required to run the ASP's site and to decrease the rate of system failure, ASPs invest in highly reliable and powerful servers. Since such server setups are not cheap, its resources should be highly utilized by sharing them among as many business clients as possible. In addition to the sharing of hardware resources, software resources may be shared across services. For instance, the DNS server will generally be shared across services and even business clients. While reducing the ASP's cost, aggressive sharing makes ensuring the Quality-of-Service (QoS) for the outsourced services difficult. Since ASPs must fulfill QoS contracts, a.k.a. service level agreements [22], they must tackle the performance interferences that result from the sharing of resources and services without deploying highly underutilized and hence, cost-inefficient servers.

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.
 
 

Figure 1:Service-sharing destroys insulation

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 P₁ accepts a service request from VS_x, the resulting P₁ activity should be charged to VS_x'' 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.
 
 

Figure 2:Virtual Service Architecture

The following points summarize the key features of our VS architecture:

• Dynamic resource bindings for shared services
• Application transparent resource management
• Applications may use several OS mechanisms to relay work to each other
• Minimal interference between VSs
• Modular implementation permits trade-off between the quality of insulation and the overhead incurred by the VS abstraction

The idea of a VS can be directly applied to distributed server farms within one administrative domain and shared VS name space. Even though collaborating services may be scattered over several machines, they still relay service requests to one another via system calls which the classification gates can intercept.

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.