Skip to Content

Configuring after upgrade

After you verify the upgrade was successful, perform the tasks listed in this topic.

Related topics

 

Upgrading BMC Helix IT Operations Management from version 25.3 to 26.1

Upgrading BMC Helix IT Operations Management from version 25.4 to 26.1

To clean up the Redis data

Perform the Redis data cleanup steps only if you are using Valkey. Redis data cleanup is required because, after Valkey becomes active, Redis is no longer used, yet its data and resources remain in the environment. Cleaning up Redis data helps free up infrastructure resources.

Important

  • For BMC Helix Service Management users:
    If you have upgraded BMC Helix Platform Common Services to a Valkey-compatible version and want to perform the Redis data cleanup steps, you must first ensure that you have upgraded BMC Helix Service Management to a Valkey-compatible version. Additionally, confirm that sanity testing is complete and the upgraded environment is stable.
    For example, BMC Helix ITSM 26.1
  • Before performing the Redis data cleanup steps:
    • Make sure you have access and permissions to create and delete resources in the ITOM namespace.
    • Make sure that you run the upgrade configuration utility and upgrade to BMC Helix IT Operations Management 26.1. Additionally, confirm that sanity testing is complete and the upgraded environment is stable.

    • Perform the cleanup steps with caution because the cleanup utility permanently deletes Redis resources and their persistent volumes, and the operation is irreversible.

  • If you have upgraded to BMC Helix ITOM 26.1 and have not performed the Redis cleanup steps, consider the resource requirements for Valkey and Redis. For more information on the sizing requirements, see Sizing and scalability considerations.
  • The cleanup script scales down the resources before deletion.

Review the information in the following table before performing the Redis cleanup activity:

RedisCluster parameter value in the deployment.config fileRedis HA existsRedis Cluster existsWhat does the Redis data cleanup script do?
YesYesYesPrompts and deletes the Redis HA (charts, deployments, StatefulSets, jobs, and PVCs).
YesNoYesNo action is taken.
NoNoYesPrompts and deletes Redis Cluster (charts, deployments, StatefulSets, jobs, and PVCs).
NoYesYesPrompts and deletes Redis HA and Redis Cluster (charts, deployments, StatefulSets, jobs, and PVCs).
Yes or noYesNoPrompts and deletes Redis HA (charts, deployments, StatefulSets, jobs, and PVCs).
  1. Navigate to the /helix-on-prem-deployment-manager/utilities/migration/redis directory.

  2. Run the following command to remove Redis HA and Redis Cluster resources:
    ./redis-cleanup.sh cleanup

    Running this command permanently deletes Redis HA and Redis Cluster data.

    A prompt is displayed to confirm the deletion of PVCs allotted for Redis data.

  3. Type y or Y to permanently delete PVCs. This permanently deletes all Redis data in PVCs.
    Or type n or N to keep the PVCs and Redis data. This keeps the Redis data in PVCs.
    PVCs are deleted only if you explicitly confirm.

If there are any issues in cleaning up the Redis data, see Troubleshooting data lake issues.

To enable disaster recovery

Warning

Important

To prevent data loss during the upgrade process, it is essential to upgrade the primary site first, enable disaster recovery on the primary site, wait until the first backup is complete, and then upgrade the standby site.

This step-by-step approach will ensure that your data is safe and secure throughout the upgrade process.

