Slashdot Mirror

Oh, that sounds like a tough one to me. Ok, ok, it's actually not that tough - but it DOES require combining a number of kernel patches, there's no one-stop-shop (at the moment) for this. It also requires that network connections be IPv6, as there's bugger all mobility support out there for IPv4 for Linux as best as I can tell.

I think you'll want to take a look at openmosix. http://www.openmosix.org/ Instead of writing your app to be cluster aware, it hides all that good stuff in the kernel. All you need todo is have an app that'll fork/pthread appropiately and mosix takes care of all the messiness behind the scenes.

Beowulf isn't the only game in town folks. A much easier to maintain and balance cluster can be built using openMosix. openMosix is a single-image-cluster extension for Linux.

shutdown -h now

How does this compare to OpenSSI? OPenSSI is nice because of the single system image approach, that makes administration very simple. AFAIK, an OpenSSI cluster also supports PVM and MPI in addition to exec and run-time load balancing (a'la mosix).

OpenSSI has a lot of "HA-" support, including support for various clustered filesystems, failover of network interfaces across nodes, and failover of the first node (hopefully soon without needing shared SCSI storage but using something like drbd).

It's called OpenMosix.

Install an cluster and get all the "Computons" you want without a goofy licensing scheme.

I didn't see a mention of OpenMosix in the article, and the original poster worried specifically about process migration in an openmosix cluster.

I believe an OpenMosix cluster CAN help load balance and thus scale an Apache web farm. Follow my logic here: If your web application is serving very heavy requests, you can very easily be CPU bound, not IO bound (disk IO or comms IO). Take for example a web app that queries a database, grabs a large complex result set, parses the results, and creates a graph or PDF file, and thus takes 15 seconds at 100% cpu per request. On a normal Apache server, two simultaneous requests take 30 seconds and no one is happy (bigtime!).

On an openMosix cluster, the first heavy request uses all local CPU. The primary box (the only one running Apache) spawns a new process for the second, 3rd, 4th, etc. requests, which migrate automatically. They use the available custer CPU power, run to completion, migrate back, and the results returned as if the box was just very fast.

I've written several CPU bound web apps; they made me nervous about timeout (I had limited optimization possibilities). I could have solved this worry with openMosix had it been available then.

Please don't get me wrong, Joe Batt (and Thanks! to "benjamindees Alter Relationship"), this cluster concept will be entirely useless serving thousands of static HTML page requests. It wouldn't help a single bit. But with fewer, heavyweight requests, it could solve the problem rather simply.

OpenMosix seems to be an ideal solution where programming time is limited and CPU needs are large (fat requests). If programming time is less limited, you could do the standard 3-tier architecture of a web, application, and database layer. You would then need to build in a one-to-many web-to-application-server architecture, so the app servers did the CPU and returned results to the web server. This method needs much more programming than my openMosix simple solution. If I was architecting Sears.com (I helped there a bit on back-end stuff), I would do 3-tier with a specialized load balancer where I had a support agreement with Quality-of-Service guarantees and liability insurance.

But, if I was serving in-house queries of subsets of what-if scenarios from a data warehouse in PDF format, I'd probably want to use openMosix since the rest of the project would be so complex I'd want to cut down on complexity if at all possible.

Another workaround would be to move the CPU requirements from Server to Client, running a big Java app on the browser box to farm out computing power. Hmmm. This would also require Java programmers, which are fewer in number, expensive, and add a completely new layer to my design. Ug. This approach limits me - I could't cache results, and I could blame their CPU's for the delay. But, Java already adds overhead (and thus time), and I don't know if the libraries are there for everything I want to do (granted Java has lots of libraries but it's not omnipotent). No, I like OpenMosix better here, too.

Further, since adding more CPU is a simple matter of adding another box with a minimum of disk (or network boot), my project costs come way down even if all 14 VPs love my app and spend every morning from 7:30 to 9 running scenarios, I don't have to explain what "CPU Bound" means to them.

OpenMosix is at OpenMosix.org.

