Rhino versions prior to 3.0.0 had two modes of operation for managing the activation state of services and resource adaptor entities: per-node and symmetric. From Rhino 3.0.0 these two modes were combined and have been superseded by default desired state which can be overridden by per-node desired state. Per-node desired state overrides default desired state if present. Default desired state is effective if no per-node desired state exists.
When using Rhino 3.2 or later configured in pool clustering mode, the symmetric activation state mode is not available at all. Pool cluster nodes only support the configuration of desired state, and any given pool cluster node can only have per-node desired state set for itself, e.g. node 101 can have per-node desired state set for itself, but cannot have per-node desired state set for node 102. This is because management state such as desired state is not automatically replicated between pool cluster nodes, so setting per-node desired state for node 102 on node 101 would not have any effect on node 102 and thus would be misleading and confusing. This also means that default desired state set for a pool cluster node only applies to that node, and different pool cluster nodes could have different default desired state. Because of this, using per-node state in a pool clustering configuration is somewhat redundant as default desired state could be used instead, but Rhino still allows both to be set.
The actual state for all functions is always maintained on a per-node basis.
Per-node activation state
In per-node activation state mode, Rhino maintained activation state for the installed services and created resource adaptor entities in a namespace on a per-node basis. That is, the SLEE recorded separate activation state information for each individual cluster node.
The per-node activation state mode was the default mode in a newly installed Rhino cluster.
Symmetric activation state
In the symmetric activation state mode, Rhino maintained a single cluster-wide activation state view for each installed service and created resource adaptor entity. So, for example, if a service was activated, then it was simultaneously activated on every cluster node. If a new node joined the cluster, then the services and resource adaptor entities on that node each entered the same operational state as for existing cluster nodes.
Default and per-node desired state and actual state
In Rhino 3.0.0 and later, a default activation state for the SLEE, an installed service, or a created resource adaptor entity is configured for all nodes in the cluster with optional overrides configured on a per-node basis. The effective desired state for a node is the per-node state, or the default state if no per-node state exists for a given function. If it is desired to manage the state of a cluster in the way previously served by symmetric activation state mode, the default state should be used and per-node state left unconfigured. Commands for managing per-node desired state can be found under the topic Per-Node Desired State.
In operation, Rhino nodes have an actual state that is the current operational state. The actual state follows the desired state with a per-node convergence subsystem managing transitions between actual states as the lifecycle rules of system functions allow.
These terms are defined under Declarative Configuration Concepts and Terminology.
