[Turn] Mosix: A powerful cluster Linux solution

Mosix: A powerful cluster Linux solution

The Linux world now seems to be frantically obsessed with cluster concepts. Almost a few months ago, the only solution was to write cluster software on its own to achieve higher practicality. Of course, in scientific clusters, you can also use Beowulf or a cluster library that transmits messages (such as PVM). But in addition to these earlier solutions, Linux has lagged far behind in terms of proprietary and business clustering.

But now the development seems comforting a lot. The failsafe of SGI has been basically transplanted, the Linux high availability (efficient Linux) program has been launched, Red Hat has launched the Piranha cluster software, and so on.

At the same time, there are some feasible scientific cluster solutions, among which the most recommended is mosix. Mosix uses a single system graphics (SSI) cluster. SSI clusters are popular because they give users the impression that they are working on a supercomputer rather than a single group of nodes. Users can log on to any node on the Mosix cluster and start programs running on any node in the cluster, as long as the cluster software in the kernel considers these programs to be operational. If the user is running DNS correctly, they can simply telnet to the Cluster.mynet.com,dns loop function and let them randomly log on to a node and its affiliates, then branch and branch.

Assemble the Mosix cluster device

Some mosix can reach the level of the world's top 50 most powerful supercomputers. If you have enough idle computer equipment, consider yourself assembling a mosix cluster.

For example, install the Mosix kernel on the following hardware:

3 Dual CPU computer, the main frequency from 500MHz to 933MHz, the total memory of 1.5GB or so.

8 Single CPU computer, the main frequency from Mmx266mhz to 933MHz, the total memory is 1.8GB.

The storage space, with the network appliance F720, is about 120GB of disk space and makes the file system readable for all computers. It is very important that all machines must have a uniform user ID and group ID, otherwise there may be problems accessing the data.

These machines are connected through a 100/1000mbit network, and the center places an optical converter.
In this design, we use the Network Appliance Storage Server to implement the central storage scheme, where all the cluster nodes are centered. Some nodes use a 1000Mbit network card and some use an older 100Mbit. The Mosix will measure the wait time between each node and consider this factor when the load is too high on a node to decide to transfer its program to another node. The NIC used here is the Phobos company's product, the converter is the Nbase company.

Download two rpm from the above Web site and install it with the "Rpm-install xxx.rpm" command. One of the RPM is for the 2.2.16 kernel, with all the compiled Mosix extensions. The other is prepared for monitoring the set of MOSIX user space commands used by the cluster.

Reboot each node into the Mosix kernel, at which point the work is nearing completion, and the last thing to do is to let each node know the location of the other nodes. To do this, edit a mapping file/etc/mosix.map, specifying all other nodes and their IP addresses in the file, similar to the/etc/hosts file.

Check if all nodes can see each other and run the "Mon" monitoring program. It displays the graph of all work nodes and their respective load levels, memory consumption, and other information.


Operating interface of MON monitoring program

Start the cluster device


Practice now, and try to create a process, such as Distributed.net's dnetc RC5 broken program. And then add a few other processes. Looking at the "Mon" program will find that your computer's load is high while others are still low. But soon, the amount of load on your node will gradually decrease, while the other nodes may rise, because some of the processes on your machine are being shifted to better nodes. Mosix automatically adjusts the time and node position of the transfer without the user having control over it.

In order to have a specific concept of the powerful performance of this new cluster, the author writes a set of scripts on Linux outside the cluster, launches the program on a node and measures the operation of the cluster. These programs consist of prime numbers operators, interactive null programs, and shared memory usage processes.

When the node is outside the cluster (dual-CPU PIII 933-MHZ,768MB RAM), the machine reaches up to 20 prime number operators, 40 interactive tasks, and approximately 30 shared memory processes. With these programs running, almost no login can be run and no additional load can be added.

The situation in the cluster is vastly different, with more than 450 prime number operators, hundreds of shells, and approximately 210 shared memory tasks running on the largest nodes (the memory reference mode stipulates that the shared-memory program cannot be transferred to another node.) ）

If you want to accomplish these tasks on a single computer, you don't know how high the configuration is, but at least not below the level of the Sun E6000 or HP V2000 mainframe, which costs $100,000 trillion. And now all these hardware needs less than 20,000 dollars, Linux is what makes us do that.

Creating a single graphics cluster on multiple nodes makes sense only if the program is moved to another node and still sees its devices and files. Mosix do this without a central memory, and how exactly.

When a process moves to another node in the cluster, its code stubs remain on the original node. Whenever input/output is required, the process sends the request to the code stub of the original node, and the code stub processes the input/output locally and returns the result.

Of course, this increases the burden on the input/output intensive programs. To reduce this network activity and increase the efficiency of the entire input/output, MOSIX developers began porting the
Global file System (SYSTEM,GFS) to the Mosix cluster. The

Global file system is a shared disk cluster file system for Linux. GFS supports logging and recovery in the case of client failures. The GFS cluster node physically shares common memory through Fibre Channel or shared SCSI devices. It seems that the file system is on each node like a local machine, and GFS keeps file access synchronized in the cluster. GFS is completely symmetric, that is, all nodes are equal, and no server is a bottleneck or has any problems. GFS uses read/write buffering when maintaining all UNIX file systems.

However, GFS also has a disadvantage that it can only run on newer SCSI controllers and not run on previous products. However, GFS is a great solution for users who are equipped with new equipment and who do have the necessary clustering. The

Mosix GFs Execution is not long, but performance is good. Think about how good it feels to have a powerful giant machine at home. So, if you have several idle machines with Linux and want to have a mainframe to play with, try Mosix.

for a comprehensive understanding of Mosix, visit the website: http://www.mosix.org/.