Using MPICH to Build a Small Private Beowulf Cluster

A Wayne City High School computer science teacher shares the step-by-step approach his students used to build a Beowulf cluster.

In the spring of 2001, my students and I constructed a Beowulf cluster in the Wayne City High School computer science laboratory using MPICH 1.2.2.2 (an implementation of the MPI library) and Red Hat 6.2. Prior to this time, none of us had any serious Linux experience, and a project that initially started on a whim later progressed to a serious learning experience for everyone involved. The successful results of our first cluster experience were published on the Beowulf Underground. Since the publication of our story, I have received many e-mails from around the world asking me to describe, in painstaking detail, how we built our cluster. My standard answer was to do the research like we did, but as time passed, I realized that I really should write down our methodology for our own behalf as well as for the benefit of others.

We are a small rural high school in southern Illinois. Even so, we have offered computer science as a formal class for the past 20 years, beginning with a single Commodore VIC-20 and progressing to our current level of 100-plus computers in a school with 200 students. Linux, however, was only another word to us until last year when we started our project. It was common to hear phrases such as "who the heck is root?" and "what's this tar thing?" for several weeks before things began falling into place. We were self-taught and had to learn the mysteries of dual-booting, networking, X, rsh and any other topic that seemed to pop up at the most inopportune time. It wasn't all fun, but the process was certainly rewarding from an educational standpoint. This fall our administration and school board approved the purchase of new computer hardware for us, which brings us to the present.

Our new Beowulf cluster consists of a private network of eight systems dual-booting between Windows 2000 Professional and Red Hat 7.1. Each computer has a single AMD 1.4GHz Athlon processor, 512MB RAM, a 30GB hard drive, a 64MB NVIDIA video card and 100Mb Ethernet with switching hub (did I say that our administration and school board were kind to us?). We are using the current version of MPICH (1.2.2.3) as our MPI library.

