Non-Clusterable Adapters in a Clustered Installation
In a cluster, the connection of adapters to external resources makes some of those adapters deployable only to a certain node in a cluster. Adapters that can be deployed to all cluster nodes can share the load across all cluster nodes, facilitating scalability and load balancing.
- Resource affinity to specific nodes.
For example, the File System adapter needs to be deployed on a specific node where it needs access to the local file system, where it collects and extracts files.
- Connectivity restrictions to external resources.
For example, with the IBM® Sterling Connect:Direct® and IBM Sterling Connect:Enterprise® servers, the connection parameters are configured for a specific connection and used only by a single adapter, thus forcing it to be deployed on a specific node.
All adapters that use perimeter servers come under this category.
- Licensing restrictions.
There might be a limit on the number of instances that can be deployed in an installation.
For example, the SAP and WebMethods Enterprise adapters might not be fully clustered across all server instances because of the licensing agreement.
The list of non-clusterable adapters is maintained in the clusteradapter.properties file. This file also can include customized adapters, along with the default list of adapters.
- File System adapter
- The file system must be mounted on a common drive, which can be accessed from all the nodes.
- Use a clustered file system.
- Sterling Connect:Direct and Sterling Connect:Enterprise
The Sterling Connect:Direct Server adapter and Sterling Connect:Direct Requester adapter establish sessions with Sterling Connect:Direct. The Sterling Connect:Enterprise adapter establishes a session with Sterling Connect:Enterprise.
Neither of these sessions are tied to a resource. Neither the Sterling Connect:Direct nor the Sterling Connect:Enterprise adapters are cluster-enabled.
- Command Line2 adapter
The commands executed by this service are supported and valid on all of the nodes.
Also, all adapters that use perimeter services are not clusterable and are deployed to a specific node attached to the perimeter server to which they are connected. When configuring these services, choose either node1 or node2 in the environment section.
For the full list of non-clusterable adapters, refer to the clusteradapter.properties file.
- FTP Client adapter
- HTTP Client adapter
- SFTP Client adapter
- Sterling Connect:Direct adapter
- Sterling Connect:Enterprise adapter
- SSH Key Grabber adapter
- SSH Cert Grabber adapter
- SWIFTNet 7 adapter
- SWIFTNet Server adapter
The following table classifies adapters to be either clusterable or non-clusterable. It also provides ways to configure for certain adapters which by default are not clusterable but can be configured differently to be deployed on two or more nodes in cluster to support failover.
|Clusterable by Default||Clusterable using Service Groups, etc.|
|BP Fault Log||Command Line2 Adapter|
|IBM Sterling Gentran:Server® NT Adapter||File System Adapter|
|JMS Adapter||All adapters that use perimeter services|
|Oracle AQ Adapter||All adapters listed in the clusteradapter.properties file, including customized adapters|
|Adapter for PeopleSoft|
|WebSphere® MQ Adapter|
|IM Adapter (XMPP)|
|Adapter for PeopleSoft CRM|
Even if an adapter can only be installed on a single node in a cluster, it has cluster-wide visibility and business processes that use it can be distributed across the cluster. Business processes running on any node in a cluster can call the adapter. When a business process calls an adapter that is on more than one node, the process first calls the adapter that is on the same node as the process. If that adapter is not available, the process calls an adapter on another node.
If an adapter is deployed on only one node, and the node where the adapter is deployed goes down, the business process fails. To circumvent single point of failover situations for non-clusterable adapters, you should attain clusterability of adapters across more than one node on a case-by-case basis, depending on the nature of the adapter.
Configuring a Cluster with Non-Clusterable Adapters
In the case of resource affinity to specific nodes, such as the File System adapter, you should use a third party vendor solution on external resources like clustered/mounted file systems by which all nodes have access to this common clustered file system. The File System adapter can then be deployed on all nodes.
In cases of connectivity or external resource restrictions, a separate instance of an adapter can be deployed on each node connected to its external resource. They can be grouped together as a service group so a business process can view them as a single entity and thus can be made clusterable to support failover and load balancing.
The final method is to have a business process detect the failure of adapters and redirect the functionality to a different component on another active node. For example, if the File System adapter is installed on a node and it fails, you can use fault detection to write files using the FTP adapter installed on a different node.
In addition, business applications that adapters communicate with may not be suitable for clustering. Each node must have connectivity to the target system in these cases, to avoid single points of failure within Sterling B2B Integrator. Moreover, if another technique is used to accomplish failover for the external business applications (for example, warm standby failover), adapters must be configured to connect to the standby system if a fault is detected in attempting to connect to the primary system. This is managed through various mechanisms, as governed by the specifics of the system interactions and communication protocols.
To support configuration of adapters to be deployed on a single node, a few nodes, or all nodes in the cluster, Sterling B2B Integrator provides support through the user interface for adapters to be targeted to specific nodes or all nodes in a cluster. This provides a facility to dynamically configure adapters to be deployed on one or more nodes. Also, on failover situations, if an adapter configured to a specific node fails and needs to be redeployed on another active node to continue processing, it can be achieved by targeting on an active node.