Skip to Content
Information
Unsupported content This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Staged-Lite upgrade - HA environments only

If you want to "stage" your production servers but minimize the the number of servers in the staging environment, you can adopt the Staged-Lite strategy. In the Staged-Lite strategy, one of the secondary servers from each zone 2 product is dismantled from production to create the staging server. You would require separate database server to host the staging environment. In this strategy, the production would run in less capacity but would require minimal hardware.

Warning

Note

The Staged-Lite strategy is applicable only for BMC Cloud Lifecycle Management deployed in a HA environment.

This topic includes the following information:

The BMC Cloud Lifecycle Management Staged-Lite environment – which is a copy of the production environment  – ensures that you can update the active applications to the target versions without affecting the current production server, except that you have less HA capacity and performance might be degraded. This includes applying customizations that were made to the BMC Remedy AR System application and server objects that were shipped with the BMC Cloud Lifecycle Management solution.

You can upgrade the following products, referred as zone 2 products, in a staging environment:

  • BMC Remedy AR System & BMC Remedy IT Service Management Suite (Enterprise-AR) (this requires database backup)

    Warning

    Note

    If you have installed the BMC Remedy Mid Tier and BMC Atrium Core Web Registry in HA environments, ensure that you also upgrade those installations.

  • BMC Remedy AR System Cloud Database (Cloud-DB) (this requires database backup)
  • Cloud Platform Manager
  • BMC Network Automation (this requires database backup)
  • BMC Atrium Orchestrator – you need to upgrade this product in a staging environment only if your current Cloud Lifecycle Management stack is using BMC Atrium Orchestrator content (for example, EC2 provider) that was shipped with the product and if you need the product to be functional during your upgrade process.
Warning

Note

The following documentation is validated only on Linux RHEL OS clustering. For MS Windows, the steps will vary, depending upon the exact cluster vendor that you configured. If you configured a Windows RDM cluster configured, you can apply the same strategy for BNA and PM upgrades. But if you configured Windows is configured with a Star Wind cluster, then you must create or reconfigure the cluster in a staging environment as well. For more information, contact your cluster administrator.

Before you begin

  • Review Upgrade options.
  • With a load-balancer, disable the primary services for Enterprise-AR, Cloud-DB, Atrium Core Web Services, and the Mid-Tier.
Warning

Note

  • Update the customer range field IDs before you start upgrading. Otherwise, the upgrade will likely fail.
  • Do not run the installer on the same VM where you install the products; use a separate VM. You can recover this VM later, after you finish the cloud installation.
  • If you used this VM to install earlier versions of BMC Cloud Lifecycle Management, perform the following tasks before you run the 4.1 upgrade.
    1. Uninstall the install planner.
    2. Back up or delete the C:\Windows\ProductRegistry.xml file.
    3. Delete %temp% files.
  • Accept the default values in the installer unless you have a good reason to change them.
  • Do not mix IP addresses and hostnames during product select in the Host Information panel. Enter all IP addresses or all hostnames, but do not combine them.
  • Some special characters create problems during installation. For more information, see Restricting the use of certain characters in passwords.
    • For BMC Network Automation, do not use special characters except _. 
    • For BMC Server Automation, do not use #. 

Upgrading the products in a Staged-Lite environment

If the task topic does not contain any contextual or prerequisite information, you can omit the procedure title.

  1. Back up the databases for Enterprise-AR, Cloud-DB, and BMC Network Automation.

    Warning

    When you back up the following product databases, note their time stamps. You must provide the time stamp information when you run the Delta Data Migration Tool to migrate data for a specific time stamp.

  2. Restore the Enterprise-AR, Cloud-DB, and BMC Network Automation databases on the database servers in the staging environment.
  3. Stop the services of the following products on the primary servers:
    • Enterprise-AR server
    • Cloud-DB
    • BMC Network Automation
  4. Move the cluster service to secondary servers for following products:
    • Platform Manager
    • BMC Network Automation
  5. Depending upon your cluster configuration, follow the correct strategy:
    • For Linux, modify cluster.conf to enable the cluster on a single node but do not restart the production nodes server if you do not want any downtime.
    • For the production cluster on Windows, delete the primary node from the cluster configuration. 
  6. To create a staging environment for BMC Atrium Orchestrator, either clone the HA nodes in production or install the same production version of BMC Atrium Orchestrator on a different server. 
    This requires a separate load balancer configuration for BMC Atrium Orchestrator HA in the staging environment, where you map the virtual IP (VIP) to the old VIP name from production. That is, the new VIP is mapped to the old BMC Atrium Orchestrator load balancer name in /etc/hosts of the staging environment so that no integration changes are required.
  7. Use the following procedures to upgrade the products in the staging environment. When you finish upgrading the products, then finish the upgrade. 

