Migrate Broker or Bridge deployments to v9 from v8.x.x

Provision a new RHEL8 (8.6 minimum) server on which the v9.0.x Moogsoft Broker will be later installed.

Stop any running brokers and integration-related Java processes on the v8.x.x server:

For RPM-based deployments:

kill -9 $(ps -ef | grep java | grep -v grep | grep broker | awk '{print $2}') 2>/dev/null
kill -9 $(ps -ef | grep java | grep -v grep | grep lam | awk '{print $2}') 2>/dev/null

For Tarball-based deployments:

kill -9 $(ps -ef | grep java | grep -v grep | grep broker | awk '{print $2}') 2>/dev/null
kill -9 $(ps -ef | grep java | grep -v grep | grep lam | awk '{print $2}') 2>/dev/null

After Moogsoft Support confirms that the Moogsoft Hosted environment has been successfully upgraded to v9.0.x:

When the new Broker and LAMs are running as expected in the v9.0.x environment, you can fully shut down the v8.x.x environment.

Install v9.0.x.

Moogsoft Onprem must be installed on new RHEL8 servers (minimum RHEL v8.6) in the same deployment configuration (single server, HA, etc.) as the v8.x.x deployment.

For installation instructions, see Install Moogsoft Onprem.

Copy the required configuration files from the v8.x.x server to the v9.0.x server.

The following folders must be backed up and copied to the v9 servers:

The following commands will create tarballs of the config and bots folders, as well as any saml xml files:

tar --ignore-failed-read --exclude=config/system.conf -C $MOOGSOFT_HOME -cvzf config_bots_for_migration.tgz config bots

The tgz file must now be copied onto the v9 servers.

On the v9 server, make a backup of the config and bots folders using this command:

tar -C $MOOGSOFT_HOME -cvzf ~/config_bots_v9_original.tgz config bots

The v8 tgz files can now be extracted, and the permissions fixed:

Moogsoft will create a new v9.0.x Hosted environment and migrate your hosted data and configuration. At the start of this process, Moogsoft will ask you to create a RabbitMQ Shovel, and to stop the local v8 and (if started, v9) Moogsoft Bridge processes. This will allow events to buffer in the local RabbitMQ instances while Moogsoft is upgrading the hosted instance to v9.

As per Moogsoft Support's instructions, create the RabbitMQ Shovel. This will forward events sent to the local v8 Bridge server to the local v9 Bridge server until the Hosted upgrade is complete.

For the following steps, these values must be used:

As per Moogsoft Support's instructions, stop the v8 Bridge process (and the v9 Bridge process, if started). Events will continue to feed into the local v8 server but now will be forwarded to the local v9 server RabbitMQ process for storage during the upgrade maintenance window.

crontab -l | sed '/moogsoft_bridge_watchdog/s/^/#/' | crontab -
kill -9 $(ps -ef | grep java | grep -v grep | grep bridge | awk '{print $2}') 2>/dev/null

Events will now queue in the v9.x.x RabbitMQ instance as they will be sent from the v8.x.x RabbitMQ instance to the v9.x.x RabbitMQ instance.

Respond to Moogsoft Support and communicate that the Shovel has been created and the Bridge(s) have been stopped.

Moogsoft Support will contact you once the hosted v9 upgrade is complete.

At this point the local v9 Bridge process can be configured and started. Start the Moogsoft Bridge on your v9.0.x server:

For RPM-based deployments:

$MOOGSOFT_HOME/bin/utils/moog_init_lams.sh --bridge

For Tarball-based deployments:

$MOOGSOFT_HOME/bin/utils/moog_init_lams.sh --bridge

Start the required Moogsoft LAMs on the v9 server

Example for RPM-based deployments:

service restlamd start

Example for Tarball-based deployments:

$MOOGSOFT_HOME/bin/utils/process_cntl rest_lam start

Update all Event Feeds to send events to your v9.0.x LAMs instead of the v8.x.x LAMs

Re-create any crontab entries on the v9.0.x server(s) which were present on the old v8.x.x servers. Possibly entries might include:

Run the following command to enter a 'vi-like' editor to update the crontab as needed:

crontab -e

Once the new v9 Bridge, v9 LAMs, and UI-based Integrations are running as expected in the v9.0.x environment, you can fully shut down the local v8.x.x environment.

Remove the v8 Shovel using this command on the local v8 RabbitMQ server:

rabbitmqctl clear_parameter shovel "my_shovel" -p TEST_ZONE

Create a new shovel going the opposite direction using the commands in this section as a template:

However this time, swap the parameters as follows:

This will send any queued events back across to the local v8 Bridge server.

Stop the v9 Bridge process and start the v8 Bridge process.