Why did we choose MPICH? When we decided to build a cluster and began our research, we discovered three possible clustering systems: MPI, MOSIX and PVM. Our first attempt at clustering involved MOSIX. Its "fork and forget" philosophy seemed ideal (because we really didn't know what we were doing), and MOSIX claimed to work with existing software. What we didn't realize was that we would have to download and compile a vanilla kernel in order for MOSIX to work properly. This seemed a daunting task for rank amateurs, so we rejected MOSIX. PVM was briefly considered, but some of the research we did indicated (correctly or not) that MPI would be a better choice for us in terms of ease of use and performance. Ultimately, we decided on the MPICH implementation of MPI for its price (free), ease of installation (the subject of this article) and programmability (the subject of a future article?).

Step-by-Step Clustering Using MPICH 1.2.2.3

First assemble the hardware. MPICH allows you to simulate a cluster using a single computer if that's all you have available. How to do single computer clustering is discussed briefly later in the article. For now, I will assume that you have at least two computers with network cards available. Here at Wayne City, we have successfully built clusters of from two to sixteen computers. With two computers, you can use a simple crossover cable to connect the network cards. With more than two computers, you will need either a hub or a switch to network your systems.

It is possible to mix and match systems. In our first clustering efforts we had various flavors of Pentium, Celeron and Mobile Pentium systems working together before we settled on a homogeneous lab of 16 300MHz Celeron computers with 10Mbps Ethernet and hub. Our current cluster retains this homogeneous structure using AMD Athlon processors and 100Mb Ethernet with a switching hub. I also have successfully connected my Dell Inspiron 8000 notebook computer to our new cluster, although its 1GHz Intel processor is a bit slow compared with the 1.4GHz AMD Athlon. Nevertheless, it's fun to watch the Dell notebook benefit from the combined power of eight additional CPUs.

All the computers we have used and experimented with were complete standalone systems with monitors, hard drives, keyboards, etc. It's possible to build clusters using bare-networked CPU boxes and a single master node with monitor and keyboard, but we did not make any attempt to build such a beast. Also, we have not had the opportunity to mix and match other types of systems such as SGI, SPARC or Alpha workstations (although we would welcome the opportunity--anyone wanting to donate old equipment can contact me directly).

Next, install a Linux distribution on each computer in your cluster (henceforth, we'll call them nodes). We are using Red Hat 7.1 for our current cluster and are pleased with its performance.

During the installation process, assign sensible hostnames and unique IP addresses for each node in your cluster. Usually, one node is designated as the master node (where you'll control the cluster, write and run programs, etc.) with all the other nodes used as computational slaves. We named our nodes node00 through node07 to keep things simple, using node00 as our master node. Our cluster is private, so theoretically we could assign any valid IP address to our nodes as long as each had a unique value. We used IP address 192.168.100.200 for the master node and added one for each slave node (192.168.100.201, etc.). If you already have Linux installed on each node in your cluster, then you don't have to make changes to your IP addresses or hostnames unless you want to. Changes (if needed) can be made using your network configuration program (I'm partial to Linuxconf in Red Hat). Finally, create identical user accounts on each node. In our case, we created the user beowulf on each node in our cluster. You can create the identical user accounts either during installation, or you can use the adduser command as root.

Then configure rsh on each node in your cluster. We used rsh for two reasons: first, rsh appeared to be easier to configure than ssh, and because we have a private network with trusted users, security is not an issue; second, from what I understand, rsh does not have the added overhead of encryption, so its cluster performance should be a bit faster than ssh.

As naive users, rsh was a bit of a problem initially, especially with Red Hat 7.1. We were prompted for passwords each time we attempted to connect with another node. Finally, after much searching on the Internet, we were able to figure out a method that seemed to work for us. Educationally, we wanted to install MPICH from both user and root perspectives, so we configured rsh to allow user and root access. Our methods, however repugnant to Linux security experts, were as follows:

Create .rhosts files in the user and root directories. Our .rhosts files for the beowulf users are as follows:

node00  beowulf
node01  beowulf
node02  beowulf
node03  beowulf
node04  beowulf
node05  beowulf
node06  beowulf
node07  beowulf

And the .rhosts files for root users are as follows:

node00  root
node01  root
node02  root
node03  root
node04  root
node05  root
node06  root
node07  root

Next, we created a hosts file in the /etc directory. Below is our hosts file for node00 (the master node):

192.168.100.200 node00.home.net node00
127.0.0.1               localhost
192.168.100.201 node01
192.168.100.202 node02
192.168.100.203 node03
192.168.100.204 node04
192.168.100.205 node05
192.168.100.206 node06
192.168.100.207 node07

Again, our network is private, so we used IP addresses beginning with 192.168 and made up the rest. Each node in the cluster had a similar hosts file with appropriate changes to the first line reflecting the hostname of that node. For example, node01 would have a first line:

192.168.100.201    node01.home.net  node01

with the third line containing the IP and hostname of node00. All other nodes are configured in the same manner. Do not remove the 127.0.0.1 localhost line (as we found out the hard way). The hosts.allow files on each node were modified by adding ALL+ as the only line in the file. This allows anyone on any node permission to connect to any other node in our private cluster. To allow root users to use rsh, we had to add the following lines to the /etc/securetty file:

rsh, rlogin, rexec, pts/0, pts/1

. Also, we modified the /etc/pam.d/rsh file:

#%PAM-1.0
# For root login to succeed here with pam_securetty, "rsh" must be
# listed in /etc/securetty.
auth       sufficient   /lib/security/pam_nologin.so
auth       optional     /lib/security/pam_securetty.so
auth       sufficient   /lib/security/pam_env.so
auth       sufficient   /lib/security/pam_rhosts_auth.so
account    sufficient   /lib/security/pam_stack.so service=system-auth
session    sufficient   /lib/security/pam_stack.so service=system-auth

Finally, after much research, we found out that rsh, rlogin, Telnet and rexec are disabled in Red Hat 7.1 by default. To change this, we navigated to the /etc/xinetd.d directory and modified each of the command files (rsh, rlogin, telnet and rexec), changing the disabled = yes line to disabled = no.

Once the changes were made to each file (and saved), we closed the editor and issued the following command: xinetd -restart to enable rsh, rlogin, etc. We were then good to go with no more rsh password prompts.

Next, download the latest version of MPICH (UNIX all flavors) from www-unix.mcs.anl.gov/mpi/mpich/download.html to the master node (node00 in our cluster). The file is around 9.5MB, and you probably should grab the installation instructions and other documents while you are there. You never know when the installation guide might be useful.

Untar the file in either the common user directory (the identical user you established for all nodes "beowulf" on our cluster) or in the root directory (if you want to run the cluster as root). Issue the command: tar zxfv mpich.tar.gz (or whatever the name of the tar file is for your version of MPICH), and the mpich-1.2.2.3 directory will be created with all subdirectories in place. If you are using a later version of MPICH than we are, the last number might be different than ours.

Change to the newly created mpich-1.2.2.3 directory. Make certain to read the README file (if it exists), but in our experience, the configure and make scripts work without modifications. Type ./configure, and when the configuration is complete and you have a command prompt, type make.

The make may take a few minutes, depending on the speed of your master computer. Once make has finished, add the mpich-1.2.2.3/bin and mpich-1.2.2.3/util directories to your PATH in .bash_profile or however you set your path environment statement. The full root paths for the MPICH bin and util directories on our master node are /root/mpich-1.2.2.3/util and /root/mpich-1.2.2.3/bin. For the beowulf user on our cluster, /root is replaced with /home/beowulf in the path statements. Log out and then log in to enable the modified PATH containing your MPICH directories.

From within the mpich-1.2.2.3 directory, go to the util/machines/ directory and find the machines.LINUX file. This file will contain the hostnames of all the nodes in your cluster. When you first view the file, you<\#146>ll notice that five copies of the hostname of the computer you are using will be in the file. For node00 on our cluster, there will be five copies of node00 in the machines.LINUX file. If you have only one computer available, leave this file unchanged, and you will be able to run MPI/MPICH programs on a single machine. Otherwise, delete the five lines and add a line for each node hostname in your cluster, with the exception of the node you are using. For our cluster, our machines.LINUX file as viewed from node00 (the master node) looks like this:

node01
node02
node03
node04
node05
node06
node07

Then make all the example files and the MPE graphic files. First, navigate to the mpich-1.2.2.3/examples/basic directory and type make to make all the basic example files. When this process has finished, you might as well change to the mpich-1.2.2.3/mpe/contrib directory and make some additional MPE example files, especially if you want to view graphics. Within the mpe/contrib directory, you should see several subdirectories. The one we will be interested in (for now -- you can explore the others on your own) is the mandel directory. Change to the mandel directory, and type make to create the pmandel exec file. You are now ready to test your cluster.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Some pointers from the sidelines

Anonymous's picture

First - Very Nice Job.

Some things you might look in to.

1. Instead of rcp try using rdist. You can update files on all nodes in one command.

2. "Version" control on your MPICH directories. I recommend putting your whole MPICH directory structure in /opt, i.e. /opt/mpich-1.2.2.3 and then create a symbolic link to the directory that is generic. i.e. "ln -s /opt/mpich-1.2.2.3 /opt/mpich" This way you can upgrade binaries by installing to a new directory and changing the symbolic link. If the new binaries do not work, restore the old link. This way you don't have to change the PATH (/opt means optional and is designated for 3rd party apps)

3. When you change your .bash_profile you can "source" it to "activate" the changes. enter the command ". /path/to/.bash_profile" This updates only the current terminal session. Logging out then in again applies the change to all new terminal sessions.

4. On the security issue - I would have to agree with others. I work at a major financial institution. I can't tell you how many small projects have become "mission critical". Try to migrate to ssh. Look at the ssh-agent man page. You can set it up to automatically forward credentials.

Also - I suggest you not have root as a "beowulf user" create individual accounts and, if necessary, set up sudo. That way you can at least have logging of all root commands. If you've gotten this far, sudo will be a snap. At the very least, use a shared beowulf user account - just not root. It is very easy to destroy everything as root.

5. Networking - if you edit the "hosts" line in the /etc/nsswitch.conf file to check files first then you do not need to setup DNS or NIS as long as all the nodes are listed in the /etc/hosts file. i.e.

#hosts: db files nisplus nis dns

hosts: files dns nis nisplus

questions

phsieh2005's picture

Hi,

I tried to follow your steps, but, because I am using SuSE 10.1, so, there are several differences.

The question I have is that, do I need to install mpich on ALL nodes? Or I only need to install one copy on the master node? In this case, how does the slave nodes sees mpich? (or maybe they do not need to access mpich?)

Your reply will be appreciated.

phsieh2005

Re: Some pointers from the sidelines

Anonymous's picture

Thanks for the compliment and your comments...

1) rdist... excellent suggestion!

2) version... we'll look into this in our new project

3) source... discovered this after the article was written, but thanks. This is a nice time-saver.

4) security... still not an issue in our situation. I know the IT professionals are screaming, but I'm not training IT professionals in my classroom and I'm not an IT professional. We explored beowulf clustering to see if we could calculate more quickly, as evidenced by the mandelbrot graphic. The focus of my computer science class is centered on graphics (OpenGL/GLUT using C) and the mathematics behind the graphics. That's it. We have since abandoned our beowulf cluster and have moved on to a distributed graphics API (Syzygy 0.4), which uses OpenGL/GLUT. Many of my students become interested in a professional career in "computing" after taking my class, but that's really not my goal. I'm trying to develop logical thought processes, spatial visualization, and creativity (and yes, critical thinking... whatever that is). On my bookshelf are titles such as: "Open Geometry: OpenGL + Advanced Geometry", "OpenGL Programming for the X Window System", the famous Red and Blue books for OpenGL, the "OpenGL SuperBible", "Computer Graphics" by Foley and van Damm, Pickover's "Computers and the Imagination"... and many other titles of the same genre. We use both Windoze and Linux, depending on which serves best, and we learn what we need to know when we need to know it! We use our computers as tools for the imagination and not as ends in themselves. I do understand everyone's concern about security... and I appreciate that concern, but come visit my lab and you'll see my position a bit better.