To upgrade BMC Atrium Orchestrator

Warning

Note

  • To upgrade 2.1.x to 4.x, you must clone the existing Atrium Orchestrator VM host after you upgrade AO-Platforms. 
  • To upgrade 3.x to 4.x, no Atrium Orchestrator upgrade is available.)
  1. Copy the installers to the BAO1, BAO2, and BAO-REPO hosts.
  2. Go to the BAO1 host and launch setup.bin from <Installer Path>/AO-Platform/Linux to upgrade Access Manager only.
  3. Go to the BAO2 host (the HA CDP machine).
    1. Launch setup.bin from <Installer Path>/AO-Platform/Linux to upgrade Access Manager only.
    2. Follow the same steps that were followed on the BAO1 host for installing Access Manager.
  4. After upgrade, verify that the BAO Access Manager is up and running. This is a prerequisite for Repository Upgrade
  5. Go to clm-aomysql (in case of RDS) or the Repository host and launch setup.bin from <Installer Path>/AO-Platform/Linux to upgrade Repository only.
  6. Go to the BAO1 host to upgrade CDP and launch setup.bin from <Installer Path>/AO-Platform/Linux to upgrade CDP. All the panels remain the same since you are launching the same setup.bin.
    The only difference is the path of the component directory. See the previous CDP installation panels, except for the following steps which are specific to HA-CDP machine.
  7. Go to the BAO2 host to upgrade HA-CDP, and launch setup.bin from <Installer Path>/AO-Platform/Linux to upgrade CDP. 

To upgrade BMC Server Automation

  1. Integrate the BSA1, BSA2, and File Server.
  2. Upgrade the File Server. 
  3. Upgrade the BMC Server Automation Application Server on (Primary) BSA1 node.
    Make sure, you should do Blade Data migration whenever Install Planner asks during installation.
  4. Upgrade the BMC Server Automation Application Server on (Secondary) BSA2 node
  5. Verify that all servers connect to the BMC Server Automation database – for example, BSA primary (BSA1) and secondary (BSA2), PXE, and Repeater.

To continue with BMC Server Automation post-installation

  1. Verify that the vCenter RSCD agent is upgraded.

  2. Execute the following blasadmin commands in BMC Server Automation to support backward compatibility:

    $nsh 
    #blasadmin –a 
    ##set AppServer DefaultRestVersion 8.1.02 (applies only to 2.x upgrades)
    ##set AppServer RestAssetAttributesUseInternalName false

  3. Run the DCO job for the vCenter a second time:

    1. During DCO job creation, in the Configuration Object Select panel, select VMware vCenter Server v85,000,000.
    2. Continue with vCenter server selection panel.

Staging the upgrades on the primary servers

For staging, we remove the primary server of each product. For Enterprise-AR, Cloud-DB, and BNA (applies only to 2.1 upgrade), clone or create new database instances to point out primary servers. Use the same name for the new database instance so that you just need to update the /etc/hosts file for new database IP address. No application-level database changes are required. 

For load-balancer applications like Enterprise-AR, Cloud-DB, Atrium Core Web Services, and the Mid-Tier, modify the /etc/hosts file of each primary server to point to the respective load balancer name as well. Add all these modified entries in all the primary servers including BNA1 and PM1.

For example, you have two Enterprise-AR computers – primary (EAR1) and secondary (EAR2). If you remove the primary computer in staging to point to the database host name, the /etc/hosts file of EAR1 now looks like:

 

