Moving or duplicating a BMC Server Automation environment

This topic outlines the procedure for moving or duplicating a BMC Server Automation environment. This includes the BMC Server Automation application, file, and PXE/TFTP servers.  

You might want to move or replicate a BMC Server Automation environment for the following reasons:

• To create a test environment to prepare for an upgrade, training or other testing
• To move BMC Server Automation infrastructure to new hardware.

When performing the upgrade of BMC Server Automation, it is usually advantageous to attempt the upgrade in a copy of the production environment — this will give you an idea of how long the actual upgrade will take and identify any possible errors that can be resolved by BMC Support in a less time-critical environment.  Additionally, the 'copy and upgrade' method can be used for the actual upgrade or for creating a new environment.  The steps below are meant to cover the high-level steps that you must perform, and the specifics will likely vary, depending on the database in use, the operating systems involved, and the particular environment details.

Some permutation of the below steps can be used to cover a few different use cases:

• Testing the upgrade in a tear-down environment before running in the live production environment
• Creating a clone of the existing environment on new hardware before decommissioning the old environment
• Moving the old environment to new hardware and upgrading in one swoop

The following sections discuss the necessary tasks:

Before You Begin

Before moving or replicating your BMC Server Automation environment, note the following issues:

• You will maybe need to temporarily stop your BMC Server Automation Application server to create a backup of your database and file server, depending on the backup mechanisms being used. This will ensure that both backups are synchronized to the same date and time.
  • Therefore, you will need to notify any BMC Server Automation users that the system will be down during this process. The amount of time that the application server will be down depends on how quickly you are able to copy your file server and database. This time period can vary, depending on how much data is contained in each of these infrastructure pieces.
• Decide what you are going to move or replicate. In some cases, you might want to move only the file server. In other cases you might want to replicate your entire infrastructure. The following sections assume that you are moving or replicating your entire environment, so if a particular piece does not apply to what you are moving or replicating, skip that step.

Duplicating the installation infrastructure

Perform the following steps in the listed order. For example, make sure that the new BMC Server Automation database instance/schema is available before installing the new application server.

Prerequisites

Ensure that your environment includes the following elements:

• A server in which to install the BMC Server Automation Application Server
• A server in which to install the RSCD Agent for the File Server (which may also be the same server as the Application Server)
• Enough space on the File Server to match the space for the current Production File Server
• A database of the same type and version as the current Production database in which to import the exported database

Moving the Database

To move the database, perform the following steps:

1. In the new database server, create the BladeLogic database or tablespaces and the bladelogic database user.
   1. Oracle
   2. MSSQL
2. Export the database/schema from the old BladeLogic Database.  There are many utilities that can do this, a couple examples are noted below.
   1. Oracle: Use the Oracle 'data pump' utility, as in the following example.
      expdp [sys username]/[password]@[sid] schemas=[bladelogic schema] directory=[test_dir] dumpfile=[bladelogic schema].dmpdp logfile=expdp_[bladelogic schema]_[date].log flashback_time="\"to_timestamp(to_char(sysdate,'mm-dd-yyyy hh24:mi:ss'), 'mm-dd-yyyy hh24:mi:ss')\"" 
   2. MSSQL
3. Import the core database into the new database server w/ the corresponding import tool.  An example is shown below.
   1. Oracle: Use the Oracle 'data pump' utility, as in the following example.
      impdp [sys username]/[password]@[sid] dumpfile=[bladelogic schema].dmpdp logfile=impdp_[bladelogic schema]_[date].log transform=oid:n full=n schemas=[old schema name] directory=[test_dir] table_exists_action=replace remap_tablespace=[old bladelogic tablespace:new bladelogic tablespace],[old bladelogic index tablespace:new bladelogic index tablespace]
remap_schema=[old bladelogic schema:new bladelogic schema]  
   2. MSSQL

Moving the File Server

To move the file server, perform the following steps:

1. Install an RSCD agent on the server that will function as a RSCD Agent.

   Note

   If you are using a non-Windows environment, you can skip this step, as the RSCD Agent is included in the Application Server installation that will be performed in the next section.

2. Copy the file server storage location from the old location to the new location.  This can be done with a variety of utilities such as dsync, rsync and NAS or SAN replication tools.  The file server replication should be paired to the database replication.
3. If the application server is not being moved then follow the Changing the location of the file server to update the application server configuration and database with the location of the new file server, otherwise wait to perform this step when the new application server is online.

Moving the Application Server

To move the application server, perform the following steps:

1. Install the application server software on the new application server(s).  Do not run the blappconf wizard.
2. Using the blasadmin utility configure the Database section parameters noted below.  These settings will be for the new database server.
   

   blasadmin -a set database ConnectionString <ConnectionString>

   blasadmin -a set database DriverClass <DriverClass>

   blasadmin -a set database UserId <user_name>

   blasadmin -a set database Password <Password>

3. Copy the files listed in the Files section of the Backup and restore of the BladeLogic environment document from the old application server to the new application server(s) except the bladelogic.keystore file.  Leave the bladelogic.keystore that we created during install on the new application server.

4. Follow the Changing the location of the file server to update the application server configuration and database with the location of the new file server

Provisioning

To move the provisioning environment, perform the following steps:

1. If replicating your provisioning environment, install the BladeLogic PXE & TFTP server.
2. Copy your provisioning data store to the new server.
3. Replicate any custom application server settings by running <bl_install_dir>/br/blasadmin.

Post-move configurations

After your environment has been moved, there are some final steps that you will want to make to ensure that there are no conflicts with your existing environment.

Updating Extended Object Locations

If there are Extended Objects that reference the old file server or other location these must be updated as well.

Removing old application servers

In the new environment run the following query to remove the old application servers

update application_server_model set is_deleted = 1;

commit; (oracle only)

Preventing access from the new environment to the existing Application Servers

There are a few ways to accomplish this. One way to handle this is to generate a self-signed certificate for an Application Server in the new environment. Another way is to restrict network access between the two environments; this will prevent accidentally connecting to the original environment.

Removing Job Schedules

If the new environment is being used for testing you will want to disable scheduled jobs so they will not run against the registered servers.  This can be done with a simple query:

update schedule set is_deleted = 1;

commit; (oracle)

Preventing access from the new environment to existing managed servers

If the new environment is being used for testing you may want to prevent the new application servers from talking to your existing targets.  This is possible by pushing out an exports file from the original appserver/environment to all target servers that allows connections from only the original application servers and any NSH client systems you need to allow connections from.

Decommissioning Servers (optional)

1. Decommission any servers that are in the development environment that you will not manage. This will prevent any confusion for anyone that might log into the duplicated environment.

   Note

   If you have an 8.x environment AND have the Licensing Portal configured, make sure that you configure the Licensing Portal to not re-claim any licenses when you decommission servers. If you do, you will need to re-license your servers in the original environment that you copied from.

2. Ensure that only the servers that are expected to be registered in the duplicated environment remain.

Final Steps

After completing the steps in the new environment, start up the Application Server services and log on to the BMC Server Automation Console.