Руководство администратора MIND Migrate #guest 2.16-1

Термины и сокращения

MIND Suite

Программный комплекс, разработанный компанией MIND Software, предназначенный для миграции и репликации IT-сервисов.

MIND Migrate #guest

Модуль комплекса MIND Suite, предназначенный для автоматизированной миграции ОС, приложений и данных между физическими серверами или виртуальными машинами, работающими на различных платформах виртуализации и облачных инфраструктурах.

MIND Flow

Технология, обеспечивающая периодическую синхронизацию данных с источника на приёмник для обеспечения «тёплой» миграции. Использует механизм Change Block Tracking (CBT) для отслеживания и передачи изменений без остановки приложений на источнике.

KTMU

Kernel Tools with MIND Utilities - загрузочный ISO-образ, содержащий базовую ОС, драйверы для различных устройств и набор утилит MIND, используемый приёмником для загрузки во временную ОС для миграции или репликации.

CBT-журнал

Файл, в котором хранится карта блоков данных, измененных с момента последней синхронизации. CBT-журналы создаются для каждого исходного диска на источнике, после чего с их помощью источник определяет данные, которые требуется передать на приёмник.

Агент

Сервис, который запускается на источнике или приёмнике и взаимодействует с контроллером в процессе настройки и запуска заданий на миграцию или репликацию. Каждый агент имеет уникальный идентификатор и регистрируется на конкретном экземпляре контроллера. Агент получает и выполняет команды с контроллера, ведет журнал событий, запускает хост-утилиты и отправляет контроллеру информацию о статусе заданий. Может устанавливаться в ручном режиме или автоматически.

Журнальный диск

Выделенное блочное устройство, путь к каталогу в файловой системе или RAM-диск, используемый для хранения CBT-журналов на источнике и приёмнике. Журнальный диск снижает нагрузку на исходные и целевые диски и уменьшает требования к свободному месту при синхронизации. При репликации данных использование журнального диска на приёмнике обязательно.

Источник

Машина, с которой выполняется копирование (синхронизация) данных на приёмник в процессе выполнения миграции. Источник содержит исходную операционную систему, приложения, данные и настройки, которые переносятся на приёмник.

Контроллер

Центральный компонент MIND Suite. Выступает в роли оркестратора для реализации функций управления и контроля за выполнением заданий миграции и репликации, координирует работу компонентов, хранит конфигурацию и предоставляет интерфейс взаимодействия (GUI и API) для пользователей и администраторов. Контроллер устанавливается на выделенный сервер под управлением совместимой ОС Linux и состоит из набора взаимодействующих между собой сервисов, работающих в виде нативных сервисов systemd и внутри контейнеров: API, Scheduler, Vault, Postgres, RabbitMQ и других.

Машина

Виртуальная машина, физическая рабочая станция или сервер, зарегистрированный на контроллере для использования в качестве источника или приёмника в заданиях миграции или репликации.

Приёмник

Машина, на которую выполняется копирование (синхронизация) данных с источника в процессе выполнения миграции. После завершения процесса приёмник содержит копию ОС, данных и приложений, идентичную источнику.

Прокси-группа

Логическое объединение из одного или нескольких прокси-серверов. При назначении машине прокси-группы агент выбирает один из серверов и использует его как промежуточный узел для сетевого взаимодействия с контроллером или другой машиной в задании миграции/репликации. При отказе сервера агент автоматически переключается на другой доступный сервер группы.

Прокси-сервер

Выделенная виртуальная машина или физический сервер с ОС Linux и установленным прокси-агентом; выполняет опциональную роль промежуточного узла для передачи трафика между источником и приёмником либо между машинами и контроллером при отсутствии прямой сетевой связности.

Синхронизация

Процесс передачи данных от источника к приёмнику для поддержания их в консистентном состоянии. MIND Suite поддерживает два варианта синхронизации - первичную (полную) и периодическую (дельта-синхронизацию). Первичная синхронизация выполняется при первом запуске задания миграции или репликации для полного копирования данных с исходных дисков источника на целевые диски приёмника. Периодическая синхронизация использует снапшоты для передачи изменений, которые появились на источнике с момента последней синхронизации. Периодическая синхронизация может выполняться по расписанию через заданные интервалы времени или вручную перед переключением.

Снапшот

Моментальный снимок диска, создаваемый при каждой итерации синхронизации данных. Используется для формирования CBT-журналов для отслеживания измененных блоков. При синхронизации данных в ОС семейства Windows используется механизм Volume Shadow Copy Service (VSS), в ОС Linux используется mindbd.

Назначение

Задачи переноса ОС, приложений и данных сопряжены с рядом сложностей, такими как:

• Отсутствие универсального подхода, который может использоваться для переноса широкого перечня операционных систем семейства Windows и Linux, независимо от того, на каком оборудовании, виртуальной инфраструктуре или облаке они запускаются.

• Нехватка специализированных функций внутри имеющихся инструментов, таких как системы резервного копирования и конверторы дисков, позволяющих упростить процесс переноса данных и избавиться от необходимости выполнения множества ручных операций, связанных с настройкой машин до и после миграции.

• Необходимость согласовывать длительный простой на время переноса для обеспечения консистентности данных.

Модуль MIND Migrate #guest в составе MIND Suite позволяет решить эти проблемы и автоматизировать процесс подготовки, запуска и выполнения миграций.

Центральным компонентом MIND Suite является контроллер, который обеспечивает единую точку управления и контроля заданий миграций, хранит конфигурации и журналы работы системы, выполняет мониторинг состояния компонентов системы, а также предоставляет графический интерфейс и интерфейс для запуска API вызовов.

Сценарии миграции

MIND Migrate #guest предназначен для реализации следующих сценариев миграции:

1. Перенос нагрузок на новую платформу

   Миграция виртуальных машин с устаревшей платформы виртуализации или гипервизора на новую платформу с минимальным временем простоя.

2. Замена оборудования

   Перенос существующих инсталляций ОС, ПО и сервисов со старого оборудования на новое без необходимости их переустанавливать и перенастраивать.

3. Миграция в облако

   Перенос рабочих нагрузок в публичные или частные облака, включая облачные платформы гиперскейлеров, а также между облаками разных провайдеров.

4. Оптимизация инфраструктуры

   Распределение нагрузок между разными кластерами и/или ЦОД с целью равномерной утилизации ресурсов и оптимизации производительность, консолидации систем из региональных ЦОД в главный ЦОД, или, наоборот, децентрализации сервисов для размещения рядом с потребителями.

5. Развертывание тестовых стендов

   Простое и быстрое создание идентичных копий производственных сервисов и приложения для задач разработки и тестирования с возможность интеграции с инструментами CI/CD для автоматизации.

Миграция из облачных сервисов:

• Cloud to Cloud (C2C);

• Cloud to Virtual (C2V);

• Cloud to Physical (C2Р).

Миграция с физических серверов или рабочих станций:

• Physical to Cloud (P2C);

• Physical to Physical (P2Р);

• Physical to Virtual (P2V).

Миграция с платформ виртуализации:

• Virtual to Cloud (V2C);

• Virtual to Physical (V2Р);

• Virtual to Virtual (V2V).

Дополнительная информация о поддерживаемых сценариях, конфигурациях и имеющихся ограничениях продукта приведена в документе «Матрица совместимости MIND Suite».

Поддерживаемая инфраструктура

Подробная информация о поддерживаемых операционных системах, гипервизорах, платформах виртуализации и облачных платформах в MIND Migrate #guest приведена в документе «Матрица совместимости MIND Suite».

Общесистемные сервисы и порты

Перечень протоколов и портов, которые используются для взаимодействия между компонентами MIND Suite и внешними сервисами, приведён в разделе Приложение > Протоколы и порты.

Для работы контроллера и ОС могут использоваться общесистемные сервисы:

Направление	Сервис	Порт/протокол	Назначение
Исходящие	DNS	TCP/UDP 53	Разрешение доменных имён
Исходящие	NTP	UDP 123	Синхронизация времени с сетевыми серверами времени
Входящие	SSH	TCP 22	Удалённый доступ с шифрованием соединения

Для повышения безопасности контроллера настройте встроенный межсетевой экран ОС так, чтобы разрешить только трафик по портам и протоколам, необходимым для работы ПО MIND Suite и ОС Linux, а весь остальной трафик заблокировать.

Поддерживаемые платформы для импорта и автоматизированного создания приёмника

Использование возможности автоматического создания целевых машин миграции на основе параметров источника доступно для следующих платформ:

• Basis Dynamix Enterprise;

• VMware vSphere;

• VMware Cloud Director;

• OpenStack;

• SpaceVM;

• oVirt/REDVirt.

Поддерживаемые версии API для интеграции с виртуальными и облачными платформами

MIND Migrate #guest поддерживает интеграцию со следующими платформами для импорта и автоматического создания целевых машин:

Платформа	Версия API
Basis Dynamix Enterprise	3.8.6, 3.8.7, 4.1.0, 4.4.0
OpenStack	2023.1 (Antelope)
VMware vSphere	6.5, 8.0
VMware Cloud Director	37.3
SpaceVM	6.5
oVirt/REDVirt	4.4.9, 4.5.0

Технология создания моментального снимка

Windows

Для обеспечения целостности данных при выполнении миграций используется стандартная служба снимков томов Microsoft Volume Snapshot Service (VSS), встроенная в гостевую операционную систему Windows.

VSS позволяет создавать согласованные снимки томов без остановки работы приложений и служб в виртуальной машине.

Важно

Корректная работа VSS зависит от актуальности установленных компонентов операционной системы. Перед выполнением миграции рекомендуется проверить, что на исходной виртуальной машине установлены все последние обновления Windows. Это позволит избежать ошибок при создании снимков.

Linux

Для создания моментальных снимков в процессе миграции используются драйверы MIND, не требующие установки дополнительных пакетов в систему.

Драйвер представляет собой набор заранее подготовленных под целевую версию операционной системы компонентов: модуль ядра и исполняемые утилиты.

Особенности драйвера:

• Не зависит от установленного в системе программного обеспечения.

• Содержит полный комплект необходимых библиотек и компонентов.

• Работает полностью автономно в пределах своей версии.

Драйвер копируется на источник и приёмник автоматически в ходе выполнения задания миграции и удаляется автоматически сразу после завершения процесса миграции.

Производительность

Фактическая производительность и скорость выполнения миграций с использованием MIND Migrate #guest зависят от множества факторов, включая:

• характеристики аппаратного и программного обеспечения исходной и целевой машин;

• характеристики аппаратного и программного обеспечения целевой платформы виртуализации или облачной среды;

• устройство сети и текущую доступную пропускную способность;

• количество дисковых устройств на источнике и их общий объём;

• уровни загруженности системы на стороне источника и поддерживаемую производительность ввода-вывода;

• количество одновременно выполняемых миграций;

• включение опции шифрования данных;

• включение опции сжатия данных.

При подготовке к масштабным проектам рекомендуется:

• провести одиночную тестовую миграцию с типичной нагрузкой для вашей инфраструктуры;

• зафиксировать полученные метрики скорости и загрузки ресурсов;

• использовать эти данные как отправную точку при расчётах и планировании следующих операций;

• учитывать возможные изменения параметров системы и сети на последующих этапах проекта.

Многопоточность

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

• пропускной способности и загруженности сетевого канала между исходной и целевой средами;

• загруженности процессоров на исходной машине.

Все процессы передачи данных выполняются напрямую от источника к приёмнику.

Количество потоков

По умолчанию платформа автоматически определяет оптимальное количество потоков передачи данных на основе количества доступных процессорных ядер виртуальной машины источника.

При необходимости пользователь может вручную задать иное количество потоков в параметрах задания. Настройка количества потоков позволяет сбалансировать скорость передачи данных и нагрузку на процессор источника.

Важно

Изменить количество потоков во время выполнения задания невозможно.

Чтобы подобрать подходящее значение, рекомендуется провести тестовые запуски с разными значениями параметра и выбрать оптимальное с учётом производительности системы и сети.

Рекомендации по запуску параллельных миграций

• Начинайте с небольшого количества одновременных заданий миграции.

