Planning for maintenance

After you install and start operating AS4 Microservice, you must plan for different kinds of maintenance, including regular maintenance, emergency maintenance, and upgrades.

How you plan for the different maintenance types depends on your system requirements, especially if you have a highly available or HA system requirement. In a highly available system, you can do routine hardware and software maintenance and updates without taking down the system. If your system is not highly available, then you need to plan to take the system out of service for hardware, operating system, and system updates.

Hardware maintenance

Hardware maintenance is determined by the local policy at your installation. AS4 Microservice has no preventive hardware maintenance dependencies.

If you have a highly available system, you can take down one hardware server and still have AS4 Microservice available and running on the other servers in your installation.

If you do not have a highly available system, then you must bring down the entire system for the hardware maintenance.

Fix pack and upgrade maintenance

For highly available systems, you can load fix packs and upgrade the AS4 Microservice software one server at a time.

If you do not have a highly available system, then you must bring down the entire system for the AS4 Microservice fix pack and software upgrades.

External database maintenance

The database is external to AS4 Microservice. Follow local practices when you are doing any maintenance on the database system.

If the database is down for maintenance or updates, the AS4 Microservice data grid holds data in memory. How much memory you have in your data grid is determined by the number of container members you have in your installation. The amount of data that is stored in a container member is documented in the system requirements and is part of planning your system.

The system can be configured to send messages when the data grid memory usage is high. If the data grid memory usage is routinely high, you might need to add container members to expand your data grid. Each server can have one only container member, so you might need to add hardware to your installation to add container members.

WebSphere MQ outage and recovery

If the WebSphere® MQ installation that you use as the message provider in a non-proof of concept installation stops running, you cannot run AS4 Microservice. To lessen the chance for a WebSphere MQ outage, use the following architecture for your WebSphere MQ installation:

  • Multi-instance queue managers
  • Cluster nodes that host each instance of a multi-instance queue manager

A multi-instance queue manager enables one instance of the queue manager to manage messages when another instance is not available. If each instance is installed on its own cluster node, you can continue processing messages through WebSphere MQ if either a node server or queue manager instance fails. WebSphere MQ uses automatic client reconnect to minimize the chance of transaction failures and duplicate data.

For information on maintaining the availability of WebSphere MQ during operations, maintenance, or upgraded, see the documentation for the version of WebSphere MQ that is specified in the System Requirements.

Shared file system outages

If the shared file system used by AS4 Microservice for storage is unavailable, AS4 Microservice also becomes unavailable.

If you have a highly available AS4 Microservice, you must use a similarly highly available shared file system for AS4 Microservice storage.

Decommission a shared server

If you need to decommission a shared server that is used for AS4 Microservice storage, you must do the following before you remove the server from service:

  1. Configure and start a suitable replacement shared server.
  2. Mount the new shared server on the machines that run AS4 Microservice and Sterling B2B Integrator.
  3. Configure a new Sterling B2B Integrator adapter to watch for new bucket variants in the new shared server.
  4. Create new storage bucket variants on the new shared server.
  5. Simultaneously with the previous step or soon after, retire all storage bucket variants on the old shared server.
For the storage blobs in the retired storage bucket:
  • When you determine that all the blobs in the retired storage bucket variants on the old shared server either are purged or can be discarded, the administrator can delete these storage bucket variants.
  • If any of the retired storage bucket variants was configured with a DivugeBlobsInto directory on the old shared server, look at those files for safekeeping before the shared server is taken offline.