1 / 23

STATEFUL DISTRIBUTED INTERPOSITION JOHN REUMANN and KANG G. SHIN

STATEFUL DISTRIBUTED INTERPOSITION JOHN REUMANN and KANG G. SHIN. Presented by Sridurga Mavram. CONTENTS. Introduction System Model Architectural Overview SDI Concepts An Example using SDI Performance Conclusion. INTRODUCTION.

giles
Download Presentation

STATEFUL DISTRIBUTED INTERPOSITION JOHN REUMANN and KANG G. SHIN

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. STATEFUL DISTRIBUTED INTERPOSITION JOHN REUMANN and KANG G. SHIN Presented by Sridurga Mavram

  2. CONTENTS • Introduction • System Model • Architectural Overview • SDI Concepts • An Example using SDI • Performance • Conclusion

  3. INTRODUCTION • Monolithic network services to modular multitier services. • Important system context is lost at system boundaries. • To manage resources, propagating information across multi-tier applications is problematic. • Virtual Services associate each service with a VS structure. • To Propagate VS resource descriptors need the OS to be changed at numerous places.

  4. INTRODUCTION • Problems • telneting from login machine to remote client. • Information loss at tier boundaries is far more serious when system security is to be preserved. • Flask and DTE propose mechanisms for distributed security. • They have some common features

  5. INTRODUCTION • SDI generalizes the common features and provides the following requirements. • Keep State : storing state variables in context object. • Generate State: automating generation of context. • Propagate Context: automates the propagation of context between cooperating services • Utilize Context: uses dynamic contextual information to trigger interposition on standard system interfaces.

  6. SYSTEM MODEL • SDI is based on the following assumptions: • Multi-tier Systems are connected via a fast, reliable Server Area Network (SAN). • Each server provides a set of services, many of which act as front-end services. • Front-ends handle the requests from outside networks. • Front-end services depend on back-end which are also part of the server farm. • Back ends may be utilized by multiple front-end services simultaneously.

  7. SYSTEM MODEL • To exchange request/replies, front-end and back-end services depend on OS communication primitives. • There are no communication channels hidden from the OS. • Contextual information can be shared among cooperating tiers without application support, only if the requests are executed by kernel-level threads. • It assumes a typical layered OS design, which helps in having interception points called taps. • A tap may be installed between the transition from a network layer to the IP layer.

  8. ARCHITECTURAL OVERVIEW • Context Abstraction • SDI provides context abstraction that stores name-value pairs similar to POSIX environment variables. • The Difference : Unlike environment variables, context acts as an abstraction which can propagate along with the workload along multiple tiers. • A context object can be associated with multiple system objects at multiple hosts simultaneously, which is a necessity in distributed system. • Context is very important to facilitate co-ordination of distributed activities in a multitiered system.

  9. ARCHITECTURAL OVERVIEW • Managing Context • Tagging of system objects to new/existing context object is needed • The initial context for messages received from outside network are tagged using classifiers. • Classifiers extract as much information as possible from incoming message and use for context determination. • The context may affect the processing of packet/process at various levels. • This is similar to the effect that environment variables have on the application.

  10. State change at various levels as request progresses.

  11. ARCHITECTURAL OVERVIEW • Managing Context • Taps intercept the control flow at the OS layer and can apply SDI rules to interception computations • SDI rules are dynamically installed by the system administrator. • SDI rules are triggered if the condition in the guard clause is met. • This may cause the modification of context attributes or tag system objects with reference to different context objects. • SDI rules have a means of policing intercepted multitier computations. • Apart from standard actions, SDI rules also permit GCF’s. For example they could be GCF’s for encryption and decryption.

  12. Structure of SDI rule

  13. ARCHITECTURAL OVERVIEW • Application-Level Integration • Applications may use the context variables in addition to environment variables. • SDI provides an interface for the applications to query and set the values of context attributes. • Application can rely on OS and no longer need to device their own mechanisms which could be incompatible across different distributed frameworks. • An additional benefit in this design could be to reduce the latency in messages that need not be error-free.

  14. SDI CONCEPTS • Context • Context: Aggregate of attribute-value pairs, that could be associated with system objects as additional state. • Naming Attributes : Global namespace is controlled by University of Michigan, Real-Time Computational Laboratory. • Addressing context: Addressing is relative to the system abstraction whose state it extends. An absolute addressing is needed. • Context Propagation: To facilitate distributed priorities, access control, system services under different kernels need to exchange context. • The tagging rule should track the control and data flow of a composite process at tier boundaries.

  15. SDI CONCEPTS • Initial Context Creation • Classifiers extract and interpret intercepted packet information in accordance with system administrator-specified context binding. • Classifier may evaluate an incoming packet’s source address, destination address, protocol and port number. • Based on the above values, the classifier either associates the incoming packet with existing context or creates a new context object. • Since there is no limit for the amount of information that could be specified inside the classifier, they proposed a grammar.

  16. SDI CONCEPTS • Handling Distributed Context Efficiently • Problem1: If the context object that SDIs refer are located remotely, frequent invocations can incur higher latencies. • Solution: Caching is the best solution. Distributed access to context attributes proceeds through caching proxy object. • Problem2: Memory efficiency – when is it safe to discard a context object? • Solution: two way – one is to check whether the context is still needed locally, second is to check how many proxies refer to this context object and use a count-based garbage collector.

  17. SDI CONCEPTS • Handling Distributed Context Efficiently • Problem3: Memory leakage due to host failures • Solution: The back-end being unresponsive is handled by heart beats, each host periodically announces its liveliness to the host holding the primary context objects for its proxies. • Context Security • The mechanisms in this framework have only addressed local access integrity leaving the rest to the IP layer. • To assure local access integrity, attribute operations are controlled by access rights. For binding privileged context, binding permissions are also enforced.

  18. An Example using SDI • Context Propagation via Local IPC • Two system calls used to send and receive messages are msgsnd and msgrcv. • We need to deal with the message queue, sender and the receiver. • It is necessary to add a context reference pointer to the message queue data structure. • If the sender priority is high, SDI copies the sender’s context to the message. • When the context tagged message is received, SDI copies the received message’s context to the receiver’s context.

  19. An Example using SDI

  20. PERFORMANCE Objective: To to see if SDI is an efficient mechanism for system extension, which requires fast interpretation to context attributes and fast interpretation of rules. The Result: They have tested the framework both on micro and macro benchmarks which indicates that SDI can be used as an efficient mechanism.

  21. CONCLUSION SDI is a low-overhead improvement for hosting multitier services, hence services can perform well in server farms, under constraints that were not anticipated during the design process. SDI is not intended to be a final standard for distributed context. It has just marked a beginning of the standardization. It will be necessary for future implementations to concentrate more on the main concepts seen in this paper.

  22. THANK YOU

More Related