• Постепенно увеличивайте их число, отслеживая загрузку сетевого канала и процессоров;

• Оптимальное количество заданий определяется экспериментально, с учётом:

  • доступной полосы пропускания;

  • производительности исходной машины;

  • требуемого времени завершения миграций.

Сжатие данных

Для операционных систем Windows и Linux поддерживается динамическое потоковое сжатие данных с использованием алгоритма Zstandard (zstd). Сжатие выполняется как при первичной миграции, так и при последующей досинхронизации данных.

Компрессию целесообразно использовать при наличии свободных ресурсов ЦП и/или узком сетевом канале, а также при параллельной миграции нескольких машин или большого количества дисков, когда узким местом становится сеть.

Активация компрессии увеличивает нагрузку на ЦП в разы в рамках одной миграции, при этом, не увеличивая разительно время передачи данных, а возможно, даже снижая его, если сеть является узким местом.

При передаче данных от источника к приёмнику агент MIND применяет встроенный механизм компрессии на основе Zstandard, что позволяет:

• снизить утилизацию сетевых каналов, особенно на линиях с пропускной способностью менее 5Гбит/с;

• достичь среднего коэффициента сжатия порядка 2.4:1.

Нагрузочные характеристики

Использование компрессии сопровождается дополнительной загрузкой процессора источника — до 50% одного ядра.

Фактические показатели сжатия и утилизации процессора могут варьироваться в зависимости от типа передаваемых данных.

Рекомендации по использованию

Включение компрессии целесообразно на каналах с ограниченной пропускной способностью.

Не рекомендуется использовать компрессию для машин, где данные уже хранятся в сжатом или зашифрованном виде (например, медиафайлы), так как дополнительное сжатие в таких случаях малоэффективно.

Использование синхронизации (Flow)

Механизм синхронизации Flow позволяет поддерживать данные на приёмнике в актуальном состоянии за счёт периодической передачи изменений с источника.

Такой подход существенно сокращает время недоступности мигрируемых сервисов в момент финальной синхронизации и переключения на приёмник.

Интервал синхронизации

По умолчанию интервал синхронизации составляет 300 секунд. Интервал задаётся в настройках задания и определяет частоту создания снапшотов и передачи изменений.

Нагрузочные характеристики

Периодическая синхронизация использует механизм создания снапшотов на источнике и приводит к кратковременному увеличению загрузки центрального процессора.

По этой причине не рекомендуется устанавливать слишком малые интервалы синхронизации для сервисов, чувствительных к нагрузке процессора.

Шифрование данных

Поддерживается возможность шифрования соединения между источником и приёмником. При включении данной опции данные передаются по защищённому каналу.

При установке защищённого соединения:

• автоматически создаётся уникальный pre-shared TLS-ключ для данного подключения;

• формируется временная учётная запись TLS для аутентификации.

Эти параметры используются:

• для взаимной аутентификации источника и приёмника (проверка прав доступа);

• для шифрования содержимого передаваемых данных на всём пути между системами.

Pre-shared TLS-ключ генерируется с использованием библиотеки GnuTLS Transport Layer Security Library, обеспечивающей реализацию протоколов TLS и соответствующую криптографическую стойкость.

Использование выделенных журнальных дисков

Журнальные диски предназначены для временного хранения файлов журналов, фиксирующих изменённые данные, которые необходимо передать с источника на приёмник в процессе миграции.

Использование выделенных журнальных дисков позволяет:

• снизить нагрузку на дисковую подсистему источника;

• уменьшить утилизацию СХД, где расположены диски мигрируемой виртуальной машины.

При создании задания миграции можно указать расположение журналов одним из двух способов:

• выбрать выделенное блочное устройство (диск) — например, диск, размещённый на отдельной СХД;

• указать путь к точке монтирования — директория, подключённая по сети (например, через NFS или iSCSI).

Выбор метода зависит от архитектуры вашей инфраструктуры и доступных ресурсов.

Ограничение пропускной способности канала

На этапе конфигурации задания миграции предусмотрена возможность задать ограничение скорости передачи данных с источника на приёмник.

При этом MIND Migrate #guest не накладывает ограничений на использование любых внешних технических средств, реализующих аналогичную функцию — например, через механизмы сетевого или дискового контроля, доступные в инфраструктуре пользователя.

Настройка ограничения скорости

• Для заданий миграции можно установить лимит на максимальную скорость чтения данных с дисков источника в диапазоне от 10 Мбит/с до 100 Гбит/с.

• Ограничение скорости позволяет снизить нагрузку на дисковую подсистему источника и минимизировать влияние миграции на работу приложений, выполняющихся на мигрируемой системе.

• По умолчанию при создании нового задания ограничение не задаётся — используется максимальный лимит скорости 100 Гбит/с.

Важно

Ограничение скорости передачи данных можно изменять динамически во время выполнения задания — новое значение будет применено без остановки миграции.

Безопасность и конфиденциальность

Взаимодействие с антивирусным ПО

В процессе своей работы MIND Suite использует набор низкоуровневых утилит и драйверов и выполняет различные системные вызовы, что может быть расценено антивирусным ПО как потенциально вредоносная активность.

Компания MIND Software выполняет регулярную проверку и отправку обновлённых версий компонентов MIND Suite для добавления в списки исключений (белые списки) средств антивирусной защиты, разрабатываемых АО «Лаборатория Касперского».

В случае использования иных решений обеспечения антивирусной защиты, для исключения их влияния на работу MIND Suite рекомендуется выполнить следующие настройки.

Настройка исключения антивирусного ПО для ВМ на ОС Windows

Добавить в исключение из проверки следующие каталоги и файлы:

• {OS_drive}:\MIND\

• {OS_drive}:\Program Files\mind\

• {OS_drive}:\Windows\winexesvc.exe

Пример настройки исключений для антивирусного ПО Windows Defender приведён в документе «Руководство пользователя MIND Migrate #guest» в разделе Настройка доступа на ОС Windows.

Настройка исключения антивирусного ПО для ВМ на ОС Linux

Добавить в исключение из проверки следующие каталоги и файлы:

• /mind

• /opt/mind

Безопасное подключение

Поддерживается возможность конфигурации контроллера MIND Suite для подключения к его веб-интерфейсу посредством защищённого протокола HTTPS (используя TLS). Шаги настройки описаны в разделе «Устройство MIND Suite».

Между источником и приёмником должно быть обеспечено сетевое соединение L3, так как перенос данных прикладной среды между ними осуществляется напрямую, при этом на контроллер никакие данные с источника или приёмника не передаются и не сохраняются.

MIND Suite не накладывает ограничений на использование каких-либо внешних технических средств для реализации шифрования канала связи между источником и приёмником.

Kerberos

Поддерживается возможность конфигурации контроллера MIND Suite для миграции машин под управлением ОС Windows, находящихся в Active Directory, где используется аутентификация посредством протокола Kerberos.

Сохранность учётных данных

Во время настройки заданий на миграцию в графическом интерфейсе MIND Migrate #guest пользователю будет предложено создать связки ключей доступа к исходной и целевой машинам. Эти данные добавляются в хранилища MIND Vault — базу данных на стороне контроллера. Чувствительные данные (пароли, SSH-ключ, SSH-key passphrase) хранятся в зашифрованном виде.

Данные используются только в случае выбора опции автоматической установки агента. При ручной установке агента предоставление доступа к машинам по SSH/SMB не требуется.

В текущей версии поддерживается добавление SSH-ключей, сгенерированных в формате OpenSSH.

Важно

Ключи доступа заводятся в рамках тенанта. После этого все ключи, заведённые в рамках конкретного тенанта, доступны для любых задач миграции в рамках этого тенанта.

Авторизация и аутентификация

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

Смена стандартных учётных записей микросервисов

Для обеспечения безопасности системы после первоначальной установки и настройки рекомендуется сменить стандартные логины и пароли, используемые для различных микросервисов.

Инструкции по изменению логинов и паролей для баз данных и хранения метрик, менеджера очередей, хранилища журналов и служб приведены в документе «Руководство по обеспечению безопасности MIND Suite».

Настройка хранения событий в системных журналах

Для изменения максимального размера системных журналов на контроллере выполните следующие действия:

1. Установите значение SystemMaxUse=10G (максимальный размер, отводимый под системные журналы — 10 ГБ) в секции [Journal] файла /etc/systemd/journald.conf.

2. Перезапустите сервис с помощью команды:

   sudo systemctl restart systemd-journald.service
   

Настройка длительности хранения журналов события на контроллере

События, не относящиеся к событиям информационной безопасности, по умолчанию хранятся в базе VictoriaLogs на протяжении 7 дней. Для изменения срока хранения добавьте в /opt/mind/etc/config.yml в секцию logs: retentionperiod: в интервале от 1d (1 день) до 100y (100 лет). Например:

-retentionPeriod=2d

После этого перезапустите сервис:

sudo systemctl restart mind_logs.service

Устройство MIND Suite

На уровне сервисов в MIND Suite задействованы следующие компоненты.

NGINX

Web-сервер, который обслуживает внешние подключения по протоколу HTTP(s) со стороны администраторов и агентов, а также запросы к API от других сервисов контроллера. За работу компонента отвечает сервис nginx.service, параметры запуска сервиса описаны в файле /lib/systemd/system/nginx.service.

Настройка NGINX выполняется через конфигурационные файлы /etc/nginx/sites-enabled/controller.conf и /etc/nginx/nginx.conf.

TaskWorker

Отвечает за установку и настройку агентов на машинах, а также за отслеживание их состояния. За работу компонента отвечает сервис mind_taskworker.service, параметры запуска сервиса описаны в /etc/systemd/system/mind_taskworker.service.

Настройка TaskWorker выполняется через конфигурационный файл /opt/mind/etc/config.yml.

JobWorker

Управляет первичной синхронизацией и репликацией данных и отслеживает статус заданий. За работу компонента отвечает сервис JobWorker.service, параметры запуска описаны в /etc/systemd/system/mind_jobworker.service.

Настройка JobWorker выполняется через конфигурационный файл /opt/mind/etc/config.yml.

SiteWorker

Управляет задачами автоматизации создания приёмников и импорта источников с платформы виртуализации. За работу компонента отвечает сервис mind_siteworker.service, параметры запуска сервиса описаны в /etc/systemd/system/mind_siteworker.service.

Настройка SiteWorker выполняется через конфигурационный файл /opt/mind/etc/config.yml.

HealthManager

Выполняет мониторинг работы контроллера, включая сбор и передачу метрик в InfluxDB. За работу компонента отвечает сервис mind_healthmanager.service, параметры сервиса описаны в /etc/systemd/system/mind_healthmanager.service.

Настройка HealthManager выполняется через конфигурационный файл /opt/mind/etc/config.yml.

API

Обеспечивает взаимодействие с контроллером с помощью RESTful API. За работу компонента отвечает сервис mind_api.service, параметры запуска описаны в /etc/systemd/system/mind_api.service.

Настройка API выполняется через конфигурационный файл /opt/mind/etc/config.yml.

Scheduler

Планировщик заданий, который отвечает за управление планами миграций и репликаций. Подключается к брокеру сообщений RabbitMQ для получения и разбора задания с последующей публикацией заданий для сервиса Jobworker. За работу компонента отвечает сервис mind_scheduler.service, параметры запуска описаны в /etc/systemd/system/mind_scheduler.service.

RabbitMQ

Брокер сообщений, используемый для передачи данных между компонентами контроллера. RabbitMQ запускается внутри контейнера mind-rabbitmq. За запуск контейнера отвечает сервис mind_rabbitmq.service, параметры запуска описаны в /etc/systemd/system/mind_rabbitmq.service.

Настройка RabbitMQ выполняется через конфигурационный файл /opt/mind/etc/config.yml.

PostgresPRO

База данных контроллера, хранящая конфигурацию, заданий, тенантов, машин, пользователей и других объектов. Экземпляр PostgresPRO работает в контейнере mind-postgres. За запуск контейнера отвечает сервис mind_postgres.service, параметры запуска описаны в /etc/systemd/system/mind_postgres.service.

