Available Plugins¶

airflow_optimization¶

AirflowOptimization

This goal is used to optimize the airflow within a cloud infrastructure.

cluster_maintaining¶

ClusterMaintenance

This goal is used to maintain compute nodes without having the user’s application being interrupted.

dummy¶

Dummy

Reserved goal that is used for testing purposes.

hardware_maintenance¶

HardwareMaintenance

This goal is to migrate instances and volumes on a set of compute nodes and storage from nodes under maintenance

noisy_neighbor¶

NoisyNeighborOptimization

This goal is used to identify and migrate a Noisy Neighbor - a low priority VM that negatively affects performance of a high priority VM in terms of IPC by over utilizing Last Level Cache.

saving_energy¶

SavingEnergy

This goal is used to reduce power consumption within a data center.

server_consolidation¶

ServerConsolidation

This goal is for efficient usage of compute server resources in order to reduce the total number of servers.

thermal_optimization¶

ThermalOptimization

This goal is used to balance the temperature across different servers.

unclassified¶

Unclassified

This goal is used to ease the development process of a strategy. Containing no actual indicator specification, this goal can be used whenever a strategy has yet to be formally associated with an existing goal. If the goal achieve has been identified but there is no available implementation, this Goal can also be used as a transitional stage.

workload_balancing¶

WorkloadBalancing

This goal is used to evenly distribute workloads across different servers.

dummy_scorer¶

Sample Scoring Engine implementing simplified workload classification.

Typically a scoring engine would be implemented using machine learning techniques. For example, for workload classification problem the solution could consist of the following steps:

1. Define a problem to solve: we want to detect the workload on the machine based on the collected metrics like power consumption, temperature, CPU load, memory usage, disk usage, network usage, etc.
2. The workloads could be predefined, e.g. IDLE, CPU-INTENSIVE, MEMORY-INTENSIVE, IO-BOUND, … Or we could let the ML algorithm to find the workloads based on the learning data provided. The decision here leads to learning algorithm used (supervised vs. non-supervised learning).
3. Collect metrics from sample servers (learning data).
4. Define the analytical model, pick ML framework and algorithm.
5. Apply learning data to the data model. Once taught, the data model becomes a scoring engine and can start doing predictions or classifications.
6. Wrap up the scoring engine with the class like this one, so it has a standard interface and can be used inside Watcher.

This class is a greatly very simplified version of the above model. The goal is to provide an example how such class could be implemented and used in Watcher, without adding additional dependencies like machine learning frameworks (which can be quite heavy) or over-complicating it’s internal implementation, which can distract from looking at the overall picture.

That said, this class implements a workload classification “manually” (in plain python code) and is not intended to be used in production.

dummy_scoring_container¶

Sample Scoring Engine container returning a list of scoring engines.

Please note that it can be used in dynamic scenarios and the returned list might return instances based on some external configuration (e.g. in database). In order for these scoring engines to become discoverable in Watcher API and Watcher CLI, a database re-sync is required. It can be executed using watcher-sync tool for example.

weight¶

Weight planner implementation

This implementation builds actions with parents in accordance with weights. Set of actions having a higher weight will be scheduled before the other ones. There are two config options to configure: action_weights and parallelization.

Limitations

• This planner requires to have action_weights and parallelization configs tuned well.