<EAR1 IP>            <EAR1 HostName>           <EAR LB Name>

<EAR NEW DB IP>      <EAR1 NEW DB Host Name>
Warning

Note

Make sure that the staging environment does not communicate with the CLM Production setup. Keep the staging environment in an isolated lab.

  1. Ensure that your staging environment is functional and that every product in the staging environment works with other zone 2 products.
  2. Upgrade the Enterprise-AR server, Cloud-DB, and BMC Network Automation products on the staging server.

To upgrade primary BMC IT Service Management

  1. Change the DB configuration of BMC IT Service Management to point to new database form staging environment. Change the service name in tnsnames.ora to the new one.
    Do not change the Connection Identifier.
  2. Upgrade Enterprise-AR Primary. 

To upgrade primary Cloud-DB

  1. Configure the database of Cloud-DB:
    1. Change the databsed configuration of Cloud-DB to point to the new database form staging environment. 
    2. Change the service name in tnsnames.ora to the new one. 
    3. Do not change the Connection Identifier.
  2. Upgrade Cloud-DB Primary. 

To upgrade the primary Mid-Tier

  1. Modify the /etc/hosts file to point to the primary Mid-Tier.
  2. Upgrade Mid-Tier Primary. 

To upgrade the primary Atrium Core Web Services Registry

  1. Modify the /etc/hosts file to point to the primary Atrium Core Web Services.
  2. Upgrade Atrium Core Web Services Primary. 

To upgrade primary BMC Network Automation

Warning

Note

These steps apply only to upgrades from 2.1.x.

For example, you have two cluster nodes – BNA1 and BNA2.

  1. Copy the /gfs data on the primary machine temporary location.
  2. Failover the cluster on secondary to work.
    BNA service remains up and running on secondary node (just like production).
  3. Power off the primary node.
  4. Remove the shared disk from the primary node, so that it becomes the standalone node.
  5. Copy the copied shared data on the /gfs directory again.

  6. Update the /etc/hosts file: 

    <BNA1 IP>           <BNA1 HostName>          <BNA Cluster IP>
    <BNA1 New DB Hostname IP>     <BNA1 New DB HostName>
  7. Upgrade primary BNA1.

To upgrade primary Platform Manager

For example, you have two cluster nodes – PM1 and PM2.

  1. Copy the /gfs data on the primary machine temporary location.
  2. Failover the cluster on secondary to work. 
    Platform Manager service remains up and running on the secondary node (just like production).
  3. Power off the primary node.
  4. Remove the shared disk from the primary node, so that it becomes the standalone node.
  5. Copy the copied shared data on the /gfs directory again.

  6. Update the /etc/hosts file: 

    <PM1 IP> <PM1 HostName> <PM Cluster IP>
  7. Upgrade primary BNA1.

Performing data migration

  1. Verify DSO and Reconciliation Engine on Enterprise-AR and Cloud-DB.
  2. Verify if there are any duplicate providers. If there are duplicates, then delete the one which are not in use.
  3. Upgrade the Staging Environment AO Contents, and upgrade the Modules and Adapters from the AO CDP Console.
  4. If you are upgrading from 2.1.x to 4.x, add the AO credential store with the certificate, private keys, and GUI ID of the Amazon provider from the Cloud-DB provider forms.
  5. Create the AWSAccountDetails.csv file on the PM1 host that contains the AWS Account Information required for CLM 4.x.
  6. Verify that the BNA URL is accessible from the Platform Manager.
  7. Before you run the Migration Utility, make sure you have proper PM primary host entry in the BMCCloudLifeCycleManagementInstalledConfiguration.xml filed (located in the <ARHOME>/BMCCloudLifeCycleManagement folder).
  8. Run Cloud Migration. 