5) Networking... outstanding suggestion!

Thanks again for your comments and your concern. The beowulf article was written well over a year ago and we have since "moved on". It was interesting, but we find distributed graphics more engaging.

Regards,

Stan

Some pointers from the sidelines

Anonymous's picture

First - Very Nice Job.
Some things you might look in to.

1. Instead of rcp try using rdist. You can update files on all nodes in one command.

2. "Version" control on your MPICH directories. I recommend putting your whole MPICH directory structure in /opt, i.e. /opt/mpich-1.2.2.3 and then create a symbolic link to the directory that is generic. i.e. "ln -s /opt/mpich-1.2.2.3 /opt/mpich" This way you can upgrade binaries by installing to a new directory and changing the symbolic link. If the new binaries do not work, restore the old link. This way you don't have to change the PATH (/opt means optional and is designated for 3rd party apps)

3. When you change your .bash_profile you can "source" it to "activate" the changes. enter the command ". /path/to/.bash_profile" This updates only the current terminal session. Logging out then in again applies the change to all new terminal sessions.

4. On the security issue - I would have to agree with others. I work at a major financial institution. I can't tell you how many small projects have become "mission critical". Try to migrate to ssh. Look at the ssh-agent man page. You can set it up to automatically forward credentials.
Also - I suggest you not have root as a "beowulf user" create individual accounts and, if necessary, set up sudo. That way you can at least have logging of all root commands. If you've gotten this far, sudo will be a snap. At the very least, use a shared beowulf user account - just not root. It is very easy to destroy everything as root.