Perform the following tasks after upgrading the primary site:

  1. If you have enabled disaster recovery, you will be prompted to re-enable it.
    Type y to enable disaster recovery.
    Wait for the first backup to be complete.
  2. After the first backup is complete, scale up the standby site

    If you have scaled down the standby site, perform the following steps to scale it up:

    1. Navigate to helix-on-prem-deployment-manager/utilities/disaster-recovery/dr-scale

    2. Run the following command:

       ./product_scale.sh  up 

      This scales up both application and data lake services.

  3. Upgrade the standby site 
    1. For all the BMC Helix ITOM applications for which you are licensed, set the value to yes; for all other services, set the value to no.
      For example, if you are only licensed to use BMC Helix Operations Management and BMC Helix Continuous Optimization:

        • To use BMC Helix Operations Management, set the value of MONITOR to yes. 
          Optionally,
          • To use AIOps, set AIOPS_SERVICES to yes .
          • To use Log Analytics, set LOG_ANALYTICS_SERVICES  to  yes.

        • To use BMC Helix Continuous Optimization, set the value of OPTIMIZE to yes. 

          SuccessBest practice
          To see your licensed product services, navigate to the configs/deployment.config file in the previously deployed version of BMC Helix ITOM.

    2. From the new working directory ( new_working_directory ), run the deployment manager to upgrade BMC Helix IT Operations Management:

      ./deployment-manager.sh

      After the upgrade, you will get the following message:
      Completed Helix On-prem Installation.

    3. (Optional) To view the logs during the upgrade, run the following command:

      tail -f logs/deployment.log
  4. (Optional) Scale down the standby site 

    After configuring disaster recovery,  you can  scale  down  the application pods and keep  only  the data lake components running on the standby  site  to save resources. 

    Perform the following steps:

    1. Navigate to helix-on-prem-deployment-manager/utilities/disaster-recovery/dr-scale

    2. Run the following command:

      ./product_scale.sh  down
      Warning

      Important

      • Data from the primary site MinIO continues to be replicated onto the standby site MinIO but the applications will not run.
      • To scale down the data lake components also, use DOWN-ALL  or  down-all. Example: ./product_scale.sh  down-all. This stops all services except MinIO, Postgres, and external  Elasticsearch, Fluentd, and Kibana (EFK)  stacks.
      • Do not run the scale down or down all script repeatedly.

To change the namespace pod security admission to restricted

Warning

Important

Perform this task only if you upgraded to Kubernetes version 1.25 or higher.

After the upgrade, the namespace pod security admission must be changed to restricted .

To change the cluster-level pod security admission, run the following command:

  kubectl label --overwrite ns <namespace> \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/warn-version=latest \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/audit-version=latest

Replace <namespace> with the namespace where you deployed BMC Helix IT Operations Management .

 

Uninstall the EFK deployment

Starting from 25.1 release, BMC Helix IT Operations Management supports external EFK integration and the log streaming from internal EFK and from the log shipper binary are disabled. To remove the EFK deployed in the internal namespace, perform the following steps:

  1. Export logs from Kibana UI to csv for reference. See Viewing logs on Kibana.

  2. Remove EFK using below commands by replacing the namespace.

    helm delete -n <namespace> efk-elasticsearch efk-fluent-bit   
    kubectl -n <namespace> delete pvc data-efk-elasticsearch-data-0 data-efk-elasticsearch-data-1 data-efk-elasticsearch-master-0 data-efk-elasticsearch-master-1

(Optional) To switch to enterprise F5 NGINX Plus Ingress Controller

Starting with BMC Helix IT Operations Management (BMC Helix ITOM)   version 24.3, we support the enterprise edition of the F5 NGINX Plus Ingress Controller.

You can use either the enterprise edition of the F5 NGINX Plus Ingress Controller or the open-source version.

To switch to the enterprise edition of F5 NGINX Plus Ingress Controller, see Switching to enterprise NGINX Plus Ingress Controller.

To learn more about the F5 NGINX Plus Ingress Controller, see NGINX Ingress Controller.

To remove the PostgreSQL database version 15.x 

Before running the clean-up script, make sure your data is migrated to PostgreSQL database version 17.x. 

  1. To remove PostgreSQL database 15.x and the older version of PVC, navigate to helix-on-prem-deployment-manager/utilities/migration/postgres.

  2. Locate the patroni-pg-migration.sh file and run the following command:
    ./patroni-pg-migration.sh cleanup

    You will be prompted to confirm if you want to delete the PVC used for the PostgreSQL database migration. 
    Type y. 
    The older version of the PVC gets deleted.

  3. You will be prompted to confirm if you want to delete the older PostgreSQL database and associated pods.
    Type y. 
    The PostgreSQL 15.x and the associated pods get deleted.
    After the cleanup, you will get the following message:
    The cleanup was completed successfully.

 

 

 

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

BMC Helix IT Operations Management deployment 26.1