260 likes | 453 Views
Resource Containers: A new Facility for Resource Management in Server Systems. G. Banga, P. Druschel, J. Mogul Rice & Compaq Presented by: Aaron J Beach. Outline. Background and Terms Previous Approaches and Problems A new Approach: Resource Containers Performance and Evaluation
E N D
Resource Containers: A new Facility for Resource Management in Server Systems G. Banga, P. Druschel, J. Mogul Rice & Compaq Presented by: Aaron J Beach
Outline • Background and Terms • Previous Approaches and Problems • A new Approach: Resource Containers • Performance and Evaluation • Conclusion
Background: Web Servers • Many users' perceived computing performance is based on how well remote web servers perform. The OS and hardware are rarely on the critical path concerning web browsing • Servers may accomplish many different tasks each consuming many different types of resources. Depending on the resource strategies of the system it can be very hard to achieve QOS, fairness, or protection for existing and new clients.
The Big Idea! • The main big problem this paper seeks to convey and build upon is this: • Independent activities or tasks are not coupled with the process or thread entity. • However, the user-level (thread or process) is treated as the independent accountable entity for resource management. • This mis-assumption is BAD!
Web servers • Previous Approaches • Problems • Previous Solutions • Mis-assumptions
An idle connection waits listens on the socket For each new connection a new process is spawned Drawbacks: Suffers from context switches Process creation IPC Possibly very vulnerable to Syn attacks Process per Connection
Single process runs and calls handlers when it receives requests Avoids IPC and context switches Drawbacks: Not really concurrent, however, can spawn multiple processes if on multi-processor system Event-Driven Single-Process
Each connection gets its own thread Threads are scheduled by scheduler thread Idle threads listen for next connections This avoids context switches and scales better Multi-threaded Server
Other Resources used by Servers • Dynamic Resources • such as pages created in response to user input may require third party software. • This usually results in another process being spawned to handle each dynamic request.. • CGI was developed for fast IPC • Kernel Resources: • The kernel does network processing in order to handle connections and send connections, • It may have buffers for the connections. • These resources are generally considered separately from the Server and charged to either no one or any unlucky process!
Process provides dual purpose Protection domain Resource Entity Basically the ideas of a protection domain and accountable resource entity are coupled by the process/thread General Assumptions of Severs
Kernel vs User Resources • Server activity extends into the kernel • This is not considered during Resource management • Network intensive apps (i.e. Servers) may result in large percentages of overall resources being spent in the kernel!
Multi-threaded server and the Kernel • The threads each require processing to be done within the kernel • Lazy Receiver Processing • Charge kernel processing to the associated connection • Allows you to scale more gracefully and protect existing threads from incoming new threads (possibly syn attacks) • Allows better QOS • Still associates the protection domain and resource principle!
Single activity may spawn multiple processes to handle same connection (i.e. Dynamic Content) Single activity may want to protect different aspects of the same activity from eachother! Conclusion: Protection domains and resource principles are not semantically coupled! Process vs Independent Activity
A new approach... RESOURCE CONTAINERS! “An abstract operating system entity that logically contains all of the system resources being used by an application to achieve a particular independent activity” • Resources • CPU, memory, sockets, buffers • Attributes • Scheduling parameters (priority, QOS level, constraints • Resource Container Aspects • Hierarchy (parents -> children) • Dynamic Resource Binding • API and other practical implementation aspects
Resources • Processes / Threads • Dynamic Resource BindingBasically processes and threads can be associated and re-associated with the activity or purpose they are serving • Charge resources within the kernel like LRP • The key idea:The resource binding is the relation between resource/processing domains and the associated resource principles, effectively decoupling the two
Attributes • Attributes are used by Resource Management to • protect QOS of clients • Can protect against SYN attacks by maintain QOS at all levels for existing clients • Can Maintain Static Content requests separate of dynamic requests • Attributes: • Priority • Type of Service • Constraints
Scheduling threads • Threads may serve one container or many, existing within the same protection domain • To avoid rescheduling threads after every resource container binding, a list of containers is associated with a thread and the thread is scheduled based on combined attributes • Threads initially inherit their parent's Container (Hierarchical)
PERFORMANCE AND EVALUATION • Isolation of separate activities • Dynamic requests vs Static requests • Priority based scheduling • QOS of differing priority clients • Protecting against Syn Floods • Continuing to Server existing clients
Experiment • Added 6550 lines of code to Digital UNIX • Modified: • CPU scheduler • To use Resource Containers as it's principle unit • TCP/IP subsystem • LRP style processing • “4820 lines ... to Integrate containers as the system's resource principles” ... the details I guess • Running a single-process Event driven server
Dynamic vs Static Requests • Can Static requests maintain throughput in the face of many Dynamic requests? • Constrain the resource usage of dynamic reqs
Differentiating QOS • Assign resource container T-high to high priority connections. • Assign resource container T-low to low priority • How do T-high response time change with increase in low priority connections • Reduce queuetime of T-high
SYN-attack resilience • Basically they had a set of known mis-behaving clients SYN attack the server, and measured the concurrent throughput to other clients.
Attributes • Attributes are used by Resource Management to • protect QOS of clients • Can protect against SYN attacks by maintain QOS at all levels for existing clients • Can Maintain Static Content requests separate of dynamic requests • Attributes: • Priority • Type of Service • Constraints
Conclusions... YO! • Resource Container decouple resource principles from protection domains and extend them into the kernel and other processes • Evaluation shows they are able to achieve fine-grained QOS differentiation enforce priorities of activities that may share the same process or pervade many processes • This makes sense, no?