Hi, reading this document it is not fully clear to me how this tool is supposed to work. Will it be a command line tool which can be run by cron (or by hand) or will this tool be a daemon working in the background?
If run as daemon i would suggest to add a parameter how aggressive or how conservative this daemon should do it's work. Simple scenario: You power down an instance because you would like to do a short maintenance (of lets say 2min). If hsqzeeze is run as daemon in an aggresive mode it might now power down the corresponding node. Powerdown and powerup might take longer than your 2min maintenance. Also you will need to handle the case that you have too less resources to power on an instance in your cluster. Shall gnt-instance start then notify hsqueeze to provide more resources and to power on a node? Just my 2ยข, Martin On Tue Oct 08, 2013 at 13:38:45 +0200, Klaus Aehlig wrote: > This design document describes a new htool, hsqueeze, to > be used to move the externally-mirrored instances in such a > way that as few nodes as possible host instances at all. > > Signed-off-by: Klaus Aehlig <[email protected]> > --- > Makefile.am | 1 + > doc/design-draft.rst | 1 + > doc/design-hsqueeze.rst | 70 > +++++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 72 insertions(+) > create mode 100644 doc/design-hsqueeze.rst > > diff --git a/Makefile.am b/Makefile.am > index bd6872e..b0677e1 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -538,6 +538,7 @@ docinput = \ > doc/design-hroller.rst \ > doc/design-storagetypes.rst \ > doc/design-upgrade.rst \ > + doc/design-hsqueeze.rst \ > doc/devnotes.rst \ > doc/glossary.rst \ > doc/hooks.rst \ > diff --git a/doc/design-draft.rst b/doc/design-draft.rst > index 4c9893a..8eee725 100644 > --- a/doc/design-draft.rst > +++ b/doc/design-draft.rst > @@ -23,6 +23,7 @@ Design document drafts > design-ceph-ganeti-support.rst > design-upgrade.rst > design-daemons.rst > + design-hsqueeze.rst > > .. vim: set textwidth=72 : > .. Local Variables: > diff --git a/doc/design-hsqueeze.rst b/doc/design-hsqueeze.rst > new file mode 100644 > index 0000000..d403314 > --- /dev/null > +++ b/doc/design-hsqueeze.rst > @@ -0,0 +1,70 @@ > +============= > +HSqueeze tool > +============= > + > +.. contents:: :depth: 4 > + > +This is a design document detailing the node-freeing scheduler, HSqueeze. > + > + > +Current state and shortcomings > +============================== > + > +Externally-mirrored instances can be moved between nodes at low > +cost. Therefore, it is attractive to free up nodes and power them down > +at times of low usage, even for small periods of time, like nights or > +weekends. > + > +Currently, the best way find out a suitable set of nodes to shut down > +is to use the property of our balancedness metric to move instances > +away from drained nodes. So, one would manually drain more and more > +nodes and see, if `hbal` could find a solution freeing up all those > +drained nodes. > + > + > +Proposed changes > +================ > + > +We propose the addition of a new htool, called `hsqueeze`, to > +automatically free up as many nodes as possible. By default, only > +externally-mirrored instances are moved, but an option is provided to > +additionally take DRBD instances (which can be moved without > +downtimes), or even all instances into consideration. > + > +Computation of the set to free up > +--------------------------------- > + > +To determine which nodes can be freed up, `hsqueeze` basically > +follows the same algorithm as the manual process. It greedily goes > +through all non-master nodes and tries if the algorithm used by `hbal` > +would find a solution (with the appropriate move restriction) that > +frees up the extended set of nodes to be drained. > + > +Instance moves and execution > +---------------------------- > + > +Once the final set of nodes is determined, the instance moves are > +determined by the same algorithm as `hbal` does. If requested by the > +`-X` option, the nodes freed up are drained, and the instance moves > +are executed in the same way as `hbal` does. Finally, the nodes are > +powered down via the :doc:`design-oob`. > + > + > +Design choices > +============== > + > +The proposed algorithm build on top of the already present balancing > +algorithm, instead of greedily packing nodes as full as possible. The > +reason is, that in the end, a balanced cluster is needed anyway; > +therefore, basing on the balancing algorithm reduces the number of > +instance moves. Additionally, in that way, the final configuration can > +benefit from all improvements to the balancing algorithm, like taking > +dynamic CPU data into account. > + > +We decided to have a separate program instead of adding an option to > +`hbal` to keep the interfaces, especially of `hbal`, cleaner. It is > +not unlikely that, over time, additional `hsqueeze`-specific options > +might be added, specifying, e.g., which nodes to prefer for > +shutdown. With the approach of the `htools` of having a single binary > +showing different behaviors, having an additional program also does not > +introduce significant additional cost. > -- > 1.8.4 > > > -- Martin Zobel-Helas <[email protected]> Debian System Administrator Debian & GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B
