A Fast Start For openMosix

axehind writes "Dr. Moshe Bar recently announced the creation of openMosix, a new OpenSource project. The project has quickly attracted a team of volunteers developers from around the globe and is off to a very fast start. openMosix, is an extension of the Linux kernel. openMosix is a Linux kernel extension for single-system image clustering. openMosix is perfectly scalable and adaptive. Once you have installed openMosix, the nodes in the cluster start talking to one another and the cluster adapts itself to the workload. "

Comments

Imagine a Beowulf Cluster of...

[cscx]

Oh wait...

Re:Imagine a Beowulf Cluster of...

[siemce]

The main difference is that Mosix doen't work with threads. You can spawn a separate process on a node and it can migrate to different nodes. But if your application is threaded all the threads will run on one node, or migrating between nodes.

Sounds like an advertisment to me.

[jellomizer]

Almost 5% of the text is the word openMosix. Is it more or did that post sound like an advertisment to recrute Open Source Developers. Now I am going to read the article.

Re:Sounds like an advertisment to me.

[gosand]

Is it more or did that post sound like an advertisment to recrute Open Source Developers.

I think it was more. But who cruted these Open Source Developers in the first place?

Hype?

[Raskolnk]

openMosix is perfectly scalable and adaptive

Nothing like a 'perfectly' statement to discredit a story.

Re:Hype?

[You're All Wrong]

Oooh, you cynic.

Maybe interpret it as "as perfectly as can be done with existing (read common, cheap) technology" instead.

Sure, we know Amdahl's law is pretty much like the laws of thermodynamics (the best you can do is break even, and you can't even break even).
However, unless you are talking about high-budget professional solutions (e.g. Cray, HP Superdomes, most big shit fom Sun, other highly integrated solutions with custom inter-processor/memory communications), you're always going to take this hit, and openMosix has no reason to be worse than other simple solutions. And if it can reach a state where there seems to be no performance improvement without throwing hardware at it, then surely it could be said to have reached perfection? However, that's a lot of "if"s, and is all pie in the sky at the moment; whether it achieves this 'perfection' target remains to be seen.

YAWAIW.

This + Linux Terminal Servers = Cool

[Brento]

There's already a mini-howto explaining how to set this up in combination with a Linux Terminal Server. Basically, you end up with a bunch of workstations that actually relieve the server from CPU load. Odd to think that the more diskless workstations you add to your network, the faster it becomes!

Re:This + Linux Terminal Servers = Cool

[56ker]

Odd to think that the more diskless workstations you add to your network, the faster it becomes!

I had to read that sentence twice just to work it out!

Great for older hardware

[nakhla]

This seems like a great technology for an enterprise to take advantage of older hardware. Upgrading your company's desktop PCs? Take the older ones and plug them into your openMosix cluster. If I recall correctly, processes can automatically migrate from node to node based on system load. I know my old had a Unix cluster for all of the CS students to use. It would get seriously bogged down at times, especially around finals. It'd be nice to have something like this which is able to take advantage of older hardware. There were times when a simple 'ls' would take 30 seconds to complete. Certainly this is something that an old 486 node could take care of.

Does MOSIX handle open socket migration yet?

[Anonymous Coward]

Migrating live processes between boxes with open sockets is the last big obstacle to OpenMOSIX being used in large web farms, as far as I know. It seems that OpenMOSIX is geared more to scientific computation problems with IO only at the beginning or end of the batch job. If a MOSIX process has a lot of I/O, it stays on the same box and is never migrated.

Re:Does MOSIX handle open socket migration yet?

[ameoba]

Web servers are generally regarded as I/O-bound applications. What's the point in running an environment where you already have more than enough CPU power?

Mosix

[DaveHowe]

The bit I am curious about is - if Mosix were GPL, and presumably contributed to by various of the now OpenMosix researchers, how did it become closed?
I have found This link, but that suggests a code fork rather than a revival-after-closing-source.

Re:Mosix

[Scarpux]

Yes, It is a fork. If you look at the project page, you'll see that openMosix split from Mosix because Dr Barak wanted to move from the GPL to a proprietary license. Moshe Bar, who worked with Barak on Mosix, took the GPL code and created the openMosix project. I read an interview awhile back with Moshe Bar, but I can't seem to locate it.

I love this

[FeeDBaCK]

OpenMosix is my best friend. I run several machines at home and I can tell you that openMosix rocks my world. I have a (gasp) Windows machine on my KVM switch that I use for playing games. When I am not using it, I run VMWare with a small Linux install and openMosix to take advantage of that machine's processor power. No point in letting it sit idle when I am working on my Linux machines.

Not without limitations...

[Gerdts]

Under some workloads, I can go along with the assertion that a MOSIX cluster is just like having a big machine with a lot of CPU's. It seems to be great for those workloads and I would love to try it out. Those loads tend to be multiple long running (more than a few seconds) and not multithreaded. For MOSIX to be most efficient, there also needs to be fewer jobs than there are CPUs to run them.

Other workloads, however, will not benefit from MOSIX. These statements are based on reading the docs a couple weeks back, not on actual experience.

