BPM, Workflow, and Case

 View Only

Installing BAW on VM decoupling binary and data on different disks

By SHUO ZHANG posted Mon February 21, 2022 03:30 AM

  

Technically, containers simplify development and operations by building all dependencies and the application itself in a single immutable image. They eliminate the “it works on my machine” excuse. An Immutable binary of the product code provides the following advantages:

  • can create multiple homogeneous environments from the same product code
  • upgrading that single product binary results in all systems getting the latest version or fixes

Several Business Automation Workflow (BAW) on-premise customers are interested in these benefits that come from containers but are not ready to move their BAW workload to Kubernetes. This article describes how to build a BAW VM image that can address the basic requirements when the customer is considering setting up a VM environment on the cloud, given the following assumptions:

  • The use of VM from a cloud provider has been decided.
  • The centralized IT team want to control OS and basic software refreshes to address Common Vulnerabilities and Exposures (CVE) by providing a base VM image. Regular refreshes are typical; for example, a new base VM image is released monthly; and the application (BAW) team must create a new application VM image based on that.
  • The VM instance must be rebuilt regularly even without an image update for security hardening purposes.

Compared with using a container via Kubernetes, the VM instance itself still needs additional resource consumption at the OS level and cannot be easily scaled, but it has the following unique values:

  • No additional learning curve for container and Kubernetes.
  • No additional resource consumption for Kubernetes.
  • No need to upgrade process applications to be container compatible.

Core ideas of how to decouple

This idea is based on WAS swinging profiles and BAW swinging profiles, which move the profiles to a new location away from the WebSphere Application Server (WAS) installation root. As result, you can install BAW on two disks:

  1. Binary disk – install Workflow/WAS/IHS binary on this disk. The whole disk can be replaced with a new VM image for “upgrading” to the next level.
  2. Profile disk – contains customized configuration/transaction log/key store. This disk is kept when you replace the binary disk. Setting up the profile (and other data) on a separate disk decouples it from the lifecycle of the machine/VM.

If you compare this solution with the container solution, the binary disk is like the container image, which is immutable and can be easily replaced with the next level. The profile disk is like the container’s volume for storing the data that must be persisted.


Limitation: This process applies to Linux only

Benefits of this solution

Separating the BAW binary and configuration/data on different disks can achieve the following benefits:

  1. When the binary disk is created/iFixed/upgraded as a template (VM image) in a master environment and then this unified binary disk is replicated to multiple homogeneous environments, it can reduce operation effort significantly.
  2. Compared with using traditional Installation Manager to upgrade the binary, replacing the binary disk is very quick and simple.
  3. When the corporate IT team regularly provide a base VM image to address new CVEs, the application team can build the BAW VM image based on that. As result, the VM instance’s binary disk can be refreshed to the new version with the fixed CVEs.

Sample flow of how to build new version of VM image

This flow demonstrates how to build BAW VM images version by version. The new version of BAW images might include iFixes from BAW or WAS, and it must be rebased on the new corporate base image when necessary.

The arrow symbols above the timeline show the release cycle of corporate base images. The arrows under the timeline show the release cycle of the application (BAW), with or without iFixes.

Build Point 1: At the beginning, with the simplest starting point, you create the BAW 19.0.0.3 image based on the corporate base image (CBI) v1.

  1. Provision a VM instance from CBI v1. The boot disk is the binary disk.
  2. Install BAW 19.0.0.3 on this machine on the binary disk.
  3. Mount a new disk as the profile disk and swing the profile to the profile disk.
  4. Create the BAW VM image from the binary disk. It will include the BAW binary based on CBI.

Build Point 3: This scenario is more complex and has iFixes published.

  1. Provision a VM instance from CBI v3. The boot disk is the binary disk.
  2. Install BAW 19.0.0.3 on this machine on the binary disk.
  3. Mount a new disk as the profile disk and swing the profile to the profile disk.
  4. Apply iFixes 1001, 1002, and 1003 sequentially.
  5. Create the BAW VM image from the binary disk. It will include the BAW binary (with iFixes) based on CBI.

Which folders and files to put on the profile disk

When you implement this idea of separating the binary from the profile, you might find it difficult to decide which files or folder to put on the profile disk. The general criteria to select them is:

  • The files are not going to be patched directly when an iFix or upgrade is applied:
    • Sometimes, post-installation steps for iFixes must be executed on each individual environment, which might update the files on the profile disk. This situation causes only an indirect impact and it is fine to put the files on the profile disk.
  • The files contain custom configuration which must be kept after applying an iFix or upgrade
  • TLS keystore and truststore files
  • LTPA key files

For BAW and WAS, keep these files on the profile disk:

  • <WAS-install-root>/profiles
  • According to swinging profiles, relocate <WAS_ROOT>/properties/profileRegistry.xml to the profile disk
  • According to swinging profiles, relocate <WAS_ROOT>/logs/mangeprofiles to the profile disk
  • <WAS-install-root>/CaseManagement/properties
    • This is a shared directory between all BAW nodes and Navigator to exchange Case-related plugins and widgets. The BAW configuration properties file has the property de.caseManager.networkSharedDirectory, which should point to a location on the profile disk. On the profile disk, mount the local folder to a shared network directory.

(Optional) For IBM Http Server (IHS), keep these files on the profile disk:

Note: It’s only applied when you use IHS to proxy BAW requests

  • <IHS-install-root>/conf
  • <IHS-plugins-root>/config/<web-server-plugin>
  • IHSKeystore

Steps to apply iFix and rollbak

This flow provides a high-level description of how to apply an iFix by updating the binary disk from v02 to v03. The v03 image includes BAW iFix or WAS fixes or OS fixes.


Notes:

  1. In step 5, if your iFix has any post-installation steps, you must run BPMEnablePostInstaller to activate them again in the VM environment
  2. If you find any regression in the new image, use the same steps to roll back the binary disk to v02.
  3. It is best to enable scheduled backups for the profile disk. Otherwise, run a full backup of the profile disk before applying the iFix image.

Steps to upgrade and rollback

This flow provides a high-level description of how to upgrade BAW to the next release with the binary disk replacement.


Notes:

  1. If you find any regression in the new image, use the same steps to roll back the binary disk to v03.
    1. Restore the profile disk backup that was created before upgrade.
    2. Restore the database backup that was created before upgrade.

#BusinessAutomationWorkflow(BAW)
#VMware

Permalink