Typically when you access a cluster system you are accessing a head
node, or gateway node. A head node is setup to be the launching point for jobs
running on the cluster. When you are told or asked to login or access a cluster
system, invariably you are being directed to log into the head node.
A head node is often nothing more than a simply configured system that is
configured to act as a middle point between the actual cluster and the outside
network. When you are on a head node, you are not actually running or working
on the cluster proper. However, all the tools and necessary programs are made
available to test and then submit your programs to the cluster, as well as view
and manage your data. purpose for this arrangement is to keep your
cluster system separate and distinct from other systems and
``appear'' as a single system rather than a
aggregation of many individual systems. This has the effect of simplifying
access, usage, and efficiency by having all interactions filtered and managed
through a few designated points. In theory, you should never have any need to
access any of the individual compute nodes of a cluster system, instead relying
on the head node and the tools it provides to submit jobs to the cluster,
monitor them, and view and retrieve their results.
Note: From a best practices standpoint although the head nodes are often
setup to provide a point of access and testing of the programs you want to run
on a cluster system, ideally you do not want to run computational programs on
the head node itself. Meaning specifically, any programs you want to run on the
cluster should not be run on the head node, instead they should be run and
tested on the cluster itself using the scheduling system tools on the head
node. You should restrict your usage of the head node to programs that let you
build and prepare your cluster programs and manage and view your data. In many
cluster systems, there are often resources (cluster nodes) explicitly reserved
for testing purposes.