Mosix: Powerful cluster Linux Solution

Mosix: A Powerful cluster Linux solution-general Linux technology-Linux programming and kernel information. For details, refer to the following section. Linux seems to be crazy about the concept of cluster. Almost just a few months ago, the only solution was to write the cluster software on its own to achieve high practicability. Of course, in terms of scientific clusters, you can also use Beowulf or the cluster library that sends messages (such as PVM ). However, apart from earlier solutions, Linux is far behind in terms of proprietary and commercial clusters.

However, the current development seems quite gratifying. SGI Failsafe has been basically transplanted; Linux High Availability (efficient Linux) has been launched; Red Hat has released Piranha cluster software; and so on.

There are also some feasible scientific cluster solutions, among which Mosix is the most recommended. Mosix uses a single system graphics (SSI) cluster. The SSI cluster is popular because they make users feel like they are working on a giant computer, rather than a group of individual nodes. You can log on to any node in the Mosix cluster and start the programs running on any node in the cluster, as long as the cluster software in the kernel thinks these programs can run. If the DNS running is correct, you only need to telnet to cluster.mynet.com. The DNS loop function allows them to randomly log on to a node and its branches, and then branch and branch.

Assemble the Mosix Cluster

Some Mosix cluster servers can reach the top 50 super computers with the strongest performance in the world. If there are enough idle computer devices, consider assembling a Mosix cluster by yourself.

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

The clock speed of the three dual-CPU computers ranges from 933 MHz to MHz, and the total memory is about GB.

8 single-CPU computers, clock speed from MMX266MHz to 933 MHz, total memory is 1.8 GB.

The storage space uses the Network Appliance F720, which has approximately GB of disk space and makes the file system readable to all computers. It is very important that all machines must have a unified user ID and group ID. Otherwise, problems may occur when accessing data.

These machines are connected through a 100/1000 Mbit network and an optical converter is placed in the center.
In this design, the Network Appliance storage server is used to implement central storage. All cluster nodes are centered around it. Some nodes use 1000 Mbit NICs, and some use an older 100 Mbit. Mosix measures the wait time between each node and determines this factor when the load on a node is too high to transfer its program to another node. The NIC used here is a product of Phobos, And the Converter uses Nbase.

Download two RPMs from the above website and run the "RPM-install xxx. rpm" command to install them. One RPM is for the 2.2.16 kernel, with all compiled Mosix extensions. The other is a set of Mosix user space commands used by the monitoring cluster.

Restart each node to enter the Mosix kernel, and the work is nearing completion. The last thing to do is to let each node know the location of other nodes. To do this, edit a/ing file/etc/mosix. map and specify all other nodes and their IP addresses in the file, which is similar to the/etc/hosts file.

Check whether all nodes can see each other and run the "mon" monitoring program. It displays the charts of all worker nodes and their respective load levels, memory consumption, and other information.

Mon monitoring program running interface

Start the Cluster

Now let's try to create a process, such as the dnetc RC5 program in distributed.net. Then add several other processes. Now let's take a look at the "mon" program and you will find that your computer is under high load, while others are still very low. But soon, the load on your node will gradually decrease, while on other nodes, it will rise as some processes on your machine are transferred to other better nodes. Mosix automatically adjusts the transfer time and node location without user control.

In order to have a specific concept for the powerful performance of the new cluster, I wrote a set of scripts on Linux outside the cluster, start the program on a node and determine the running status of the cluster. These programs are composed of a mass calculator, an interactive void program, and a shared memory usage process.

When the node is out of the Cluster (dual-cpu piii 933-MHz, 768 mb ram), the machine has a maximum of 20 prime memory processors, 40 interactive tasks, and about 30 shared memory processes. After running these programs, almost no logon operation can be performed, and no additional load can be added.

The situation in the cluster is quite different, on the largest node, you can run more than 450 prime number Referer, hundreds of shells, and about 210 shared memory tasks (the memory reference mode stipulates that shared memory programs cannot be transferred to other nodes .)

If you want to complete these tasks on a single computer, you don't know how high the configuration is required, but at least not below the Sun E6000 or HP V2000 Mainframe level, they are priced at up to $100,000. Now all these hardware costs less than $20 thousand, which is what Linux has done.

Network File System

Creating a single graph cluster on multiple nodes makes sense only when the program is transferred to another node and its devices and files are still visible. Mosix does not require central storage. What is the actual situation?

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

Of course, this will increase the burden on input/output intensive programs. To reduce this network activity and improve the efficiency of the entire input/output, Mosix developers start
The Global File System (GFS) is transplanted to the Mosix cluster.

The Global File System is a Linux shared disk cluster file system. GFS supports log and recovery when the client fails. The GFS cluster node physically shares the common memory through the fiber Channel or shared SCSI device. It seems that the file system is like a local machine on each node. GFS keeps file access synchronized in the cluster. GFS is completely symmetrical, that is, all nodes are equal, and no server is a bottleneck or has any faults. GFS uses read/write buffering to maintain all Unix file systems.

However, GFS also has a disadvantage that it can only run on newer SCSI controllers, rather than on previous products. However, GFS is a good solution for users with new devices and clusters.

The execution time of Mosix GFS is not long, but the performance is indeed good. Think about how nice it would be to have such a powerful giant computer at home. If you have several idle Linux machines and want to have a mainframe to play with them, try Mosix.