OpenMosix is a Linux Kernel Patch that distributes load between Linux boxes invisibly to the user. Spawn an application and it is migrated to the box with the most availble processing power. Details available at OpenMosix.org. It's in wide university use.

Simply put, it makes any group of linux boxes into a highly scalable cluster.

This may do what you wish, it may not, but it's a good option. I'm in process on setting it up t home now - first I had to get a kernel compile going.

OpenMosix sounds very interesting for multiplying processing power. We have more horsepower needs than capability now, and Solaris boxes are WAY too expensive - I want to migrate to an openMosix Linux cluster for way cheap.

I am a big fan of thin clients, and have administered two setups. When it is done right, the amount of administration work drops to virtually nothing. If you can set up a new company to rely on only web apps or custom jobs, the user has virtually no power to mess with anything, can only use the apps you offer them, and, if they hose their home directory, you simply copy it back from a daily backup for them. Simple and beautiful.
The administration costs on this are minimal, and hardware rarely needs to be upgraded, except to add another server to the setup.

When it comes down to it, you only get cost-effective scalability by using distributed systems or clustering. In fact, for really large systems, it's the only possible way at all.

Something like OpenMosix should really be a standard part of the Linux kernel already, as should other support for simplifying clustering, distributed computing, communications, and distributed shared memory. Distributed systems and clustering is the future, not SMP.

From what I can remember, Microsoft is currently working on a p2p database. I would love to see something similar implemented in the *nix community. I know it would be hard as hell, but it'd be nice to have something that sets up easier than an openmosix cluster, preferably something that you can install once and forget about...

Well, I don't know how to use CLIC, but I set up a cluster using some surplus P2s, RH 7.3, and openMosix.

For kernel 2.4.18, openMosix consists of two kernel patches - a kernel patch to actually do the clustering, and a kernel patch for administration. You patch your kernel, change a few settings (all documented on the site), reboot (gasp!), and you're done.

You can get more fancy with net installs, but you don't really need to for a small number of nodes. Anyway, I just used a Fast Ethernet switch - the boxes all came with Ethernet cards, luckily for me.

Mine is a pretty craptacular cluster, but hey, it's pretty cool to have one. The cluster behaves like one powerful computer in the sense that processes on one machine will migrate to another. However, in order to achieve any noticeable affect, the program has to take advantage of multiple CPUs. If you're going to program your own, look into forking, message-passing interface (MPI), and parallel virtual machine (PVM). Sorry, I don't have the addresses for them on hand, I think www.beowulf.org links to them.

Maybe I'm missing something, but how is this different from MOSIX?

I have a small 6-node cluster of P2s running openMosix...

OSX makes a good desktop system for people who want a no-hassles UNIX system that runs out of the box. It makes it easy for people with modest computer experience to install and maintain their machine. And it runs a bunch of commercial desktop apps.

Once you are talking number crunching with a compute cluster, you are almost certainly better off with Linux-based systems. Linux has extensive cluster administration tools. Cluster installation and maintenance is much easier than OSX installation and maintenance. You can easily run any GUI-based Linux programs remotely using X11, which still beats Apple's remote desktop software in both functionality and performance. You get automatic process migration across a cluster with OpenMOSIX. There is much more numerical and scientific software available for Linux than for OSX, much of it open source; while porting to OSX usually isn't hard, it does require some effort.

Also, you do much better in terms of hardware. While XServe pricing is OK, Pentium and AMD-based servers are still cheaper and offer better performance, and they are offered by many vendors in many different configurations. And, if you like, people already use 64bit Itanium-based machines, or you can still get Alpha-based 64bit compute servers.

Also, be sure to support OpenMOSIX

Apparently MOSIX is going to go closed source, so test out OpenMOSIX if you can, the project is really taking off and has several contributers, but it needs your help in testing the kernels. OpenMOSIX is being sucessfully used in major installations now, so it should be fine for what you want to use it for, and also you won't be getting yourself going on a (soon to be) proprietary path.