[Engine-devel] SPM Priority Design - Wiki Page

[Andrew Cathrow]

----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Andrew Cathrow" <acathrow at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, December 29, 2011 9:47:24 AM
> Subject: Re: [Engine-devel] SPM Priority Design - Wiki Page
> 
> On 12/29/2011 04:34 PM, Andrew Cathrow wrote:
> >
> > ----- Original Message -----
> >> From: "Itamar Heim"<iheim at redhat.com>
> >> To: "Miki Kenneth"<mkenneth at redhat.com>
> >> Cc: engine-devel at ovirt.org
> >> Sent: Thursday, December 29, 2011 5:41:41 AM
> >> Subject: Re: [Engine-devel] SPM Priority Design - Wiki Page
> >>
> >> On 12/27/2011 05:22 PM, Miki Kenneth wrote:
> >>> Few points:
> >>> - From requirement perspective - 0-10 scale is OK too.
> >>> - There is an RFE to allow manual SPM selection, let's make sure
> >>> that we clarify how we do that in the scenarios.
> >>> - There is a case were all Hosts are set as "no SPM" (-1), user
> >>> should be notify (on the last host?)
> > I don't agree with/understand the requirements
> > <snip>
> > - Enable setting a priority between -1 and 100 for a host (100 is
> > the highest, -1 means never to choose this host).
> > - When SPM selection process takes place, use the SPM priority to
> > select an SPM.
> > - Default for upgrading ovirt will be 50.
> > </snip>
> >
> > Here we are asking the user to define priorities for the SPM
> > selection. A user should be able to influence the selection but
> > the actual choice should come down to runtime status.
> > If Host A us running 100 VMs and host B is running 50 then it seems
> > more efficient for B to be the SPM rather than A
> > If Host C has multiple storage paths to the LUN then it seems a
> > better fit than host B that has only one path.
> >
> > We need to step back and review the requirements here.
> >
> > Today SPM selection is random, that certainly needs to change but a
> > user defining priorities is overly complex and won't solve the
> > runtime selection issue.
> >
> > We need to start by defining an algorithm for selecting the SPM
> > independent of user input.
> > At selection time I'd suggest that we at least need to consider
> > number of paths to the storage (for block based) number of VMs on
> > that host, perhaps #cores?
> 
> Paths to which storage domain? the master? all? on average?
> Do you prefer 2x10Gb iSCSI connection, or 4x1Gb?
> 
> - What about available bandwidth to the storage (assuming it may be
> capped and compete with VM IO traffic) ?
> - Latency?

Yep, exactly - we need to use these kind of inputs into the algorithm and these can change hence the need to do this more dynamically rather than user selection which is invariably wrong.

> 
> > Perhaps we should dynamically create a score for a host that takes
> > these factors into account, each may get higher rating - eg. maybe
> > # storage paths is more important that # cores ?
> 
> This is why I've suggested High(8)-Med(5)-Low(2) and add dynamically
> the
> system scoring, with whatever params we get to eventually. 'Never'
> could
> be 0, 'Always' could be '10'.

Yep, the big change that I'm suggesting is that these scores are only an input to the algorithm not the whole basis for selection.


> Y.
> 
> >
> >
> > On top of this we can add some user defined preference that plays
> > into the score. For example a user can say "this host can NEVER be
> > an SPM" or can set a preference - eg. "Preferred SPM" or perhaps
> > even "always SPM"
> >
> > This algorithm would apply for automated selection of SPMs but a
> > user should be allowed to override this and at runtime say "make
> > this node the SPM now"
> >
> >
> >
> >> SPM is DC level, not cluster level.
> >>
> >>> - Need to be able to view in the GUI:
> >>>     - the SPM priority for all Hosts, on the GRID?
> >> isn't this cluttering the hosts grid? general subtab maybe?
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
>