Настройка PostgresPRO выполняется через конфигурационный файл /opt/mind/etc/config.yml.

InfluxDB

База данных, хранящая метрики компонента мониторинга HealthManager. Экземпляр InfluxDB работает в контейнере mind-influxdb. За запуск контейнера отвечает сервис mind_influxdb.service, параметры запуска описаны в /etc/systemd/system/mind_influxdb.service.

Настройка InfluxDB выполняется через конфигурационный файл /opt/mind/etc/config.yml.

VictoriaLogs

Компонент для сбора и хранения журналов событий. Экземпляр VictoriaLogs работает в контейнере mind-logs. За запуск контейнера отвечает сервис mind_logs.service, параметры запуска описаны в /etc/systemd/system/mind_logs.service.

Настройка VictoriaLogs выполняется через конфигурационный файл /opt/mind/etc/config.yml.

Vault

Компонент для интеграции с внешними системами хранения секретов на базе SecMan. За работу компонента отвечает сервис mind_vaults.service, параметры запуска описаны в /etc/systemd/system/mind_vaults.service.

MIND System

Сервис отвечает за первоначальную настройку контроллера, считывание и сохранение настроек контроллера через веб-интерфейс. За работу компонента отвечает сервис mind_system.service, параметры запуска описаны в /etc/systemd/system/mind_system.service.

mind-ctrl.target

Отвечает за запуск и перезапуск сервисов MIND mind_taskworker.service, mind_jobworker.service, mind_siteworker.service, mind_healthmanager.service, mind_api.service, mind_scheduler.service, mind_vaults.service, mind_system.service на контроллере в правильном порядке.

Параметры запуска описаны в /etc/systemd/system/mind-ctrl.target.

Backup

Выполняет резервное копирование конфигурации контроллера по расписанию и удаляет устаревшие копии. За работу компонента отвечает сервис mind_backup.service, параметры запуска сервиса описаны в /etc/systemd/system/mind_backup.service. Настройка Backup выполняется через утилиты /opt/mind/bin/mind_backup.

MIND drworker

Компонент управления планами аварийного восстановления. За работу компонента отвечает сервис mind_drworker.service, параметры запуска описаны в /etc/systemd/system/mind_drworker.service.

В портфель решений программного комплекса MIND Suite на данный момент входят модули по переносу рабочей нагрузки между платформами: MIND Migrate #guest для миграции и MIND Guard #guest для репликации данных, а также драйверы и агент MIND, необходимые для выполнения заданий на миграцию и репликацию.

Обзор контроллера

Контроллер — виртуальная машина с основной панелью доступа к инструментам комплекса MIND Suite. Данная машина рекомендуется к размещению в том же сетевом контуре, где будет находиться приёмник. Единый интерфейс с многопользовательским разграничением прав доступа позволяет контролировать выполнение параллельных задач по миграции в условиях корпоративной среды, а его доступность посредством RESTful API обеспечивает эффективную интеграцию с уже имеющимися порталами самообслуживания, системами автоматизации, DevOps-инструментами или средствами мониторинга.

Контроллер разворачивается на физическом сервере или ВМ с помощью предоставляемых скриптов из заранее подготовленного пакета и не требует доступа к Интернету. Контроллер управляет ходом выполнения заданий по миграции, но не участвует в процессе копирования данных, который происходит напрямую от источника к приёмнику.

Для проведения миграции на контроллере требуется наличие драйвера, представляющего собой набор заранее подготовленных под конкретную версию ОС модуля ядра и исполняемых утилит.

Если обнаружится, что на контроллере отсутствует драйвер для используемой на пользовательских машинах версии ОС, необходимо обратиться в Службу Технической поддержки MIND, где его индивидуально подготовят в рамках релизного цикла продукта.

Драйверы для MIND Suite можно скачать в Личном Кабинете Пользователя в разделе Загрузки.

Контроллер предоставляет возможность удобного добавления таких драйверов через GUI, а также проведения обновления основных программных компонентов до последних версий продукта.

Настройка доступа к контроллеру по протоколам HTTP и HTTPS

Интерфейс управления платформой MIND Suite работает за обратным прокси NGINX, который транслирует внешние запросы на внутренние сервисы контроллера. Для настройки шифрованного канала передачи данных необходимо иметь сертификат и приватный ключ для вашего домена. Также требуется сертификат Удостоверяющего Центра, который выдал сертификат.

Все эти файлы следует разместить на файловой системе контроллера MIND Suite.

Важно

При установке контроллера выписывается самоподписанный сертификат, который используется системой. При необходимости данный сертификат можно заменить на собственный.

Доступ к контроллеру по HTTP и HTTPS

По умолчанию контроллер принимает входящие подключения по протоколам HTTP (порт TCP 80) и HTTPS (порт TCP 443). Для изменения порта, на котором будет доступен веб-интерфейс контроллера, отредактируйте один из блоков в файле /etc/nginx/sites-enabled/controller.conf.

Для изменения порта подключения по протоколу HTTP измените порт 80 на требуемый в блоке:

server {
   listen 80 default_server;
}

Для изменения порта подключения по протоколу HTTPS измените порт 443 на требуемый в блоке:

server {
   listen 443 ssl;
}

Перезапустите сервис nginx:

sudo systemctl restart nginx

Работа контроллера с сертификатами

При установке ПО MIND Suite на контроллере автоматически создаются самоподписанные сертификаты корневого Удостоверяющего Центра (УЦ) и сервера для организации зашифрованного канала передачи данных при подключении к контроллеру по HTTPS. Информация о замене сертификата приведена в разделе Работа контроллера с сертификатами. Контроллер поддерживает TLS версии v1.2 и v1.3.

На контроллере файлы сертификатов размещаются в каталоге /opt/mind/etc/tls:

• ca.mindsw.io.pem — X.509 сертификат корневого УЦ в формате Base64;

• ca.mindsw.io.key — закрытый ключ сертификата корневого УЦ;

• tls.mindsw.io.pem — X.509 цифровой сертификат сервера в формате Base64;

• tls.mindsw.io.key — закрытый ключ сертификата сервера.

Для обеспечения безопасного подключения к контроллеру замените самоподписанные сертификаты сервера и корневого УЦ на сертификаты, выданные доверенным корпоративным или публичным УЦ.

Важно

При установке агента MIND сертификат корневого УЦ ca.mindsw.io.pem, используемый контроллером, сохраняется на машине в каталог установки /opt/mind/etc/tls — для Linux и %ProgramFiles%\mind\ — для Windows.

При замене сертификата сервера или УЦ на контроллере переустановите агент для обновления файла ca.mindsw.io.pem или скопируйте обновлённый сертификат корневого УЦ в соответствующий каталог на машине и перезапустите агент MIND.

При необходимости использования собственных TLS-сертификатов подготовьте каталог с файлами:

• ca.mindsw.key;

• ca.mindsw.pem;

• tls.mindsw.key;

• tls.mindsw.pem;

• custom.mindsw.pem.

Эти файлы будут скопированы в каталог /opt/mind/etc/tls.

Подробная информация по замене сертификатов приведена в разделе Сертификат.

Драйверы MIND

Драйверы используются для снятия и передачи моментальных снимков в ходе выполнения миграционного задания. Они не требуют пакетной установки в системе и представляют собой набор заранее подготовленных под определённую версию ОС модуля ядра и исполняемых утилит, которые не имеют каких-либо дополнительных зависимостей от системного ПО и содержат весь перечень библиотек и компонентов, необходимых для своей работы.

В MIND Suite существует механизм валидации драйверов для более строгой проверки целостности и соответствия метаданных.

Драйвер состоит из следующих компонентов:

• модуль ядра для работы с блочными устройствами;

• модуль, обеспечивающий снятие снимков;

• модуль, отслеживающий изменение блоков (механизм CBT);

• модуль, отвечающий за передачу данных блочных устройств по сети (активируется на источнике);

• модуль, отвечающий за прием данных блочных устройств по сети (активируется на приёмнике).

Важно

Для задач миграции доступны все драйверы, зарегистрированные на данном контроллере MIND Suite.

Механизм валидации утилит хоста

Механизм валидации утилит хоста обеспечивает критически важный уровень доверия между агентом и контроллером, исключая возможность скрытого внедрения вредоносного кода. Валидация с использованием цифровой подписи — это эффективная, расширяемая и прозрачная защита от подмены утилит в инфраструктуре.

Для обеспечения доверенной модели исполнения утилит хоста реализован механизм криптографической валидации на стороне агента. Основные принципы:

1. Все утилиты хоста подписываются при сборке с использованием закрытого ключа.

2. Агент перед запуском каждой утилиты проверяет её подпись, используя встроенный открытый ключ.

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

Агент MIND

Компонент взаимодействия контроллера с машинами, использующий для связи протокол WebSocket; устанавливается на источник и приёмник автоматически (с предоставлением доступов) или вручную (предоставление доступов не требуется).

В процессе работы установленный агент MIND и утилиты хоста взаимодействуют с различными компонентами ОС, включая файловую систему, файлы конфигурации и сервисы.

Перечень взаимодействий приведён в документе «Руководство по обеспечению безопасности MIND Suite».

MIND Migrate #guest

Модуль автоматизированных миграций, в котором на основе учёта ключевых аспектов исходной и целевой сред создаётся, подтверждается и передаётся к исполнению план переноса клиентской системы.

MIND Flow

Возможности модуля MIND Migrate #guest обеспечивают непрерывную репликацию и синхронизацию сред источника и приёмника, не требуют остановки работы приложений и минимизируют время простоя между последней репликацией и полным восстановлением работоспособности машины.

При синхронизации применяется технология передачи данных на уровне блоков устройств хранения, при этом при использовании MIND Flow после первичной синхронизации данных продолжится процесс репликации источника с использованием механизма отслеживания изменённых блоков (Change Block Tracking), периодически досылая на приёмник накопившиеся инкрементальные изменения.

Автоматизация

Интегрированная в MIND Migrate #guest подсистема автоматизации управления виртуальными машинами и сетями в различных облачных платформах.

Наиболее популярным сценарием применения автоматизации является создание приёмника для указанного источника и объединение их в миграционное задание. При этом характеристики создаваемой машины подбираются системой самостоятельно на основе информации, которая была получена в результате автоматизированного анализа источника, с учётом технологических потребностей процесса миграции.

Таким образом, механизм автоматического создания приёмников позволяет избежать ручной подготовки целевой инфраструктуры и сразу получать в MIND Migrate #guest приёмники, готовые к использованию в миграционных сценариях.

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

Реализован пакетный режим автоматического создания приёмников — для этого пользовательский интерфейс предоставляет механизм шаблонизации действий, связанных с настройкой ресурсов.

С помощью подсистемы автоматизации можно выполнять следующие действия:

• Создание новой виртуальной машины с заданными характеристиками. В результате в указанной облачной инфраструктуре появляется новая ВМ, а в MIND Migrate #guest сохраняется информация о ней.

• Актуализация сохраненной в MIND Suite информации о конфигурации виртуальной машины (созданной автоматически или импортированной).

• Импортирование в MIND Migrate #guest информации об уже существующих в указанной инфраструктуре сетях.

• Актуализация сохраненной в MIND Migrate #guest информации о конфигурации ранее импортированной виртуальной сети.

Процесс создания миграционного задания при использовании автоматического приёмника, в случае если запущен и доступен только источник, состоит из следующих шагов, выполняемых платформой автоматически:

