management of Samba4

[James Peach]

On Fri, Jun 03, 2005 at 05:59:09PM +1000, James Peach wrote:
> On Fri, Jun 03, 2005 at 01:10:43PM +1000, Andrew Tridgell wrote:
> > After our discussions in the web server thread, I've been thinking a
> > bit more about the low level details of management and monitoring
> > interfaces in Samba4. 
> > 
> > To try to crystalise things a bit, the specific bits of information I
> > have been trying to work out how to report are:
> > 
> >   - lists connected users
> >   - lists of open files in the ntvfs backends
> >   - counts of packet types in the nbt server
> > 
> > This is only a tiny subset of what we want to be able to report, but
> > its acts as a good basis for thinking about the types of solutions we
> > could use. Each of the 3 bits of information above illustrates a type
> > of problem we need to solve.
> > 
> > The goals I want to meet are:
> > 
> >   - should be easy to add new sources of information in the server
> >     code
> >   - should be accessible from js scripts
> >   - should not reduce performance when not being used
> >   - should work on all our supported platforms
> 
> [snip]
> 
> > So, how can we put together a framework for gathering this type of
> > information while meeting the above goals? I'd like to propose the
> > following:
> > 
> >  - using our smbd messaging layer (the one based on unix domain
> >    datagram messages) as the basic transport. 
> > 
> >  - add a NDR encoded layer on top of this transport
> > 
> >  - use IDL to write the structures that will be accessible, allowing
> >    pidl to generate the marshalling/unmarshalling code for these
> >    structures.
> 
> I like this idea. It will add some latency to a monitoring application,
> but that's probably ok because normal sampling frequencies would be in
> order of seconds.

Hmm .. I'm thinking twice about this now. Say we have 1000 smbds
running. We have a monitoring app that is sampling performance
metrics every second. If one of the values the app is calculating is the
total number of SMB packets, would this require 1000 round trips per
second? If so, what happens when the app needs more metrics?

In this proposal, each time the the app requests a metric, an smbd has
to stop serving clients (briefly) to service the request. A couple of
these now and then wouldn't matter, but regular sampling of large
numbers of metrics or large numbers of smbds might be a problem.  The
cost of sampling the metrics with the scheme is proportional to the
sampling rate and the number of metrics being sampled (O(n^2)??).

If performance metrics are enabled, each smbd will have to gather the
data irrespective of whether any sampling was occurring. This is a
fixed cost, but for simple counters, it's probably not very high. In a
scheme like a shared memory segment or shared mmap, samba does not pay
the cost of sampling the metrics, only the cost of gathering them
(which is a fixed cost however you arrange your metrics).

So I think this proposal will work well for smbstatus-style apps, and I
can imagine building a really useful samba debugger on top of it. I'm
not sure it is suitable for exporting performance statistics, however.

-- 
James Peach | jpeach at sgi.com | SGI Australian Software Group
I don't speak for SGI.