This documentation supports the 9.0 version of BMC Remedy ITSM Deployment.

To view the latest version, select the version from the Product version menu.

Upgrading platform components with zero downtime

The following topics are provided:

Note

With this release, zero downtime upgrade is supported only if you are upgrading from version 7.6.04 SP2 or 8.1 SP2 and, only for Windows server and Microsoft SQL.  

With service pack 1 and later, you can upgrade the platform components directly on the production server with zero downtime (ZDT). The platform components that can be upgraded with zero downtime include the BMC Remedy AR System server and BMC Atrium Core components.

Zero downtime means no outage of the environment. The production work can continue while upgrade continues in the background. However, there is always the possibility of some reduction in throughput. There will be additional load generated that will be going on in parallel to live system. Thus, it is recommended that you must perform the upgrade during non-peak hours or when the usage is lower. 

Also, it is important to understand that certain features and functionality will not be available during the upgrade process. See, Functionality that will not be available during the upgrade process.

In zero downtime upgrade process, you don't need a staging environment. You directly upgrade the platform components on the production server. However, you still need the upgrade development server and the upgrade QA server. For more information about the prerequisites see Prerequisites for zero down time upgrade

Zero downtime upgrade process overview 

The following diagram illustrates the process of how you can upgrade your platform components with zero downtime. Also, refer to the Zero downtime upgrade stages table to understand the high-level sequence of activities. 

 Zero downtime upgrade stages 

StageDescription

Stage 1

Preparing for zero downtime upgrade

  1. Before you start the upgrade, you must restrict any admin changes in the production environment. See, Restrictions after restoring the database on the upgrade server.
  2. Ensure that BMC Remedy Mid tier has the entire cache till the upgrade is complete.
    P
    reload the mid tiers. See, Preparing mid tier for zero downtime upgrade.

Stage 2

Complete development and QA activities

You must complete all the activities related to reconciling AR system customization, QA testing, UAT, and creating the deployment package that contains the changes you need to migrate to the production environment. During this stage you will be using the upgrade development and upgrade QA server.

Stage 3

Preparing for production upgrade

You need to complete certain AR system configuration changes on both the primary and non-primary servers. See, BMC Remedy AR System configuration changes before performing zero downtime upgrade.

You need to revert these changes after each server upgraded.

Stage 4

Upgrade the primary server

The primary server in the context of upgrades is the server that has a rank 1 for administration operation in the AR System Server Group Operation Ranking form. You should first upgrade the server with the administration operation rank 1 because administration operations ownership is required to import workflows during an upgrade.

You must upgrade the BMC Remedy AR System server and BMC Atrium Core components.

During this stage you can also perform a fresh installation of BMC Remedy Smart Reporting and BMC Remedy Single Sign On.

See, Upgrading the platform.

You must ensure that no traffic is diverted towards the server that is being upgraded. You can achieve this by either configuring the load balancer or changing the port.

Stage 5

Primary server go live

Add the primary server to the server group and revert all the AR system configuration changes you had done in stage 3 for primary server.

Stage 6

Upgrade the secondary server

You must upgrade the BMC Remedy AR System server and BMC Atrium Core components. See, Upgrading the platform.

You must ensure that no traffic is diverted towards the server that is being upgraded. You can achieve this by either configuring the load balancer or changing the port.

Note

Complete stage 6 and stage 7 one at a time for all the non-primary servers. For example complete stage 6 and stage 7 for the secondary server and then move to the next server.


Stage 7

Secondary server go live

Add the secondary server to the server group and revert all the AR system configuration changes you had done in stage 3 for secondary server.

Stage 8

Post upgrade activities

After you upgrade all the servers in the production environment, complete the Post upgrade procedures for zero downtime upgrade.

  

related-topic Related information

For detailed end-to-end steps, see End-to-end steps for performing zero downtime upgrade

Prerequisites for zero downtime upgrade

For a zero downtime upgrade the following prerequisites must be met: 

  • You must have a server group environment. Without a server group, there is no ability to have zero downtime because there is always going to be the need to restart the executable. 
  • You must have a load balancer. 
    • You must route all the accesses by users and automated programs into the system through a load balancer so that the load can be redirected when each server is upgraded. If you do not, the user or program that is directly targeting a single server will lose access when the server is upgraded. 

    • For automated feeds, if you want to maintain the operation, you can set up a load balancer to route all traffic to a specific server (for example, an integration server) and only redirect when that server is not available. This approach still isolates the load but, has a backup strategy if you lose that server. 

    • You can route interactive traffic separately from automated traffic as normal.  Just that there must be an ability to fail over or you cannot have zero downtime.

Functionality that will not be available during the upgrade process

During the upgrade, the following functionalities won't be available:

  • The multi form search capability is not available during the upgrade.  You will not be able to perform operations such as the knowledge search. 

    Note

    This limitation is not valid if you are upgrading from version 8.1.02 or later and if you have configured full-text search and multi form search in high availability mode.

  • You won't be able to launch the BMC Atrium CMDB console if the mid tier cache is updated to version 9.0.xx,. You will get an error about the BMC Atrium CMDB version mismatch or not being recognized. Also, any BMC Atrium CMDB console integration with BMC Remedy ITSM will not be accessible. 

High availability limitations 

When you are upgrading the primary server, on the non-primary servers following functionalities will not be available:

  • In the BMC Atrium Core console, you will not be able to access the list of datasets.
  • The Normalization Engine jobs will not be displayed. 
  • If you are upgrading the primary server from version 7.6.04 Sp2, the BMC Atrium Console will not be accessible on the non primary servers. 
  • After you upgrade any server, and till the time you don't complete the entire upgrade (primary and non-primary), the new menu items available as part of 9.0.xx enhancements will not be available. The following error is displayed:

    The specified menu is invalid.

Related topics

End-to-end steps for performing zero downtime upgrade

Preparing for zero downtime upgrade

Post upgrade procedures for zero downtime upgrade

Platform installation and upgrade known and corrected issues

Troubleshooting

Was this page helpful? Yes No Submitting... Thank you

Comments