Configuring the on-premises gateway for high availability in on-premises Kubernetes and OpenShift clusters


A high-availability deployment of the BMC Helix Intelligent Integrations on-premises gateway uses object storage to back up and restore the on-premises gateway configuration. As a tenant administrator, you can use one of the following options as the object storage when configuring the on-premises gateway for high availability (HA).

  • BMC Helix object storage (Recommended) — The storage associated with the current BMC Helix SaaS tenant.

  • Private object storage — A storage deployed and managed in your on-premises environment. You can use a standalone S3-compatible storage (for example, MinIO or an Amazon Simple Storage Service (S3)) available in your environment. 
Warning
Important

To switch from one object storage type to another, you need to reconfigure the on-premises gateway instances. When you switch, the on-premises gateway configuration is not copied automatically.

 

Before you begin

  • To use the BMC Helix object storage:
    • Access the UI for the on-premises gateway instances that are part of the high-availability deployment and make sure that the same destination is added for all instances.
    • Make sure that the access key and secret key used in the destination have all [*] permissions.
  • To use a private object storage, make sure that a standalone S3-compatible storage instance is set up, and you have obtained the credentials that have permissions to create and read objects. Contact your system administrator to obtain the credentials.
Warning
Important

The high-availability deployments of the on-premises gateway have been validated with the Community Edition of MinIO. The Enterprise Edition is also expected to function correctly.

Task 1: To prepare the environment for data collection by using a webhook connector

If you are using a webhook connector to collect data from a third-party product in a high-availability deployment, you can use a load balancer (for example, F5) to direct the webhook data traffic to the active on-premises gateway instance. 

Warning
Important

The following steps are specific to the F5 load balancer and might differ for other load balancer types.

Perform the following steps to prepare the environment for data collection by using a webhook connector:

  1. Configure the load balancer.
    1. Create a DNS record (for example, VIP_HII) for the virtual IP (VIP).
    2. Create a pool, and add the on-premises gateway instances as members, as shown in the following example:-ltm pool VIP_HII {
          description "Gateway Pool"
          members {
              aus-pun-01.abc.com:https {
                  address 192.168.111.xx
                  session monitor-enabled
                  state down
              }
              aus-pun-02.abc.com:https {
                  address 192.168.112.xx
                  session monitor-enabled
                  state down
              }
                 }
          monitor VIP_HII
      }

      The above example creates a pool for VIP_HII, with two members: aus.pun-01.abc.com (IP address: 192.168.111.xx) and aus.pun-01.abc.com (IP address: 192.168.112.xx) 

      1. Create the monitor to check the status of an on-premises gateway instance, as shown in the following example:
        ltm monitor https VIP_HII {
          adaptive disabled
          defaults-from https
          interval 5
          ip-dscp 0   
          recv false
          recv-disable none
          send "GET /hii/api/mediator/v3/standbyStatus HTTP/1.1\r\nHost: VIP_HII\r\nConnection: Close\r\n\r\n""
          time-until-up 0
          timeout 16
        }

        Warning
        Important

        The monitor you are creating must use the standbyStatus API to determine the status of an instance, as shown in the above example.

  2. While including the webhook collector URL in the third-party product (for example, Entuity), replace the on-premises gateway host name with the DNS record in the webhook collector URL. For example, an updated webhook collector URL looks like:
    https://VIP_HII/hii/api/mediator/v3/push/9mn-6c97-4c2e-8pc5-12c0asdfd?token=385261281::Y40OSC49QZA11Q8A1H9H6::MnVLk69TNyCEponsthHJ1Hj1uKcjTB
    For more information about configuring the URL for Entuity, see Integrating with Entuity via webhook.

