[Mauiusers] Moab and Ganglia integration

Dave Jackson jacksond at supercluster.org
Thu Oct 21 12:38:15 MDT 2004


Chris,

  In Doug's defense, he was responding WRT Moab 4.2.0  The FNLIST and
FLAGS resource manager attributes are very recent enhancements and only
available in Moab 4.2.1 and higher.

Sorry for any confusion,
Dave

On Thu, 2004-10-21 at 12:25, Dave Jackson wrote:
> Chris,
> 
>   There are two undocumented features within Moab 4.2.1 which may be of
> interest.  First, you can configure a resource manager as a slave which
> will cause it to only update resources discovered by another resource
> manager.  Second, you can specify the function list the resource manager
> is willing to support.  In the case of ganglia, it is a subtype of the
> native interface and can thus theoretically support all types of job and
> node commands.  However, using the 'FNLIST' attribute, a resource
> manager can be constrained to only using a subset of the available
> functions. i.e.,
> 
> RMCFG[ganglia] FLAGS=slave FNLIST=clusterquery
> 
>   However, in the case of ganglia, you would actually never want to do a
> job query.  We have modified the latest Moab 4.2.1 snapshot to only
> activate the clusterquery function for ganglia based interfaces.
> 
>   Let us know if you would like to test this out.  BTW, Moab Cluster
> Manager 1.2 GA's this week.  You really should try it out.  It is really
> powerful.  If you need any assistance, let us know.
> 
> Dave
> 
> ps.  Are you going to SC?
> 
> On Thu, 2004-10-21 at 09:02, Wightman wrote:
> > Great! We're glad another site has decided to take advantage of multiple 
> > resource managers.
> > 
> > About the second issue, Moab will run the WorkloadQuery function for 
> > each resource manager that it finds configured.  If the WorkloadQuery 
> > function has not been defined then this message still prints out (it 
> > doesn't mean anything really).  We'll put a patch in there to not print 
> > out anything if no function has been defined.
> > 
> > About the second issue, it is not yet possible to confine Moab's search 
> > to only those nodes that are reported on both.  This feature might be 
> > available later, but as of right now, Moab was built with the idea of 
> > allowing multiple resource managers control disjoint resources, with one 
> > coherent view given by Moab.
> > 
> > If you have any recommendations for the documentation (from your 
> > experience) please let us know.
> > 
> > Thanks,
> > 
> > Douglas
> > Cluster Resources, INC.
> > 
> > Chris Samuel wrote:
> > 
> > >Hi folks,
> > >
> > >I've turned on Ganglia in our Moab installation and it seems to work quite 
> > >nicely, it gives us real stats for disk usage finally, as well as spotting 
> > >that three nodes which had recently had motherboards swapped out had not had 
> > >HyperThreading turned off and consequently were reporting 4 cpus's versus 
> > >PBS's config of 2!
> > >
> > >Two questions though:
> > >
> > >1) Is it possible to confine Moab to only take notice of those nodes that are 
> > >found through both the PBS and Ganglia RM's ?
> > >
> > >Our Ganglia information includes head, storage and management nodes which we'd 
> > >prefer Moab to ignore.
> > >
> > >
> > >2) Moab is complaining about not being able to get the workload's through 
> > >Ganglia, diagnose -R says:
> > >
> > >RM[ganglia]  type: 'NATIVE'  state: 'Active'
> > >  Cluster Query URL: 'ganglia://'
> > >  Flags: 'typeIsExplicit'
> > >  P[0]: Host: ''  Port: 8649
> > >  Event Management:  (event interface disabled)
> > >  RM Performance:  Avg Time: 0.92s  Max Time:  3.13s  (502 samples)
> > >
> > >RM[ganglia] Failures:
> > >  Thu Oct 21 16:30:27  workloadquery    'cannot get workload info' (251 of 251 
> > >failed)  (etc etc)
> > >
> > >Is this something that is expected to be injected into Ganglia through 
> > >Gmetric, or are we too far behind with our version of Ganglia (2.5.4) ?
> > >
> > >cheers!
> > >Chris
> > >  
> > >
> > >------------------------------------------------------------------------
> > >
> > >_______________________________________________
> > >mauiusers mailing list
> > >mauiusers at supercluster.org
> > >http://supercluster.org/mailman/listinfo/mauiusers
> > >  
> > >
> > 
> > _______________________________________________
> > mauiusers mailing list
> > mauiusers at supercluster.org
> > http://supercluster.org/mailman/listinfo/mauiusers
> 
> _______________________________________________
> mauiusers mailing list
> mauiusers at supercluster.org
> http://supercluster.org/mailman/listinfo/mauiusers



More information about the mauiusers mailing list