Multiple Apache Karaf containers

Natively, Apache Karaf provides a high availability mechanism based on a locking system. It's a master-slaves configuration, following an active/passive pattern. Apache Karaf supports two kinds of locks, which are as follows:

• Lock on the filesystem

• Lock on a database (JDBC)

When the first Apache Karaf instance starts, if the lock is available, the instance acquires the lock and becomes the master.

If another instance starts, as the lock is not available (held by the master), the instance is in standby (slave) mode and periodically checks the lock.

When you use a lock on a filesystem, all instances have to share the same filesystem. The lock is a simple file. If the Apache Karaf instances are located on different machines, it means that the filesystem storing the lock has to be available for all machines (using NFS, CIFS, SAN, and so on).

In order to enable the filesystem locking system, you have to update the etc/system.properties configuration file as follows:

karaf.lock=true
karaf.lock.class=org.apache.karaf.main.SimpleFileLock
karaf.lock.dir=/path/to/lockfile
karaf.lock.delay=10

When a shared filesystem is not an option (for security or infrastructure reasons, for instance), you can use a database to store the lock. With database locking, Apache Karaf uses a lock on a table (the KARAF_LOCK table by default). Any database that supports JDBC can be used.

The configuration is also defined in the etc/system.properties configuration file as follows:

karaf.lock=true
karaf.lock.class=org.apache.karaf.main.DefaultJDBCLock
karaf.lock.level=50
karaf.lock.delay=10
karaf.lock.jdbc.url=jdbc:derby://dbserver:1527/sample
karaf.lock.jdbc.driver=org.apache.derby.jdbc.ClientDriver
karaf.lock.jdbc.user=user
karaf.lock.jdbc.password=password
karaf.lock.jdbc.table=KARAF_LOCK
karaf.lock.jdbc.clustername=karaf
karaf.lock.jdbc.timeout=30

You have to copy the JDBC driver JAR file into the lib/ext folder. Apache Karaf provides the JDBC lock implementation dedicated to some specific databases (DefaultJDBCLock is the generic one, OracleJDBCLock for Oracle databases, DerbyJDBCLock for Derby databases, MySQLJDBCLock for MySQL databases, PostgreSQLJDBCLock for PostgreSQL databases, and SQLServerJDBCLock for Microsoft SQLServer databases).

The Apache Karaf locking mechanism provides a good solution for high availability. However, only one Apache Karaf instance is active (the master); all other instances are inactive (standby/master).

In order to provide both high availability and performance scalability, having multiple active Apache Karaf instances is a great advantage.

Provisioning clusters

Imagine you have a farm of Apache Karaf containers, each on a different machine. If you want to provision an OSGi application on the container instances, you have to connect on each container and install the features.

This means that you have to perform the following tasks:

• Log on on each container in order to perform the same action again and again

• Eventually, adapt the configuration depending on each local instance (port number, file path, and so on)

• Add new instances, which will require the same action again

Basically, this means a lot of human actions with a potential risk of error. This is where a provisioning cluster helps.

The purpose of a provisioning cluster is to keep multiple container instances synchronized. For Apache Karaf, it means that a change in the status of a resource will be broadcasted to all the containers' members of the same cluster.

A resource can be a bundle, feature, configuration, or any kind of resource local to a node. This means that local actions will send an event to update the other members of the cluster.

On the other hand, it's also possible to create a cluster event that is sent to all the members to update them.

Basically, this means that a provisioning cluster performs the following tasks:

• Creates event: This event can be created due to a local change or by hand

• Broadcasts event: This event is sent to the members of the cluster

If provisioning is the first purpose of a provisioning cluster, it doesn't mean that it can't provide additional features useful in a cluster topology. For instance, centralized logs, load balancers, session replication, and so on are interesting features that can be provided on top of a provisioning cluster. In the next chapters, we will see Karaf Cellar as a provisioning cluster solution.