[Pacemaker] Making Virtual Domain utilization dynamic

[Andrew Beekhof]

On 02/05/2013, at 5:25 PM, Michael Schwartzkopff <misch at clusterbau.com> wrote:

> Am Donnerstag, 2. Mai 2013, 17:08:25 schrieb Andrew Beekhof:
> > On 02/05/2013, at 5:03 PM, Michael Schwartzkopff <misch at clusterbau.com> wrote:
> > > Am Donnerstag, 2. Mai 2013, 16:56:19 schrieb Andrew Beekhof:
> > > > On 02/05/2013, at 4:43 PM, Michael Schwartzkopff <misch at clusterbau.com> wrote:
> > > > > Am Freitag, 26. April 2013, 22:14:59 schrieb Michael Schwartzkopff:
> > > > > > Hi,
> > > > > > 
> > > > > > I picked up my old idea to make resouce utilizations dymanic and
> > > > > > wrote
> > > > > > the
> > > > > > little patch for VirtualDomain to check CPU utilization every time
> > > > > > the
> > > > > > VirtualDomain is monitored:
> > > > > > 
> > > > > > --- /usr/lib/ocf/resource.d/heartbeat/VirtualDomain     2013-01-06
> > > > > > 23:50:54.000000000 +0100
> > > > > > +++ /usr/lib/ocf/resource.d/misch/VirtualDomain 2013-04-26
> > > > > > 22:09:18.377784406 +0200
> > > > > > @@ -404,6 +404,12 @@
> > > > > > 
> > > > > >             fi
> > > > > >         
> > > > > >         done
> > > > > >      
> > > > > >      fi
> > > > > > 
> > > > > > +
> > > > > > +    if [ -x /usr/bin/virt-top ]; then
> > > > > > +      CPU_TICKS=$(/usr/bin/virt-top -n 2 -d 5 --stream | grep
> > > > > > $DOMAIN_NAME
> > > > > > 
> > > > > > | tail -1 | awk '{printf "%.0f",$7}')
> > > > > > 
> > > > > > +      /usr/sbin/crm_resource -r $OCF_RESOURCE_INSTANCE -z -p ticks
> > > > > > -v
> > > > > > $CPU_TICKS
> > > > > > +    fi
> > > > > > +
> > > > > > 
> > > > > >      return ${rc}
> > > > > >  
> > > > > >  }
> > > > > > 
> > > > > > I choose the measure CPU ticks since it is more granular than plain
> > > > > > CPU
> > > > > > usage.
> > > > > > 
> > > > > > With this patch pacemaker updates the utilization of the resource
> > > > > > every
> > > > > > time it monitors the resource. Together with the
> > > > > > placement-strategy="minimal" and live-migration you could do very
> > > > > > cool
> > > > > > things.
> > > > > > 
> > > > > > Especially if you think about an extended fencing system that is
> > > > > > able to
> > > > > > switch off unused nodes and turn on node as needed.
> > > > > > 
> > > > > > Comments are welcome.
> > > > > 
> > > > > No comments?
> > > > 
> > > > Seems reasonable to me, though you'd probably want to have it controller
> > > > by
> > > > a new resource parameter.
> > > 
> > > Why?
> > 
> > Because presumably not everyone is using or wants to use utilisation.
>  
> Ehm. I though utilizations were introduced to provide exactly this feature.

Yes, but not everyone has a need for it to be always on.
And in this situation, they might object to strange values being stored into the cib after every monitor action.

> But I could add a boolean parameter UTIL_DYN to check if the admin of that resource wants this utilization made dynamic or fixed.
>  
> > > I think utilizations are the right thing to control dynamically. Nodes
> > > provide fix utilizations (i.e. CPUs and RAM) and resources consume it.
> > > The real demand is measured dynamically and the cluster manager can react
> > > on different load situations moving resources to "empty" nodes.
> > > 
> > > As a first test is used CPU_TICKS (i.e. 1/100 of seconds) with this unit
> > > you can tune the resource consumation more detailed.
> > > 
> > > The only problem: Can utilizations be changed using the hysteresis of
> > > attrd_update?
> > I don't understand the question... I don't think attrd is involved.
>  
> Yes. Up to not it is not involved. But I'd like to use the hysteresis feature of the attrd_updater. Is is possible to change utilizations with the attrd_updater?
>  
> Greetings,
>  
> -- 
> Dr. Michael Schwartzkopff
> Guardinistr. 63
> 81375 München
>  
> Tel: (0163) 172 50 98
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org