Information Technology Reference
In-Depth Information
Metric and Service Metering
•
User Behavior Modeling: estimates cus-
tomer behavior for a given service specifi-
cally dealing with interactivity and human
aspects such the impact of attention, deci-
sion making and situational awareness. It
should be noted that customer behavior
(e.g. Kevin tends to submit large jobs and
takes many short brakes!) is often the criti-
cal factor in accurately estimating resource
requirements.
Service metering is increasingly becoming an
important issue as QoS-assured service, service
monitoring and on-demand resource provision-
ing all depend on it. In order to meter the service
usage, metrics must be defined to measure the
service usage. The SLA manager should be able
to retrieve usage information from functional
services (e.g. job services), records the usage and
optionally constrains and/or bills for the usage.
Different functional services will need to report
usage of different measurable quantities. For
example, a job service will report usage of CPU
but a data service will report usage of disc space.
These measurable quantities, known as “metrics”
are represented by URIs.
GRIA middleware (v5.3.1) (http://www.gria.
org/) has a simple while practical service metering
and monitoring component. The GRIA middle-
ware provides a Service-Oriented Infrastructure
(SOI) designed to support B2B collaborations
through service provision across organisational
boundaries in a secure, interoperable and flexible
manner. In GRIA, the use of metrics is recorded
in terms of “instantaneous” measurements and
“cumulative” usage. The cumulative usage is the
integration of the instantaneous measurements
over time. For some metrics, data-transfer for
example, the instantaneous measurement is best
regarded as a rate (bytes per second) and the
cumulative usage has no time dimension (bytes).
For other metrics, such as CPU, the instantaneous
measurement is just the quantity in use at the time
(e.g. 3 CPUs) and it is the cumulative usage that
has the time dimension, e.g. 180 CPU.seconds
(Boniface et al., 2006). The GRIA SLA service
can convert between the two, as shown in (http://
www.gria.org/), e.g.:
•
Resource Behavior Modeling: estimates
resource reliability probabilities including
both in-house and third party resources ob-
tained from infrastructure providers. These
models use resource knowledge derived
from both QoS reports from infrastructure
providers and local Quality of Experience
(QoE) measurements. The Application
Provider may use QoE measurements to
validate the QoS reported to it by the infra-
structure provider.
•
Un-interrupted Fault-free Application
Behavior Modeling: estimates completion
time probability from given customer re-
quirements and obligations. A combination
of techniques are used to determine com-
pletion time probabilities such as artificial
neural networks, benchmarking, curve
fitting, lookup tables, and discrete values
based on actual knowledge
•
Interactive Application Performance
Estimation: estimates the key application
performance indicators by combining in-
formation about the normal (uncorrupted)
behavior of the application with informa-
tion about exceptional circumstances that
might occur, i.e. different failure probabili-
ties and times for recovery. Finite State
Automata (FSA) models are used to deter-
mine an applications reaction to both input
and resourcing events.
•
If a job runs on 1 CPU for 5 minutes then
the SLA service will be notified that the
instantaneous measurement of CPU usage
went to 1 at the start and then to 0 five min-
Search WWH ::
Custom Search