Note: This content is accessible to all versions of every browser. However, this browser may not support basic Web standards, preventing the display of our site's design details. We support the mission of the Web Standards Project in the campaign encouraging users to upgrade their browsers.
Friday, October 01, 2004 09:34 // SANE 2004, RAI, Amsterdam, Nederlands // href
a presentation for Kris Buytaert
OpenMOSIX is a platform for HPC clustering.
An OpenMOSIX cluster is self organizing. It has no central node. New nodes are discovered as they join the cluster.
Each process is split in two parts, the frontend part which does all the IO and a backend part which does 'the math'. The frontend node stays where it was started. The backend will migrate to another node where it will be executed. Backend parts can continue to migrate at a later stage if the situation changes.
OpenMOSIX uses an economics model to figure out where a process should migrate to.
OpenMOSIX does not require any special libraries to run application. All the core functionality is in the kernel. There is a set of special tools for administration of the cluster. A lot of configuration information is in the /proc interface.
Applications do not have to be recompiled to run on an OpenMOSIX cluster.
For performance reasons, there is no security between the nodes of an OpenMOSIX cluster. So the setup has to be done on a private network.
OpenMOSIX does not do Batch queuing. It can be combined with condor for this to get the best from both worlds (excellent scheduling from condor and simple process migration and check-pointing from OpenMOSIX.
New Features: Migration of shared memory, port to 2.6, no more OpenMOSIX file system (there are enough cluster file-systems already like luster or gfs), migration of most features into user-space.
HOWTO: (www.faqs.org ...)
Homepage: (openmosix.sourceforge.net ...)
OpenMOSIX Knoppix (bofh.be ...)
Friday, October 01, 2004 10:23 // SANE 2004, RAI, Amsterdam, Nederlands // href
a presentation by Marco Pfatschbacher
Normally a load-balancer is a physical box sitting in front of the nodes doing the actual work. In this setup the load-balancer becomes a single point of failure. To have high reliability, we need a second load-balancer with fail-over.
Marco presented a method to setup a group of hosts with load sharing/balacing functionality. Instead of using a dedicated load-balancer, the worker nodes are sitting on the same Ethernet segment and each node receives all traffic and just consumes the traffic it is supposed to use.
In order to receive all traffic, all nodes setup a virtual interface with the same Ethernet address and ip number. Simple repeaters have no problems with this, but switches are normally not happy when they do see the same mac address on several ports. The trick to solve this problem, is to configure the physical interfaces to respond with proxy ARP responses telling the switch the Ethernet address of the virtual interface. This will make the switch to always flood the network with traffic destined for the IP address of the virtual interface.
The nodes now use a distributed filtering approach (nms.lcs.mit.edu ...) to decide for each incoming TCP connection which node is going to handle it.
High-Availability is implemented through a small daemon ifstated and CARP (www.newsforge.com ...) to redistribute incoming connections appropriately if one node becomes unavailable.
Known Limitations and further work: Load-Sharing is static and stateful packet filtering (PF) can not be used.
Friday, October 01, 2004 14:33 // SANE 2004, RAI, Amsterdam, Nederlands // href
A talk by Sjoera Nas
Bits of Freedom is an Dutch NGO funded by private parties. Their topics are privacy, freedom of speech, spam, e-voting and copyright. In September 2004 they did a test how simple it was to get Dutch ISPs to take down a web page which contains an obviously public domain text.
7 out of 10 providers acted swiftly by taking down the alleged violating document.
The full paper: (www.bof.nl ...)
Content © by Tobias Oetiker