5. Networking - if you edit the "hosts" line in the /etc/nsswitch.conf file to check files first then you do not need to setup DNS or NIS as long as all the nodes are listed in the /etc/hosts file. i.e.
#hosts: db files nisplus nis dns
hosts: files dns nis nisplus

Java on clusters

Anonymous's picture

Has anyone tried to use Java threads on clusters like these or MOSIX clusters?

Re: Java on clusters

Anonymous's picture

From Rick Philbrick -Seattle

If you go to the FAQ at Mosix.org you'll find the part that covers the limitations of using JAVA on a MOSIX cluster.

If YOU had actually read the

Anonymous's picture

If YOU had actually read the fact (or understood it), it would be obvious that this isn't a LIMITATION of Java. The normal method to achieve parallism in a Java program is with either multiple threads or RMI. Obviously, passing threads doesn't make any sense (I am assuming you have a CS background), and while RMI will work with MOSIX, it would be redundant. If you're using RMI, you already have a parallel programming framework, and very likely, a parallel program.

The portion of the faq related to Java is posted below.

Parallel JAVA programs
----------------------------
JAVA supports thread level parallelism, while MOSIX can migrate only processes. Therefore, JAVA parallel programs will not benefit much from process migration.

However, JAVA programs which use more than one VM could benefit from process migration. Examples are programs that use RMI, programs that communicate through pipes/sockets, or simply many executions of the same program. For ease of converting your parallel program into a multiple VM program, it is recommended to use one of the many available Grid packages based on JAVA.

