
by fault tolerant Resource Adaptors). Because of the clustering infrastructure and the single management image, this allows
even applications configured without fault tolerance to offer high availability.
Fault Tolerance means that in the event of a failure.
1. The SLEE is continuously available for management operations.
2. Each deployed service is continuously available.
3. Each services’ session is continuously available
4. A proportion (>95%) of sessions residing on a failed cluster member will be failed-over to another cluster member.
For example "phone calls" being processed by that cluster member will be able to be processed on another cluster member.
With fault tolerant Services, SBB entities and their state are replicated across all nodes in the cluster using a replicated version
of the main working memory. If a cluster node fails or a network segmentation occurs, the replicated SBB state is still visible
to other nodes. With fault tolerant Resource Adaptors, all activities created by a fault tolerant RA are replicated to other
nodes in the cluster. If the activity creating node fails another cluster member will be able to ‘adopt’ the activity and assume
responsibility for processing events it produces.
High Availability means that in the event of a failure:
1. The SLEE is continuously available for management operations.
2. Each deployed services is continuously available.
3. Each services’ session is not continuously available.
4. Any session being executed on a cluster member which fails will be destroyed.
For example “phone calls” being processed by that cluster member will fail.
With “high availability”, state is not replicated across cluster nodes, so if a node failure or network segmentation occurs some
activities will be lost, however the application will continue running and still be available on other nodes.
16.4.2 Fault Tolerant Services
In Rhino the persistent state of applications managed by the container is stored in the main working memory. This state includes
SBB entity state, activity context naming bindings and SLEE timers. With a fault tolerant service, Rhino uses a replicating
version of the main working memory (called MemDB). The primary difference between a fault tolerant and a non-fault tolerant
service is replication of state - when a non-fault tolerant service is deployed a non-replicating version of the main working
memory is used (called MemDB-Local). With replicating main working memory, committed changes to an applications state
are visible to other nodes in the cluster, allowing the application to continue operating after a cluster member fails.
When a service is deployed Rhino examines the (optional)
oc-service.xml
deployment descriptor for extended service prop-
erties. One of the supported service properties,
replicated
is a flag which determines whether that services state should be
replicated. If no value is specified Rhino assumes the default value of
False
. The example
oc-service.xml
below shows a
configuration for a fault tolerant service.
<?xml version="1.0"?>
<!DOCTYPE oc-service-xml PUBLIC
"-//Open Cloud Ltd.//DTD JAIN SLEE Service Extension 1.0//EN"
"http://www.opencloud.com/dtd/oc-service-xml_1_0.dtd">
<oc-service-xml>
<service id="pingservice">
<service-properties replicated="True"/>
</service>
</oc-service-xml>
The default for services in Rhino is if a service is deployed without the
replicated
flag set to true then its state will not be
replicated and it will not be fault tolerant.
Open Cloud Rhino 1.4.3 Administration Manual v1.1 98
Kommentare zu diesen Handbüchern