Cloud Services

Enterprise Marketplace

Migrate a non-MT dedicated environment to an MT environment
Published On Oct 04, 2024 - 8:29 AM

Migrate a non-MT dedicated environment to an MT environment

Steps needed to restore data from a non-multi-tenant (non-MT) system to a MT system or a single tenancy bridge mode deployment.
This page covers the steps needed to restore data from a non-multi-tenant (non-MT) system to a MT system or a single tenancy bridge mode deployment.

Prerequisites

Complete the following prerequisites before attempting to migrate your data:
  1. If the non-MT system is using external context, ensure that the external context adapter setup is ready. Kyndryl Modern Operations Applications MT environments provide support for internal authorization only.
  2. Install MongoDB Community Edition in your system. It can be downloaded from the MongoDB website.

Setup procedure

To migrate your data to the new MT system, complete the following steps:
  1. Navigate to the
    Kyndryl Modern Operations Applications Tenant Manager
    page.
  2. Click
    Create Tenant
    .
    Do not associate this tenant with any broker.
  3. On the
    Create Tenant
    page, enter the following information for the new tenant:
    • Customer Name
    • Enter Tenant Hostname
    • Enter Customer Email
    • Enter Kyndryl Client ID
    • API Host URL
    • Choose an Identity Provider:
      Select an IDP that matches the one of the non-MT systems.
    • Choose a Database Connection:
      Select the connection you want to use from the drop-down menu.
    • Applications:
      Do not associate this tenant with any application.
  4. Click
    Create
    .
  5. When you receive the invitation email, make a note of the tenant id, which in this example is
    5e975ebd0d904800015dd9d2
    . Then, click the
    Get Started
    button in the email to log in with basic info and without any role.
  6. Create a MongoDB dump from the non-MT system using the following command:
    rajat@GS-5339 mongodump_zipped % mongodump --host mydocker.edge --port 300
    .
    If the backup file is encrypted, decrypt it using the following command:
    openssl enc -aes-256-cbc -d -in .tar.aes -k -md sha256 | tar x
    .
    The following shows an example directory structure generated by the
    mongodump
    process:
    rajat@GS-5339 mongodump_zipped % tree . ├── mongodb_backup__catalog.gz ├── mongodb_backup__gcs.gz └── mongodb_backup__shopping_bag.gz0 directories, 3 files
  7. Restore the MongoDB dump to the new MT system using the following command:
    mongorestore --host <hostname> --port <port> --gzip --archive=<backupfilename> --username <username> --password <password> --authenticationDatabase=<authenticationdbname> --nsFrom='<fromDBname>.*' --nsTo='<tenant_id>_<toDBname>.*'
  8. Download the following files and store them in the same folder:
    • migrate.sh
    • vault_update.js
  9. Restore the backup data using the following MongoDB script. The script will also add configuration database documents to the default configuration database. It take the following arguments:
    • Mongo Connection String URI
    • Path to the folder containing dump files in .gz format. The backup file names should be in the format
      <mongodb_backup>__<db_name>.gz
      .
    • Tenant ID
    • (optional) Path to an
      SSL CA.pem
      file. If this argument is provided, SSL authorization will be enabled for Mongo connection.
      ./migrate.sh "mongodb://<username>:<password>@mydocker.edge:30727" MONGODB/ "5e86d44fc6814600018a3541" [/path/to/ca.pem]
      The following databases and collections are excluded from the backup:
      • Admin DB from system
      • Authorization DB
        • roles_v2 collection
      • Notification DB
        • notificationtemplates collection
        • Category collection
      • api_gateway database 
  10. (optional) If you are performing this migration on your local machine and do not want to set up an already existing external context, delete the external context tag type from the context collection under authorization database
    >db.getCollection('contexts').find({"context.value_source": "external"}
    . Otherwise skip this step.
  11. (optional) If you are performing this migration on your local machine, edit the
    cb-core-authorization deployment
    file to expose the host and host API for
    cb-core-authorization service
    as shown in the following example and then run
    ./local_build.sh
    on the cb-core-authorization service.
    hostAliases: - ip: 192.168.1.2 (your machine IP) hostnames: - testdemo7.gravitant.net (should match to tenant host) - testdemo7-api.gravitant.net (should match to tenant api host)
  12. On the
    Kyndryl Modern Operations Applications Tenant Manager
    page, click the
    Edit
    icon for the tenant you just created.
  13. In the
    Applications
    section, associate the tenant with
    IBM Multicloud Core Plus
    .
  14. Click
    Update
    .

Verifying the migration

To verify that your data has been migrated successfully, perform the following tests:
  1. Verify whether the user that you migrated with, such as [email protected], can log in to the tenant that you created. This user must have the system admin role and should belong to the same teams as it did in the non-MT system.
  2. Check whether [email protected] can perform all the system admin functions such as view all the users, teams, contexts, organization, and so on.
  3. Verify whether [email protected] can create a team with the assignment of user and role.
  4. Corroborate whether [email protected] can regenerate the API key and use it for API flow.
Do you have two minutes for a quick survey?
Take Survey