FortiSIEM Migrating VMware ESX-based Deployments

Migrating VMware ESX-based Deployments

The options for migrating VMware ESX deployments depend on whether you are using NFS for storage, and whether you choose to migrate in-place, or by using a staging system or rsync. Using the staging system requires more hardware, but minimizes downtime and CMDB migration risk compared to the in-place approach. The rsync method takes longer to complete because the event database has to be copied. If you use the i n-place method, then we strongly recommend that you take snapshots of the CDMB for recovery.

Migrating an ESX Deployment with Local Storage in Place

Overview

This migration process is for an FortiSIEM deployment with a single virtual appliance and the CMDB data stored on a local VMware disk, and where you intend to run a 4.2.x version on the same physical machine as the 3.7.x version, but as a new virtual machine. This process requires these steps:

Prerequisites

Upgrading the 3.7.x CMDB to 4.2.1 CMDB

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

Assigning the 3.7.x Supervisor’s IP Address to the 4.2.1 Supervisor Registering Workers to the Supervisor

Prerequisites

Contact AccelOps Support to reset your license

Take a snapshot of your 3.7.x installation for recovery purposes if needed

Make sure the 3.7.x virtual appliance has Internet access

Download the 4.2.1 migration scripts (ao-db-migration-4.2.1.tar). You will need the Username and Password associated with your AccelOps license to access the scripts.

Use More Storage for Your 4.2.1 Virtual Appliance

Install the 4.2.1 virtual appliance on the same host as the 3.7.x version with a local disk that is larger than the original 3.7.x version. You will need the extra disk space for copying operations during the migration.

Upgrading the 3.7.x CMDB to 4.2.1 CMDB

1. Log in over SSH to your running 3.7.x virtual appliance as root.
2. Change the directory to /root.
3. Move or copy the migration script ao-db-migration-4.2.1.tar to /root.
4. Untar the migration script.
5. Run ls -al to check that root is the owner of the files ao-db-migration.sh and ao-db-migration-archiver.sh.
6. For each AccelOps Supervisor, Worker, or Collector node, stop all backend processes by running the phtools
7. Check the that archive files phoenixdb_migration_* and opt-migration-*.tar were successfully created in the destination directory.
8. Copy the opt-migration-*.tar file to /root.

This contains various data files outside of CMDB that will be needed to restore the upgraded CMDB.

10. Run the migration script on the 3.7.x CMDB archive you created in step 7.

The first argument is the location of the archived 3.7.x CMDB, and the second argument is the location where the migrated CMDB file will be kept.

11. Make sure the migrated files were successfully created.
12. Copy the migrated CMDB phoenixdb_migration_xyz file to the /root directory of your 4.2.1 virtual appliance This file will be used during the CMDB restoration process.

Removing the Local Disk from the 3.7.x Virtual Appliance

1. Log in to your vSphere client.
2. Select your 3.7.x virtual appliance and power it off.
3. Open the Hardware properties for your virtual appliance.
4. Select Hard disk 3, and then click Remove.

Restoring the Upgraded CMDB in a 4.2.1 Virtual Appliance

1. Log in to your 4.2.1 virtual appliance as root.
2. Change the directory to /opt/phoenix/deployment/.
3. Run the post-ao-db-migration.sh script with the 3.7.x migration files phoenixdb_migration_xyz and opt-migration-*.ta r.
4. When the migration script completes the virtual appliance will reboot.

Adding the Local Disk to the 4.2.1 Virtual Appliance

1. Log into your vSphere client.
2. Select your 4.2.1 virtual appliance and power it off.
3. Go the Hardware settings for your virtual appliance and select Hard disk 3.
4. Click Remove.
5. Click Add.
6. For Device Type, select Hard Disk, and then click Next.
7. Select Use an existing virtual disk, and then click Next.
8. Browse to the location of the migrated virtual disk that was created by the migration script, and then click OK.
9. Power on the virtual appliance.

Assigning the 3.7.x Supervisor’s IP Address to the 4.2.1 Supervisor

1. In the vSphere client, power off the 3.7.x Supervisor.

The IP Address for the 3.7.x Supervisor will be transferred to the  4.2.1 Supervisor.

2. Log in to the 3.7.x Supervisor as root over SSH.
3. Run the vami_config_net

Your virtual appliance will reboot when the IP address change is complete.

Registering Workers to the Supervisor

1. Log in to the Supervisor as admin.
2. Go to Admin > License Management.
3. Under VA Information, click Add, and add the Worker.
4. Under Admin > Collector Health and Cloud Health, check that the health of the virtual appliances is normal.

Setting the 4.2.1 SVN Password to the 3.7.x Password

1. Log in to the 4.2.1 Supervisor as root over SSH.
2. Change the directory to /opt/phoenix/deployment/jumpbox.
3. Run the SVN password reset script ./phsetsvnpwd.sh
4. Enter the following full admin credential to reset SVN password

Organization: Super

User: admin

Password:****

Migration is now complete – Make sure all devices, user created rules, reports, dashboards are migrated successfully