Copyright © 1999 - 2024. All rights reserved.

General

Question:

Answer:

MOSIX Supports automatic resource discovery and dynamic workload distribution. It provides users and applications with the illusion of running on a single computer with multiple processors.

More information can be found in the About web page and the MOSIX white paper.

Question:

Answer:

MOSIX^® is a registered trademark of Amnon Barak and Amnon Shiloh.

Question:

Answer:

Question:

Answer:

In a MOSIX cluster/multi-cluster there is no need to modify or to link applications with any library, copy files or login to remote nodes, or even assign processes to different nodes, including nodes in different clusters - it is all done automatically.

The outcome is ease of use, better utilization of resources and near maximal performance.

Question:

Answer:

Users can run their regular sequential and parallel applications as if they use one computer (node), while MOSIX automatically (and transparently) seek resources and migrate processes among nodes to improve the overall performance.

This is accomplished by on-line algorithms that monitor the state of the system-wide resources and the running processes, then, whenever appropriate, initiate process migration to:

1. Balance the load;
2. Move processes from slower to faster nodes;
3. Move processes from nodes that run out of free memory;
4. Preserve long-running guest processes when clusters are about to be disconnected from the multi-cluster.

Question:

Answer:

Question:

Answer:

Question:

Answer:

Question:

Answer:

MOSIX-1 for Linux-2.4 managed a single cluster.

Question:

Answer:

Note that such processes run in a sandbox, preventing them from accessing local resources in the hosting nodes.

Question:

Answer:

Question:

Answer:

Question:

Answer:

Question:

Answer:

This means that:

1. Users can login on any node and do not need to know where their programs run.
2. No need to modify or link applications with special libraries.
3. No need to copy files to remote nodes.
4. Automatic resource discovery: whenever clusters or nodes join (disconnect), all the active nodes are updated.
5. Automatic workload distribution by process migration, including load balancing, process migration from slower to faster nodes and from nodes that run out of free memory.

Question:

Answer:

MOSIX provides the following features to manage such clouds:

1. Support of disruptive configurations: clusters can join or leave the cloud at any time.
2. Clusters could be shared symmetrically or asymmetrically. For example, the owner of cluster A can allow processes originating from cluster B to move in but block processes originating from cluster C.
3. A run-time priority for flexible use of nodes within and among groups. For example, to partition a cluster among different users.
4. Each cluster owner can assign priorities to processes from other clusters. For example, the owner of cluster A can assign higher priority to processes from cluster B and lower priority to processes from cluster C. This way, when guest processes from cluster B wish to move to cluster A, they will push out guest processes from cluster C (if any).
5. Local and higher priority processes force out lower priority processes.
6. Migrated processes to/from a disconnecting cluster are moved out/back, so that long-running migrated processes are not killed.

Question:

Answer:

Individual nodes may have different number of cores, different speed, different memory size or I/O devices.

Question:

Answer:

When a checkpoint is performed, the image of the processes is saved to a file. The process can later recover itself from that file and continue to run from that point.

For successful checkpoint and recovery, a process must not depend heavily on its Linux environment. For example, for security reasons processes with setuid/setgid privileges or processes with open pipes or sockets can't be checkpointed.

Checkpoints can be triggered by a program, by a manual request and/or automatically - at regular time intervals, see the next question.

Question:

Answer:

1. By providing the "-C< file-name> " and "-A< integer-number>" flags to mosrun. This will perform a periodic checkpoint every "integer-number" of minutes and the checkpointed file will be saved to the files "file-name.1", "file-name.2", etc. Read the mosrun manual for details.
2. By using the "migrate < pid> checkpoint" command to perform a checkpoint at a specific time externally to the program. Read the migrate command manual for details.
3. From within the program, by using the MOSIX checkpoint interface.

  /proc/self/checkpoint
  /proc/self/checkpointfile
  /proc/self/checkpointlimit
  /proc/self/checkpointinterval

