openlava is made of a set of scheduling and resource management algorithms built on top of Unix system calls, (man page 2) and C Standard Library (man page 3). The code base is in C programming language and the entire system is made of several daemons and libraries. API are available to communicate with the daemons, to control and analyze the overall system behavior. openlava organizes hosts into a cluster which is a set of hosts sharing commong accounts and file systems, althought shared file system is not a requirement. openlava uses standard TCP/IP and UDP/IP so there is no restriction to network layout. Clusters up to thousands of cores are currently in use.

openlava core

openlava base

The core is composed of what is called openlava base, it is made of two main daemons LIM and RES and the API to communicate with them. Both daemons are installed on each host of the openlava cluster.

  1. LIM

Every machine in the openlava cluster has a LIM process. The name stands for openlava load information manager its task is to monitor machine’s load and exchange these information with the master LIM. On one host in the cluster LIM acts as a master, its task is to collect the load and status information from all other LIMs and provides them to the applications via API or command line interface. In other words LIMs are organized into a one level tree structure, with the master LIM as the root of the tree. If the master becomes unavailable for whatever reason, the next LIM configured in the cluster file takes its role. The order in which the daemons become masters is the order in which they are configured in the lsf.cluster.openlava file.

  1. RES

The name stands for openlava remote execution server its task is to execute user tasks on remote hosts. It provides the same command remote execution functionality of ssh or the old rsh and it does support the pseudo terminal as well. Unlike ssh/rsh it does have an api interface allowing users to perform remote execv() functions from their programs. To start a job remotely the base library contacts the RES on the remote host, the NIOS network I/O server on the sending machine takes care of the terminal input output from the remote process.

The main difference between the openlava and other remote execution software is the ability to run the commands on the most suitable host to perform the given task, the definition of most suitable host is up to the application. For example an application can define a policy to run its task on hosts having at least a certain amount of ram, disk space or core used less than a given percent etc, then specify this policy as resource requirement to the openlava remote execution api, then openlava will guarantee that all hosts on which the application is launched do satisfy the specific resource requirement. If there are no host that do so, the application will not run. openlava build on top services


openlava batch

openlava batch transparently executes user jobs in the cluster using batch queues. Users submit batch jobs to a queue, which can have access to many hosts on your network and will automatically run jobs as soon as a suitable host is available. The system is built on top of the openlava base system, its two main components are the master batchd daemon MBD and slave batch daemon SBD.

  1. MBD

Responsible for executing scheduling policies and dispatch users’ jobs base on them. Beside being a scheduler MBD is a central system hub that dispatches user events and messages to job, collects job statistics and provide overall system information to users.

  1. SBD

Responsible for starting the jobs, monitor them act on them based on user request and collect their status once they terminate and report it to user.


Other possibile services

Many distributed services can be built on top of openlava remote execution. The next architectural picture shows the existing openlava distributed batch system and a resource scheduler that could be possibly built. architecture picture 2. openlava distributed batch system

openlava cluster administrator

openlava cluster has one or more administrators. An administrator is a user account that has permission to change the configuration and perform other maintenance functions.