See the "Problems" section of the FAQ if you have problems with JAVA VM processes that won't migrate.
----------------------------

Applications for said cluster?

Anonymous's picture

Now that you have your cluster. Are you actually creating applications that can take advantage of this? If so could you describe what types of applications briefly? I have set up Mosix clusters before but never a cluster using MPI. This for the simple fact I wanted to take advantage of precompiled/pre-existing applications without rewritting for MPI. There are of course limitations with Mosix as well and I am not implying you should have used it. I am just wondering how you are taking advantage of your current setup.

Re: Applications for said cluster?

Anonymous's picture

From Stan Blank:

Good question. This was primarily a "Can we do this?" exercise. We had some afterthoughts about "Now, what can we do with this", but instead, chose to go another route and delve into distributed graphics (Syzygy). This is our current area of cluster interest. It was/is my intent to expose my students to "interesting" things in the hopes that some of them will be inspired to greater efforts, both as a hobby and as a career. So far, the rewards have been very worthwhile.

So, other than some minor original programs assigned as a teaching/learning exercise, we have not accomplished anything "great". There are several online tutorials available on MPI programming. We also used the book "Using MPI" by Gropp, Lusk, and Skjellum as a resource (2nd edition).

In reply to the security issue, I disagree. Security should not ALWAYS be the primary concern. My primary concern was building a working cluster with my students and having all of us learn from that experience. When and IF security becomes an issue, we will tackle the problem at that time and I have no doubt that we are up to the task.

Actually, a security breach (assuming one were possible on our cluster), would be an invaluable learning experience for us. We would then see first-hand how such a breach could occur and could then research and learn how to prevent future calamities. Hmmmm... a teachable moment, perhaps?

Good Article

blop's picture

I work at a small ISP, and i was looking around at cluster information to try to get some use out of these 17 pII 333mhx computers just gathering dust. This article looks to be the most strightforward and hands on ive have seen yet so im going to try it. The combined processing power of all the machines wont reach over 3ghz, the fastest processor out right now, but i know there are going to be more instructions done per clock cycle so.... who knows? I went to college like your students but our teacher never exposed anybody to linux. I stray in many different paths when it comes to using computers and already have some linux experience. And i agree linux is really confusing at first, if you come from a DOS/windows background. Mainly i hate the abbreviations for EVERYTHING, shortening commands and paths down to 3 letters, at least dos tried to use up the whole 8 char limit! Makes it hard to tell what does what, but supposedly it was implemented to save time typing. Other than that linux has so much more to offer in the lines of experimentation. Im going to try to make this work, and maybe do some benchmarks to see how much of a performance gain i get. Hell i got 8 hours a day to fill if nothin breaks down here at the office :) Thanks for the article!

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

Suggestions:

1. Substitute rsh with ssh

2. Setup NIS/DNS/NFS to share the accounting etc

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

Hi,

Nice facts given in simple format. Even i was able to

build the cluster based on rsh. My problem with ssh seems to

be apparent with the login/passwd. Any help in this will

be highly appreciated.

regards

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

Stan Blank replies:

Thanks for the response. I tried to keep everything simple (so I could understand it!). I'm certain someone will step in and help you with the ssh issue.

Regards...

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

Stan Blank again:

I forgot to congratulate you on building your cluster! If you get the opportunity, drop me an email and let me know the details. Thanks again for the compliment.

