Slashdot Mirror


Building Your First Cluster?

An anonymous reader asks: "I'm interested in building a DIY cluster using Linux and will be using conventional Linux software. However, the number of possible ways to do this is huge. Aside from Beowulf, there's Mosix, OpenMosix, Kerrighed, Score, OpenSSI and countless others. Therein lies the problem. There are so many ways of clustering, development seems to be in fits and starts, most won't work on recent Linux kernels and there's no obvious way to mix-and-match. What have other people used? How good are the solutions out there?"

18 of 71 comments (clear)

  1. Don't sweat it ... by tomhudson · · Score: 5, Funny

    Try them all. After all, you just KNOW your first one's going to be a clusterf*ck.

    Seriously, if you're going to take that route, you really should be prepared to invest the time in test-driving several different solutions.

  2. Rocks by corvair2k1 · · Score: 5, Informative

    Rocks is a great tool to build a cluster. It includes lots of monitoring tools and such, so you can see the status of nodes, etc. However, I'm not quite sure how large you're planning on going... May be overkill for a 4-noder. =)

    1. Re:Rocks by kst · · Score: 4, Informative

      No, Rocks isn't overkill for a 4-node cluster; I'm running three 4-node Rocks clusters myself.

      I'm not familar with other solutions, but Rocks is remarkably easy to install.

  3. Find the problem before trying to solve it by linuxkrn · · Score: 4, Informative

    Sounds like you're trying to solve a problem that you don't have.

    Cluster need special software to take advantage of the disturbed computing. They are built with a specific task in mind. Or do you already have a need and just failed to tell us?

    For me, I run my network with distcc (http://distcc.samba.org/) So all of my Gentoo boxes can compile using shared computing power. It cut a typical 33Min app down to less then 2 mins doing this. And works wonders for my slower laptop.

    With distcc, all you need to do is have the same tool chains. (glibc, gcc, coreutils, etc) You can even specify how many threads per box you want running to fine tune your network.

    On the other hand, if you just want to learn, then you should try them all. The all suit different needs.

    1. Re:Find the problem before trying to solve it by Daxster · · Score: 3, Funny
      Cluster need special software to take advantage of the disturbed computing.

      Well, indeed, clusterf*cks might turn your distributed computing project into a disturbed one..
      --
      Death by snoo-snoo!
    2. Re:Find the problem before trying to solve it by Fishbulb · · Score: 3, Insightful

      Cluster need special software to take advantage of the disturbed computing. They are built with a specific task in mind. Or do you already have a need and just failed to tell us?

      And specifically, is this a processing cluster or a failsafe cluster? I kind of assume a processing cluster, since that's what most people on slashdot refer to as a cluster, but in my experience most of the clusters out there are failsafe clusters ("5 9's" of service versus raw horsepower). Two rather different applications of clustering, requiring different design philosophy and sometimes different clustering applications.

      OB Mony Python ref:
      "I don't know what you mean, an african cluster or a euopean cluster?"

  4. Re:Well, uh... by kimvette · · Score: 4, Insightful

    "massively SMP" does not provide fault tolerance and does not eliminate certain bottlenecks such as disk I/O and network throughput, so if it's for an extremely high volume/high availability fileserver, mail server, or web server, massive SMP isn't going to cut it.

    Also, I'd go a render farm (if that's the task) if I had to choose between clustering and SMP, because if one node dies (depending on the managing application) the job just continues, whereas if it's on one single monster machine with no fault tolerance, if the job dies you often have to start rendering again from the beginning. Not fun.

    So let's back up and ask:

      1. What problem are you trying to solve?

      2. If it's a learning experience, try them all, take notes on which suit you best for tasks a, b, and c,

      3. What are your priorities

    --
    The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
  5. Whatever happened to... by techno-vampire · · Score: 3, Interesting
    I remember in the '80s, back at JPL, they were talking about connecting a number of computers into a hypercube. One node would be for I/O, and it would communicate with the others along the edges of a hypercube.


    Two computers make a 1 dimensional "cube." Four, in a round-robin make a square. Six, properly connected, make a regular cube and so-on. Does anybody out there know if they still connect clusters this way and if not, why?

    --
    Good, inexpensive web hosting
    1. Re:Whatever happened to... by sophanes · · Score: 5, Informative

      While a few early parallel computers used hypercube based interconnects (eg, CM-1), there hasn't been a lot of interest in hypercubes since then. The advantage of hypercubes is that their diameter only increases logarithmically with the number of nodes in the network. Their disadvantage is that the node degree increases with the dimension, meaning that each node must be configured with sufficient ports to support the maximum dimensionality of the network -- making hypercube-based networks either expensive or non growable. (This can be solved to an extent by using cube-connected cycles.)

    2. Re:Whatever happened to... by SirLoadALot · · Score: 3, Informative

      No, cluster network links are not nearly as elaborate as that, for the most part. The advent of high-speed crossbar links means that only the largest clusters need to even consider the network structure. You can get a 288 port Infiniband switch that provides full crossbar connectivity across all data paths. Only if you outgrow the largest available switch do you need to consider how to best link the multiple switches together. Generally this would involve minimizing the amount of IO that would need to be performed between the switches, which isn't always easy, or even possible.

  6. My Experence by PAPPP · · Score: 3, Informative

    I have a stack of five origional Pentium boxes with 32mb of RAM and 2gb harddrives (except for one, with a larger drive for a software repository). Origionally built it to experiment with AFAPI based clustering, but since AFAPI is a reasonably non-invasive setup, it works well for trying other techniques too, everthing from simply running distcc on the nodes to speed up i586 software builds to briefly fiddling about with some of the other clustering options mentioned. Fiddling around with options on a real cluster (running cluster software on a single node really isn't a good impression) that could be reinstalled from scratch in a few hours, and the machines aren't worth enough to matter if it is physically damanged is a great way to learn.

  7. sweating it out.. by tempest69 · · Score: 4, Interesting
    ok a few caveats (I cant spell)

    1. I do beowulf, other clusters arent my thing. 2. I can handle C and C++, but I'm not a guru. 3. I can fumble my way through unix-linux but I get cranky with new versions (command/ flag changes in utilities). 4. I have 6 lazyish years as a unix sysadmin.

    getting prepped,

    You want to make sure that the boxes that are talking to eachother are very secure from the rest of the world. Most of the concepts on a cluster are about trashing the security of the machines in question. There are ways to make a secureish cluster, but a good firewall is a better way to go. let the firewall talk to your "head node", and preferably locks the "body nodes" from seeing the outside world. There are a ton of ways to get this done. on the cheap have all the body nodes have a non-existant gateway ie 192.168.0.1, set the firewall as 192.168.0.129 (forget dhcp) and let the head node point to the 192.168.0.129,, and have the firewall route services (ssh, ftp, telnet (ok not ftp or telnet)) to the head node.

    getting started

    1. Load all the boxes with the same OS. (the same way) (DONT select SELINUX or you will cry) 2. build a hosts file (names for machines) /etc/hosts 3. build a hosts.allow , hosts.equiv (still in /etc) 4. add in some entries into securetty for your rlogin rcp rsh.. 5. youll probably have kerberos(weakly secured) rlogin rcp rsh... you want to rename those and replace them with the non secure versions, there are other ways, but this saves a bunch of hassle. 6. pop into /etc/pam.d and adjust the rlogin rcp rsh.. (this may not be needed in some cases). 7. add in a + + in the .rhosts file of each cluster user.

    after you have pulled your hair out decyphering my glossed over instructions, you should be able to type: rsh node002 and be at the prompt for node002 with no password asked, and no silly kerberose failed: trying /usr/bin/rsh message given.

    At this point then you can configure LAM (you may nee to download it and get it installed on your boxes)

    basically it needs an arbitrary file Mynodes.txt that will contain the list of nodes you wish to launch. you type in lamboot Mynodes.txt and then it will kick back some silly error 99% of the time because something small was forgotten. you fight through those errors until it finally gives you a sucess.

    Now your golden, then its just a matter of figuring out how to compile and run MPI programs with the mpiCC and mpirun. But if you got through the first gloss over then the rest is a snap.

    Remember if these machines see the outside world they are naked, defenseless, and totally exploitable..

    Be aware that these instructions can cause all sorts of havok and any reasonable person would just hire an expert.

    Honestly I hope that this gives you a starting point. You'll still need a bunch of time with google.

    GOOD LUCK!!

    Storm

  8. Rocks Rocks! by Frumious+Wombat · · Score: 4, Informative

    No, seriously, if you're setting up a cluster where your work can be batch-queued, or intend to run MPI, then Rocks http://www.rocksclusters.org/ is the way to go. It also comes with tools such as SGE (Sun Grid Engine) or OpenPBS pre-configured, Intel compilers and libraries ready for you to drop a license onto (but of course the entire GNU suite is there as well, including Ada), has more monitoring tools (plus some nice web-based interfaces) than you can shake a stick at, and runs on IA-32/AMD-64/IA-64 (Itanium). It also has a Roll to help build a tiled display wall, which would be a really cool use of a small cluster.

    They're also really great guys.

    On the other hand, Oscar is supposed to be good, and if you're not into the whole batch-mode thing, you can get OpenMosix up and running using http://clusterknoppix.sw.be// ClusterKnoppix, and just fire jobs off into space and let them find their own unburdened node.

    But still, Rocks is really an elegant and clean way to go, plus it will scale up in case you're going to deploy a huge one of these for real after you get your feet wet.

    --
    the more accurate the calculations became, the more the concepts tended to vanish into thin air. R. S. Mulliken
  9. Depends on what you're doing by mrsbrisby · · Score: 3, Informative

    Clustering means too many different things these days. I operate several clusters- but they're all so different that I can't say that any of them are the same.

    I run ClamAV and Spamassassin- both very slow programs- with cexec which simply lets me farm regular unix tools across multiple (lots) of CPU servers. This lets me replace the clamscan and spamc programs with "wrappers" that use my farm. I like cexec because it doesn't make me create lists of clients and servers, but automatically load balances and fails out very nicely.

    For my frontend web servers, I use fake/heartbeat and some custom proxy software for routing frontend requests to backend farms.

    I haven't found a real reliable replicated directory- with one, I could use cexec as a filesystem... Maybe some day...

  10. Diskless OpenMosix by rwa2 · · Score: 3, Informative

    I worked for a linux supercomputing startup way back when. The easiest time I had was by separating the components : one big machine for storage, and lots of little diskless machines for computation.

    So I'm a Debian fan, so that involves just creating one large computer (or two with redundancy using linux-ha) with a good RAID as a shared home directory. Then just install the "diskless" package. This will allow you to spawn off as many hosts that mount root off of NFS as you like. All you have to do is get the compute nodes to boot a kernel that supports nfs root (I used a single floppy, but you can do bootcds or net-boot if you're more sophisticated).

    I used a Mosix kernel at the time, but I suppose OpenMosix is a better bet today. Mosix pretty much makes the entire system look like a massive SMP, so you just launch a whole lot of batch scripts on one computer, and it automatically distributes the load out to idle machines, and ships the results back to the one you started on. You just choose a node to become the master diskless-image, and then use the diskless scripts to clone it as many times as you like.

    The compute nodes could have a local drive, but I just used them for swap and maybe local /tmp. It's damn convenient to be able to configure all the nodes from one place whether they were online or not.

    The other nice thing about OpenMosix is that it's architecture agnostic, so you could conceivable join and remove nodes that were all different speeds, AMDs or Intels or maybe even 64-bit platforms in any combination. The faster processors would get the heaviest loads first, etc.

    After you have this system up and running, you might start playing with more sophisticated stuff, like parallel distributed global filesystems and the like. But before that you could certainly make your NFS root server scale up by splitting it up across multiple machines (for /home , /usr, etc.). You'd be amazed at the performance you can get with a well tuned NFS share... since one server can cache most of the disk access, it can even dish out files from one big high performance RAID faster than if you had bothered to give all the nodes their own drive or two.

    Anyway, it's the systems management that will get you... so I recommend using Debian, getting real cozy with aptitude, and searching the apt repository for all of the little command and monitoring thingies that will help you, like clusterssh and cfengine and nagios2 and stuff.

    Burning a bunch of ClusterKnoppix CDs will pretty much get you on track with most of this, I'd imagine. Also check out the "KNOPPIX Remastering" howto so you can customize your own livecds, should you choose that path insteads of diskless nfsroot.

    So that's a software approach, the hard part is really selecting, testing, and optimizing all of the hardware. The slowest component is always going to be storage (invest in lots of separate SATA cards using the Linux software RAID5 or RAID10 - reconfigure and test lots with hdparm -t and bonnie++ and format reiserfs), followed by network (gigabit NICs are cheap - you could afford separate ones for the NFS and the "real" network, though gigabit switches are still up there - Linksys and D-Link make some good 16-port ones for ~$300).

    Um, if you're looking for parallel applications, povray is fun. And for a time we could sort of measure how many nodes I had up and running by monitoring my stats at distributed-net . But with OpenMosix, just about anything with lots of CPU-intensive parallel batch processing is fair game and works out of the box.

    Have fun!

  11. OSCAR by Odocoileus · · Score: 3, Informative

    Last year I built a cluster using OSCAR http://oscar.openclustergroup.org/
    I haven't tried any others, but OSCAR installs pretty easy. Just run the installer on the head node, and when it is done it feeds an image to each of the other computers that are a part of the cluster. It includes the ganglia monitoring tools and the apache server so you can view it.

    --
    ...
  12. OpenMosix LiveCD by dargaud · · Score: 3, Interesting
    First, here are some notes about the first cluster I build 3 years ago, and most of it is still relevant.

    This being said, for an instant trial, there are some OpenMosix LiveCDs, such as Quantian or other variants of Knoppix. Put the Quantian DVD in the 1st PC, boot, enable the remote boot option, boot the other computers over the network. Here: you have an operational cluster.

    I think there may also be Rocks LiceCDs but haven't tried them. And remember your electricity bill when playing with clusters !

    --
    Non-Linux Penguins ?
  13. my first cluster setup by Wornstrom · · Score: 4, Interesting

    For my first diskless cluster, I used the warewulf cluster solution to see one up and running. Then, I wiped the master node's disk and built one with the openmosix kernel patch etc, and used the Linux terminal services project which was really cool. the ltsp stuff made the node filesystem stuff easy to build onto. I am waiting for the openmosix team to finish up work and release the userland tools for the 2.6 kernel for my next build. here is a good how-to on LTSP+Openmosix - http://ltsp.org/contrib/ltsp-om5r3c.html

    Once you get that going, you might look at PVFS2 Parallel Virtual File System. "PVFS2 stripes file data across multiple disks in different nodes in a cluster. By spreading out file data in this manner, larger files can be created, potential bandwidth is increased, and network bottlenecks are minimized."

    Good Luck!!