THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
anchortoptop
6.7. Configuring Failover Deployments
This chapter will demonstrate how to configure failover deployments.
Simple
...
lock file
The Simple Lock File simple lock file mechanism is intended for failover configurations where instances reside on one the same host machine.
To use this feature the following must be set on each system in the master/slave setup:, edit the $KARAF_HOME/etc/system.properties file
...
as follows on each system in the master/slave setup:
...
Simple Lock File with container level locking.
The Container Level locking mechanism allows bundles to be loaded into the slave kernel instance in order to provide faster failover performance. The Container Level refers to the starting priority assigned to each bundle in the OSGI container. These start levels are specified in $KARAF_HOME/etc/startup.properties, in the format jar.name=level. The core system bundles have levels below 50, where as user bundles have levels greater than 50.
Level | Behavior |
|---|---|
1 | A 'cold' standby instance. Core bundles are not loaded into container. Slaves will wait until lock acquired to start server. |
<50 | A 'hot' standby instance. Core bundles are loaded into the container. Slaves will wait until lock acquired to start user level bundles. The console will be accessible for each slave instance at this level. |
>50 | This setting is Not recommended as user bundles will be started. |
To use this feature the following must be set on each system in the master/slave setup:
- $KARAF_HOME/etc/system.properties file updated to reflect the below entries.
| No Format |
|---|
karaf.lock=true
karaf.lock.level=50
karaf.lock.delay=10
|
Please note that when using a 'hot' spare on the same host the jmx remote port will need to be configured to a unique port to avoid bind conflicts. The servicemix start script can be edited to include the following:
| No Format |
|---|
DEFAULT_JAVA_OPTS="-server $DEFAULT_JAVA_OPTS -Dcom.sun.management.jmxremote.port=1100 -Dcom.sun.management.jmxremote.authenticate=false"
|
...
Note: Ensure that the karaf.lock.dir property points to the same directory for both the master and slave instance, so that the slave can only acquire the lock when the master releases it.
JDBC locking
...
The JDBC locking mechanism is intended for failover configurations where instances exist on separate machines. In this deployment, the master instance holds a lock on a servicemix Karaf locking table hosted on a database. If the master losses this lock then an awaiting loses the lock, a waiting slave process may gain gains access to the locking table , then and fully start starts its container. The former master upon detection of lock loss will switch run levels as configured by lock level.
To use this feature, do the following must be set on each system in the master/slave setup:
- Classpath updated Update the classpath to include the JDBC driver.
- $KARAF_HOME/etc/system.properties file updated to reflect the below entries.
- Update the
$KARAF_HOME/bin/karafupdated script to have unique jmx JMX remote port set if instances reside on the same host.
...
- Update the
$KARAF_HOME/etc/system.propertiesfile as follows:
...
Note:
- Will fail if jdbc JDBC driver is not on classpath.
- The database name "sample" will be created if it does not exist on the dbdatabase.
- First The first Karaf instance to acquire the locking table is the master instance.
- If the connection to the DB database is lost then , the master instance will attempt tries to gracefully shutdown, allowing a slave instance to become master when the DB database service is restored. The former master will require manual restart.
JDBC locking on Oracle
If you are using Oracle as your database in a JDBC locking scenario, the karaf.lock.class property in the $KARAF_HOME/etc/system.properties file must point to org.apache.felix.karaf.main.OracleJDBCLock.
Otherwise, configure the system.properties file as normal for your setup, for example:
...
As with the default JDBC locking setup, the Oracle JDBC driver JAR file must be in your classpath. You can ensure this by copying the ojdbc14.jar into Karaf's lib folder before starting Karaf.
Note: The karaf.lock.jdbc.url requires an active SID, which means you must manually create a database instance before using this particular lock.
locklevel
Container-level locking
Container-level locking Container Level locking mechanism allows bundles to be loaded preloaded into the slave kernel instance in order to provide faster failover performance. Container-level locking is supported in both the simple file and JDBC locking mechanisms.
To implement container-level locking, add the following to the $KARAF_HOME/etc/system.properties file on each system in the master/slave setup:
...
The karaf.log.level property tells the Karaf instance how far up the boot process to bring the OSGi container. Bundles assigned the same start level or lower will then also be started in that Karaf instance.
Bundle The Container Level refers to the starting priority assigned to each bundle in the OSGI container. These start levels are specified in $KARAF_HOME/etc/startup.properties, in the format jar.name=level. The core system bundles have levels below 50, where as user bundles have levels greater than 50.
Level | Behavior |
|---|---|
1 | A 'cold' standby instance. Core bundles are not loaded into container. Slaves will wait until lock acquired to start server. |
<50 | A 'hot' standby instance. Core bundles are loaded into the container. Slaves will wait until lock acquired to start user level bundles. The console will be accessible for each slave instance at this level. |
>50 | This setting is Not not recommended as user bundles will be started. |
...
Note: When using a 'hot' spare on the same host you need to set the JMX remote port to a unique value to avoid bind conflicts. You can edit the Karaf start script to include the following:
...
...
...