Batch services typically process big amounts of data periodically. Most of the time, these data are transported via files using shared folders, ftp, sftp, or similar mechanisms.
In contrast to load balanced scenarios, we try to avoid that the batch service and its backup service is active simultaneously to avoid write conflicts on non-safe resources such as files. The following figure depicts a setup where only one Bridge instance is active, enabling all resources to be shared safely. The resources such as the service repositories, logs, Bridge properties, etc. can be shared by using a shared file system. This approach is even possible for sharing a database. For example, it is possible to put the database file of a SQLite instance on the file share. However, depending on the quality of the network connectivity, using a shared database as shown in the load balancing architecture might be more robust.
To allow a separate update of the used binaries, the E2E_BRIDGE_PROG directory is not shared. So E2E Bridge updates can be done on each node separately (see Updating a BRIDGE (Installer) and Managing the xUML Runtime of the Node Instance).
Figure: Bridge Setup for Batch Processing
Since only one node is running, there is no backup monitoring service available. If there are other Bridge instances running (say for online services), we recommend to deploy a backup monitoring service to one of this instances and register it to the Bridge.
Additionally, it is important that operators monitor the OS Console service/daemon, because if this OS service/daemon is dead no management and monitoring of the deployed service will take place anymore.
In case of switching from one node to the other, the operator must apply the following procedure:
- Stop all batch services by shutting down the E2E Console service/daemon – if this service is still alive. Make sure all services are shutdown.
- Move the file system mount for E2E_BRIDGE_DATA from one server to the other.
- Start up the E2E Console OS service/daemon. The batch services will start up automatically, if they have the Automatic Startup flag selected.
This manual switch over can be done automatically by writing scripts executing above steps or by using a cluster software. Normally, the cluster switches from one machine to the other if the Bridge is not functional anymore or if an operator manually triggers the switch. In the latter case, the operator should first stop all services and making sure that all services are shut down before triggering the fail over.
If a cluster is operated in the above way, it is typically called an active/passive cluster.