MOSIX: Linux Clusters without the Pain
Configuring MOSIXAs I am never content to just trust software, I also performed a manual installation. The manual installation is basically the same, and provides some insight into why the automated version is so easy. After performing a manual patching of the kernel and configuring through the menuconfig program, the only things remaining were the file configuration and the user space utility compilation.
The basic configuration of MOSIX was simple. I only had to modify some standard system files such as /etc/inittab and /etc/inetd.conf. The reason I edited these files was to make sure that the services I did not want to cluster did not get migrated. Migration is the term that MOSIX uses to describe a process that is moved (migrated) to another node within the cluster. If a process is migrated, the node it is migrated to takes responsibility for processing the request. Therefore, services such as shutdown should not be migrated.
Installing MOSIX on the Development MachineFrom this point, I began to install MOSIX on a development machine that's a completely different machine in terms of hardware. My machine is a K6/2-550 with 256 megabytes of RAM. The development machine is a Intel Celeron 333 (overclocked to 405) with 128 megabytes of RAM. I expected at least one bump in the installation process, but was denied the satisfaction. The installation went just as clean as the first installation. Again, on reboot it asked me to edit the /etc/mosix.map file. Again, it came up clean to the login prompt.
I was at a loss. I actually just sat in my chair staring at the machine for a minute. I had to have forgotten something. I logged into my machine (the K6) and proceeded to fire up KDE2 final beta.
Testing the InstallationMOSIX comes with several user space programs that are designed to allow you to monitor, administer, and tune the MOSIX cluster. The simple but effective mon program is used to monitor the utilization of each node via a curses-based graph. Once I had mon running, I tried to execute a couple of programs and see if mosix would migrate them to the other machine.
The program I first tried was Netscape. As Netscape is traditionally a very bulky program, I thought it would be interesting to run the Netscape process on a different CPU rather than tie up my CPU cycles. Netscape did not migrate on its own, but I was able to force the migration using the runon command.
I then proceeded to optimize MOSIX by running the tune program. The tune program performs several optimizations to help the migration algorithms work more effectively with the different machines. I noticed something when running the program: MOSIX will require machines that have good Floating Point Units (FPU). The K6/2, although a great CPU, suffers in this arena and the Celeron easily stomped the K6/2, even though the K6/2 is 145MHZ faster and has more RAM. If you prefer AMD, I would make use the Athlon/Duron series because it has more efficient FPU.
I would have to explore MOSIX a great deal more than this article allows to truly test the limits of this software, but from the experience that I have had with it and the experience that I have read from other people's comments on the mailing list, MOSIX has great potential. If you are looking for a way to increase your computing horsepower in a cost-effective manner for a shared environment or distributed application, I strongly suggest you look into MOSIX.
-- Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.
Joshua Drake is an e-commerce and Linux consultant who owns his own company, Command Prompt. He has been using Linux for almost nine years and is the Linux Documentation Project's Webmaster. His other projects include the LinuxPorts.com Website and the OpenDocs publishing company.
Page 2 of 2