Linux Cluster login node changes: During the Fall Semester of 2006, the login head node (cluster01.tccs.tufts.edu) was
upgraded to an Intel 64bit 4 processor dual core SMP computer with 16 gig of ram.
The Xeon emt64 processors are capable of executing both native x_64 and legacy
i32a codes. This upgrade provides eight 64bit cpus for increased computational
resources and speed. However the 40 Intel dual processor compute nodes will remain
32bit during the 2006-2007 academic year. As a result, minor changes are necessary
to allow for an environment that is as close as possible to the previous 32bit login
node while providing access to 64bit versions of some of the licensed commercial
applications available to Tufts and for home grown 64bit applications .
Module based environments for 64bit applications:
The new login node will use the Module approach to managing the user environment
for different 64bit software and versions. The advantage of the Module approach
(with some minor exceptions) is that the user is no longer required to specify paths,
and other application specific shell environment information via startup scripts or
dotfiles. If you rely upon startup scripts, dotfiles and other approaches to create
your environment, it is likely that you will need to remove these and use the Module
approach.
What is a Cluster?
Cluster computing is the result of connecting many local computers (nodes) together via a high speed connection to provide a single shared resource. Its distributed processing system allows complex computations to run in parallel as the tasks are shared among the individual processors and memory. Applications that are capable of utilizing cluster systems break down the large computational tasks into smaller components that can run in serial or parallel across the cluster systems, enabling a dramatic improvement in the time required to process large problems and complex tasks. The Tufts Linux Research Cluster
The Tufts Linux Research Cluster is currently comprised of 40 identical Linux systems (compute nodes) interconnected via a Gigabit Ethernet network. Each cluster node has a pair of 2.8Ghz Intel Xeon CPUs and 4 gigabytes of memory. The Linux operating system on each node is configured identically across every machine. The client workstations access the cluster via the 130.64.0.0 LAN. The user node, however, has an additional NIC that connects to the compute nodes using private non-routable IP addressing . This scheme allows the compute nodes to be a "virtualized" resource, abstracted away behind the user node. Users don't have to know or care about any other specific machine. This approach allows the cluster to scale up to any number of nodes without the users noticing anything other than the fact that their jobs are completing faster. This will also enable the cluster to silently grow as needed and keep pace with usage demands.
 Future cluster01 nodes are also not restricted by current hardware and software configurations. The cluster can, for example, combine and connect nodes with different operating systems, nodes with large amounts of memory, nodes with more than 2 CPUs, and nodes that run on 64-bit architectures, such as Opteron, Itanium and Sparc.
The management node, (a second server that is identical in hardware configuration to the user node) is used for administrative and maintenance tasks and is invisible to the cluster users. Scratch storage space (always located at the path of /scratch/) is provided for temporary storage of compiled data. Users are advised to treat the scratch directory as temporary storage because it is not backed up, not intended as a place for permanent storage, and will be periodically cleaned out. Important data should be saved in the user home directory, as it is on Amber. It should also be noted that /scratch on each system is unique. Putting a file in /scratch/username on the user node will not make it available to any of the compute nodes. Likewise, files put in /scratch on one compute node are not visible elsewhere.
If you have any questions about accounts, application compatability, or need more information, contact the cluster administrator: cluster01-support@tufts.edu.
| 