Best wishes...

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

1. stick with rsh for performance reasons, use a firewall if you connect

the cluster to any other network

If you get heavy MPI traffic ssh will consume lots of CPU

2. Agree, definetly use NIS/NFS, if you don't need Internet access

from the cluster nodes, NIS is good enough for host name resolution

Regarding security, NFS and NIS stinks, but just switching to ssh

will not save you, use a firewall

for more parallel software go to SAL http://sal.kachinatech.com

If you want to do some serious number crunching look into cfd

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

Stan Blank replies:

Thanks for the information! We will definitely look at the website you mentioned and research cfd.

Our main school network has a firewall, but our cluster is private and isn't connected to the main network at this point. My philosophy of cluster security is a bit like how I handle my home security. We live in a rural area and there hasn't been a burglary in our village for many years. I lock the doors to my house and my dachsund is good at yapping when anyone approaches. However, I don't have bars on my doors and windows and I don't have a burglar alarm wired to the local sheriff's office. I use the security that I think is warranted for the situation. If I lived in an urban area, I would rethink my home security options. If our cluster were connected to the main network, then I would rethink the security of the cluster.

Thanks again for the feedback and information.

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

What about performance? If the cluster is totally private, won't ssh be slower than rsh?

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

SSH is a little slower during initial job setup. Once the connections are established, the overhead is miniscule (it was well under 1% when benchmarked several years ago). SSH is also easier to manage, as one protocol replaces telnet/ftp/rlogin, and is, of course, far more secure. Finally, if you want to log into your cluster from off your internal network, you should be using SSH anyway. If you're using SSH already, why complicate things by adding rsh and messing around with PAM?

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

From Stan Blank:

As I indicated in the article, security is not an issue in our situation since our cluster is isolated from the outside. We have a simple 8 node cluster connected via a switch. That's all.

We are using rsh because that's what we started with. At this point, it works very well for us and we understand its operation. I know that ssh is simple to use... that's not the issue. We are staying with a method that is working well for us and see no overwhelming reason to change. The lesson for us was not rsh vs. ssh, but building a cluster that worked.

Those of you who want to use ssh (or have to use ssh), go for it. We may try it at some time or we may not. In our situation, even if security were an issue, what's the worst thing that could happen? That we would have to reformat and start from scratch? That's no big deal on an 8 node cluster with several students (and a teacher) who enjoy doing such things.

Thanks for the comments and suggestions. I'll be happy to discuss this and/or any other issues relating to the article.

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

"As I indicated in the article, security is not an issue in our situation since our cluster is isolated from the outside."

security should always be an issue, even when starting small. After all, all great things start small? Who is to say your small project isn't found useful and expanded. Security should be a concern during the initial design in whatever you do. Never as an afterthought.

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

From Jim Pallister:

I am at least willing to put a name to my comment.

I think its commendable what they have accopmlished with no experience in Linux at all. Don't shoot them down over something that in their case wasn't an issue.

Who is to say your small project isn't found useful and expanded. -- security can be your "expanded"

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

I am not discrediting them for what they have done (although i do not think they have broken new ground, they did accomplish a lot without prior experience... but alas "standing on the shoulders of giants"...).

Let me put it this way, you do not get your start in physics by simply ignoring hundreds of years of research and discovery. You examine what has been done, and build on it / expand on it.

This is also true with building larger scale systems. You do not simply toss out security/safety. What are you teaching to your students? Grunt work is just as important as the glamorouos portions.

What about documentation? If documentation gets the same priority as security, you are doing your students a great diservice.

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

From Stan Blank:

I seem to be unable to communicate our situation and our goals, so one last time...

We had NO intention of breaking new ground. Of COURSE we "stood on the shoulders of giants"... I thought my article implied these facts. Did I not list our resources? Do you really think that we thought we were doing something original? By your usage of "alas" did you somehow infer from the article that we believed we were creating new knowledge. If so, then what led you to assume that? The only unusual aspect of our experience is that, based on our research and on the emails I've received, a working beowulf cluster in a small rural high school is somewhat rare. Please read the first couple of paragraphs again to understand my purpose for writing the article. It's hardly for the glory... nobody around here, other than my family, students, and my principal are even aware that the article was published.

