1 / 24

Resource Containers: A new Facility for Resource Management in Server Systems

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

elita
Download Presentation

Resource Containers: A new Facility for Resource Management in Server Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Resource Containers: A new Facility for Resource Management in Server Systems G. Banga, P. Druschel, J. Mogul Rice & Compaq Presented by: Aaron J Beach

  2. Outline • Background and Terms • Previous Approaches and Problems • A new Approach: Resource Containers • Performance and Evaluation • Conclusion

  3. 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.

  4. 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!

  5. Web servers • Previous Approaches • Problems • Previous Solutions • Mis-assumptions

  6. 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

  7. 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

  8. 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

  9. 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!

  10. 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

  11. 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!

  12. 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!

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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)

  18. 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

  19. 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

  20. Dynamic vs Static Requests • Can Static requests maintain throughput in the face of many Dynamic requests? • Constrain the resource usage of dynamic reqs

  21. 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

  22. 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.

  23. 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

  24. 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?

More Related