Performing Delta Data Migration

  1. Install the Delta Migrator tool on a Windows host.

  2. Before starting DeltaMigration.exe (by default, C:\Program Files\BMC Software\Migrator\migrator\DeltaDataMigration), change the Configuration.xml in the same path to point to the correct directory of the DeltaMigration.exe.
    Review the following parameter:

    <delta work-dir=".\Working" migrator-dir="C:\Program Files\BMC Software\Migrator\migrator">
  3. Log on to the BMC Remedy IT Service Management server host and navigate to <BMCCloudLifeCycleManagement>\Cloud_DB\publicextensions\ddmpackage.
  4. Extract and copy the CLM folder from BMC Remedy IT Service Management (Enterprise-AR) host from the previous path to the migrator machine in the C:\Program Files\BMC Software\Migrator\migrator\DeltaDataMigration\Packages folder.
  5. Modify the C:\Program Files\BMC Software\Migrator\migrator\DeltaDataMigration\Configuration.xml file on the migrator host to add the following lines:
    ddm.png
    You can copy these entries from the BMC Remedy IT Service Management host (    <BMCCloudLifeCycleManagement>\Cloud_DB\publicextensions\ddmpackage\Configuration.xml).
  6. Disable DSO and the Reconciliation Engine on the Source and Target AR System servers, and make sure that AR System server have the migrator license.
  7. Launch the migrator utility and run the migration for Enterprise-AR and Cloud-DB.

Performing the upgrades on the secondary servers

You now can perform the upgrades on the secondary servers. 

To upgrade secondary Mid-Tier

  • Upgrade the secondary Mid-Tier.

To integrate secondary BMC Remedy IT Service Management

  1. Make sure that Enterprise-AR Secondary points to the upgraded database. 
    Make sure that you change the service name in tnsnames.ora to the upgraded database, and do not change the Connection Identifier.
  2. Make sure that Enterprise-AR Secondary is in the server group.
  3. Upgrade Enterprise-AR Secondary.

To upgrade Cloud-DB

  1. Make sure that Cloud-DB Secondary points to the upgraded database. 
    Make sure that you change the service name in tnsnames.ora to the upgraded database, and do not change the Connection Identifier.
  2. Make sure that Cloud-DB Secondary is in the server group.
  3. Upgrade Cloud-DB Secondary.

To upgrade secondary Atrium Core Web Services

  • Upgrade the secondary Atrium Core Web Services.

To upgrade secondary BMC Network Automation

  1. Reconfigure the cluster to add the primary server into the BNA cluster again.
    For more information, see the cluster deployment documentation.
  2. Failover the cluster to secondary.
  3. Upgrade the secondary BMC Network Automation.

To upgrade secondary Platform Manager

  1. Reconfigure the cluster to add the primary server into the Platform Manager cluster again.
    For more information, see the cluster deployment documentation.
  2. Failover the cluster to secondary.
  3. Create the soft links for CSM and the Quick Start service on secondary. 
    You do not need to perform a secondary installation. 

To upgrade secondary Atrium Orchestrator

For 2.1.x upgrades only, shut down (that is, dismantle) the production Atrium Orchestrator servers. 

Finishing the Staged-Lite upgrade

  1. When you finish the secondary upgrade, enable the disabled or suspended services on the load-balancer.
  2. Make the appropriate changes to the /etc/hosts file of each server.

Where to go from here

  1. When you finish upgrading all the BMC Cloud Lifecycle Management products, verify that the upgrade was successful.
  2. Apply the following hotfixes/patches after you install or upgrade version 4.1.00:
    Error
    Synchronize-Virtual-Cluster-or-SOI-causes-VMs-to-be-decommissioned—Patch 4 is required. If you do not apply this patch the agent runs out of Java heap memory and thereby results in BMC Cloud Lifecycle Management erroneously decommissioning VMs on that cluster.
    • 000110488—This hotfix provides missing files necessary for using a currency other than USD.
    • 000111195—This hotfix updates field values that are displayed blank for Cloud Platform and Installable Resources in Service Designer and is required for all BMC Cloud Lifecycle Management deployments. QM001858190/QM001876321 in BMC Cloud Lifecycle Management 4.1 Patch 3 fixes this issue. For details, see Known and corrected issues.
    • 000031574—This hotfix applies only if you have BMC Capacity Optimization deployed in your environment.
    • 000107519—This hotfix is required for all BMC Cloud Lifecycle Management deployments.
  3. Perform the post-upgrade configuration tasks.

 

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

BMC Cloud Lifecycle Management 4.1