Workload Import & Migration

Each Trilio Workload has a dedicated owner. The ownership of a Workload is defined by:

• OpenStack User - The OpenStack User-ID is assigned to a Workload

• OpenStack Project - The OpenStack Project-ID is assigned to a Workload

• OpenStack Cloud - The Trilio Serviceuser-ID is assigned to a Workload

OpenStack Users can update the User ownership of a Workload by modifying the Workload.

This ownership secures, that only the owners of a Workload are able to work with it.

OpenStack Administrators can reassign Workloads or reimport Workloads from older Trilio installations.

Import workloads

Workload import allows to import Workloads existing on the Backup Target into the Trilio database.

The Workload import is designed to import Workloads, which are owned by the Cloud.

It will not import or list any Workloads that are owned by a different cloud.

To get a list of importable Workloads use the following CLI command:

workloadmgr workload-get-importworkloads-list [--project_id <project_id>]

• --project_id <project_id> ➡️ List workloads belongs to given project only.

To import Workloads into the Trilio database use the following CLI command:

workloadmgr workload-importworkloads [--workloadids <workloadid>]

• --workloadids <workloadid> ➡️ Specify workload ids to import only specified workloads. Repeat option for multiple workloads.

Orphaned Workloads

The definition of an orphaned Workload is from the perspective of a specific Trilio installation. Any workload that is located on the Backup Target Storage, but not known to the TrilioVualt installation is considered orphaned.

Further is to divide between Workloads that were previously owned by Projects/Users in the same cloud or are migrated from a different cloud.

The following CLI command provides the list of orphaned workloads:

workloadmgr workload-get-orphaned-workloads-list [--migrate_cloud {True,False}]
                                                 [--generate_yaml {True,False}]

• --migrate_cloud {True,False} ➡️ Set to True if you want to list workloads from other clouds as well. Default is False.

• --generate_yaml {True,False} ➡️ Set to True if want to generate output file in yaml format, which would be further used as input for workload reassign API.

Running this command against a Backup Target with many Workloads can take a bit of time. Trilio is reading the complete Storage and verifies every found Workload against the Workloads known in the database.

Reassigning Workloads

OpenStack administrators are able to reassign a Workload to a new owner. This involves the possibility to migrate a Workload from one cloud to another or between projects.

Reassigning a workload only changes the database of the target Trilio installation. When the Workload was managed before by a different Trilio installation, will that installation not be updated.

Use the following CLI command to reassign a Workload:

workloadmgr workload-reassign-workloads
                                        [--old_tenant_ids <old_tenant_id>]
                                        [--new_tenant_id <new_tenant_id>]
                                        [--workload_ids <workload_id>]
                                        [--user_id <user_id>]
                                        [--migrate_cloud {True,False}]
                                        [--map_file <map_file>]
                                        [--source-btt <source-btt> [<source-btt> ...]]
                                        [--source-btt-all]

• --old_tenant_ids <old_tenant_id> ➡️ Specify old tenant ids from which workloads need to reassign to new tenant. Specify multiple times to choose Workloads from multiple tenants.

• --new_tenant_id <new_tenant_id> ➡️ Specify new tenant id to which workloads need to reassign from old tenant. Only one target tenant can be specified.

• --workload_ids <workload_id> ➡️ Specify workload_ids which need to reassign to new tenant. If not provided then all the workloads from old tenant will get reassigned to new tenant. Specifiy multiple times for multiple workloads.

• --user_id <user_id> ➡️ Specify user id to which workloads need to reassign from old tenant. only one target user can be specified.

• --migrate_cloud {True,False} ➡️ Set to True if want to reassign workloads from other clouds as well. Default if False

• --source-btt <source-btt> [<source-btt> ...] ➡️ It searches workloads in the given Backup Target Types Id. If not provided then considers default BTT. Only single --source-btt is allowed if --workload-ids are provided. --source-btt <source-btt-1> <source-btt-2> ... <source-btt-N>

• --source-btt-all ➡️ This will search in all Backup Target Types and reassign the workloads. Only allowed when --workload-ids is NOT provided. User must provide --old_tenant_ids and --new_tenant_id to use it.

• --map_file ➡️ Provide file path(relative or absolute) including file name of reassign map file. Provide list of old workloads mapped to new tenants. Format for this file is YAML.

A sample mapping file with explanations is shown below:

