Commit a39eb306 authored by Alessio Netti's avatar Alessio Netti

Analytics: documentation for the Cooling Control plugin

parent bf8397b2
......@@ -29,6 +29,7 @@
7. [Tester Plugin](#testerPlugin)
4. [Sink Plugins](#sinkplugins)
1. [File Sink Plugin](#filesinkPlugin)
2. [Cooling Control Plugin](#coolingcontrolPlugin)
5. [Writing Plugins](#writingPlugins)
### Additional Resources
......@@ -981,6 +982,42 @@ Additionally, input sensors in sinks accept the following parameters:
|:----- |:----------- |
| path | The path to which the sensors's readings should be written. It is interpreted as described above for the _autoName_ attribute.
## Cooling Control Plugin <a name="coolingcontrolPlugin"></a>
The _Cooling Control_ plugin enables proactive control of the inlet temperature in a warm-water cooling system using the SNMP protocol. Its logic is simple: at each computation interval, operators fetch as input temperature readings for a set of sensors, as specified in the configuration.
Then, for each sensor, an operator establishes if the associated temperature is above a certain _hotThreshold_ value, in which case the sensor is flagged as _hot_. If the percentage of hot sensors is higher than a _hotPercentage_ value, the operator proceeds to decrease the inlet temperature. Otherwise, it increases it.
The plugin provides two different possible cooling strategies:
* _continuous_: at each computation interval the operator sets a new inlet temperature value. The more sensors are flagged as hot in comparison to _hotPercentage_, the steeper the decrease in temperature - conversely, the increase in temperature will be stronger if just a minimal amount of nodes is flagged as hot.
* _stepped_: this strategy functions similarly to _continuous_, with a more conservative approach. The main difference is that the space of possible inlet temperature settings is not continuous, but rather separated in evenly-spaced bins: the new inlet temperature setting is applied via SNMP only upon crossing boundaries between bins, and otherwise it is simply stored locally.
Operators in this plugin cannot have any output sensors. The operators themselves provide the following configuration parameters:
| Value | Explanation |
|:----- |:----------- |
| window | Length in milliseconds of the time window that is used to query temperature sensors. In order for a sensor to be flagged as _hot_, all of the readings in the time window must be above _hotThreshold_. Defaults to 0.
| hotPercentage | Percentage of sensors (from 0 to 100) to be flagged as _hot_ in order to trigger a decrease in the inlet temperature. Defaults to 20.
| minTemperature | Minimum allowed value to be set as inlet temperature. The scale must be appropriate for the corresponding SNMP sensor. Defaults to 350.
| maxTemperature | Maximum allowed value to be set as inlet temperature. Defaults to 450.
| bins | Number of bins in which the (_minTemperature_, _maxTemperature_)range is divided when using the _stepped_ strategy. Defaults to 4.
| strategy | Cooling strategy to be used. Can either be _continuous_ or _stepped_. Defaults to _stepped_.
| OIDPrefix | OID prefix of the SNMP sensor that can be used to control the inlet temperature.
| OIDSuffix | OID suffix of the SNMP sensor that can be used to control the inlet temperature.
Cooling Control operators additionally support all of the configuration parameters available in the _dcdbpusher_ SNMP plugin in order to set up connections to SNMP hosts. In particular, these are _Host_, _Community_, _Version_, _Username_, _SecLevel_, _AuthProto_, _PrivProto_, _AuthKey_ and _PrivKey_.
Sensors in the Cooling Control plugin support the following parameters:
| Value | Explanation |
|:----- |:----------- |
| hotThreshold | Threshold value for the sensor to be considered _hot_. It must have the same scale as the readings of the sensor itself. Defaults to 70.
Finally, the plugin supports the following REST API actions:
| Action | Explanation |
|:----- |:----------- |
| status | Displays the temperature settings currently in use, as well as the cooling strategy.
# Writing Wintermute Plugins <a name="writingPlugins"></a>
Generating a DCDB Wintermute plugin requires implementing a _Operator_ and _Configurator_ class which contain all logic
tied to the specific plugin. Such classes should be derived from _OperatorTemplate_ and _OperatorConfiguratorTemplate_
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment