Skip to content

Heuristics

Gabriel Beims Bräscher edited this page Apr 19, 2016 · 6 revisions

Our agents act upon the environment constantly, striving to do the best effort to fulfill the goal of the heuristics that are used by it. Each agent works on clusters of the environment, meaning that they will map migrations among hosts of the same cluster; in the future we intend to extend the architecture to allow the planning of migrations across clusters, but that is not yet developed.

We had developed few heuristics to be tested and used. The heuristics can be configured through a parameter at the ACS interface; the parameter key is "autonomiccs.clustermanager.algorithm". You can change heuristics on the fly, anytime you want. If a heuristic name is invalid or if it is unknown, we use a dummy heuristic that will disable our agent and the environment will work as a normal Apache CloudStack. The heuristics are presented in the next subsections.

Consolidation heuristics

This set of heuristic will try to co-locate as many VMs as possible in the same physical server (considering the over provisioning factors). After the consolidation of VMs, it will try to power off idle hosts of the environment. Whenever the environment is running out of resources, it will activate servers that were deactivated. In order to work this heuristic assumes that hosts of the environment have the wake on LAN (WOL) enabled. Additionally, today this heuristics only works for XenServers/XCP hosts; however, we intend to add support to more hypervisors such as KVM, LXC, and Hyper-V.

We have two different heuristics of this type that can be used:

  • XenServer without high availability (HA) heuristic: this set of heuristic will try to shut down as many hosts as possible. It may even deactivate an entire cluster. However, to work properly this heuristic requires that the XenServer pool HA is not enabled. If your environment is heterogeneous as ours, we provide two different types of this heuristic; one that gives preference to small hosts and other to big hosts; the heuristics names are "br.com.autonomiccs.autonomic.administration.algorithms.impl.ConsolidationScoredPreferenceForSmallHosts" and "br.com.autonomiccs.autonomic.administration.algorithms.impl.ConsolidationScoredPreferenceForBigHosts";

  • XenServer with high availability (HA) heuristic: this set of heuristic assumes that the XenServer pool HA is enabled. Therefore, to avoid Xen fencing, we let a minimum of three (3) servers per cluster active. The name of the heuristic to be used is "br.com.autonomiccs.autonomic.administration.algorithms.impl.ConsolidationXenHaPreferenceForBigHostsHomogeneousEnvironment". When we achieve the number of three (3) servers, the heuristic tries to balance the VM load that is being imposed on the cluster.

Virtual machines dispersion heuristic

This set of heuristic does not deactivate idle servers; in fact, it will try not to let idle servers. It will strive to balance the VMs load among all servers in the cluster that are being dealt with (remember each agent will manage/work on a cluster at time). The dispersion heuristic assumes that clusters of the environment have hosts with the same configuration; that does not mean that hosts across clusters need to have the very same configuration, only hosts in the same cluster. The dispersion heuristic works for clusters that have hosts with different configurations, but in these cases, the results might not be as good as the ones you can get in clusters with hosts that have the same configuration.

Moreover, this heuristic simulates the mapping of VMs using three distinct approaches, striving to find the lower standard deviation (StD) of resource usage among hosts of the cluster; the lower the StD the more similar the load in each host is; e.g. StD equal to zero (0), in this case, every host would have the same load.

The name of the heuristic is "br.com.autonomiccs.autonomic.administration.algorithms.impl.VmsDispersionAlgorithmForHomogeneousEnvironment". This is the default heuristic that is configured and used right after the installation process.

Dummy heuristic

This heuristic has the goal of keeping ACS running without any interference of our plugin. If the admin wants that the plugin stops to migrate VMs, deactivate or activate hosts; e.g. in order to execute some maintenance or debug a problem, this heuristic will ensure that the agents will not act in any cluster.

The name of the heuristic is "br.com.autonomiccs.autonomic.administration.algorithms.impl.ClusterManagementDummyAlgorithm".