1. Создание приёмника на основе заранее подготовленного из загруженного на целевую платформу шаблона (см. раздел Подготовка шаблонов для автоматического создания виртуальных машин в документе «Руководство пользователя MIND Migrate #guest»).

2. Настройка ресурсов целевой ВМ в соответствии с собранными с источника параметрами.

3. Запуск данной ВМ.

4. Назначение IP-адреса согласно выбранной политике (статический/динамический/копирование с источника).

5. Создание миграционного задания для сформированной пары источника и приёмника.

Терминология MIND Migrate #guest

Платформа (Platform)

Набор данных, необходимых для подключения контроллера к инфраструктуре. Автоматизация взаимодействует с API целевой облачной платформы, для чего требуется информация о типе платформы, версии API, URL контроллера и авторизационных данных.

Размещение (Placement)

Набор параметров, определяющих контекст размещения ресурсов, создаваемых в целевой облачной платформе. Помимо основных характеристик (например, количества процессоров и объёма ОЗУ), указываются параметры, задающие расположение, группировку или принадлежность виртуальных ресурсов.

Драйвер платформы (Site driver)

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

Сетевая схема MIND Migrate #guest

Сетевая схема MIND Migrate #guest с автоматическим созданием приёмника

Работа с прокси-серверами

Прокси-сервер используется для маршрутизации как пользовательского трафика между источниками и приёмниками в процессе миграции, так и управляющего трафика между машинами и контроллером. Прокси функционирует как транспарентный узел: он не модифицирует и не кеширует данные, скрывает реальные IP-адреса, не проверяет активность соединений и просто перенаправляет потоки с помощью NAT-правил iptables. Конфигурация правил осуществляется контроллером.

В случае сетевых ошибок исходная машина может автоматически переключиться на другой прокси-сервер из группы. Работа обеспечивается процессом mind_proxy, установленным как агент, с собственным хранилищем для ключей доступа.

MIND Suite поддерживает следующие сценарии работы с прокси-серверами:

• Использование двух прокси-серверов: на источнике и приёмнике. В данном режиме исключено какое-либо прямое сетевое взаимодействие между источниками, приёмниками и контроллером. При выполнении миграции источник отправляет данные на прокси-источник, который затем транслирует их на прокси-приёмник, а прокси-приёмник передаёт данные на приёмник.

• Использование одного прокси-сервера: на источнике. При выполнении миграции источник отправляет данные на прокси-источник, который затем передаёт данные на приёмник. Прокси используется не только для передачи данных от источника к приёмнику, но и для связи источника с оркестратором. Приёмник также использует этот прокси для отправки служебного трафика (watermill) на источник, но сам связывается с оркестратором напрямую.

• Использование одного прокси-сервера: на приёмнике. При выполнении миграции источник отправляет данные на прокси-приёмник, который затем передаёт данные на приёмник. Источник напрямую взаимодействует с оркестратором, но для передачи данных и watermill-трафика использует прокси приёмника. Приёмник слушает входящий трафик на открытых портах, принимая его через прокси. Все соединения с оркестратором производятся также через прокси приёмника.

• Работа без прокси-серверов. В данном режиме данные передаются напрямую между источником, приёмником и контроллером.

При использовании прокси с обеих сторон (у источника и у приёмника) автоматически формируются так называемые прокси-пары — соответствия между прокси из группы источника и прокси из группы приёмника. Это обеспечивает однозначность маршрутизации трафика.

Важно

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

Работа с прокси-серверами выполняется в разделе Прокси в веб-интерфейсе контроллера. На вкладке Список отображаются все прокси-серверы, зарегистрированные на данном контроллере.

Важно

В данном разделе отображаются только те прокси-серверы, которые зарегистрированы на текущем контроллере MIND Suite. Один прокси-сервер может быть привязан только к одному контроллеру; использование одного и того же прокси несколькими контроллерами не поддерживается.

На вкладке Прокси группы отображаются группы, включающие один или несколько прокси-серверов.

Чтобы создать новый прокси-сервер, нажмите на кнопку + Добавить, и справа появится всплывающее окно с параметрами, которые необходимо заполнить.

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

• Имя — название записи для отображения в интерфейсе MIND;

• IP/FQDN — статический адрес машины или её полное доменное имя.

• Расширенные настройки:

  • Порт SSH — открытый порт для удалённого подключения к машине. По умолчанию — 22 для SSH.

  • Ключи доступа — (необязательно) данные для доступа к добавляемой машине требуются только в случае автоматической установки агента.

Нажмите на кнопку Сохранить. После этого созданный прокси-сервер отобразится в списке в разделе Прокси. В столбце Действия напротив каждой строки можно нажать на соответствующие иконки для редактирования информации, удаления прокси-сервера и выполнения действий с агентом. Подробная информация по работе с агентами приведена в документе «Руководство пользователя MIND Migrate #guest».

После добавления одного или нескольких прокси-серверов требуется создать прокси группу, которую затем можно привязать к источнику и (или) приёмнику во время создания машины или задания на миграцию.

Примечание

В прокси группе должен присутствовать как минимум один прокси-сервер. Рекомендуется добавить несколько прокси-серверов для обеспечения отказоустойчивости и автоматического переключения на резервные прокси-серверы в случае сбоя одного из прокси-серверов в группе.

Для создания новой группы требуется перейти на вкладку Прокси группы и нажать на кнопку + Добавить. В открывшейся форме необходимо выбрать прокси-серверы, которые необходимо включить в группу, отметив их флажком.

Затем необходимо ввести название группы в поле Имя и нажать Сохранить. После этого созданная прокси группа отобразится в списке на вкладке Прокси группы. В столбце Действия напротив каждой строки можно нажать на соответствующие иконки для редактирования информации или удаления прокси группы.

Важно

Все прокси-серверы в группе используют одинаковый набор NAT-правил iptables, синхронизируемых с контроллером. Прокси-агент периодически пингует оркестратор, проверяя актуальность правил. При несоответствии правила загружаются заново через API, после чего старые удаляются, а новые применяются автоматически.

После настройки прокси при создании источника и приёмника в разделе Машины в расширенных настройках будет отображаться возможность привязки машины к прокси группе.

Ресурсы для прокси-серверов

Принцип работы прокси-серверов

Прокси-серверы обеспечивают сетевую связность между компонентами MIND Suite, такими как машины-источники, машины-приёмники и контроллер посредством трансляции сетевых адресов.

Для этого прокси-сервер использует стандартные средства ядра Linux: подсистему iptables и цепочки PREROUTING, DNAT и FORWARD. Такой подход обеспечивает высокую пропускную способность при минимальной нагрузке на процессор и оперативную память, так как не требуется глубокая инспекция или модификация трафика на уровне приложений.

Базовые рекомендации по ресурсам (CPU и RAM)

Поскольку iptables сам по себе не требует значительных вычислительных ресурсов, базовая нагрузка на CPU и RAM остаётся низкой. Однако по мере увеличения числа активных соединений и объёма проходящего трафика возрастает нагрузка на сетевой стек ядра.

Рекомендации по ресурсам приведены на основе обобщённой практики и документации (включая источники от Linux Foundation, Red Hat и Netgate).

Пропускная способность	Рекомендованные ресурсы	Примечания
До 100 Мбит/с	1 vCPU, 512 МБ RAM	Подходит для начального уровня; минимальные задержки
До 500 Мбит/с	1 vCPU, 1 ГБ RAM	Умеренная нагрузка; стабильная работа NAT/iptables
До 1 Гбит/с	2 vCPU, 2 ГБ RAM
До 10 Гбит/с	4 vCPU, 4 ГБ RAM
> 10 Гбит/с (high perf)	8 vCPU, 8 ГБ RAM	Возможно, iptables начнёт вносить увеличенные задержки

Чтобы точно рассчитать требуемые ресурсы, необходимо выполнить следующие действия:

1. Оцените трафик миграции:

   • Получите список ВМ, участвующих в миграции через данный прокси.

   • Проанализируйте средний и пиковый трафик от каждой ВМ.

   • Просуммируйте предполагаемую общую пропускную способность, например:

     ВМ1: 50 Мбит/с
     ВМ2: 120 Мбит/с
     ВМ3: 300 Мбит/с
     -------------------------
     Общая пиковая: 470 Мбит/с
     

2. Заложите резерв. Рекомендуется добавлять минимум 25–50 % на рост нагрузки и всплески трафика. Резерв с запасом: 470 Мбит/с * 1.25 = 590 Мбит/с.

3. Назначьте ресурсы. В соответствии с таблицей выше выберите конфигурацию для 600 Мбит/с: 2 vCPU и 2 ГБ RAM.

Дополнительные возможности

Снятие первичной диагностической информации

После того как задание на миграцию сконфигурировано и запущено, записи о состоянии его текущих процессов заносятся в систему и сохраняются в виде логов. Эти логи содержат подробную информацию о выполнении задания, включая его этапы, действия, ошибки и предупреждения.

На странице задания предусмотрена кнопка Скачать журнал выполнения миграции, которая позволяет получить доступ к этим записям в любой момент, независимо от того, завершилась ли миграция с ошибкой или без. Нажав эту кнопку, пользователь может скачать логи задания в формате JSON на своё устройство для более детального анализа или последующего обращения в Службу Технической поддержки MIND.

Объединение в группы

Пользователь может осуществлять групповые действия с обнаруженными на контроллере машинами. После формирования миграционных заданий из пар машин появляется возможность объединять несколько заданий в Группы с поэтапным выполнением.

Для одной группы применяются единые настройки режима синхронизации, а также доступны групповые действия для добавленных машин — валидация, удаление.

Выполнение скриптов

На этапе конфигурации миграционного задания пользователь может добавить дополнительные индивидуальные наборы команд или инструкции для выполнения на источнике или приёмнике.

Скрипты загружаются пользователем, принадлежат ему, хранятся в зашифрованном виде и могут быть организованы в Сценарий, определяющий порядок их исполнения.

Скрипты загружаются Пользователем в тенант и доступны всем пользователям с возможностью работы в рамках тенанта. Сами скрипты хранятся на контроллере в зашифрованном виде и могут быть организованы в Сценарий, определяющий порядок их исполнения. Для Linux-систем поддерживаются языки для написания скриптов Shell и Bash.

Важно

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

Сценарий — это упорядоченная последовательность исполнения скриптов.

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

Таким образом, для удобства использования скриптов предусмотрена возможность запуска скриптов на источнике или приёмнике на разных этапах миграции. Сами этапы миграции разбиты на несколько подэтапов — Начало, Снимки, Завершение.

Начало — подразумевает возможность запускать скрипты в самом начале процесса миграции. Данный подэтап включает возможность запустить скрипты в следующей очерёдности:

• Перед первым снимком;

• После первого снимка;

• После первичной синхронизации.

Снимки — подразумевает возможность запускать скрипты в процессе работы механизма снапшотирования. Данный подэтап включает возможность запустить скрипты в следующей очерёдности:

• Перед каждым снимком;

• После каждого снимка;

• Перед последним снимком;

• После последнего снимка.

Завершение — после финальной синхронизации.

Важно

Приведённые выше этапы применимы для источника.

Для приёмника предусмотрена возможность запуска скриптов только на этапе завершения процесса миграции. Для ОС Linux скрипт выполняется перед перезагрузкой из режима работы chroot. При этом сами скрипты как на источнике, так и на приёмнике на всех этапах выполняются агентом mind_agent, который работает от пользователя с ролью Администратора.

При исполнении скриптов их содержимое не играет роли. Пользователь может установить политику для каждого скрипта, определяющую реакцию на исключительные ситуации.

У каждого скрипта может быть сценарий «фолбэк», т.е. альтернативное действие, которое будет выполнено при возникновении ошибки.

Пользователь может выбрать одну из трёх реакций:

1. Продолжить миграцию.

2. Остановить миграцию с ошибкой.

3. Запустить запасной скрипт.

Контроллер предоставляет возможность отключения механизма скриптов и сценариев. Данная возможность может использоваться для снижения риска запуска неавторизованных команд на источниках или приёмниках в процессе выполнения заданий миграции или защиты машин.

Чтобы отключить скрипты и сценарии, выполните следующие действия:

1. Подключитесь к контроллеру и добавьте в файл /opt/mind/etc/config.yml строку disablescripts: true в раздел runmode.

   runmode:
     debug: false ## Set debug mode
     webdebug: false ## Set debug mode for web
     research: false ## If false then check operating system support
     disablescripts: true
   

   Важно

   Параметр debug: true в разделе runmode включает расширенный отладочный режим контроллера. В этом режиме система генерирует большое количество диагностических сообщений и записей в журналах.

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

2. Перезапустите сервис mind_api:

   sudo systemctl restart mind_api.service
   

После отключения скриптов и сценариев вкладка Скрипты исчезнет из графического интерфейса контроллера. Если попытаетесь выполнить запросы RESTful API, связанные с просмотром, созданием или редактированием скриптов и сценариев, контроллер выдаст ошибку вида:

{
  "error": "Scripts api is disabled",
  ...
}

Проверка целостности скриптов

При добавлении пользовательских скриптов на контроллер MIND Suite они сохраняются в зашифрованном виде в каталоге /opt/mind/share/userscripts.

Перед запуском задания зашифрованные скрипты передаются на источник и приёмник, где расшифровываются и сохраняются в каталоге /mind/scripts.

В случае подмены скриптов на стороне контроллера или в процессе передачи они не смогут быть расшифрованы агентом и журнале Аудита появится соответствующая запись об ошибке обработки скрипта.

Управление платформой MIND Migrate #guest

Управление платформой MIND Migrate #guest возможно двумя основными способами: через графический веб-интерфейс или программный интерфейс (RESTful API). Оба способа обеспечивают удобное и эффективное управление системой согласно потребностям пользователя.

Графический интерфейс (GUI) предоставляет интуитивное и простое в использовании окружение для управления MIND Migrate #guest. Пользователь получает доступ ко всем функциям и инструментам, позволяющим настраивать и отслеживать различные этапы миграции. Более детальное описание возможностей GUI можно найти в документе «Руководство пользователя MIND Migrate #guest».

Программный интерфейс приложения (API) предоставляет программистам и разработчикам возможность взаимодействовать с MIND Migrate #guest напрямую, используя набор API-методов. Это позволяет автоматизировать процессы, интегрировать систему с другими приложениями и настраивать её возможности в соответствии с индивидуальными потребностями и сценариями использования. С описанием API-запросов и примерами ответов можно ознакомиться в интерфейсе Swagger — соответствующий раздел доступен в меню контроллера.

Ролевая модель

Управление ролевой моделью в MIND Migrate #guest осуществляется на уровне тенанта — объекта, включающего в себя набор ключей доступа, проектов и машин, доступ к которым предоставляется для пользователей и групп на основании ролевой модели.

MIND Suite использует ролевую модель для управления учётными записями и правами пользователей, а также для определения доступных возможностей миграции и репликации: три роли определяют возможности Администратора, ещё три — права и возможности Пользователя.

System Admin — роль даёт права на доступ ко всем API и возможностям платформы.

Security Admin — роль позволяет просматривать объекты платформы.

Platform Operator— роль даёт права на мониторинг и управление конфигурацией платформы без возможности запуска заданий на миграцию, а также позволяет создавать пользователей и их окружения.

Super User — роль позволяет предоставлять доступ к тенантам, полноценно работать с платформой и миграциями, но без возможности создания новых пользователей.

Power User — роль даёт возможность работать с основными объектами платформы кроме действий с тенантами.

User Operator— роль даёт доступ к осуществлению миграций, но с ограниченным набором действий.

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

Раздел «Администрирование»

Данный раздел содержит перечень вкладок с инструментами для управления объектами MIND Migrate #guest:

• Общие настройки;

• Мониторинг;

• Управление доступами;

• Интеграции.

Общие настройки

В разделе Общие настройки используйте подразделы Публичный адрес, Часовой пояс и Сертификат.

Важно

При авторизации по HTTPS сессионные cookie получают флаги secure и samesite=strict.

При доступе по HTTP cookie получают флаг samesite=strict.

Публичный адрес

Для изменения публичного адреса скорректируйте адрес в поле Публичный адрес и нажмите кнопку Сохранить.

Важно

После изменения публичного адреса переустановите агентов.

Часовой пояс

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

Сертификат

В подразделе Сертификат проверьте следующие сведения о текущем сертификате контроллера:

• Действителен по;

• Самоподписанный;

• Субъект;

• Издатель;

• Отпечаток.

Используйте поле Отпечаток для проверки контрольного значения сертификата. Значение указано в виде шестнадцатеричных пар, разделённых двоеточиями. При необходимости скопируйте отпечаток кнопкой копирования рядом с полем.

1. Нажмите кнопку Заменить.

2. Оставьте установленным флажок Самоподписанный и нажмите кнопку Генерировать.

3. В окне с предупреждением о недоступности установленных агентов после генерации сертификата нажмите кнопку ОК.

После генерации сертификата убедитесь, что в области уведомлений отобразилось сообщение об успешном изменении сертификата.

Для замены сертификатов на сертификаты доверенного УЦ:

1. Нажмите кнопку Заменить.

2. Снимите флажок с поля Самоподписанный.

3. Заполните поля:

   • Сертификат контроллера — сертификат сервера в формате Base64 (.pem). Пример:

     -----BEGIN CERTIFICATE-----
     ...
     -----END CERTIFICATE-----
     

   • Приватный ключ сертификата контроллера — закрытый RSA-ключ (.key). Пример:

     -----BEGIN RSA PRIVATE KEY-----
     ...
     -----END RSA PRIVATE KEY-----
     

   • Промежуточный сертификат УЦ — сертификат корневого или промежуточного УЦ, выпустившего сертификат контроллера, в формате Base64 (.pem). Пример:

     -----BEGIN CERTIFICATE-----
     ...
     -----END CERTIFICATE-----
     

   Важно

   Если вы заменили сертификат сервера или УЦ на контроллере, обновите сертификат корневого УЦ на машинах с агентом одним из способов:

   • переустановите агент, чтобы обновить файл ca.mindsw.io.pem;

   • скопируйте обновлённый сертификат корневого УЦ в каталог установки агента и перезапустите агент.

4. Нажмите кнопку Сохранить.

5. В окне с предупреждением о недоступности установленных агентов нажмите кнопку ОК.

Настройка анимации в интерфейсе

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

Мониторинг

Состояние сервисов и систем

На вкладке Состояние сервисов и систем отображена информация о состоянии служб и ресурсов контроллера MIND. В этом разделе осуществляется мониторинг, проверка и оценка состояния запущенных сервисов.

При необходимости возобновления работы сервисов нажмите Перезапустить напротив соответствующей строки, а в открывшемся окне предупреждения нажмите ОК.

Логи

На вкладке Логи просматривайте важную информацию о событиях контроллера и агента MIND.

Чтобы отфильтровать журналы, введите запрос в строку поиска или выберите один из последних запросов в выпадающем списке. При необходимости укажите количество отображаемых записей и временной интервал, за который они были сформированы.

Важно

В системе можно отобразить не более 1 000 событий за один запрос.

Чтобы сохранить отображённые журналы в файл, нажмите Скачать внизу страницы.

Чтобы загрузить полный архив журналов с контроллера, нажмите Скачать полный архив журналов. Используйте этот архив для массового устранения неполадок, связанных с заданиями на миграцию и состоянием контроллера. Архив включает все журналы с Syslog-сервера и JSON-файлы заданий на миграцию.

Примечание

Для активных заданий на миграцию в разделе Проекты нажмите Скачать журнал выполнения миграции.

Откроется форма запроса, в которой можно выбрать журналы для скачивания:

• Загрузить dmesg -T — для Linux;

• Загрузить builder.log — для Windows;

• Загрузить журналы агентов.

Для сбора диагностической информации на контроллере используйте скрипт collect_diagnostic_information.sh, который расположен по пути /opt/mind/bin/. Чтобы запустить скрипт, выполните команду:

bash collect_diagnostic_information.sh

После запуска скрипт формирует архив /tmp/collect_<date>.tar.gz, который включает:

• вывод системных команд df -h, lsblk -f и dmesg -T; для dmesg -T сохраняются последние 2000 строк;

• журналы NGINX из каталога /var/log/nginx; для каждого файла сохраняется до 1000 строк;

• данные Podman по контейнерам:

  • конфигурацию контейнеров;

  • журналы контейнеров;

• журналы systemd по сервисам контроллера;

• журналы systemd для контейнерных сервисов, включая сервисы Postgres, RabbitMQ, InfluxDB и сервиса журналов;

• частичную диагностическую выгрузку данных БД контроллера.

Примечание

Архив включает журналы systemd для контейнерных сервисов. Это позволяет получить информацию о запусках, падениях и перезапусках контейнеров, даже если журналы самого контейнера недоступны.

Примечание

Если требуется освободить место на диске контроллера, очистите временные директории с инсталляторами агентов через API-метод POST /agent/clear-temporary. Метод удаляет все директории внутри /opt/mind/tmp/agent и доступен только ролям sysAdmin и platformOperator. Подробная информация о вызове приведена в документе «Руководство по работе с API».

Аудит

На вкладке Аудит доступен журнал аудита системных событий.

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

При двойном нажатии на любую запись аудита справа отобразится форма с детальной информацией по конкретному логу.

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

• Поле ID события содержит идентификатор события на контроллере.

• Поле Дата содержит информацию о дате и времени регистрации события на контроллере.

• В поле Субъект операции указано имя учётной записи, которая сгенерировала событие.

• В поле Критичность указано описание уровня критичности события. Подробная шкала оценки критичности событий приведена в таблице.

Код	Расшифровка	Комментарий	Примеры событий
0	Informational / Информационный	Информационное сообщение о событии или действии, на которое, как правило, не требуется реагировать каким-либо образом.	login success, object create/update/delete success, successful system start (for successful security logging subsystem initialization see «minor security event»)
1	Warning / Предупреждение	Событие, в процессе которого возникла некритичная нештатная ситуация, которая, тем не менее, не помешала завершению действия.	partial object information retrieval/update
2	Error / Ошибка	Событие, в процессе которого возникла ситуация, которая не позволила завершить начатое действие.	error when parsing API parameters, internal error when creating/updating/deleting object (for access denial see «minor security event»)
3	Minor security event / Незначительное событие безопасности	Событие, имеющее отношение к сфере информационной безопасности, но не оказывающее критического влияния на MIND Suite или не требующее немедленного реагирования.	object access denial, login failure, password change, password reset request, password reset, user create/delete, successful security logging facility start
4	System state change / Изменение состояния системы	Запуск/инициализация системных компонентов MIND Suite, а также сбой внутренних подсистем MIND Suite или внешних информационных сервисов, от которых зависит его функционирование.	system facility initialization, process/microservice failure detected, process restart
5	Major security event / Крупное событие безопасности	Событие, имеющее отношение к сфере информационной безопасности, потенциально способное оказать критическое влияние на MIND Suite или требующее немедленного реагирования.	user blocked for excessive failed login attempts, login failure while block is active, login attempt by banned user, security policy create/update/enable/disable/delete, user role update, user ban/permit, inability to initialize security logging facility

• Поле Название содержит имя события.

• В поле Адрес объекта операции отображается имя или IP-адрес контроллера, указанный в PublicURL.

• В поле Название хоста указано имя компьютера/хоста, на котором установлен контроллер.

• Поле Объект операции указывает, для какого объекта было сгенерировано событие.

• В поле Роль пользователя указана роль, назначенная учётной записи пользователя, выполнившего операцию. Подробная информация о ролевой модели приведена в документе «Руководство пользователя MIND Migrate #guest».

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

• Поле IP-адрес содержит IP-адрес виртуальной машины (рабочей станции), с которой пользователь отправил запрос.

• В поле Класс для удобства учёта и анализа все регистрируемые события группируются в несколько классов, каждый из которых объединяет события, сходные по объекту или содержанию действия. Описания классов приведены в таблице.

Класс	Комментарий	Примеры событий
Доступ пользователя	События, возникающие в процессе получения пользователем доступа к MIND Suite или изменения параметров доступа	user login; user logout; user password set
Управление пользователями	События, возникающие в процессе настройки доступа к MIND Suite или прав пользователей	user create; user ban; user role update
Управление объектами	События, связанные с управлением жизненным циклом объектов в MIND Suite (за исключением пользователей и политик) и доступом к ним	project get; unit create; set delete
Управление действиями	События, связанные с запуском, остановкой или мониторингом статуса выполнения процессов, влияющих на объекты	job start; job stop; job get
Управление политиками	События, связанные с управлением жизненным циклом политик, регулирующих различные аспекты работы пользователей с ресурсами MIND Suite	policy create; policy enable; policy update
Системные события	Системные события, связанные с изменением состояния внутренних процессов и сервисов MIND Suite	process failed; process start
Специальный	Сервисные события, служащие для отладки MIND Suite и передачи служебной информации, непосредственно не связанной с задачами аудита важных событий	test

• Значения поля Действие приведены в таблице.

Действие	Описание
logout	Выход из учётной записи
logout	Отключение пользователя\сессии по таймауту
login	Авторизация в системе
logblock	Запрет на авторизацию пользователя
pwdchng	Изменение пароля пользователя
pwdresetreq	Отмена запроса на изменение пароля пользователя
pwdreset	Сброс пароля
tokeninvalid	Неверный токен
create	Создание объекта
delete	Удаление объекта
get	Получение информации об объекте
update	Обновление информации об объекте
ban	Блокировка пользователя
permit	Разблокировка пользователя
pwdmust	Установка флага обязательной смены пароля
roleupd	Изменение роли пользователя
emailupd	Обновление электронного адреса пользователя
attrupd	Обновление атрибутов объекта
aclupdate	Изменение списков доступа к объекту
start	Запуск действия
stop	Остановка действия
enable	Разрешение действия
disable	Запрет действия
procstart	Попытка запуска системного процесса/инициализация подсистемы
procfail	Неуспешное завершение процесса
syslogstart	Запуск логирования системных событий
testinfo	Логирование тестового события
restart	Перезапуск сервиса

• Поле Тип объекта может быть заполнено одним из следующих значений: group (группа), job (задание), project (проект), unit (машина), user (пользователь) и т. д.

• В поле ID объекта при определении ID задания (job) используется GUID. Для остальных объектов используется числовое значение. ID — уникальный идентификатор объекта, для которого было выполнено действие.

• В поле Подсистема указывается принадлежность объекта или действия к одному из модулей: migrate, guard или controller.

• Поле Описание события содержит расширенную информацию о выполненном действии.

  • Для событий с типом объекта job в поле указывается внутренний идентификатор задания (GUID).

  • При перезапуске сервиса через веб-интерфейс в журнал записываются логин и идентификатор пользователя, выполнившего действие.

  • Для остальных типов объектов указывается текстовое описание события или поле остаётся пустым, если описание не применимо.

• Поле Результат может быть заполнено одним из значений, приведённых в таблице.

Значение	Пример
Успешно	Успешная авторизация пользователя
Сбой	Неуспешная авторизация пользователя из-за неверного пароля
Исключение	Ошибка при обращении к БД в процессе авторизации пользователя

Статистика миграций

На вкладке Статистика миграций отображена информация о состоянии прохождения миграций в каждом продукте на контроллере MIND.

Ротация логов

На вкладке Ротация логов выполняется настройка срока хранения и ротации журналов контроллера, а также ротации журнала dtm-server.log в KTMU.

Настройки на вкладке позволяют управлять:

• журналами событий, хранящимися в /var/log/mind;

• журналами аудита;

• событиями, хранящимися в базе VictoriaLogs;

• журналом dtm-server.log в KTMU.

Для управления другими файлами журналов настройте конфигурацию сервиса journald. Информация по настройке приведена в разделе Настройка хранения событий в системных журналах.

Чтобы задать параметры глубины хранения событий, ротации по сроку хранения или объёму данных на диске, переведите переключатель Включено в активное положение. После этого поля формы станут доступны для редактирования:

• Сколько часов хранить логи в БД (час);

• Интервал проверки файлов журналов аудита (сек);

• Интервал ротации файлов журналов аудита (час);

• Максимальное число архивных журналов аудита;

• Максимальный размер суммы файлов api_audit.log и sec_events_audit.log, после которой начинается ротация логов (МБ);

• Максимальный размер файла журнала на машинах (МБ).

В форме Настройка ротации журналов в KTMU настройте ротацию журнала dtm-server.log в KTMU:

• Максимальный размер журнала (МБ);

• Максимальное число архивных журналов.

При достижении заданного размера dtm-server.log сохраняется в архив, а запись продолжается в новый файл журнала. Если количество архивных журналов превышает установленный лимит, система удаляет самые старые файлы.

При настройке через интерфейс архивные файлы журнала сохраняются в формате zip. Максимальное значение для размера журнала и числа архивных журналов — 1024.

Настройки ротации журналов контроллера и KTMU доступны через API.

Примечание

Максимальный размер журналов указывается в МБ.

Управление доступами

Тенанты

На вкладке Тенанты отображается информация о созданных тенантах, а также пользователях и группах пользователей, которые имеют права на доступ в соответствующий тенант. Чтобы создать новый тенант, нажмите кнопку + Добавить. В открывшейся форме введите название тенанта и нажмите кнопку Сохранить.

Для добавления, просмотра и изменения перечня групп или пользователей нажмите Смотреть напротив строки с названием тенанта. Во всплывающей форме выберите новые для тенанта объекты и нажмите + Добавить. Для редактирования тенанта нажмите иконку напротив соответствующей строки. Для удаления тенанта нажмите .

Группы

На вкладке Группы Администратор может создать локальную группу, включить в нее пользователей и назначить доступ к определённым тенантам. Для создания группы нажмите кнопку + Добавить.

В открывшейся форме укажите название группы, а также выберите пользователей, приведённых в выпадающем списке.

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

В столбце Действие Администратор может отредактировать информацию о группе, нажав на иконку напротив соответствующей строки. Для удаления группы нажмите на .

Пользователи

На вкладке Пользователи Администратор может просматривать, создавать, редактировать и удалять учётные записи пользователей, а также назначать роли.

Для создания локальной учётной записи пользователя нажмите кнопку + Добавить одного пользователя.

В открывшейся форме укажите имя пользователя, пароль и адрес электронной почты для отправки уведомлений о ходе выполнения миграции и сообщений о необходимости смены пароля для локальных учетных записей пользователей, когда срок действия пароля подходит к концу.

При заведении локального пользователя также можно добавить возможность принудительной смены пароля после первого входа под этим пользователем. Для этого установите флажок Требовать смены пароля после входа.

После заполнения формы нажмите Сохранить.

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

При нажатии Смотреть в столбце Тенанты или Группы можно просмотреть список тенантов, к которым у пользователя есть доступ, а также группы, в которые включён соответствующий пользователь. Во всплывающей форме можно выбрать новые для пользователя объекты и нажать + Добавить.

Важно

Для доменных пользователей редактирование имени, пароля и электронной почты недоступно.

Для удаления пользователя нажмите иконку . При удалении доменной учётной записи на контроллере удаляется только информация о регистрации этой учётной записи, но сама запись остаётся в каталоге.

В столбце Роль каждому пользователю можно назначить нужную роль с определёнными правами, выбрав нужное из выпадающего списка. У одного пользователя может быть несколько ролей, в таком случае права ему назначатся суммарно от каждой роли.

В столбце Статус можно увидеть, активна ли данная учётная запись или заблокирована.

В столбце Действие Администратор может заблокировать учётную запись, нажав . Для редактирования информации нажмите иконку напротив соответствующей строки. Для изменения пароля пользователя нажмите иконку .

В столбце Действие также можно принудительно завершить активные сессии пользователей. Для этого нажмите иконку напротив соответствующей строки. Отобразится окно предупреждения, в котором нажмите ОК.

Группы LDAP

На вкладке LDAP Администратор может связывать роли с группами из LDAP-каталога, а также просматривать, редактировать и назначать роли группам.

Для назначения новой роли нажмите кнопку + Сопоставить роль и группу LDAP и в карточке роли в выпадающем списке и выберите соответствующую роль. В поле Выберите сервер укажите имя конфигурации для подключения к LDAP-серверу. В поле Тенанты укажите тенант на группу.

В поле Запись о группе укажите Distinguished Name группы, которой требуется назначить данную роль. Для этого используйте формат:

distinguishedName: "cn=Администратор,cn=Users,dc=ldaptest,dc=mind,dc=io"

Если роль необходимо назначить нескольким группам, нажмите кнопку + Добавить группу в карточку роли.

Для редактирования записи о группе нажмите иконку напротив соответствующей строки. Для удаления нажмите на .

Для просмотра и добавления тенанта нажмите Смотреть в соответствующей записи.

Политики

На вкладке Политики отображается особый набор правил безопасности. Для редактирования необходимо привести переключатель Включено в активное положение.

Для управления политиками паролей доступны следующие настройки:

• Максимальное время жизни пароля (задаётся в секундах) – по умолчанию составляет 5184000 секунд (60 дней).

• Минимальное время жизни пароля (задаётся в секундах) – по умолчанию составляет 0 секунд.

• Количество попыток неправильного ввода пароля до блокировки – по умолчанию без ограничения.

• Время блокировки пользователя при превышении числа попыток неправильного ввода (задаётся в секундах) – по умолчанию 16 минут.

• Время блокировки неактивного пользователя (задаётся в секундах) – по умолчанию составляет 45 дней.

• История хранения паролей – по умолчанию не хранит.

• Максимальное время жизни сессии пользователя, с – по умолчанию 86400 секунд (24 часа).

• Минимальная длина пароля – по умолчанию 8 символов.

• Минимальное количество букв в верхнем регистре – по умолчанию не менее 1 символа.

• Минимальное количество букв в нижнем регистре – по умолчанию не менее 1 символа.

• Минимальное количество цифр – по умолчанию не менее 1 символа.

• Минимальное количество спец. символов – по умолчанию не менее 1 символа.

• Пороговое значение для отправки уведомления об истечении срока пароля (задаётся в % от максимального времени жизни пароля) – по умолчанию 90. При превышении порогового значения времени жизни пароля, пользователь получит письмо с уведомлением о том, что пароль скоро истечёт.

• Время бездействия – период, в течение которого пользователь не выполняет действий в интерфейсе. По истечении этого времени сессия завершается автоматически. По умолчанию составляет 0 минут.

После внесения изменений нажмите кнопку Сохранить.

Примечание

Если максимальный срок жизни пароля локального пользователя истёк, при следующем входе в веб-интерфейс контроллера откроется форма смены пароля.

Интеграции

Внешние секреты

На вкладке Внешние секреты настройте интеграцию с внешней системой хранения и управления секретами SecMan.

1. Нажмите + Добавить.

2. В открывшейся форме Добавить сервер заполните поля:

   • В поле Название введите произвольное имя хранилища секретов.

   • В поле Тип выберите SecMan.

   • В поле Параметры подключения укажите параметры подключения к серверу SecMan в формате JSON.

     

     Используйте следующие параметры:

     • serverUrl — адрес сервера SecMan. Обязательный параметр.

       Пример: {"serverUrl":"t.xxxxxx.test.domain.com"}

     • MFAMethodID — идентификатор метода аутентификации пользователя. Указывайте его, если учётная запись в SecMan защищена OTP.

     • namespace — название пространства имён в SecMan. Необязательный параметр.

       Пример: {"namespace":"CIXXYYZZYY_CIIXXYYZZYY"}

     • AD — имя LDAP-домена для авторизации в SecMan. Обязательный параметр.

       Пример: {"AD":"ad\external.domain.com"}

     • insecure — параметр, который отключает проверку сертификатов. Если указать true, проверка сертификатов выполняться не будет.

3. Нажмите Сохранить.

После сохранения на вкладке Внешние секреты отобразится добавленный сервер с типом SecMan. В разделе Ключи доступа станет доступен выбор типа ключа SecMan.

Для аутентификации на сервере SecMan доступны два способа: Учётные данные AD и OTP и Токен AD.

Выберите Учётные данные AD и OTP, чтобы ввести логин, пароль и OTP.

Выберите Токен AD, чтобы ввести токен AD (client_token), полученный в интерфейсе SecMan. При использовании этого способа логин, пароль и OTP вводить не нужно.

Примечание

Токен AD привязан к выбранному внешнему серверу. Если срок действия токена истёк, выполните аутентификацию повторно и введите новый токен.

Примечание

При использовании интеграции с SecMan и ключа типа signed key SSH-ключи контроллера не хранятся на файловой системе на постоянной основе. Файлы /opt/mind/etc/keys/id_rsa и /opt/mind/etc/keys/id_rsa.pub отсутствуют. Ключи хранятся в БД контроллера в зашифрованном виде. Если операции с агентами недоступны из-за повреждённого ключа, перезапустите контроллер. После перезапуска ключи будут сгенерированы повторно, и действия с агентами снова станут доступны.

LDAP серверы

На вкладке LDAP серверы осуществляется привязка ролей Пользователей MIND Suite к группам из каталога LDAP. Для этого нажмите + Добавить и в открывшейся форме заполните поля:

1. В поле Имя сервера введите уникальное имя LDAP сервера;

2. В поле Адрес сервера введите IP-адрес LDAP сервера в формате ldap://<domain_controller_fqdn>:<ldap_port>, например, ldap://controller.example.local:389;

3. Установите флажок Игнорировать проверку SSL сертификата для возможности отключения проверки сертификатов при настройке интеграции с контроллерами домена через ldaps://.

4. В поле Базовый DN введите путь до OU или каталога, где будут размещаться учётные записи пользователей и групп пользователей, для которых требуется предоставлять доступ к контроллеру в формате DistinguishedName. Например, dc=ldaptest,dc=mind,dc=io.

5. В поле Bind DN введите путь до учётной записи пользователя, под которой будет выполняться подключение к контроллеру домена в формате DistinguishedName. Например: cn=Администратор,cn=Users,dc=ldaptest,dc=mind,dc=io.

   Примечание

   Для подключения к контроллеру домена достаточно использовать учётную запись с правами на просмотр содержимого OU и каталогов, а также чтение атрибутов учётных записей пользователей и групп, например, учётной записи, состоящей в группе Domain Users.

6. В поле Пароль введите пароль.

   

7. Выполните тестовое подключение к LDAP с заданными настройками, нажав кнопку Протестировать. В случае неудачного подключения отобразится уведомление с текстом ошибки.

8. Нажмите Сохранить.

Примечание

После добавления LDAP-сервера в интерфейсе в целях безопасности будет скрыто отображение значения полей Базовый DN и Bind DN.

Для настройки подключения к LDAP с TLS выполните следующие действия:

1. Добавьте сертификат LDAP в доверенные на ОС:

   • Поместите сертификат в каталог /usr/share/local/ca-certificates. Если каталог отсутствует, создайте его.

   • В файл /etc/hosts добавьте новую строку с IP-адресом LDAP-сервера и его доменным именем.

   • Выполните команды.

     Для ОС Astra Linux 1.7.7 и Ubuntu Server 24.04:

     cd /usr/share/local/ca-certificates
     sudo update-ca-certificates
     

     Для ОС РЕД ОС 8 и SberLinux 8.10.x:

     cd /usr/share/local/ca-certificates
     sudo update-ca-trust
     sudo update-ca-trust extract
     

2. В интерфейсе MIND перейдите в раздел Администрирование, в списке Управление доступами выберите пункт Группы LDAP и выполните настройку. Подробная информация приведена в разделе Группы LDAP.

После исправления конфигурации вход с LDAP-пользователем будет успешным.

Kerberos

Чтобы мигрировать машины под управлением ОС Windows, находящиеся в Active Directory с аутентификацией по протоколу Kerberos, выполните следующие действия на вкладке Kerberos.

1. Включите переключатель Включено.

2. В поле Realm по умолчанию введите имя домена.

3. В поле Сервер DC введите адреса контроллеров домена через запятую.

4. В поле Сервер аутентификации укажите сервер аутентификации.

   

5. Нажмите кнопку Сохранить.

Почта

На вкладке Почта настройте оповещения о ходе миграции по электронной почте.

Перечень событий, по которым отправляются оповещения, приведён в таблице.

Тип	Событие
Информация	Запуск миграционного задания Переход в режим Flow Редактирование Flow Остановка Flow Успешное выполнение миграционного задания
Предупреждение	Ошибка миграции

Создание правила оповещения

Чтобы создать правило оповещения:

1. Нажмите + Добавить правило.

2. В открывшейся форме заполните поля:

   • Тип оповещения — выберите значение Информация или Предупреждение.

   • Тип объекта — выберите объект, по которому нужно отправлять оповещения.

   • Объект — укажите имя объекта и его [id].

   • Повторная отправка оповещения через, минут — укажите интервал повторной отправки сообщений.

   • Получатели — укажите один или несколько email-адресов получателей.

3. Если в поле Тип объекта выбрано значение Проект, настройте отправку оповещений о заданиях в проекте.

4. Если в поле Тип объекта выбрано значение Тенант, укажите ID тенанта, чтобы отправлять оповещения о всех заданиях в указанном тенанте.

5. Если в поле Тип объекта выбрано значение Задание, выберите конкретное задание в проекте.

6. Если в поле Тип объекта выбрано значение Все, настройте отправку оповещений о заданиях на контроллере.

7. Нажмите Сохранить.

Правило отобразится в таблице на странице Почта.

Изменение и удаление правил оповещения

Чтобы изменить правило оповещения:

1. Найдите нужное правило в таблице.

2. В столбце Действие нажмите иконку .

   

3. В форме Обновить правило измените необходимые параметры.

4. Нажмите Сохранить.

Чтобы удалить правило, найдите нужную строку и нажмите иконку .

Настройка SMTP

Чтобы настроить SMTP:

1. Нажмите Настроить SMTP.

2. В форме Настройки SMTP заполните поля:

   • Адрес почтового сервера;

   • Порт для подключения;

   • Тип аутентификации;

   • Email отправителя.

3. При необходимости установите флажок Использовать SSL/TLS.

4. В поле Тип аутентификации выберите один из вариантов:

   • Без аутентификации — для подключения к SMTP-серверу без логина и пароля;

   • Аутентификация по логину и паролю — для подключения к SMTP-серверу с использованием учётных данных.

5. Нажмите Сохранить.

Чтобы проверить параметры подключения, нажмите Протестировать.

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

Чтобы удалить все параметры подключения к SMTP-серверу с контроллера, нажмите Очистить. Чтобы закрыть форму Настройки SMTP без сохранения изменений, нажмите Отменить. После настройки SMTP и сохранения правила оповещения на указанные email-адреса будут приходить уведомления о ходе выполнения репликации. В письмах содержится следующая информация:

• имя контроллера;

• имя и ID тенанта;

• имя и ID проекта;

• имя и ID задания;

• имена и ID источника и приёмника.

Syslog

На вкладке Syslog Администратором MIND Suite осуществляется отправка событий безопасности (audit logs) и информации о включённом/выключенном шифровании в задании в систему SIEM.

Для этого используется протокол syslog. Логи отправляются в формате CEF (Common Event Format). Для включения требуется выполнить следующие действия:

Нажать кнопку + Добавить и в открывшейся форме заполнить следующие поля:

• в поле Адрес подключения ввести IP-адрес или домен сервера syslog;

• в поле Тэг ввести тег сообщений, которые отправляются в syslog;

• в поле Протокол выбрать:

  • TCP

  • UDP

• в поле Тип выбрать соответствующий пункт. MIND Suite поддерживает отправку логов через протокол syslog в двух режимах:

  • audit – для передачи событий безопасности (audit logs) и информации о шифровании заданий в SIEM-системы (в формате CEF);

  • general – для экспорта общих журналов событий во внешние системы сбора логов.

Оба типа (audit и general) могут работать параллельно. Для этого необходимо создать две отдельные конфигурации Syslog. В первой указать тип audit, во второй – general. Настроить разные Тэги или Адреса подключения при необходимости.

Совместная настройка позволяет отправлять аудит-логи в SIEM, а общие логи – в системы мониторинга, а также распределять нагрузку между серверами.

Бекапы

На странице Администрирование выберите Интеграции | Бекапы.

Сервис mind-backup используется для восстановления следующих компонентов MIND Suite:

• сертификаты;

• основной конфигурационный файл config.yml;

• драйверы;

• InfluxDB;

• NGINX;

• Postgres.

На вкладке Восстановление просматривайте сохранённые резервные копии контроллера и при необходимости выполняйте восстановление или удаление резервных копий.

В блоке Хранилище отображается информация о занятом и свободном месте в хранилище резервных копий. Таблица резервных копий содержит следующие столбцы:

• Дата создания;

• Тип;

• Версия контроллера;

• Действия — иконки для восстановления и удаления резервной копии.

Чтобы восстановить контроллер из резервной копии:

1. На вкладке Восстановление найдите в таблице нужную резервную копию.

2. В столбце Действия нажмите иконку .

3. Подтвердите действие в диалоговом окне.

Чтобы удалить резервную копию:

1. На вкладке Восстановление найдите в таблице резервную копию, которую нужно удалить.

2. В столбце Действия нажмите иконку .

3. Подтвердите действие в диалоговом окне.

На вкладке Резервное копирование выполняйте ручное создание резервных копий и настраивайте автоматическое резервное копирование по расписанию.

Важно

При настройке автоматического резервного копирования время запуска указывается в формате UTC.

Например, если для ежедневного резервного копирования указано время 00:00, а на сервере установлен часовой пояс GMT+3, резервная копия будет создана в 03:00.

Для настройки резервного копирования выполните следующие действия:

1. На вкладке Резервное копирование включите переключатель Автоматическое резервное копирование.

2. В поле Где хранить резервные копии укажите каталог для хранения.

3. В поле Автоматически копировать каждый выберите значение Час, День или Неделя.

4. Если выбрано значение День, заполните поле Время.

5. Если выбрано значение Неделя, заполните поля Время и День.

6. В поле Количество хранимых копий укажите количество резервных копий для хранения.

7. Чтобы создать резервную копию вручную, нажмите Создать копию вручную.

8. Нажмите Сохранить.

Примечание

Во время выполнения резервного копирования или восстановления контроллер становится временно недоступным. На время этих операций веб-интерфейс может возвращать ошибки. По завершении процессов копирования или восстановления контроллер снова будет доступен.

Сервис хранит конфигурацию в базе данных. Если API недоступен, обновите конфигурацию из командной строки. Документ «Руководство по работе с API» содержит подробную информацию об API-вызовах для работы с конфигурацией.

Работа с mind-backup в командной строке

Утилита mind_backup предоставляет интерфейс для управления резервным копированием и восстановлением оркестратора, находится по пути /opt/mind/bin/mind_backup.

Важно

Запускайте команды утилиты от имени пользователя mindctrl.

Примечание

Остановите сервис mind_backup с помощью команды systemctl stop mind_backup. Если сервис активен, команды mind_backup serve, mind_backup create и mind_backup restore завершаются ошибкой с идентификатором активного процесса (PID).

Пример команды:

mind_backup [flags]

Параметры: -v, --version – показать информацию о версии программы.

version

Выводит текущую версию программы.

mind_backup version

Пример вывода:

VERSION: development, BUILDTIME: 1757435065, BRANCH: base-impl, COMMIT: a18af30, HOTFIX:

serve

Запускает сервер резервного копирования как фоновый процесс.

mind_backup serve [flags]

Параметры: -s, --servercfg string – путь к файлу конфигурации сервера.

Пример:

mind_backup serve --servercfg /tmp/backup_server.yaml

Пример файла конфигурации:

{
    "addr": "0.0.0.0:8085",
   "pgConf": {
   "rtDBUser": "cG9zdGdyZXM=",
   "rtDBPassword":
   "M3xqNURPQjEwdkdvMSRhbzZEfUE=",
   "rtDBAddress": "127.0.0.1",
   "rtDBPort": 5432,
   "rtDBName": "mind",
   "rtDBSSLMode": "disable"
   }
}

Особенности:

• проверяет, работает ли сервер резервного копирования;

• если сервер резервного копирования уже работает, команда завершается с ошибкой;

• загружает конфигурацию и запускает сервер.

list

Выводит список всех доступных резервных копий.

mind_backup list [flags]

Параметры: -b, --cfg string – путь к файлу конфигурации резервных копий.

Пример:

mind_backup list --cfg /etc/mind/backup_config.yaml

Пример файла конфигурации:

{
   "backupSettings": {
   "path": "/tmp",
   "interval": {
   "step": "HOUR"
   },
   "numberOfCopies": 3
   },
   "pgConf": {
   "rtDBUser": "cG9zdGdyZXM=",
   "rtDBPassword":
   "M3xqNURPQjEwdkdvMSRhbzZEfUE=",
   "rtDBAddress": "127.0.0.1",
   "rtDBPort": 5432,
   "rtDBName": "mind",
   "rtDBSSLMode": "disable"
   }
}

Пример вывода:

auto_backup_development_1757434140.tgz
auto_backup_development_1757435160.tgz
auto_backup_development_1757435400.tgz

create

Создаёт резервную копию.

mind_backup create [flags]

Параметры: -b, --cfg string – путь к файлу конфигурации резервных копий.

Пример:

/opt/mind/bin/mind_backup create

restore

Восстанавливает систему из указанной резервной копии.

mind_backup restore [filename] [flags]

Аргументы: filename – имя файла резервной копии (обязательный). Не указывайте путь к файлу: утилита определяет каталог резервных копий по конфигурации. Чтобы получить имя файла резервной копии, выполните команду mind_backup list.

Параметры: -b, --cfg string – путь к файлу конфигурации резервных копий.

Пример:

/opt/mind/bin/mind_backup restore auto_backup_development_1757435400.tgz

Выполняйте восстановление на совместимой версии системы. Во время резервного копирования и восстановления контроллер временно недоступен. Продолжительность периода недоступности зависит от скорости остановки и запуска сервисов: mind_system, mind_api, mind_healthmanager, mind_jobworker, mind_scheduler, mind_siteworker, mind_taskworker, mind_vaults.

Процесс валидации происходит следующим образом:

• Все команды, кроме serve и version, проверяют, работает ли сервер резервного копирования.

• Если сервер резервного копирования работает, команды завершаются с ошибкой.

• Команды проверяют настройки из конфигурационного файла.

Система уведомлений

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

1. Миграция была запущена.

2. Первичная репликация завершена и был выполнен переход в режим Flow.

3. Миграция завершена успешно.

4. Миграция завершена неуспешно.

Информация об используемом ПО

В соответствии с лицензионным соглашением № П041/06/2024 между ООО «Майнд Софт» и ООО «Постгрес Профессиональный» продукт «СУБД Postgres Pro Standard» может быть использован в качестве встраиваемого компонента в составе MIND Suite и только для целей функционирования ПО MIND Suite. Лицензия предоставляется на весь срок поддержки MIND Suite.

Информация о программном обеспечении с открытым исходным кодом, используемом в MIND Suite.

• Nginx;

• RabbitMQ;

• Victoria Logs;

• InfluxDB.

Приложение

Устанавливаемые драйверы для ОС Windows при миграции в платформы на базе VMware и KVM

VMware

Имя драйвера	Windows Server 2016/2019/2022; client 10/11	Windows Server 2008 R2	Windows Server 2012/2012 R2
vsock	—	10/29/2021, 9.8.19.0	—
vnetWFP	12/15/2022, 12.2.0.0	12/15/2022, 12.2.0.0	12/15/2022, 12.2.0.0
vmci	—	10/29/2021, 9.8.18.0	10/29/2021, 9.8.18.0
vmusbmouse	—	10/27/2021, 12.5.12.0	10/27/2021, 12.5.12.0
vmmemctl	—	10/27/2021, 7.5.7.0	10/27/2021, 7.5.7.0
vmhgfs	—	10/27/2021, 11.0.44.0	—
vmxnet3	11/30/2022, 1.9.12.0; 04/29/2021, 1.9.2.0	11/30/2022, 1.9.12.0	11/30/2022, 1.9.12.0
vmmouse	—	10/27/2021, 12.5.12.0	10/27/2021, 12.5.12.0
pvscsi	11/30/2022, 1.3.26.0	11/30/2022, 1.3.26.0	11/30/2022, 1.3.26.0

KVM

Имя драйвера	Windows Server 2012	Windows Server 2012 R2	Windows Server 2016	Windows Server 2019
vioscsi	05/20/2022, 62.91.104.221	08/03/2018, 62.76.104.160	05/21/2022, 100.91.104.221	05/21/2022, 100.91.104.221
viorng	05/20/2022, 62.91.104.221	08/03/2018, 62.76.104.160	05/20/2022, 100.91.104.221	05/20/2022, 100.91.104.221
vioser	05/20/2022, 62.91.104.221	08/03/2018, 62.76.104.160	05/21/2022, 100.91.104.221	05/21/2022, 100.91.104.221
qemufwcfg	—	—	05/21/2022, 100.90.104.221	05/21/2022, 100.90.104.221
qxl	—	—	—	—
qxlodd	11/20/2020, 10.0.0.210	05/28/2017, 10.0.0.180	11/20/2020, 10.0.0.210	11/20/2020, 10.0.0.210
viofs	05/20/2022, 62.91.104.221	05/20/2022, 62.91.104.221	05/20/2022, 100.91.104.221	05/20/2022, 100.91.104.221
qemupciserial	05/21/2022, 100.90.104.221	05/21/2022, 100.90.104.221	05/21/2022, 100.90.104.221	05/21/2022, 100.90.104.221
vioinput	05/20/2022, 62.91.104.221	08/03/2018, 62.76.104.160	05/21/2022, 100.91.104.221	05/21/2022, 100.91.104.221
balloon	05/20/2022, 62.91.104.221	08/03/2018, 62.76.104.160	05/21/2022, 100.91.104.221	05/21/2022, 100.91.104.221
viostor	05/20/2022, 62.91.104.221	08/03/2018, 62.76.104.160	05/21/2022, 100.91.104.221	05/21/2022, 100.91.104.221
pvpanic	05/20/2022, 62.91.104.221	08/03/2018, 62.76.104.160	05/20/2022, 100.91.104.221	05/20/2022, 100.91.104.221
vioprot	—	—	05/20/2022, 100.91.104.221	05/20/2022, 100.91.104.221
smbus	—	—	—	—
netkvm	05/20/2022, 62.91.104.221	08/03/2018, 63.76.104.160	05/20/2022, 100.91.104.221	05/20/2022, 100.91.104.221
fwcfg	05/20/2022, 62.91.104.221	—	05/21/2022, 100.91.104.221	05/21/2022, 100.91.104.221
viogpudo	05/20/2022, 62.91.104.221	—	05/20/2022, 100.91.104.221	05/20/2022, 100.91.104.221

Имя драйвера	Windows Server 2022	Windows Server 2008	Windows Server 2008 R2	client 10, client 11
vioscsi	05/21/2022, 100.91.104.221	08/03/2018, 60.76.104.160	08/03/2018, 61.76.104.160	01/13/2025, 100.100.104.27100
viorng	05/20/2022, 100.91.104.221	06/11/2018, 60.76.104.154	06/11/2018, 61.76.104.154	01/13/2025, 100.100.104.27100
vioser	05/21/2022, 100.90.104.221	06/11/2018, 60.76.104.154	06/11/2018, 61.76.104.154	01/13/2025, 100.100.104.27100
qemufwcfg	05/21/2022, 100.90.104.221	—	—	05/21/2022, 100.90.104.22100
qxl	—	—	09/22/2015, 6.1.0.100	—
qxlodd	—	—	—	11/20/2020, 10.0.0.210
viofs	05/20/2022, 100.91.104.221	—	—	01/13/2025, 100.100.104.27100
qemupciserial	05/21/2022, 100.90.104.221	05/21/2022, 100.90.104.221	05/21/2022, 100.90.104.221	05/21/2022, 100.90.104.22100
vioinput	05/21/2022, 100.91.104.221	06/07/2019, 61.77.104.172	05/21/2022, 100.91.104.221	01/13/2025, 100.100.104.27100
balloon	05/21/2022, 100.91.104.221	06/11/2018, 60.76.104.154	03/10/2019, 61.77.104.169	01/13/2025, 100.100.104.27100
viostor	05/21/2022, 100.91.104.221	07/25/2018, 60.76.104.158	06/07/2019, 61.77.104.172	01/13/2025, 100.100.104.27100
pvpanic	05/20/2022, 100.91.104.221	06/11/2018, 60.76.104.154	06/11/2018, 61.76.104.154	01/13/2025, 100.100.104.27100
vioprot	05/20/2022, 100.91.104.221	—	—	01/13/2025, 100.100.104.27100
smbus	04/27/2017, 100.0.0.0	04/27/2017, 100.0.0.0	—	—
netkvm	05/20/2022, 100.91.104.221	08/03/2018, 63.76.104.160	06/07/2019, 61.77.104.172	01/13/2025, 100.100.104.27100
fwcfg	05/21/2022, 100.91.104.221	—	05/21/2022, 100.91.104.221	01/13/2025, 100.100.104.27100
viogpudo	05/20/2022, 100.91.104.221	—	05/20/2022, 100.91.104.221	01/13/2025, 100.100.104.27100
pvpanic-pci	—	—	—	01/13/2025, 100.100.104.27100
viomem	—	—	—	01/13/2025, 100.100.104.27100

Протоколы и порты

Источник трафика	Назначение трафика	Порт назначения	Протокол	Комментарий
MIND Migrate #guest
Машина	Контроллер	TCP 80	HTTP	Подключение агента к контроллеру
		TCP 443	HTTPS
Рабочая станция администрации	Контроллер	TCP 80	HTTP	Подключение к веб-консоли администрирования и доступ к RESTful API
		TCP 443	HTTPS
Контроллер	Машина	TCP 22	SSH	Автоматическая установка агента на машинах с ОС Linux
Контроллер	Машина	TCP 445	SMB	Автоматическая установка агента на машинах с ОС Windows
Машина (источник)	Машина (приёмник)	TCP 9000	MIND Data Plane	Передача трафика миграции от источника к приёмнику
Прокси-серверы
Машина (источник)	Прокси-сервер	TCP 9000–9999	MIND Data Plane	Передача трафика миграции через прокси между машинами
Прокси-сервер	Машина (приёмник)	TCP 9000	MIND Data Plane	Передача трафика миграции от прокси к приёмнику
Прокси-сервер	Прокси-сервер	TCP 9000–9999	MIND Data Plane	Передача трафика миграции между прокси при использовании прокси с обеих сторон
Контроллер	Прокси-сервер	TCP 19000–19999	SSH	Управляющий доступ контроллера к машинам через прокси (перенаправление на TCP 22)
Прокси-сервер	Машина (источник)	TCP 22	SSH	Управляющий доступ прокси к источнику
Прокси-сервер	Машина (приёмник)	TCP 22	SSH	Управляющий доступ прокси к приёмнику
Машина	Прокси-сервер	TCP 20000–20999	HTTP	Подключение агента к контроллеру через прокси (перенаправление на TCP 443)
			HTTPS
Прокси-сервер	Контроллер	TCP 80	HTTP	Получение конфигурации прокси с контроллера
		TCP 443	HTTPS
Автоматизация
Контроллер	Сервер vCenter	TCP 443	HTTPS	Подключение к виртуальной инфраструктуре VMware vSphere для возможностей Автоматизации
Контроллер	Контроллер Basis Dynamix Enterprise	TCP 443	HTTPS	Подключение к виртуальной инфраструктуре Basis Dynamix Enterprise для возможностей Автоматизации
Контроллер	Контроллер OpenStack	TCP 443	HTTPS	Подключение к виртуальной инфраструктуре OpenStack для возможностей Автоматизации
Вспомогательные сервисы
Контроллер	Контроллер домена	TCP 389	LDAP	Аутентификация через домен на контроллере
		TCP 636	LDAPS
Контроллер	Контроллер домена	TCP 88	Kerberos	Аутентификация на машинах с ОС Windows с использованием Kerberos
		UDP 88
Контроллер	Сервер Secman	TCP 443	HTTPS	Взаимодействие с внешним хранилищем секретов
Контроллер	Почтовый сервер	TCP 25	SMTP	Отправка почтовых уведомлений
Контроллер	Сервер логирования	TCP 514	SYSLOG	Отправка журналов на внешний сервер по Syslog
		UDP 514