Conclusions

We demonstrated that VSs are an effective, application-transparent resource management abstraction when sub-services are shared across business clients. Furthermore, our implementation showed that VSs can be integrated into an off-the-shelf OS without incurring much additional overhead. To manage VSs, a limited understanding of the managed applications suffices. In particular, one needs to know how services and sub-services interact. On the basis of these knowledge, the VS architecture transparently and dynamically updates the VS binding for service activities and thereby their resource bindings.

VSs are shown to be able to emulate the VH abstraction. Furthermore, we have shown that VSs provide sound insulation between competing services in spite of shared sub-services. ASPs who multiplex hardware and software resources among their business clients, benefit greatly from the proposed solution. Given the great interest in the outsourcing market, future versions of commercial resource management approaches such as WLM or Sun Resource Manager, will consider the interference caused by shared services between otherwise well-insulated services. They may use VS tracking to minimize this interference, thus improving resource management for multi-tier services significantly.

Since the VS architecture is extensible, one may choose only a small set of classification mechanisms and limited configuration options for gates. This allows a staged integration of VS tracking into off-the-shelf OS's. VS can also be integrated easily by putting the classification rules into a separate look-up table. Then a VS descriptor reduces to a RC or Reservation Domain. Therefore, it is possible to augment RC's or Eclipse to provide VS-like dynamic resource bindings by introducing a classification table and intercepting the VS relevant system calls.

In spite of the overall acceptable performance of our experimental implementation, there is still sufficient room for improvement. To speed up classification in a commercial OS, filtering and classification should be tightly integrated into the intercepted system calls as opposed to simply placing call-back hooks inside system call code -- calling an empty C function on a 300MHz AMD K6 already takes 9microseconds. A tighter integration would also avoid duplicate lookups of processes, file descriptors, etc., once to execute the system call and another time to execute classification.

The primary remaining issue in insulating co-hosted sites from each other using VSs is file cache management. To improve insulation, each disk-bound VS should be equipped with its own file cache [5]. To accomplish this goal, the inodes in the file cache must be tagged with their VS affiliation. Furthermore, one must limit the total number of inodes in the file cache for each VS. If an inode is shared by two or more VSs it should retain the tag of the highest priority VS that is using it. Otherwise, priority inversion would result. Although easy to describe, this feature requires substantial changes to the structure of the file cache. Nevertheless, content servers with very large inode working sets would benefit from such insulation. It is possible that this eliminates the small performance degradation of the well-behaved site in Figure 12.