Under the MOSIX model, when a process forks, the child may run on the current machine or it may migrate somewhere else. If the job is short lived (ls, echo whatever | sed s/blah/baz, you get the point) MOSIX will perform poorly because it will spend more time trying to figure out where the process should run than would have if it had just run the program on the local host.

If you need more CPU time than one CPU can provide and your program is multi-threaded, a single multiprocessor machine will also work better. This is because MOSIX does not yet support threads running on different machines. A 128-node cluster of 386's is going to run Netscape slower than a single 486 because you will only be using one 386 CPU.

For cases where you just have too many jobs for the resources available (CPU or memory), you may be better off with something like Condor. It is great for submitting batch jobs, migrating those jobs around, and only running the number of jobs that the system can handle.

Re:Not without limitations...

[JeffL]

Under some workloads, I can go along with the assertion that a MOSIX cluster is just like having a big machine with a lot of CPU's. It seems to be great for those workloads and I would love to try it out. Those loads tend to be multiple long running (more than a few seconds) and not multithreaded. For MOSIX to be most efficient, there also needs to be fewer jobs than there are CPUs to run them.

Other workloads, however, will not benefit from MOSIX. These statements are based on reading the docs a couple weeks back, not on actual experience.

Speaking from experience, you are pretty much correct. Jobs that use lots of CPU, but have little IO are good for mosix clusters, but jobs that have high IO are bad. The mosix filesystem and other things can partly get around the IO problems if the users plan carefully, but mostly they just want to start 30 jobs and forget about it for a few days.

There is no reason that a mosix cluster can't be combined with a batch/queueing system. This lets lazy/stupid users run their CPU bound jobs and lets mosix distribute them, but more savy users can script their IO jobs to run on particular machines and use local disk for IO.

It took a few months for the users of the cluster I setup to get trained into what jobs work well, and which kill the cluster. The problem is that launching 40 "good" jobs on a single machine is not a problem, because they just shoot out to the other nodes, but launching 40 "bad" jobs on a single machine will make that machine almost unusable.

This can have adverse effects on the cluster if the good jobs were started from the overloaded machine; for example the good jobs might have to check back with their originating machine every few minutes to update a checkpoint file.

Basically, mosix isn't some magic bullet to solve machine limitations, but it is a very cheap and effective way to solve certain problems.

Migratable sockets/filehandles yet?

[JungleBoy]

I tried (vanilla)mosix a while back. It was cool, but had some real world drawbacks. If you start a process on a node and that process opens a socket, opens a file, or uses shared memory, then that process is stuck on that node. So if you start 10 dnet processes on one node, they won't migrate to idle nodes because they have open sockets (to the key server).

I don't know if this is the case any longer, I heard rumor that all these things were going to be implimented, so it'll be an interesting project to watch.

Good Luck Open Mosix!

-The JungleBoy

openMosix?

[Viking Coder]

What openMosix was openMosix the openMosix name openMosix of openMosix that openMosix project openMosix again?

So the practical upshot is....

[mbourgon]

actually, I'm curious. What is the practical upshot, since it's different from Beowulf?

(also: so how's this differ from Appleseed?)

Re:So the practical upshot is....

[The Madpostal Worker]

The biggest difference between a MOSIX cluster and a beowolf cluster is what they use to do their distributed computing.

Beowolf usually uses PVM which requires you to do some explicit work with the PVM library. With PVM you also get a better control of something (how tasks distribute to what machines is one). The other thing is that PVM is entirely userspace, and can use a cluster of computers that say has x86 linux boxes and sparcs in it.

Mosix is almost entirely kernel space. When you use mosix you fork off a process and then communicate using unix domain sockets. You can't use threads beacuse there isn't shared memory support, but you don't have to make any calls to a mosix library to make your program work. The downside is that you can't really controll where you proccess goes and the cluster has to be all the same arch(beacuse the entire proccess migrates rather than the correct executable being called on the remote machine).

is this a good way to run a desktop environment

[BroadbandBradley]

if I 'open mosix" 4 computers and leave each one as a graphical login terminal to open a gnome desktop, would it make for a "snappy" or fast desktop, or would the I/O slow it down. (asssume 100baseT ethenet)

if anyone has tried using a cluster for 'end user desktop apps' how does it work out fsater/slower/no diff?

Re:is this a good way to run a desktop environment

[Elbereth]

I also wish someone would do some research on this. I have several multi-processor computers sitting around doing nothing (or very little), because I can't think of a good use for them. You can't play Quake 3 on a dual Pentium Pro, but it would make for an awesome node in a cluster.

The problem is that I'm not sure I'd get any benefit from all that work (learning Mosix or Beowulf, implementing it, etc).

Well, since nobody else seems to be doing it, I guess I'll have to break down and do it one of these days...

Anyone want to donate a gigabit switch?

Re:Original author can create closed source

[DaveHowe]

One effect that *does* occur to me - while the actual source of the changes made by Y to X's code are GPLed, any IP in the changes is also owned by Y (and licenced under GPL). As a side effect, presumably not only would X have to reproduce the effect of Y's patches if the new closed source release is to have the same abilities, he would have to show that he either came up with the ideas incorporated in Y's patches independently, or that they would have been obvious to anyone approaching the problem (the usual IP stuff).

obviously, IANAL, so if anyone wants to take a stab at answering this one..