Task 2 (BMC Helix SaaS storage): To configure on-premises gateway instances for HA

  1. Log on to the host controller to access the Kubernetes or OpenShift cluster on which the on-premises gateway instances have been deployed.
  2. If you have not configured the primary instance for HA during deployment, perform the following steps. Otherwise, skip to step 3.  
    1. Open the ConfigMap for the primary instance.
      kubectl -n <namespaceName> get cm get swp-mediator-conf -o yaml
      Example:
      kubectl -n iionpremha1 get cm get swp-mediator-conf -o yaml
    2. Set the following properties:
      • USE_ADE_STORAGE: Specifies the object storage to be used in the HA deployment. Set the property to true (default is false) to use the storage asscoiated with the BMC Helix SaaS tenant.
        USE_ADE_STORAGE: "true"

      • HIIG_HA_CLUSTER_ID: Specify a unique cluster ID (an integer from 0 and 9) in case you have multiple clusters, each cluster containing multiple on-premises gateway instances. The default value is 0, which indicates that you have only one cluster.
      • DATA_PUSH_INTERVAL: Specify the interval (in milliseconds in epoch format) at which an on-premises gateway instance should push data to the BMC Helix object storage (default and minimum 300000 milliseconds).
        DATA_PUSH_INTERVAL: "300000"

      • SOURCE_HOSTNAME: Set the value of this parameter in the swp-mediator-<namespace> format (for example, swp-mediator-iionpremha1).

    3. Go to step 4.

  3. If you have configured the primary instance for HA during deployment, perform the following steps:
    1. Open the ConfigMap for the primary instance.
      edit mediator config map swp-mediator-conf
    2.  
    3. Review and update (if required) the values of other parameters, as shown in the following example:
      ​​​​​SOURCE_HOSTNAME: "swp-mediator-iionpremha1"
      USE_ADE_STORAGE: "true"
      HIIG_HA_CLUSTER_ID: 0
      MINIO_ACCESS_KEY: ""
      MINIO_SECRET_KEY: ""
      MINIO_SERVER_URL: ""  
      MINIO_BUCKET_NAME: "helix-hii-backup"
      DATA_PUSH_INTERVAL: 300000 
      ​​​​​
  4. Save and close the ConfigMap.
  5. Perform a rolling restart of the swp-mediator pod:
    kubectl -n <namespaceName> rollout restart deployment swp-mediator
    Example: 
    ​kubectl -n iionpremha1 rollout restart deployment swp-mediator​
  6. Back up the /<user>/ii_auth directory and then delete it. 
  7. Extract the utility files, hii-bmc-<buildNumber>.zip.
  8. Repeat steps from 2 to 5 for the secondary instance.

Task 2: To configure on-premises gateway instances for HA with private object storage

  1. Log on to the host controller to access the Kubernetes or OpenShift cluster on which the on-premises gateway instances have been deployed. 
  2. If you have not configured the primary instance for HA during deployment, perform the following steps. Otherwise, skip to step 3.
    1. Open the ConfigMap for the primary instance.
      kubectl -n <namespaceName> get cm get swp-mediator-conf -o yaml
      Example:
      kubectl -n iionpremha1 get cm get swp-mediator-conf -o yaml

    2. Set the following properties:

      • USE_ADE_STORAGE: Indicates the object storage to be used in the HA deployment. Make sure that it is set to false.
        USE_ADE_STORAGE: "false"

      • MINIO_SERVER_URL: API endpoint URL for the S3-compatible storage.

        Example
        # MinIO
        https://vx-push-dev26.abc.com:9000
        # Amazon S3
        https://s3.us-west-1.amazonaws.com
      • MINIO_BUCKET_NAME: The name of the bucket you want to create on the S3-compatible storage instance.
        Important: If you are using the same S3-compatible storage server for multiple HA environments (for example, Test and Production), make sure that each bucket has a unique name.

      • DATA_PUSH_INTERVAL property to the interval (in milliseconds) in epoch format at which an on-premises gateway instance should push data to the storage bucket (default and minimum 300000 milliseconds).
        The following example shows sample values:
        MINIO_SERVER_URL: https://vx-push-dev26.abc.com:9000
        MINIO_BUCKET_NAME: "helix-hii-backup"
        DATA_PUSH_INTERVAL: "300000" 
      • SOURCE_HOSTNAME: Set the value of this parameter in the swp-mediator-<namespace> format (for example, swp-mediator-iionpremha1).
    3. Go to step 4.
  3. If you have configured the primary instance for HA during deployment, perform the following steps:  
    1. Open the ConfigMap for the primary instance.
      edit mediator config map swp-mediator-conf

    2. Set the value of the SOURCE_HOSTNAME parameter in the swp-mediator-<namespace> format, as shown in the following example:
      ​​​​​SOURCE_HOSTNAME: "swp-mediator-iionpremha1"
    3. Set the value of the USE_ADE_STORAGE parameter to false. This parameter indicates the object storage to be used in the HA deployment
      USE_ADE_STORAGE: "false"

    4. Review the values of other parameters, as shown in the following example:
      HIIG_HA_CLUSTER_ID: 0
      MINIO_ACCESS_KEY: "P3pWEoNUEmZB8i0zJAnC"
      MINIO_SECRET_KEY: "SgA3ntRrdM3nzUGpvKjRMQ2FJZNHujfngxJgTb"
      MINIO_SERVER_URL: https://vx-push-dev26.abc.com:9000
      MINIO_BUCKET_NAME: "helix-hii-backup"
      DATA_PUSH_INTERVAL: "300000"

  4. Save and close the ConfigMap.
  5. Perform a rolling restart of the swp-mediator pod:
    kubectl -n <namespaceName> rollout restart deployment swp-mediator
    Example: 
    ​kubectl -n iionpremha1 rollout restart deployment swp-mediator​

  6. Back up the /<user>/ii_auth directory and then delete it. 
  7. Extract the utility files, hii-bmc-<buildNumber>.zip.
  8. Repeat steps from 2 to 5 for the secondary instance.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

BMC Helix Intelligent Integrations 26.1