Creating user accounts....

[Srihari Angaluri]

So, is BeoNSS a replacement to NIS, or is it on top of NIS? How are you
able to solve the problem of saturating the network or overloading a
single server (as in the case of NIS) exactly? Do you have replicated
services over the network? Or, is there a hierarchical scheme of naming
users in the network, so that the authentications are handled as name
resolutions like in the case of DNS?

"Using BeoNSS, compute nodes only need know about the users that are
actively running jobs. They
don't keep any persistant configuration that might be outdated. Only the
master needs the full user list."

How is it different from NIS? In case of NIS, as I understand it,
whenever a compute node needs to authenticate a particular user, it will
contact the NIS server, correct? So, where is the point of (or advantage
of) maintaining a "partial user list"? 

Thank you,
Srihari

> -----Original Message-----
> From: Donald Becker [mailto:becker at scyld.com] 
> Sent: Friday, February 14, 2003 11:47 AM
> To: Srihari Angaluri
> Cc: 'RANGI, JAI'; 'Jeffrey B. Layton'; Beowulf List; 
> scyld-users at beowulf.org
> Subject: RE: Creating user accounts....
> 
> 
> On Thu, 13 Feb 2003, Srihari Angaluri wrote:
> 
> > Is there any serious performance/scalability issue to using NIS,
> 
> Yes.  A difference between a clusters and a collection of workstations
> is that a cluster-wide job will cause all nodes to be active at once.
> Rather than getting scattered name service requests, all requests will
> arrive at once.  More than about 25 clients will cause a NIS server to
> drop requests, and even in the best case you end up with a 
> serialization
> point and slow-downs.
> 
> The current practice is changing the name system, both implementation
> and administrative model, to match each installion.
>     - People use NIS when there is a rapidly changing user base
>     - explicitly copy files when there is a small user and 
> node set, or
>     - synchronize, large mostly-static files with 'rsync'.
> 
> The file approach is typically implemented with ad hoc scripts, which
> work well for the people that wrote the scripts but make it 
> difficult to
> trace an error to the change that caused the error.
> 
> We developed BeoNSS, a cluster nameservice, to address the
> administration and scaling problems.  The advantage of our 
> BeoNSS system
> is that it 
>     - Scales very well
>     - Uses an unchanged administrative model
>     - Allows a single point of administration
>        (add users on just the master),
>     - May be extended to support multiple administrative domains
>        (each master sharing a cluster might have their own user list).
> 
> > as
> > opposed to copying the individual files to each and every 
> node on the
> > cluster? Is this even a desirable option for large clusters, for
> > example? What if I need to add more accounts?
> 
> You missed a big one: what about machines that are down or
> non-responsive (!) when you update?
> 
> If you are willing to deal with more complexity and 
> administration, copying
> files to cluster nodes with full installs will result in good scaling,
> but... then you have administration issues.
> 
> We designed our architecture on the following principle: compute nodes
> exist to perform computations for a master.  Using BeoNSS, 
> compute nodes
> only need know about the users that are actively running jobs.  They
> don't keep any persistant configuration that might be outdated.  Only
> the master needs the full user list.
> 
> Look at this from end-goal perspective: there shouldn't be an
> administrative change or a compute node performance difference between
> the master having 10 users, having 10,000 users, or 
> supporting arbitrary
> job submission from an even larger user base.  We still have to try to
> keep UIDs less that 32767 but that's a compatibility issue with
> old-style 16 bit UIDs, not a design limit.
> 
> -- 
> Donald Becker				becker at scyld.com
> Scyld Computing Corporation		http://www.scyld.com
> 410 Severn Ave. Suite 210		Scyld Beowulf cluster system
> Annapolis MD 21403			410-990-9993
>