Центр знаний
Центр знаний по приложениям для бизнеса
Kaspersky Symphony XDR
Перенос данных в Open Single Management Platform
О переносе данных из KUMA
Перенос данных автономной версии KUMA в Open Single...
Kaspersky Symphony XDR
Онлайн-справка
FAQ Форум Запрос в поддержку Обучающие видео

Перенос данных автономной версии KUMA в Open Single Management Platform

03 июня 2026

ID 272361

Скачать PDF

Развернуть все | Свернуть все

В этой статье описан сценарий переноса данных и сервисов из автономной версии KUMA в Open Single Management Platform.

После завершения переноса данных все службы автономной версии KUMA повторно подключаются к Ядру KUMA под управлением Open Single Management Platform, а сервисы автоматически перезапускаются. Автономная версия Ядра KUMA не изменяется во время переноса данных, но если какие-либо сервисы были установлены на том же устройстве, что и автономная версия Ядра KUMA, автономная версия Ядра KUMA может стать недоступной, поскольку двоичные файлы заменяются в ходе процедуры.

Перенос данных из автономной версии KUMA в Open Single Management Platform состоит из следующих этапов:

  1. Создание токена

    В автономной версии KUMA сгенерируйте токен для пользователя, имеющего права на выполнение запроса /api/v1/system/backup, и сохраните токен в надежном месте. Позже вам потребуется этот токен для создания резервной копии автономной версии KUMA.

  2. Подготовка устройств для установки Open Single Management Platform

    При подготовке устройств для установки Open Single Management Platform, выполните следующее:

    • Убедитесь, что вы открыли необходимые порты.
    • Убедитесь, что у вас есть root-доступ по SSH к целевым устройствам автономного KUMA и доступ с рабочих узлов Open Single Management Platform к TCP-порту 7223 развернутой автономной версии KUMA. При необходимости выполните следующую команду, чтобы предоставить root-доступ по SSH к целевым устройствам автономной версии KUMA:

      ssh-copy-id -i /home/xdr/.ssh/id_rsa.pub <user>@<ip_kuma>

  3. Создание резервной копии данных

    Перед выполнением переноса данных создайте резервную копию автономной версии KUMA и сохраните ее в надежном месте. Вы можете восстановить экземпляр автономной версии KUMA и повторить перенос данных заново. Иначе в случае сбоя Ядро KUMA может быть повреждено и вы не сможете выполнить перенос данных.

    Прежде чем создать резервную копию, убедитесь, что Ядро KUMA в Open Single Management Platform имеет сетевой доступ к API-портам сервисов автономной версии KUMA.

    Вы можете создать резервную копию данных одним из следующих способов:

    • С помощью REST API.
    • С помощью следующий команды:

      curl -sS -k "https://<KUMA_standalone_core_FQDN>:7223/api/v1/system/backup" -H "Authorization: Bearer $(cat standalone_token)" --output kuma_standalone_backup.tar.gz

      где standalone_token – это токен, который вы ранее сгенерировали в автономной версии KUMA. Также вы можете указать токен вместо $(cat standalone_token).

    После создания резервной копии убедитесь, что она не повреждена. Для этого выполните следующую команду:

    file kuma_standalone_backup.tar.gz

    На экране вашего устройства отобразится следующее сообщение:

    kuma_standalone_backup.tar.gz: gzip compressed data, last modified: <date_time_modified>, from Unix, original size modulo 2^32 <original_size_bytes>

    Например:

    kuma_standalone_backup.tar.gz: gzip compressed data, last modified: Thu Jul 31 09:05:53 2025, from Unix, original size modulo 2^32 25722880

    Дата и размер могут отличаться, но сообщение должно содержать элементы, сжатые с помощью gzip и original size/original size modulo 2^32 (информация о размере исходных данных).

    Если содержимое сообщения отличается, архив может быть поврежден.

  4. Подготовка файла инвентаря для переноса данных

    Подготовьте файл инвентаря. В файле инвентаря перечислите все устройства, которые вы используете для сервисов в автономной версии KUMA. Устройства должны совпадать в обоих файлах инвентаря, то есть в файле инвентаря, который вы использовали для развертывания автономной версии KUMA, и в файле инвентаря, который вы собираетесь использовать для переноса данных. При необходимости вы можете получить необходимую информацию об устройствах в автономной версии KUMA в разделе Ресурсы → Активные сервисы.

    Если вы хотите расширить инфраструктуру и развернуть сервисы KUMA во время выполнения переноса данных, убедитесь, что вы указали дополнительные устройства в файле инвентаря для развертывания и что эти устройства совпадают с устройствами в файле инвентаря для переноса данных.

    Путь к файлу инвентаря, который вы подготовили, указывается в файле multinode.smp_param.yaml или singlenode.smp_param.yaml в параметре inventory.

    При подготовке файла инвентаря, соблюдайте следующие условия:

    • В группе параметров kuma_utils указаны устройства с сервисами. Если вы хотите расширить инфраструктуру вместе с переносом данных, в этой группе параметров вы также можете указать новые устройства, на которых развернуты сервисы KUMA.
    • Для всех устройств указаны FQDN и IP-адреса.
    • Пропущен раздел kuma_core.
    • В группе параметров all нет изменений для переменных ansible_connection и ansible_user, поскольку переменные соответствуют пользователю и типу соединения, используемого для invocation-образа.
    • В группе параметров kuma убедитесь, что переменные ansible_connection и ansible_user соответствуют пользователю, который выполняет установку на удаленных устройствах. Подробную информацию о файле инвентаря, пользователях и правах см. в справке KUMA.
    • Если DNS разрешает все имена, вы можете указать false для параметра generate_etc_hosts или пропустить параметр generate_etc_hosts.

    Пример файла inventory.yaml с сервисами автономной версии KUMA, установленными на одном устройстве

    Пример файла inventory.yaml с сервисами автономной версии KUMA, установленными на нескольких устройствах

  5. Перенос данных

    На этом этапе сценария выполните перенос данных:

    1. Поместите файл резервной копии автономной версии KUMA на устройство, на котором вы собираетесь установить Open Single Management Platform.
    2. На устройстве администратора выполните следующую команду с параметром kuma_backup_file. Укажите путь к транспортному архиву с компонентами Open Single Management Platform и путь к подготовленному файлу multinode.smp_param.yaml или singlenode.smp_param.yaml, как и при первоначальной установке.

      ./kdt apply -k <путь_к_транспортному_архиву> -i <путь_к_конфигурационному_файлу> --accept-eula -p --if kuma_backup_file=./<резервная_копия_данных_для_автономной_версии_KUMA>.tar.gz

    После завершения переноса данных все сервисы подключаются к Ядру KUMA в Open Single Management Platform и становятся доступными в Консоли KUMA в разделе Ресурсы → Активные сервисы.

    Если автономная версия Ядра ​​KUMA была установлена на отдельном устройстве, после переноса данных автономная версия Ядра ​​KUMA сохранит возможность обращаться к сервисам, перенесенным в Open Single Management Platform. В этом случае отображаются статусы сервисов, а вы по-прежнему можете перезапускать сервисы, изменять конфигурацию сервисов, получать журнал событий сервисов и просматривать события. Чтобы избежать этого, используйте один из способов:

    • Перед выполнением переноса данных отключите автономную версию Ядра KUMA.
    • После переноса данных Open Single Management Platform перейдите в Консоль KUMA Параметры → Общие, нажмите на Перевыпустить внутренние CA-сертификаты, выполните следующую команду и дождитесь перезапуска Ядра KUMA и всех сервисов в Open Single Management Platform.

      ./kdt invoke kuma --action resetServicesCert

Вам помогла эта статья?
Что нам нужно улучшить?
Спасибо за ваш отзыв, вы помогаете нам становиться лучше!
Спасибо за ваш отзыв, вы помогаете нам становиться лучше!