Next: Paper
Organization Up:
Introduction Previous: Problem Statement
This paper proposes the Polus
framework that tries to take away the complexity of writing policy mapping code
from human experts and moves it to a combination of reasoning and learning
engines (as shown in Figure 1). The Polus framework addresses the complexity and brittleness
problems described in section 1.1, in the following manner. In Polus, as shown in Figure 2, the
system administrator inputs knowledge in the form of rules of thumb. For
example, ``To invoke Prefetch
action requires memory'', ``Invoke Prefetch
action requires the workload to be Sequential'', ``Prefetch
action improves throughput.'' The generic form of the specification is
(Relationship [Type of relationship]) where the Relationship
is between actions and resources, workload characteristics, system
behavior. The optional Type of relationship gives a hint about
the nature of the relationship (e.g., improves, requires). It should
be noted that the rule-of-thumb specifications do not require the system
administrator to quantify the threshold values for actions, observables,
workload characteristics and resources. In addition, he does not have to
spell-out the details of the action to be invoked for a given state of
resources, workloads, and observables. The relationships defined in the
rule-of-thumb specifications are quantified by the use
of a learning engine. The system management actions, the state of the system
resources/workload characteristics when the a
particular action was taken, and the current values of the observables (e.g.,
throughput, latency, etc.) are monitored and stored as part of the knowledge
base. The learning engine uses this monitored information to predict and
quantify the relationships described in the specifications; for example, ``Prefetching improves throughput when available memory is
greater than 20 percent'', and ``Use prefetching when
Sequential/Random ratio is greater than 0.4.'' It is important to note that the
rule-of-thumb specifications help to prune the number of variables used in the
interpolation function, which in turn helps improve the convergence rate of the
learning function. For example, while interpolating relationships of the prefetch action, the system is not required to take into
account observables related to security. In the current implementation of Polus, the learning engine does not discover additional
relationships (apart from those in the specifications) and also assumes that
the hints in the specifications are correct. In the future, these assumptions
will be addressed using learning approaches such as ``bagging'' [5]. When a
particular QoS goal is violated in the system, the Polus reasoning engine is invoked. The semantics of the
reasoning engine are expressed in first-order predicate calculus and are
similar to the thought-process that is implicit in ECA rules. For example, an
action can be invoked only if the resource required
for its invocation are available in the
current-state
. The current-state
is defined in terms of values of resources, workload characteristics, and
observables. This is expressed in first-order predicate calculus as:
|
|
Using the current-state as input and the
information (i.e., combination of specifications and learning) in the knowledge
base as facts, the reasoning engine derives the actions to be invoked at
run-time. For example, when the reasoning engine tries to invoke the prefetch action the function is
instantiated as
which will be true if
|
|
In this predicate, is unified
with the values that were passed as input to the reasoning engine, and the
information of the prefetch action is retrieved from
the knowledge base. It is important to note that combinations of declarative
specification and predicate calculus (as done in Polus)
are the basis of the well-known field of logic based programming [16,10]. Polus is applying and extending these concepts for the
domain of storage management.
Next: Paper Organization Up:
Introduction Previous:
Problem
Statement