Polus Framework Details of the Polus Details of the Polus

Polus Terminology

Before describing the system model, we define the terms behavior, goals and actions. In Polus, behavior is a defined as a set of QoS dimensions such as $\{throughput, latency, availability, reliability\}$. These dimensions are also referred to as observables. Goals are defined as threshold values on behavior dimensions. e.g. response-time for reads should less than 5 sec, a client's average throughput should be 150 MBps etc. The definition of actions is domain-specific. In Polus, the actions are divided into two categories: a) tunable parameters i.e., changing the value of configuration parameters such a prefetch size, clean-delay, etc., and b) internal actions such as migration, replication, and back-up of data. The model of the system is shown in figure 4. It consists of two key entities: the management software and the managed system. The management software is assigned QoS goals and is responsible for ensuring that the managed system meets these goals. The interaction between the management software and the managed system is via sensors and actuators. Monitors gather information about the managed system, while the actuators effect the actions invoked by the management software on the managed system. The managed system consists of physical components that interact to service the application requests. The components service the requests in a particular sequence, with each component processing the information before handing it to the next component. For example, within a SAN file system, the components are client machines, metadata servers, storage controllers and disks. A component has pre-defined properties such as the maximum number of requests that it can service, the error rate, the average down-time etc. Each component consists of one of more atomic entities referred to as resources. In other words, resources serve as an abstraction to refer to components in a generic fashion. In Polus, the possible resources are memory, CPU, network, and storage. For example, the storage controller component consists of memory and storage resources, the client machine component consists of CPU, memory and network resource. Sensors collects information about the state of the managed system. The state of the system is defined as a quadruple $S,\:R_{current},\:IP,\:B_{current}$, defined as follows:

• $Workload\; Characteristics$$(S)$: $S$is represented as set of measurable parameters that characterize the application requests. These characteristics are dynamic and constantly changing. For example, in a storage system, typical dimensions are the read/write ratio of access requests, the access pattern (sequential/random), and block size of requests.
• $R_{current}$: Represents the current usage of the resources on a per component basis.
• $Invocation\:Path$$(IP)$: Represents the sequence in which the components are invoked while servicing the application requests. For example, client machine $\rightarrow$storage controller 2 $\rightarrow$LUN 8 represents a possible invocation path
• $B_{current}$: Represents the current values of the behavior dimensions.

Actuators invoke the actions selected by the management software. The impact of invoking an action is not constant and is a function of the $state$. Furthermore, whether an action can be invoked or not is dependent on the $state$(i.e. not all actions are applicable within a particular $state$).

Figure 4: System model (R: Resource)

Polus Framework Details of the Polus Details of the Polus