These pseudo-files allow the process to modify its checkpoint parameters and to trigger a checkpoint operation.

Question:

Answer:

#include < stdlib.h>
#include < unistd.h>
#include < string.h>
#include < stdio.h>
#include < fcntl.h>
#include < sys/stat.h>
#include < sys/types.h>

// Setting the checkpoint file from withing the process
// This can also be done via the -C argument to mosrun
int setCheckpointFile(char *file) {
     int fd;

     fd = open("/proc/self/checkpointfile", 1|O_CREAT, file);
     if (fd == -1) {
        return 0;
     }
     return 1;

}

// Triggering a checkpoint from within the process
int triggerCheckpoint() {
     int fd;
     fd = open("/proc/self/checkpoint", 1|O_CREAT, 1);
     if(fd == -1) {
        fprintf(stderr, "Error doing self checkpoint \n");
        return 0;
     }
     printf("Checkpoint was done successfully\n");
     return 1;
}

int main(int argc, char **argv) {
     int j, unit, t;
     char *checkpointFileName;
     int checkpointUnit = 0;

     if(argc < 3) {
        fprintf(stderr, "Usage %s < checkpoint-file> < unit> \n", argv[0]);
        exit(1);
     }

     checkpointFileName = strdup(argv[1]);
     checkpointUnit = atoi(argv[2]);
     if(checkpointUnit < 1 || checkpointUnit > 100) {
        fprintf(stderr, "Checkpoint unit should be > 0 and < 100\n");
        exit(1);
     }

     printf("Checkpoint file: %s\n", checkpointFileName);
     printf("Checkpoint unit: %d\n", checkpointUnit);

// Setting the checkpoint file from within the process (can also be done using
// the -C argument of mosrun
     if(!setCheckpointFile(checkpointFileName)) {
        fprintf(stderr, "Error setting the checkpoint filename from within the process\n");
        fprintf(stderr, "Make sure you are running this program via mosrun\n");
        return 0;
     }

// Main loop ... running for 100 units. change this loop if you wish
// the program to run do more loops
     for( unit = 0; unit < 100 ; unit++ ) {
        // Consuming some cpu time (simulating the run of the application)
        // Change the number below to cause each loop to consume more (or) less time
        for( t=0, j = 0; j < 1000000 * 500; j++ ) {
          t = j+unit*2;
       }
       printf("Unit %d done\n", unit);

// Trigerring a checkpoint request from within the process
       if(unit == checkpointUnit) {
          if(!triggerCheckpoint())
             return 0;
          }
       }
       return 1;
}

To compile: gcc -o checkpoint_demo checkpoint_demo.c
To run: mosrun checkpoint_demo

A typical run:
> mosrun ./checkpoint_demo ccc 5
Checkpoint file: ccc
Checkpoint unit: 5
Unit 0 done
Unit 1 done
Unit 2 done
Unit 3 done
Unit 4 done
Unit 5 done
Checkpoint was done successfully
Unit 6 done
Unit 7 done
Unit 8 done
^C

The program triggered a checkpoint after unit 5. The checkpointed file was saved in ccc.1.
After unit 8 the program was killed.

To restart:
> mosrun -R ccc.1
Checkpoint was done successfully
Unit 6 done
Unit 7 done
Unit 8 done
Unit 9 done
Unit 10 done
...

The program was restarted from the point right after it was checkpointed.

Question:

Answer:

Question:

Answer:

MOSIX can run in a virtual machine in any platform that supports virtualization.

Question:

Answer:

Note that the total number of processors used by the VMs should not exceed the number of physical processors.

Question:

Answer:

Question:

Answer:

Specifically:

1. Migrating a whole VM requires the transfer of much more memory. Even in the case of "live-migration" (that works only for certain types of processes - not all), this can overload the network more.
2. Once in a VM, a process that splits (using "fork") can not get independent resources for each split process: the original process with all its children will have to remain together on the same VM.
3. Processes within a VM can not maintain most of their connections (pipes, signals, parents/children, IPC, etc.) with other processes, either on the generating host or in other VM's.
4. Allocating a full virtual-disk image for each process can consume a large amount of disk space.
5. Current VM technology doesn't support migration between different clusters that are on different switches.

Question:

Answer:

Question:

Answer:

Question:

Answer:

If you use a common NFS root directory for your cluster, you can install MOSIX in that directory.

Otherwise, on a small cluster, you can install MOSIX node by node.

Question:

Answer:

Question:

Answer:

Question:

Answer:

It can display the number of active nodes (type t), loads (l), size of total/used memory (m), dead nodes (d) and relative CPU speeds (s).

Question:

Answer:

Once you modify configuration files, the changes will take effect within a minute.

After editing the list of nodes in your cluster ("/etc/mosix/mosix.map") you need to run "mossetpe", but if you are using "mosconf" to modify the local configuration, then there is no need to run "mossetpe".

Question:

Answer:

Next, using "mosconf", select:   "1. Which nodes are in this cluster",

then type "+" to turn on the advanced features,

then type "a" to define aliases and for each node in the other cluster, define its Inifiniband IP address (despite being unreachable from the node that is being configured) as an alias to its Ethernet IP address.

Question:

Answer:

mosrun -e awk 'BEGIN {for(i=0;i<100000;i++)for(j=0;j<100000;j++);}'

First you should see an increase of the load in one node. After a few seconds, if the process migration works you will see how the load is spread among the nodes.

If your nodes are not of the same speed then more processes will run in the faster nodes.

Question:

Answer:

Question:

Answer:

Question:

Answer:

UDP ports 249 and 253.

Question:

Answer:

Question:

Answer:

Question:

Answer:

1. In the login script add the commands:
   > mosctl block
   > mosctl expel &

   The "mosctl block" command prevents new remote processes from migrating to that workstation.
   The "mosctl expel &" move out MOSIX guest processes. Note that an & is used after the expel command, since expelling processes may take some time and we don't want the user login process to hang. The processes are expelled while the user logs in.

2. On logout, run the command:
   > mosctl noblock

   This command allows remote processes to migrate to the workstation.

   On a Debian system using GDM the appropriate file to add this command is /etc/gdm/PostSession/Default .

Note that when adding the mosctl commands to the GDM script you shouldn't interfere with the correct work of gdb.

Question:

Answer:

Question:

Answer:

Question:

Answer:

Question:

Answer:

> mosnative {threaded_program} [program-args]...

Question:

Answer:

Question:

Answer:

Note that the amount and frequency of I/O is taken into account and weighted against other considerations in making such a decision.

The direct-communication (migratable socket) can reduce this slow-down affect for I/O between communicating processes.

Question:

Answer:

Otherwise, MOSIX is not different from Linux: depending on the particular needs of the process, whatever approach (other than shared-memory) that is best in Linux is best on MOSIX. It could be pipes, SYSV-messages, UNIX-sockets, TCP-sockets and files.

Obviously files can be slow when they usually require writing on a physically-moving surface and/or networking. On the other hand, Linux has very good caching mechanisms for local files.

Question:

Answer:

Question:

Answer:

Direct communication allows processes to exchange messages directly between migrated processes, bypassing their home-nodes.

Question:

Answer:

Question:

Answer:

Question:

Answer:

Question:

Answer:

2. When allocating a new job ("srun", "salloc" or "sbatch"), use the flag "-Cmosix\*{MHN}", where "MHN" is the desired number of MOSIX home-nodes for the job.

3. Precede your commands with "mosrun [mosrun-parameters]". The mosrun-parameters should normally include "-b" and "-m{mem}".

4. Do not specify memory-requirements in "srun", because this does not work with overcommit.

Question:

Answer:

2. Even with overcommit, SLURM does not allow more than 128 tasks per node.

Question:

Answer:

Question:

Answer: