Update of /cvsroot/ssic-linux/web/frags/docs
In directory sc8-pr-cvs1:/tmp/cvs-serv24948/frags/docs
Modified Files:
intro.html
Log Message:
Changes from Bruce
Index: intro.html
===================================================================
RCS file: /cvsroot/ssic-linux/web/frags/docs/intro.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** intro.html 12 Nov 2003 23:16:44 -0000 1.1
--- intro.html 17 Jan 2004 08:04:40 -0000 1.2
***************
*** 1,5 ****
<pre>
Introduction to the SSI Cluster
! Release 0.9.96 for RH9
I: Overview
--- 1,5 ----
<pre>
Introduction to the SSI Cluster
! Release 1.0.0 for RH9
I: Overview
***************
*** 8,20 ****
IV: /dev and devices
V: Filesystems
! Va: NFS client and NFS server
! VI: Swap
! VII: /proc and cluster process model
! VIII: Networking model and CVIP (cluster virtual IP, cluster alias)
! IX: Inter-process communication (IPC)
! X: Added and changed commands/utilities
! XI: HPTC Middleware
! XII: libcluster, cluster.h and programming
! XIII: System Management
--- 8,21 ----
IV: /dev and devices
V: Filesystems
! VI: NFS client and NFS server
! VII: Swap
! VIII: /proc and cluster process model
! IX: Networking model and CVIP (cluster virtual IP, cluster alias)
! X: Load balancing
! XI: Inter-process communication (IPC)
! XII: Added and changed commands/utilities
! XIII: HPTC Middleware
! XIV: libcluster, cluster.h and programming
! XV: System Management
***************
*** 41,53 ****
the nodes but the non-process part of /proc is showing local information
(e.g. cpuinfo, meminfo, etc.).
! The networking model has 2 parts to it.
! First, each node has one or more addresses that are only locally visible.
! One address is used for kernel-to-kernel communication to support the SSI.
! That address can also be used for MPI or other cross-node application
! communication.
! Second, to make the cluster look like a single, highly available
machine, there is a CVIP, or cluster alias. This address is on an external
network and is an alias on the external network card. This CVIP fails over
to another card on another node if the first node leaves the cluster.
All inter-process communication (IPC) is nameable clusterwide and is
shared clusterwide. This means there is one namespace for semaphores,
--- 42,58 ----
the nodes but the non-process part of /proc is showing local information
(e.g. cpuinfo, meminfo, etc.).
!
! The networking model has 2 parts to it. First, each node has one or more
! addresses that are only locally visible. One address is used for
! kernel-to-kernel communication to support the SSI. That address can
! also be used for MPI or other cross-node application communication.
! Second, to make the cluster look like a single, highly available
machine, there is a CVIP, or cluster alias. This address is on an external
network and is an alias on the external network card. This CVIP fails over
to another card on another node if the first node leaves the cluster.
+ There are two forms of load balancing built into the system. First,
+ incoming network connections can be load balanced using the HA-LVS
+ capability. Processes can be load balanced through the load leveling
+ subsystem, which does exec-time load leveling and process migration.
All inter-process communication (IPC) is nameable clusterwide and is
shared clusterwide. This means there is one namespace for semaphores,
***************
*** 61,70 ****
control load levelling (loads, loadlevel) and a command to run other programs
in a "localview" mode (localview - more on this in the process management and
! IPC sections below).
Many of the opensource HPTC middleware has been run on the SSI cluster,
along with some purchasable capabilities. The list of things tested
include MPICH, LAMPI, HP MPI, openPBS, ScalablePBS, SLURM, ganglia,
supermon, Totalview, Lustre, PVFS, and Maui.
! Programming is very SSI and many/most programs don't need a specific
SSI calls. However, there is a libcluster.so and cluster.h available to
do some cluster-specific functions. In libcluster.so there are
--- 66,76 ----
control load levelling (loads, loadlevel) and a command to run other programs
in a "localview" mode (localview - more on this in the process management and
! IPC sections below). This release has a first cut at man pages for many
! of the commands.
Many of the opensource HPTC middleware has been run on the SSI cluster,
along with some purchasable capabilities. The list of things tested
include MPICH, LAMPI, HP MPI, openPBS, ScalablePBS, SLURM, ganglia,
supermon, Totalview, Lustre, PVFS, and Maui.
! Programming is very SSI and many/most programs don't need any specific
SSI calls. However, there is a libcluster.so and cluster.h available to
do some cluster-specific functions. In libcluster.so there are
***************
*** 76,79 ****
--- 82,89 ----
Some aspects of this are covered in other sections. In this section
we describe the "services" model in SSI and a few other topics.
+ This release has a first cut at some of the man pages. There are also
+ documents in /usr/share/doc/openssi-tools-1.0.0/docs on the following
subjects:
+ README.X-Windows README.clusterfstab README.ipvs cdsl rc-design-notes
+ README-mosixll README.cfs README.hardmounts README.upgrade.
II: Installation
***************
*** 93,97 ****
/var has 3 context links (lock, log and run).
/cluster/var is the global /var files symlinked back from each node's
! var (utmp is an example of this);
IV: /dev and devices
--- 103,109 ----
/var has 3 context links (lock, log and run).
/cluster/var is the global /var files symlinked back from each node's
! var (utmp is an example of this).
! /usr/share/doc/openssi-tools-1.0.0/docs have documents on CFS, the
! clusterwide fstab and shared-disk hardmounts
IV: /dev and devices
***************
*** 103,110 ****
on any node). If a process migrates, it retains the /dev context of the
node it started on. The onnode command changes the context
! to that of the destination node. Currently ptys are
! allocated locally so they are unique only as /dev/x/ptys/yy, where x
! is a node number. This will change to provide a clusterwide ptys
! numbering scheme so who and ps can work better.
V: Filesystems
--- 115,121 ----
on any node). If a process migrates, it retains the /dev context of the
node it started on. The onnode command changes the context
! to that of the destination node. /dev/pts is now supported as a
! clusterwide device. There is a single pool of ptys, allocated uniquely
! clusterwide.
V: Filesystems
***************
*** 120,136 ****
Lustre. Filesystems with CFS automatically stacked can transparently
failover from node to another if they are stored on a shared disk but
! the management of this isn't quite finished. File record locking is
! visible and enforced clusterwide. BSD-style "flock" is only visible and
! enforced locally.
There is some ongoing work to improve the filesystem experience.
! /etc/fstab will be used to describe all filesystems on all nodes, with a
way to indicate which filesystems are on each node and which can
failover from node to node. /etc/mtab will better indicate where a
! filesystem is mounted. The current problem that fsck/mount complain
! if a given device name is already mounted (albeit on another node) will
! be fixed. A paper describing the new filesystem management capability is
! available.
! Va: NFS client and NFS server
NFS client capability is fully functional (including locking and statd
and failure handling), assuming all nodes have connectivity to the remote
--- 131,146 ----
Lustre. Filesystems with CFS automatically stacked can transparently
failover from node to another if they are stored on a shared disk but
! the management of this isn't quite finished except for the root
! filesystem. File record locking is visible and enforced clusterwide.
! BSD-style "flock" is only visible and enforced locally.
There is some ongoing work to improve the filesystem experience.
! /etc/fstab is now used to describe all filesystems on all nodes, with a
way to indicate which filesystems are on each node and which can
failover from node to node. /etc/mtab will better indicate where a
! filesystem is mounted.
! /usr/share/doc/openssi-tools-1.0.0/docs have documents on CFS, the
! clusterwide fstab and shared-disk hardmounts
! VI: NFS client and NFS server
NFS client capability is fully functional (including locking and statd
and failure handling), assuming all nodes have connectivity to the remote
***************
*** 145,160 ****
is in place but it is not fully operational.
! VI: Swap
Swap space is not particularly SSI, with each node providing its own
swap space. Swap space designation is done in the common /etc/fstab.
- Added capability to allow different nodes to have different swap
- partitions is part of the filesystem improvement project (ongoing).
To determine which nodes are using which swap, you can execute an
onall swapon -s.
! VII: /proc and cluster process model
Processes have clusterwide unique pids and process management
is completely SSI. Sessions and process groups can be distributed, as can
! parent-child pairs. Users, administrators and processes have complete
visibility and access to all processes on all nodes, just as if it was one
big machine. Process can be launched on other nodes a variety of ways and
--- 155,168 ----
is in place but it is not fully operational.
! VII: Swap
Swap space is not particularly SSI, with each node providing its own
swap space. Swap space designation is done in the common /etc/fstab.
To determine which nodes are using which swap, you can execute an
onall swapon -s.
! VIII: /proc and cluster process model
Processes have clusterwide unique pids and process management
is completely SSI. Sessions and process groups can be distributed, as can
! parent - child pairs. Users, administrators and processes have complete
visibility and access to all processes on all nodes, just as if it was one
big machine. Process can be launched on other nodes a variety of ways and
***************
*** 168,191 ****
loadlevelling is turned on (which it is by default); lvs and ip_vs_...
have to do with the cluster ip alias).
! /proc/cluster/nodex/ has "load" with a load value (taken
! from Mosix code) which is used by the loadleveller and "loadlevel" which
! indicates if loadlevelling is turned on for that node.
! /proc/cluster/loadlevellist is the list of programs that can be
! loadlevelled (and this characteristics is inherited) so if you run
! /bin/bash-ll, everything you execute after that can be loadlevelled,
! either at exec time or while it is running (via process migration).
! Loadlevelling is started by the standard RC service mechanism and the
! /proc/cluster/loadlevellist is initialized by the
! /etc/sysconfig/loadlevellist file.
Note that the "localview" feature can restrict the view of the
processes in /proc to just those executing locally. localview can
be used as a command, so "localview top" will just display the most
active processes on the local node and not clusterwide. The
! localview attribute is inherited.
! VIII: Networking model and CVIP (cluster virtual IP, cluster alias)
! The networking model has 2 parts to it.
! First, each node has one or more addresses that are only locally visible.
! One address is used for kernel-to-kernel communication in support of SSI.
That address is in /etc/clustertab (which is used to build /etc/dhcpd.conf
and a file in the ramdisk so networking with the address can
--- 176,193 ----
loadlevelling is turned on (which it is by default); lvs and ip_vs_...
have to do with the cluster ip alias).
! /proc/cluster/nodex/* are files used for load levelling and are
! discussed in section X below.
Note that the "localview" feature can restrict the view of the
processes in /proc to just those executing locally. localview can
be used as a command, so "localview top" will just display the most
active processes on the local node and not clusterwide. The
! localview attribute is inherited. The onnode command has a -l option
! to restrict the view of the command executed to the node it is run
! on.
! IX: Networking model and CVIP (cluster virtual IP, cluster alias)
! The networking model has 2 parts to it. First, each node has one
! or more addresses that are only locally visible. One address is
! used for kernel-to-kernel communication in support of SSI.
That address is in /etc/clustertab (which is used to build /etc/dhcpd.conf
and a file in the ramdisk so networking with the address can
***************
*** 200,206 ****
to another card on another node if the first node leaves the cluster.
The "clustername" command returns the same result on all nodes and should
! be associated with the CVIP.
! IX: Inter-process communication (IPC)
All inter-process communication (IPC) is nameable clusterwide and is
shared clusterwide. This means there is one namespace for semaphores,
--- 202,226 ----
to another card on another node if the first node leaves the cluster.
The "clustername" command returns the same result on all nodes and should
! be associated with the CVIP. In /usr/share/doc/openssi-tools-1.0.0/docs
! there is a document on ipvs.
! X: Load Balancing
! There are two forms of load balancing built into the system. First,
! incoming network connections can be load balanced using the HA-LVS
! capability described in the previous section.
! Processes can be load balanced through the load leveling
! subsystem, which does exec-time load leveling and process migration.
! /proc/cluster/nodex/ has "load" with a load value (algorithm from
! Mosix) which is used by the loadleveller, and "loadlevel", which
! indicates if loadlevelling is turned on for that node. The loads(1)
! command shows the loads of each node.
! /proc/cluster/loadlevellist is the list of programs that can be
! loadlevelled (and this characteristics is inherited) so if you run
! /bin/bash-ll, everything you execute after that can be loadlevelled,
! either at exec time or while it is running (via process migration).
! Loadlevelling is started by the standard RC service mechanism and the
! /proc/cluster/loadlevellist is initialized by the loadlevel service.
!
! XI: Inter-process communication (IPC)
All inter-process communication (IPC) is nameable clusterwide and is
shared clusterwide. This means there is one namespace for semaphores,
***************
*** 211,221 ****
node. IPC objects do not currently move from one node to another, like
processes can.
! Currently the ipcs command only shows local objects but that will be
! corrected soon.
! It is planned that the "localview" command will limit the scope of
ipcs and also allow "local" sysVipc objects (keys need only be unique on
! the given node). This semantic of localview is not operational yet.
! X: Added and changed commands/utilities
There are very few new commands, the idea being that standard single
system commands should just work. There is a command to see
--- 231,240 ----
node. IPC objects do not currently move from one node to another, like
processes can.
! The ipcs command shows all sysvipc objects as does /proc/sysvipc/*.
! The "localview" command also limits the scope of
ipcs and also allow "local" sysVipc objects (keys need only be unique on
! the given node).
! XII: Added and changed commands/utilities
There are very few new commands, the idea being that standard single
system commands should just work. There is a command to see
***************
*** 227,232 ****
IPC sections).
The "localview" command can be used to launch other commands in a mode
! where readdir of /proc only shows local processes. Eventually it will
! also limit the visibility of sysVipc objects. "onnode -l" allows you to
run a command on a specific node and only see the /proc of that node.
ps shows all the processes on all the nodes (it is
--- 246,251 ----
IPC sections).
The "localview" command can be used to launch other commands in a mode
! where readdir of /proc only shows local processes. It also limits the
! visibility of sysVipc objects. "onnode -l" allows you to
run a command on a specific node and only see the /proc of that node.
ps shows all the processes on all the nodes (it is
***************
*** 245,252 ****
A little more about this is described below in the System Management
section.
! who and last are clusterwide although the current pty device naming
! is causing some entries to be missed.
! XI: HPTC Middleware
Many of the opensource HPTC middleware has been run on the SSI cluster,
along with some purchasable capabilities. The list of things tested
--- 264,271 ----
A little more about this is described below in the System Management
section.
! who is clusterwide. last (i.e. wtmp) has some problems with log
! rotate that must still be addressed.
! XIII: HPTC Middleware
Many of the opensource HPTC middleware has been run on the SSI cluster,
along with some purchasable capabilities. The list of things tested
***************
*** 256,260 ****
to the SSI cluster.
! XII: libcluster, cluster.h and programming
Programming is very SSI and many/most programs don't need a specific
SSI calls. However, there is a libcluster.so and cluster.h available to
--- 275,279 ----
to the SSI cluster.
! XIV: libcluster, cluster.h and programming
Programming is very SSI and many/most programs don't need a specific
SSI calls. However, there is a libcluster.so and cluster.h available to
***************
*** 263,270 ****
There are also calls to check the membership of the cluster, get information
about nodes in the cluster and to get a cluster membership history.
! Man pages for the libcluster.so calls are included in the distribution
! (currently html but will be nroff soon).
! XIII: System Management
System management means a lot of things from installation to filesystem
management to networking and user accounts and performance monitoring.
--- 282,288 ----
There are also calls to check the membership of the cluster, get information
about nodes in the cluster and to get a cluster membership history.
! Man pages for the libcluster.so calls are included in the distribution.
! XV: System Management
System management means a lot of things from installation to filesystem
management to networking and user accounts and performance monitoring.
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
|
