Download Configuration & Controller Services, Giorgia Lodi, UniBo

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Zero-configuration networking wikipedia , lookup

Remote Desktop Services wikipedia , lookup

Distributed operating system wikipedia , lookup

SIP extensions for the IP Multimedia Subsystem wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Quality of service wikipedia , lookup

Transcript
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