Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!dali.cs.montana.edu!milton!uw-beaver!cornell!tclark
From: tclark@honir.cs.cornell.edu (Timothy Clark)
Newsgroups: comp.sys.isis
Subject: Network Manager man pages
Message-ID: <50859@cornell.UUCP>
Date: 17 Jan 91 19:05:14 GMT
Sender: nobody@cornell.UUCP
Reply-To: tclark@cs.cornell.edu (Timothy Clark)
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 107

.TH NMGR 1  "14 December 1990" NMGR "ISIS COMMANDS"
.SH NAME
nmgr \- ISIS Network Manager Program.
.SH SYNOPSIS
.B nmgr [isis_portnumber]
.SH DESCRIPTION
The
.I nmgr
program is an ISIS server-based application which manages idle or 
lightly-loaded machines on the network.  The application actually
consists of three parts: the 
.I nmgr 
server application; the remote stub
application,
.IR netclient (1);
and the user interface,
.IR reserve (1).
The 
.I nmgr
server program manages a database of "registered" machines and 
services.  Remote machines are registered by running the remote stub 
program,
.IR netclient ,
which connects to the nmgr when the remote machine is available to
run services (see
.I netclient
for details).  Once connected (registered), the nmgr is free 
to send requests for remote execution to that machine.  Requests for 
resources or services are generated via the user interface commands,
.IR reserve 
and
.IR net_exec .
.PP
As for most other ISIS utilities, the ISIS portnumber to  use may be
specified as an option; if not specified, the port number will be
determined by first checking for the environment variable ISISPORT and, if
that is not specified, by a lookup in the /etc/services file.

.PP
When the nmgr
is run, it starts by reading an initialization file,
.IR nmgr.sites (5),
which contains the udp port number for the nmgr to use 
in it's communication with remote stubs.
Lines in this file have the format

  hostname port-no

where the hostname is normally the short-name for the host (the one
returned by the gethostname(3) system call).
The manager then reads in a second file, 
.IR nmgr.rc (5),
which it uses to initialize an in-core database of machine
and service types.  
.IR nmgr.rc
is a command script that can be changed by the user
to customize the network resource manager to
the types of equipment and services that 
commonly run in your environment.

The notion of a service is relevant primarily to ISIS programmers,
and corresponds loosely to an ISIS process group.
In an environment where a set of fault-tolerant services are needed
(either at all times, or on demand), the network manager can be
programmed to know how to pick machines on which to run server
instances and when to do so.

Users working through the UNIX commands
.IR reserve(1)
and
.IR net_exec(1)
would normally NOT be concerned with ISIS-based applications.
From the perspective of these users, the nmgr is primarily a
machine reservation service, scheduling a set of users onto a
set of machines in a way that balances load as fairly as possible,
and later providing interfaces for monitoring and (if necessary)
stopping remote programs that exhibit undesired behaviors.


A powerful feature of the network manager is that
the attribute sets used to select processors are arbitrarily extensible.
For example, an installation running a package called "mathlab" but
only has licenses for certain machines might use this attribute as
a machine selection criteria when running programs that depend on
mathlab features.  Even though the network manager doesn't have
any built-in notion of mathlab or how its licenses work, the utility
can easily be configured \fIby the user\fR to keep track of the
machines which have this license and to assign these programs only to
suitable machines.
Similarly, new resource types and (for ISIS users)
services can be defined dynamically, through the
.IR netclient.rc
file
and 
.IR nmgr.rc
file.
The format used in these files is documented in nmgr.rc(5).

.PP
The nmgr program is normally replicated on several
independent machines for 
fault\-tolerance.  In such cases, work is shared among the machines
in a uniform way.  Any nmgr failures are completely masked from
users, provided of course that at least one copy survives.

.SH "SEE ALSO"
netclient(1), reserve(1), nmgr_command(3), nmgr.rc(5), nmgr.sites(5)