reassign_mappings:
   - old_tenant_ids: [] #user can provide list of old_tenant_ids or workload_ids
     new_tenant_id: new_tenant_id
     user_id: user_id
     source_btt: source_btt # list of source_btt ID's where provided workload IDs will be searched
     source_btt_all: True # searches all workloads in all available BTTs
     workload_ids: [] #user can provide list of old_tenant_ids or workload_ids
     migrate_cloud: True/False #Set to True if want to reassign workloads from
                  # other clouds as well. Default is False
    
   - old_tenant_ids: [] #user can provide list of old_tenant_ids or workload_ids
     new_tenant_id: new_tenant_id
     user_id: user_id
     source_btt: source_btt # list of source_btt ID's where provided workload IDs will be searched
     source_btt_all: True # searches all workloads in all available BTTs
     workload_ids: [] #user can provide list of old_tenant_ids or workload_ids
     migrate_cloud: True/False #Set to True if want to reassign workloads from
                  # other clouds as well. Default is False

Note:- We cannot reassign the immutable backup target workload from one cloud to another. To do this, we need to follow the steps outlined below

Steps:-

1. Download the immutable workload directory from its mount path and upload/copy it to the non-immutable backup target mount path.

2. We need to update the backup_target_types and backup_media_target metadata property of the workload and all it’s snapshots at backup target to the current backup target where it exists. Here reference Please perform following steps to accomplish the task.

3. Check the original backup_target_types and backup_media_target metadata property of the workload using either less or jq command. If you already knows this information then you may skip this step.

    a. Using less command
        i. less <file_system_mountpath>/workload_<workload_uuid>/workload_db
        ii. Example
            1. less /var/trilio/triliovault-mounts/L2hvbWUva29sbGEv/workload_385d0e94-d602-4963-96c2-28bebea352f1/workload_db
        iii. search backup_target_types and backup_media_target in the file and note down it’s respective values

    b. Using jq command
        i. jq '.metadata[] | select(.key == "backup_media_target") | .value' <file_system_mountpath>/workload_<workload_uuid>/workload_db
        ii. Example
            jq '.metadata[] | select(.key == "backup_target_types") | .value' /var/trilio/triliovault-mounts/L2hvbWUva29sbGEv/workload_385d0e94-d602-4963-96c2-28bebea352f1_backup/workload_db
        iii. search backup_target_types and backup_media_target and note down it’s respective values

1. Find & replace the backup_target_types property of the workload and it’s all respective snapshots

    a. grep -rl 'old_BTT' <file_system_mountpath>/workload_<workload_uuid> | xargs sed -i 's/<old_BTT>/<new_BTT>/g'
    b. Here,
        i. old_BTT  ---> Old Backup Target Type name
        ii. new_BTT ---> New Backup Target Type name  
    c. Example
        i. grep -rl 'nfs_1' /var/trilio/triliovault-mounts/L2hvbWUva29sbGEv/workload_385d0e94-d602-4963-96c2-28bebea352f1 | xargs sed -i 's/nfs_1/nfs_2/g'

1. Find & replace the backup_media_target property of the workload and it’s all respective snapshots

    a. grep -rl '<old_filesystem_export>' <file_system_mountpath>/workload_<workload_uuid> | xargs sed -i 's/<old_filesystem_export>/<new_filesystem_export>/g'
    b. Here,
        i. old_filesystem_export  ---> File system export path of old Backup Target
        ii. new_filesystem_export ---> File system export path of new Backup Target
    c. Note: Please make sure to use {{}} before every {{/ }} character in old_filesystem_export & new_filesystem_export places.
    d. Example
        i. grep -rl '192.168.0.51:/home/kolla/' /var/trilio/triliovault-mounts/L2hvbWUva29sbGEv/workload_385d0e94-d602-4963-96c2-28bebea352f1 | xargs sed -i 's/192.168.0.51:\/home\/kolla\//192.168.0.52:\/home\/kolla_new\//g'
        ii. Here the original filesystem export is 192.168.0.51:/home/kolla/ which we have mentioned in above command as 192.168.0.51:\/home\/kolla\/ by adding additional }} before every {{/ character. The same changes are expected for new filesystem export path as well.

1. Verify the changes

    a. The following commands must show the files having the updated changes.
        i. grep -rl 'new_BTT' <file_system_mountpath>/workload_<workload_uuid>
        ii. grep -rl '<new_filesystem_export>' <file_system_mountpath>/workload_<workload_uuid>

1. Now try reassigning the workload.