CS 443 Advanced OS

Fabián E. Bustamante, Spring 2005

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

G. Banga, P. Druschel, J. MogulRice & 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 ApproachesProblemsPrevious SolutionsMis-assumptions

Process per Connection

An idle connection waits listens on the socket

For each new connection a new process is spawned

Drawbacks:Suffers from context switchesProcess creationIPC Possibly very vulnerable to Syn attacks

Event-Driven Single-Process

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

Multi-threaded Server

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

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!

General Assumptions of Severs

● 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

Kernel vs User Resources

Server activity extends into the kernelThis is not considered during Resource managementNetwork 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!

Process vs Independent Activity

● 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!

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 / ThreadsDynamic Resource BindingBasically processes and threads can be associated and re-associated with the activity or purpose they are servingCharge 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 clientsCan protect against SYN attacks by maintain QOS at all levels for existing clientsCan Maintain Static Content requests separate of dynamic requests

Attributes:PriorityType of ServiceConstraints

Scheduling threads

Threads may serve one container or many, existing within the same protection domainTo 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 attributesThreads initially inherit their parent's Container (Hierarchical)

PERFORMANCE AND EVALUATION

Isolation of separate activitiesDynamic requests vs Static requests

Priority based scheduling QOS of differing priority clients

Protecting against Syn FloodsContinuing to Server existing clients

Experiment

Added 6550 lines of code to Digital UNIXModified:

CPU schedulerTo use Resource Containers as it's principle unit

TCP/IP subsystemLRP style processing

“4820 lines ... to Integrate containers as the system's resource principles” ... the details I guessRunning 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 connectionsReduce 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 clientsCan protect against SYN attacks by maintain QOS at all levels for existing clientsCan Maintain Static Content requests separate of dynamic requests

Attributes:PriorityType of ServiceConstraints

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?