Access and System Names
From UMaine Supercomputer
Contents |
Panopticon
Description
Access to the clusters is now centralized through one common gateway: panopticon.clusters.umaine.edu. You, as a user, will be able to log onto panopticon for most of the work that you do (checking results, editing files, job submission, job control). You will only need to log onto fawlty, kearney2 or bender in order to compile. Direct access to Bender, Fawlty or Kearney from the outside world will no longer be active.
Why did we make this change?
As we all know, computer security is becoming a bigger issue. By having only one access point, it becomes far easier for us to monitor and control access to the clusters. Remember, if a malicious person breaks into the computer, there will be inevitable downtime while we remove any compromised services or machines. Even worse, a truly malicious (or just inept) person may cause data loss. In the end, it will be our research that suffers.
Isn't this just going to be a hassle?
We hope not once you get used to it. Here are the pros and cons as we see them:
- Pro:
- You can now control all you jobs on all virtual clusters from one point. That is, you can submit jobs on fawlty, bender and kearney2 from panopticon without logging into each compile node individually. You can also edit your data files, or check job status on panopticon.
- You only need to log into a specific compile (bender, fawlty, or kearney2) only when you are compiling new code or when a system upgrade has required a recompilation.
- We are working on solutions that will bypass the need for using black as a gateway when you are off-campus.
- It will be far easier for your friendly admins to discover and block any attempts at unauthorized access. (Perhaps surprisingly, this does happens commonly enough to warrant concern).
- Con:
- The familiar names are gone externally
- There is one more machine to bounce through if you need to compile code.
Summary of Actions That Panopticon Can Perform
- Job Control (submission, deletion, status checks etc.)
- PBS Script editing.
- Data File Control (upload, download, edit)
- Cluster Status Monitoring (via Moab or Torque commands).
Virtual Clusters
Description
Historically, we had three clusters available to University researchers. At that time, all three resided on separate networks where only very slight interaction was allowed throughout (Home Directories and Authentication). The recent upgrade has move all three of these clusters into the same network, controlled by the same servers. So the Torque/Moab server that controls PIII nodes also controls both OS X and Linux Xserves. As this is a potentially confusing change, we will refer the the three clusters as virtual clusters even though, they are really all the same now.
It is important to note that each virtual cluster has a compile node associated with it. Read on for more information.
Bender
- Virtual Cluster:
- Nodes: Dual G5 2Ghz, 2Gb RAM
- OS X 10.4.7 (Darwin 8.6.0)
- Access to node1 through node256.
- Compile Node
- Accessible through Panopticon via ssh.
- For use to compile jobs to run in the Bender Virtual Cluster or for those more comfortable with OS X.
Fawlty
- Virtual Cluster:
- Nodes: Dual G5 2Ghz, 2Gb RAM
- Gentoo Linux, 64-bit userland, multilib enabled
- Kernel 2.6.16.27, gcc-4.1.1
- Access to node1 through node256.
- Compile Node
- Accessible through Panopticon via ssh.
- For use to compile jobs to run in the Fawlty Virtual Cluster
Kearney2
- Virtual Cluster:
- Dual Pentium III, 1.0 GHz processors
- Fedora Core 5
- Kernel 2.6.16.20, gcc-4.1.1
- Access to all nodes in the 300 range.
- Compile Node
- Accessible through Panopticon via ssh.
- For use to compile jobs to run in the Kearney2 Virtual Cluster
Historical Notes
Fawlty
The name Fawlty comes from the British television comedy Fawlty Towers. In the early days, before fan control for this architecture, Fawlty was rather loud and obnoxious, much like Basil Fawlty.
The work on Fawlty started in the fall of 2004, back when linux on the ppc64 was very new, and consisted only of John's G5 desktop with a couple nodes booted from it. We evaluated the Debian, Gentoo, and Yellow Dog distros. All had their major problems at that time. Debian was able to provide more functionality at the expense of being a 32 bit operating system with some 64 bit extensions.
In its first generation, Fawlty was essentially a diskless cluster. The disks were available for scratch space, but the OS resided entirely in a combination of RAM (bin, sbin, var, etc) and network mounts (usr, lib). Fawlty was reliable, but its performance was not measurably better than Bender, the OSX side of the cluster. Another drawback of Fawlty was that it was diskless. Although there are valid arguments for a diskless cluster, primarily involving disk cost and maintenance, there are also disadvantages, such as a significant increase in network load. Given that the nodes were equipped with disks, it ceased to make sense not to use them.
In spring of 2006, we set out to build the current generation of Fawlty, the fruits of which are in the stable system today. Again a number of distros were evaluated, Red Hat, SuSE, Yellow Dog, Debian and Gentoo. Debian and Gentoo were miles ahead of the others at this time and required only minor hacks to install. We continued using both, and began development of the Netboot service in use today. This allowed us to quickly reboot nodes into any of the images we had saved for testing. Eventually, we hit a wall with Debian due to the 32-bit userland which was causing authentication problems in Torque. At this time, we decided on Gentoo, which was based on a true 64-bit userland with 32-bit emulation libraries. (It's important to note that even OS X doesn't fully make use of the 64-bit G5 processor).
