Migrating KUMA standalone to Kaspersky Next XDR Expert

May 15, 2024

ID 272361

To perform the migration from KUMA standalone to Kaspersky Next XDR Expert, complete the following stages.

Preparation

Before you perform the migration, follow the preliminary steps:

  1. Copy the CA certificate from KUMA Core standalone to the Administrator's host.
  2. Generate a new token and keep the token in a safe place. Later, you will specify the new token in the smp_param file.
  3. Prepare a backup for KUMA standalone and keep the backup in a safe place. In case of a force majeure, you will be able to restore the instance of KUMA standalone and repeat the migration all over again. Otherwise, in case of a failure, KUMA Core may be corrupted and you will not be able to perform the migration.

    Also, we recommend that you keep track of time when preparing the backup, and notice the size of the backup. Later, you may need to adjust the respective values for timeout and spare space on the storage volume in the smp_param file.

  4. Prepare the hosts for installation of Kaspersky Next XDR Expert: verify that you opened the required ports, copied the CA certificate from KUMA Core to the Administrator’s host, generated the token, that you have SSH root access to the target hosts of KUMA standalone and access from Kaspersky Next XDR Expert workers to port TCP 7223 of the deployed KUMA standalone .
  5. Prepare the inventory file. In the inventory file, list all hosts that you use for services in KUMA standalone. The hosts must match in both inventory files. If necessary, you can get the required information regarding hosts in KUMA Resources → Active services. Please note that you should specify both FQDN and IP-address for all hosts.
  6. Prepare the smp_param file. Ensure that you set the following parametes:
    1. Set the migration flag to true.

      - name: migration

      source:

      value: "true"

    2. Specify the path to the CA certificate that you copied from KUMA standalone to the Administrator’s host.

      - name: coreSourceCA

      source:

      path: "<full path to the CA certificate>"

    3. Specify FQDN for KUMA Core standalone.

      - name: coreSourceFQDN

      source:

      value: "<KUMA Core standalone FQDN>”

    4. Specify the token.

      - name: coreSourceToken

      source:

      value: <token>

    5. Specify the helm timeout.

      The default value of the helmTimeout parameter is 5 minutes. If copying backup takes longer than the specified timeout value, an error may occur. As a result, KUMA resources may become unavailable. To avoid such scenario, keep track of time when preparing the backup and adjust the timeout value accordingly. In the following example, the timeout is set to 50 minutes.

      - name: helmTimeout

      source:

      value: "50m0s"

    6. Specify custom settings for storage volume.

      If you plan to import a large MongoDB base, ensure that the LowResource parameter value is set to false.

      - name: lowResources

      source:

      value: 'false'

      Also, please specify the required size of the volume in accordance with the size of a prepared backup. The default size value is 512 GB which may be excessive for your deployment. Adjust the value as applicable and specify the required values. In the following example, the volume for KUMA Core is set to 50 GB:

      - name: coreDiskRequest

      source:

      value: 50Gi

Migration

Run the KDT utility using the prepared smp_param file, same as for initial installation.

After migration is complete, all services are available in KUMA console under Resources → Active services.

Troubleshooting

If the migration fails, follow the steps:

  1. Go to the directory, where the KDT utility is located and run the following command to check the log file:

    ./kdt status -l kuma

    If you figure out that the migration failed when installing the services, which would be clear of the log records, the other steps of this procedure would be of no help and we recommend that you contact the Customer support service.

  2. Check the parameters in the smp_param file. Verify that the required ports are open and the target hosts are available, and that you set appropriate value for the helmTimeout parameter. If necessary, export the smp_param file and amend the values as applicable:

    ./kdt ec > /root/ksmp/smp_param1.yaml

  3. Run the kdt tool with the edited smp_param file:

    ./kdt apply --force -k <KUMA as a part of XDR archive>.tar -i /root/ksmp/smp_param1.yaml

Did you find this article helpful?
What can we do better?
Thank you for your feedback! You're helping us improve.
Thank you for your feedback! You're helping us improve.