Your second statement was redundant... I understood you the first time.

Once again, this is not a large scale project and will NEVER be a large scale project. Our security is absolutely rock solid, however. We aren't plugged in to the main network. You can't crack our cluster from the outside, period :). And once again, even if our cluster were hacked/cracked... so what? We'll build it again. I need to install RH 7.3 anyway. Our intent was to build a small working cluster and nothing more.

If you literally meant that I was doing my students a disservice by scrimping on the documentation, the article was based on our documentation! If the intent was a more general "disservice" (ie. security issues), then I strongly disagree. I believe I'm doing my students a service by providing new and innovative opportunities for them to explore. I am not preparing them for immediate placement in the industry, but merely trying to expose them to ideas and concepts that may or may not help them decide whether or not to pursue a career in computer science. If they should pursue a career in CS or IT, then don't you think they'll learn security as a part of their college curriculum? I should hope so.

"Alas", your judgment of my curriculum and teaching methods and your implication that we were avoiding "grunt work" by concentrating solely on "fun" projects has absolutely no validity. I strongly believe that it's my duty to make learning as interesting and as enjoyable as possible. I have no plans to change my philosophy in this regard. Until you visit our school and view our situation first hand, you are in no position to judge what we do.

I believe that what I'm doing IS educationally sound and I have the full support of my administration and school board. More important to me, however, are the endorsements of my former students (30+ from our tiny high school) who have entered the CS/IT field (and of course, make far more money than I do).

I was warned by some of my university friends that the linux security mavens would misunderstand our project and descend upon my article. I suppose, to a small extent, they were correct :).

Finally, I do appreciate your comments and I don't mean to sound harsh, but I feel strongly about my curriculum and it is very easy to become defensive in such situations. If you are a teacher, please teach according to your own philosophy and stand your ground if you believe you are correct. If you aren't a teacher, then try it sometime. I can't think of anything I'd rather be doing (except play major league baseball, but I don't think there has ever been a 47 year old rookie).

Please feel free to email if you wish to continue the discussion or have questions.

Regards,

Stan Blank

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

You're a crazy old man.I will see you at home.

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

From Bill Ross:

Hear Hear!

Excellent article Stan.

-Bill

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

Its an excellent Article ...I have not seen such a step by step procedure ...its wonderfull explanation

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

I've been remiss in not reading the posts... thanks to Bill Ross and the last poster for your kind words! I also want to thank the many individuals from all over the globe who wrote for advice and/or simply to send encouragement.

I'm not certain I was able to give any worthwhile advice, but your thoughtfulness was much appreciated!

Regards,

Stan

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

Being several months after the fact, you might not ever read this. Your article is now the insipration for a friend in Australia attempting to build a cluster at his school. He's not going to try and break new grounds in research either, but what his kids will learn from the experience will be invaluable. He's in the lucky position of having 100 SunBlades to retire.

Congratulations on the article. Excellent work.

Damien

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

Thanks Damien, I appreciate the kind remarks. You and your friend have captured the spirit and intent of the article completely!

100 SunBlades... that should be great fun! I would appreciate hearing about the progress/results if possible and if time permits. Also, while I'm hardly an expert, if you or your friend have any questions, don't hesitate to contact me. My email address is at the end of the article.

My students and I are going to rebuild our cluster from scratch this year using the latest MPICH, so while reading/printing my article this morning for our own reference, I saw your note.

Thanks again... you made my week!

Regards,

Stan

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

Well After One year ur Article is still helping people like Me to build the Beowolf and further Addon.Here is what I can suggest to this .Install LAM/MPI modules and Bproc and then working on the same ground a good beowolf can be created.thanks a lot ..for step by step procedure..

Parshuram

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

Thanks for the kind words, Parshuram... we will investigate Bproc as we build our new cluster using RedHat 9 and the latest MPICH source.

Best wishes,

Stan

Re: Using MPICH to Build a Small Private Beowulf Cluster

Anonymous's picture

From Stan Blank:

Thanks for the support, Jim. We are learning about Linux and clustering AND having fun at the same time. Life is good...