The best11.13 way to build your beowulf nodes (as opposed to the easiest) will be to learn some things that enable you to improve the scalability of your installation. What exactly does that mean?
If you followed my advice (assuming you are new to all this) and built a small beowulf by hand-installing and configuring a few nodes, you probably noticed that you did a lot of things over and over again. You configure the disk. You pick the packages. You install the root password. You (possibly) set up the video, mouse, serial port, printer(s) and all that. You configure the network. You come along afterwards and copy the same set of /etc files from your master copy of them on your server. You also unpack the same set of beowulfish add-ons, and configure them the same way.
With all that repetitive work (and a computer handy, for God's sake!) one expects there to be a better way and of course there is. What one needs is a way of encapsulating all of those actions that were the same over and over again into a script (possibly with some variables) to do it for you.
If you are a Unix or linux expert, you're shaking your head and saying, ``Well Duh...''. On the other hand, if you are coming out of the Windoze or Macintoad world, you probably think that a script is the thing used to put on a play or a movie11.14.
So it is, my friends, so it is, but the particular play we wish to put on is one where the computer itself is the actor while it ``installs itself'' according to our specifications!
Fortunately, linux comes with marvelously powerful scripting languages (like /bin/[ba]sh11.15, perl and python11.16, and still others that are arcane or archaic, depending on one's religious convictions and history.
Unfortunately, all the different linux distributions are, well, different. And the one place they are most annoyingly different is in how they lay out certain key files that one most certainly will need to configure, and in how they actually install themselves onto a system in the first place.
These differences are not insurmountable, but they make a truly proper and portable scriptset for installing a beowulf node a childish fantasy. Your odds are better of winning the Publisher's Clearing House Sweepstakes, or of being brained by a small meteorite as you step out your front door11.17 than they are of writing something that works on any three of the available linux distributions. Alas, beowulf install scripts for distributions exist, but they tend to be crafted as one-of-a-kinds and therefore also tend to break even for that distribution when, for example, it goes up a major revision number.
Fortunately (we just did unfortunately, right, so we're back to fortunately) it isn't that hard to come up with a decent install paradigm that works with the strengths and overcomes the weaknesses of any given distribution, once you know what you are doing and now you do. To show you roughly how to proceed, I'm going to outline what I do that exploits the nice scripting features of Red Hat's kickstart install. Near-equivalent approaches can be constructed for most of the other distributions as well, where you have to do more or less of the configuration work yourself with external scripts.
On major advantage of the Red Hat kickstart approach is that one does not need (or want) a CD-ROM drive in a node in this approach - a floppy and hard disk suffice. One may not need a graphics adapter, although even a host bios that permits one to boot without one usually has to be booted with one first to set the bios to boot without one11.18.
Now the point of kickstart is that Red Hat has encapsulated a large portion of the configuration tree that you followed setting up nodes by hand into a single file, where it effectively defines a ``script'' to be used by Red Hat's Install program. Using kickstart, one builds this configuration file that tells Red Hat's installation scripts how to build and configure a node, sets up an NFS exported directory containing all required RPM's, the kickstart configuration script, and builds any scripts to run after the RPM phase of the install to (for example) distribute /etc/passwd and the like.
A nice way to proceed (although not strictly necessary) is to set up the head node (which should already be built and configured separately by hand) to be a dhcp server. This server is configured to recognize the ethernet number of each node as it boots and deliver to that node its IP number and all network setup information and the instructions for getting to its kickstart file. Finally, one builds a Red Hat kickstart boot floppy, which is basically a standard boot floppy that times out into kickstart instead of an interactive install. Detailed instructions for setting all of this up (with code and examples) are given in the Software appendix and are available online at URL's given therein.
When all goes well, a node install from the point where it is plugged in and connected to the network (with no monitor or keyboard attached) looks something like:
The advantages of this strategy are manifold.
As you can see, kickstart or kickstart-like automated script-driven installation tools in general permit one to build ``a node'' as a virtual description that can be reused for all nodes. This scales excellently well and lets you work on solving problems once with the assurance that your solution will appear uniformly on all nodes in due course. In managing networks in general but beowulfs in particular, heterogeneity is evil. Try to ensure that all your nodes are boringly identical in hardware and are running a boringly identical software setup as well. Every single thing you have to do ``by hand'' or on the basis of a node's particular identity is work that will become a hideous burden over time and retard upgrades and so forth. Only your head node should be at all different.