By Default Rio creates watches for depletion oriented compute resource capabilities. The current system watches include:
The diagram below illustrates the interactions between the components involved with monitoring, registration and notification of system properties:
The area constrained by the ---- boundary indicates the Rio ComputeResource. The ComputeResource represents an abstract notion of a compute resource that offers computational resources that can be measured, and which correlate to qualitative and quantitative capabilities.
The ComputeResource creates (and updates) a ResourceCapability object when it registers for availability to discovered Provision Monitor instances. This allows the Provisioner to match service requirements to compute resource capabilities.
For each MeasurableCapability, there is a corresponding MeasurableMonitor. The MeasurableMonitor provides platform specific monitoring of the compute resource attribute being observed.
Rio uses Hyperic SIGAR to assist with the collection of system monitoring.
Hyperic SIGAR is licensed under the GPL with a FLOSS license exception,
allowing it to be included with the Rio Apache License v2 distribution.
If for some reason the GPL cannot be used with your distribution of Rio,
remove the RIO_HOME/lib/hyperic directory.
If a service has declared SLA requirements that include one of the monitored system resources, the wiring up of the service's corresponding SLAPolicyHandler is handled by the Cybernode.
Since the MeasurableCapability is a Watch (it extends the PeriodicWatch), a ThresholdManager registers for the notification of out of bound values. For example, if memory utilization goes beyond the declared threshold of 90%, the associated SLAPolicyHandler is invoked and it takes action. Based on the 'type' of policy handler you choose will determine if the SLAPolicyHandler invokes methods on the Provision Monitor, having it increment, decrement, relocate (or take other action).
Examples of declaring SLAs for system watches follow:
systemRequirements {
utilization id:'CPU', high:0.8
}
This example shows how you can declare that the service will not be allocate to a compute resource whose CPU utilization is greater then 80%. Similar declaration can be made for 'Memory and 'DiskSpace'.
systemRequirements {
utilization id:'CPU', high:0.8
}
This example shows how you can declare that the service will scale up if CPU utilization exceeds 80% (to a max of 3 services), and scale down if CPU utilization drops below 20%.
The upper and lower 'dampeners' are properties that allow the scaling policy handlers to avoid values that oscillate across an upper or lower boundary. In this case, scaling behavior (increment or decrement) will only take place if the threshold condition is still an issue 3 seconds after the threshold has been breached. If the threshold has been cleared (falls back within acceptable range), then the increment or decrement action will not take place.