29 Dec
2011
29 Dec
'11
3:51 p.m.
----- Original Message ----- > From: "Yaniv Kaul" <ykaul@redhat.com> > To: "Andrew Cathrow" <acathrow@redhat.com> > Cc: engine-devel@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@redhat.com> > >> To: "Miki Kenneth"<mkenneth@redhat.com> > >> Cc: engine-devel@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@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > >