openMosix, past, present and future

by Kris Buytaert and Matt Rechenburg

Legal openMosix is Copyright (c) 2002, 2003 by Moshe Bar.

Mosix is Copyright (c) 2002 by Amnon Barak. The Mosix is a trademark of Amnon Barak.

Linux is a Registered Trademark of Linus Torvalds.

openMosix is licensed under version 2 of the GNU General Public License as published by the Free Software Foundation.

Kris Buytaert

openMosix package maintainer

Maintainer of the openMosix-HowTo

working as a Linux/open-source consultant

Matt Rechenburg

Member of the openMosix community

openMosix developer -> openMosixview

Freelancer, working for Qlusters

clustering, an overview

openMosix internals

installation and configuration

administration/monitoring/managing

usefull utilities and examples

Recent developments in openMosix

openMosix Roadmap

Time for discussion

Clustering, an overview

Failover Clustering

( e.g Heartbeat)

Loadbalancing

(e.g openMosix, LVS)

High Performance Computing

(e.g. openMosix, MPI, LAM, PVM)

openMosix

Kernel Patch + Userland Tools

Automatic Migration of Processes to other nodes

Statistics define to which node a process can migrate

Not everything migrates, there are limitations

Advantages

No extra libraries required (pvm,mpi)

No changes to code required

No need to actually parrallellize your application

Autodisovery ==> Easy Configuration

Limitations

Threading issues (in Linux)

At one point Neo asks what happens if somebody dies in the Matrix, if he would also die in the real world. Trinity answered to him that a body (a pthread) cannot live without a mind.

(ie memory, ie address space).

Shared Memory

Programs using Shared Memory normally do not migrate, patches are available to enable migration for some Shared Memory programs.

openMosix internals

Preemptive Process Migration (PPM)

decentralized resource-sharing algorithms

(no central master/slave relationship)

user + system context

UHN -> the processes home node

well defined openMosix API

--> convert the total usage of several

heterogeneous resources into a single

homogeneous "cost"

Using openMosix

1) patch+compile kernel with openMosix patch

from http://openmosix.sf.net/

(or use the available RPM's or DEB packages)

2) reboot the system with the openMosix kernel

3) compile userspace tools

4) start the openMosix autodiscovery

5) run your programs

easy configuration

nodes are detected automatically

no need of a static cluster-map file

Autodisovery deamon

nodes may join/leave the cluster dynamically

Administrating openMosix

the openMosix commandline administration utilities

mosctl	(basic administration)

mosrun	(running applications)

setpe	(configure cluster-map)

migrate + miggroup	(manual process migration)

Administration using the /proc interface

block

lock

bring

Checkpointing on openMosix

install chpox and add the chpox module

register processe and its libraries

sequential dump process state to file(s)

restore process from dump-file

--> full-migration of processes possible

openMosix calibration & tuning

io and/or cpu intensive applications

decay value / load-statistics

speed value

locking processes

openMosix hardware tuning

increasing the network bandwith + latency

increasing the processor power

increasing the number of nodes

Running applications on openMosix

decentralized concept -> no master-node

applications installed once on one node

applications can be started on any nodes

Parallel applications on openMosix

consists of more than one process

starts processes on every cluster-nodes

uses own communication mechanism

mostly uses special parallel library

running PVM applications on openMosix

master/slave concept of PVM applications

static load/process assignment by PVM

dynamic loadbalancing by openMosix

minimizes the configuration needs for PVM

MPI applications on openMosix

MPI standard and implementations

similar master/slave concept as PVM

multiple program single data (MPSD)

limitations and common pitfalls

openMosix patch to MPICH

openMosix and sequentiel applications

parallellization of the problem to solve

splitt into subtasks by splitting data

run as MPMD (multiple program multiple data)

forking using the openMosix API

the openMosixview project

intuitive GUI

supports all common used actions

QT based user interface

8 usefull monitoring applications

easy to install

the main openMosixview application window

the configuration dialog

advanced execution

openMosixprocs, a graphical "top"

migration dialog

About remote processes

the openMosixanalyzer (load)

the openMosixanalyzer (memory)

node overview

openMosixhistory

the openMosixmigmon

3dmosmon by Johnny Cache

openMosixWebview by Ramón Pons Vivanco

GOMD stands for "general openMosix deamon"

The purpose of the gomd project is to provide:

an integrated way to collect cluster statistics

a simple and well-defined format

easy-to-use API

new tools and mechanisms

support for new openMosix tools

additional usefull utilities

oMApplet

KludgeKollection

wmomload

various bootable openMosix CD's

openMosixLoaf

Gentoo and Debian packages

openMosixblaster

..... and many more

New features in openMosix

LoadLimit

ClusterMask

GOMD

Features Checker

MigSHM

Checkpointing

Roadmap 2.4.

No new 2.4.22 versions

2.4.24 release is pending test and review.

2.4.26 release will be the last official openMosix

release for 2.4

2.4.26 is to be oMFS-less

adds the mighsm compile-time option,

adds features-checker.

eliminate oMFS support.

No other ports than AMD 64Bit Opteron

Roadmap 2.6

moving all possible code from kernel to user-space,

zero configuration operation is the goal, just as in 2.4.

separating arch dependant/independent code.

2.6 has arch directories with preliminary code

for PPC, I86-64 etc.,

summary and conclusion

transparent clustering for users and adminstrators

easy to control and monitor, lots of tuning options

provides speedup for almost any application

lots of contributed projects and tools from the community

one of the most active linux-clustering project

Question time now

?

!

Thank you !! :)

and thanks to the community,

to the linuxtag-organisators and

the sponsors

-> Qlusters, Myrinet, Unesco, NASA, AMD,

Johns Hopkins Medicine, Dolphin,

University of Arkansas, Democritos,

the university of Pisa

not to mention Debian + Gentoo

Happy clustering !

2004-02-20T13:39:32