Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Giovanna Ferrari ([email protected]) School of Computing Science University of Newcastle upon Tyne Giorgia Lodi ([email protected]) Department of Computer Science University of Bologna V.Ghini, F. Panzieri Bologna, 25 - 26 September 2003 Summary • TAPAS Architecture: a quick look through it • Sensors • Reporting Service • Configuration Service • Controller Service • Concluding remarks • References Bologna, 25 - 26 September 2003 2 TAPAS Architecture Inter-Org. Interaction Regulation (Nick’s talk) QoS Monitoring and Violation Detection (Carlos’ talk) Applications Middleware Services for QoS Management, Monitoring and Adaptation (Gio&Gio’s talk) QoS Enabled Application Server Bologna, 25 - 26 September 2003 3 Middleware Services Partner SLA End user SLA INTERPRETER SENSOR A P P L END USER SENSOR CONFIGURATION SECURITY COORDINATOR CONTROLLER LOCAL RESOURCES SENSOR Bologna, 25 - 26 September 2003 REPORTING REMOTE RESOURCES SENSOR 4 Sensors & Reporting Service Partner SLA End user SLA INTERPRETER SENSOR A P P L END USER SENSOR CONFIGURATION SECURITY COORDINATOR CONTROLLER LOCAL RESOURCES SENSOR Bologna, 25 - 26 September 2003 REPORTING REMOTE RESOURCES SENSOR 5 Sensors (1/5) • Which resources to monitor: – Physical Resources (e.g. hosts, networks) – Logical Resources (e.g. the applications, file system, middleware services) • Data collected by means of Sensors (i.e. sensors for physical and logical resources) • Sensors activated by the Reporting Service when needed Bologna, 25 - 26 September 2003 6 Sensors (2/5) • SLA used to derive basic QoS parameters for each type of the aforementioned resources SLA item Quantification Percentage of transactions Completed within defined Performance Levels Availability of all Components Connected to the Network Availability of Applications on the Network % Application response Time during peak periods Median Application response Time ms Average one way latency ms External memory access time CPU usage Bologna, 25 - 26 September 2003 % % ms ms % 7 Sensors (3/5) Raw Metrics CPU running Queue Length CPU blocked Queue Length Composite Metrics Host CPU Swapped Queue Length CPU usage System Call Rates Availability CPU User Percentage CPU System Percentage CPU idle Percentage Free Available Memory Sensor Bologna, 25 - 26 September 2003 ………. 8 Sensors (4/5) Host Host Sensor Sensor Raw metrics Network RTT ……. Bologna, 25 - 26 September 2003 Raw metrics Composite Metrics Average one way latency Network RTT ……. 9 Sensors (5/5) Raw Metrics Composite Metrics Applications Availabiliy Percentage of transactions completed Median Application RT Application Response Time (RT) Application RT during peak periods ………….. Sensors Bologna, 25 - 26 September 2003 10 Reporting Service (RS) • It periodically collects Raw Metrics by means of the sensors • It calculates Composite Metrics according to the SLA items • It records the data into repositories for statistical analysis, as well as for providing trustworthy reports Bologna, 25 - 26 September 2003 11 Configuration Service (1/2) Partner SLA End user SLA INTERPRETER SENSOR A P P L END USER SENSOR CONFIGURATION SECURITY COORDINATOR CONTROLLER LOCAL RESOURCES SENSOR Bologna, 25 - 26 September 2003 REPORTING REMOTE RESOURCES SENSOR 12 Configuration Service (2/2) • Enabled at deployment time • Responsible for admission control (i.e. discovery, negotiation and reservation of the resources) • Produces AgreedQoS, i.e. a contract between the middleware platform and the environment which is to be hosted • AgreedQoS used as input for the Controller Service (CTRL) Bologna, 25 - 26 September 2003 13 Configuration Service: The Protocol (1/2) • A Configuration Service (CS) for each Application Server (AS) – Application Service Provider (ASP): a distributed architecture consisting of a cluster of ASs (i.e. cluster of CSs) • Two different CS personalities: Leader and Slave – Leader gets SLS as input and starts the admission control protocol – Slaves contacted by the Leader in order to get their local resource availability and to negotiate QoS parameters Bologna, 25 - 26 September 2003 14 Configuration Service: The Protocol (2/2) • Leader forms the group of CSs – IP addresses of Slaves known e.g at deployment time, … • For each member of the group (Slave), Leader kicks off the admission control protocol: – Asks local RS for its own resource availability and asks each Slave for its local resource availability Every Slave contacts its own RS for getting resource info – Every CS (i.e. Leader and Slaves) books its local available resources – Leader gets Composite Metrics from each Slave and from himself; starts the QoS negotiation: AgreedQoS contract as final result – From this contract, Leader confirms (totally, partially, or not at all) the initial resource booking Resources are allocated – Leader instruments Instantiate Manager in order to instantiate application components into containers according to AgreedQoS Bologna, 25 - 26 September 2003 15 What does the AgreedQoS look like? • • • It is an object seen as the run-time version of the SLS It contains useful info about the platform which is going to be used for the execution of distributed applications It contains info about the resources reserved and allocated after the negotiation 3 database replicas: colline:130.136.x.x bess:130.136.x.x bologna:120.128.x.x Machines newton:130.136.x.x Availability CPU: 50%, Memory 50%, RTT=#ms, no database av. leonardo:130.136.x.x Web page:xxxx available …………………….. Bologna, 25 - 26 September 2003 16 Group Communication Requirements • Group communication required for carrying out the admission control protocol • Some primitives necessary in order to manage the group of CSs in a dynamic manner: – – – – – CreateGroup: creates a group of CS for a certain application Memebership: obtains information about the members of a group Join: allows a new group member to join a group Leave: allows a group member to leave a group Send: enables message exchange among the members of a group (with QoS guarantees as well) – Deviler: delivers messages to the invoker in a reliable and QoSaware way Bologna, 25 - 26 September 2003 17 Controller Service (1/3) Partner SLA End user SLA INTERPRETER SENSOR A P P L END USER SENSOR CONFIGURATION SECURITY COORDINATOR CONTROLLER LOCAL RESOURCES SENSOR Bologna, 25 - 26 September 2003 REPORTING REMOTE RESOURCES SENSOR 18 Controller Service (2/3) • At runtime, if CTRL detects any variation in QoS values (e.g. fluctuation of the workload or change in required I/O QoS levels); actions are being taken for adapting the platform • These actions represent the Adaptive strategies that manage and control the resources and the output delivered • Adaptation starts when the QoS level is close to the Warning Point, even if the SLA is not breached yet • At the Breaching Point the adaptation has failed and an event notification is sent Bologna, 25 - 26 September 2003 19 Controller Service (3/3) • It receives from the CS the AgreedQoS contract • It periodically retrieves from the RS the Actual QoS Values (QoS achieved according to the measurements of the sensors) • It compares the two sets of values – If there is a violation, it decides the Adaptive Strategy to deploy – The adaptation may require a resource re-allocation • CS re-negotiates QoS – The adaptation may fail an exception is raised to the higher monitoring service (i.e, Carlos’ monitoring) Bologna, 25 - 26 September 2003 20 Concluding Remarks • Two possible implementations of Configuration and CTRL services: 1. Both services as extensions of AS • assume one AS per machine – – – • • CTRL responsible for local resources, only invokes CS if detects deviation from AgreedQoS CS re-negotiate QoS, if necessary (i.e., adaptation) 2. CTRL as support service for AS • can be hosted by TTP UNIBO wishes to evaluate the alternative 1 – conceptually simpler More about it, tomorrow … Bologna, 25 - 26 September 2003 21 References • W.Beckman, J.Crowcroft, P.Gevros and M.Oleneva ``TAPAS Deliverable D1'', University of Cambridge and Adesso AG, 2002-10-17. • L. R. Welch, B.A.Shirazi, B. Ravindran and C. Bruggeman “DeSiDeRaTa: QoS Management Technology for Dynamic Scalable, Dependable, RealTime System”, University of Texas at Arlington, USA. • M. Debusmann and A. Keller “SLA-driven Management of Distributed Systems using the Common Information Model " IBM Research Division, NY August 16 2002. Bologna, 25 - 26 September 2003 22