Вступление
Привет, Хабр! Миграция большого числа рабочих станций с Windows на Astra Linux — это не запуск установщика и не вечерняя переустановка ОС на одном компьютере. Это проект, в котором нужно провести инвентаризацию парка, проверить совместимость, согласовать сроки, сохранить данные, настроить доменную интеграцию, проконтролировать результат и разобрать ошибки. Вручную это потребует значительных ресурсов ИТ-служб.
Astra Migration — клиент-серверное решение, которое берёт эту работу на себя. Оно состоит из серверной части с веб-порталом, агента для Windows и компонентов для установки и первичной настройки целевой ОС. В статье хочу рассказать из каких частей состоит Astra Migration, как выглядит путь от установки серверной части до первой загрузки Astra Linux, что такое сценарии и волны миграции, зачем нужны блокеры и какие дополнительные детали раскрываются в решении.
Архитектура Astra Migration
Astra Migration — не универсальный конвертер между любыми ОС. Он работает в конкретной связке: исходная — Windows, целевая — Astra Linux. На уровне архитектуры решение состоит из нескольких компонентов:
● AMS (Astra Migration Server) — сервер управления. Хранит данные, управляет сценариями и волнами, формирует конфигурации миграции и собирает результаты.
● AMA (Astra Migration App) — агент для рабочих станций Windows. Собирает инвентаризационные сведения, проверяет условия готовности, получает команды сервера и взаимодействует с пользователем.
● AML (Astra Migration Linux) — минимальный образ Astra Linux для автоматической миграции. Содержит установочные файлы целевой системы.
● Astra FirstBoot — компонент, выполняющий процедуры первой загрузки Astra Linux и первоначальной настройки.
● Astra FirstLogin — компонент, который настраивает пользовательское окружение при первом входе.
Получается классическая схема централизованной оркестрации: сервер принимает решения на уровне проекта, агент обеспечивает связь с конкретным АРМ, а AML выполняет переход в специальной среде.
Astra Migration Server построен на микросервисной архитектуре и разворачивается в контейнерах Docker. В серверную часть входят образы сервисов AMS, конфигурационные файлы Docker Compose и дополнительные компоненты. Для работы нужны PostgreSQL, RabbitMQ и S3-совместимое хранилище. В комплекте поставки присутствуют образы этих сервисов, но можно использовать уже существующие экземпляры в инфраструктуре организации.
Что видит пользователь
AMA не превращает миграцию в полностью невидимую операцию. Пользователь АРМа получает приветственное уведомление, сообщения о назначенной дате, напоминания и инструкции перед запуском. Через значок в области уведомлений можно открыть интерфейс агента вручную.
Дату миграции пользователь может подтвердить или перенести. Диапазон доступных дат задаёт администратор, число самостоятельных переносов ограничено двумя.
Пользователю приходят напоминания за 14, 7, 3 и 1 день до миграции, а также в день миграции. В последнем уведомлении показывается таймер. Перед началом пользователь должен закрыть приложения и документы, сохранить данные, не выключать компьютер, подключить рабочую станцию к электропитанию.
Такой подход решает две задачи: снижает вероятность потери несохранённых данных и делает изменение ОС предсказуемым для пользователя. Он заранее знает дату и может подготовить рабочее место.
При этом у простого пользователя минимум вовлечения. Основные действия выполняются автоматически, а от сотрудника требуется подтвердить дату, выполнить инструкции перед запуском и после миграции войти в новую систему. Это важное отличие от ручной установки, при которой пользователь часто становится участником длинной последовательности технических операций.
После успешного перехода Astra Linux запускается автоматически. Учётные данные для входа предоставляет администратор. Данные из Windows доступны в каталоге Basic data partition, который открывается через файловый менеджер Astra Linux.
Первый запуск и активация
После развертывания AMS администратор заходит на веб-портал через браузер. Там доступны три основных раздела:
● «Волны миграции» — планирование, запуск и контроль наборов миграций.
● «Исходные ОС» — сведения об АРМ и результаты инвентаризации.
● «Сценарии миграции» — правила и параметры будущего перехода.
После установки и настройки AMA сервер начинает получать сведения об АРМ. В карточке устройства отображаются UUID, hostname, тип и версия ОС, сведения о конфигурации АРМа (GPU, CPU и так далее) и установленном программном обеспечении. Системный администратор может оценить технические параметры АРМов и сопоставить их с требованиями сценариев миграции.
Astra Migration — проприетарное решение. Для полнофункционального режима нужен личный кабинет группы «Астра» или локальный сервер активации лицензий. Последний вариант рассчитан на закрытые или полуизолированные контуры, где доступ в интернет ограничен. Лицензия Astra Migration списывается только после успешного завершения миграции АРМ. Если переход завершился ошибкой, лицензия остаётся свободной до момента исправления проблем.
Сценарий как декларативный план миграции
Главная идея Astra Migration — создать отдельные сценарии для конкретной группы компьютеров, а потом мигрировать АРМы. В сценарии задаются исходная ОС, блокирующие условия, режим запуска AML, параметры целевой системы, дополнительные пакеты и интеграции. Для миграции администратор указывает название сценария и наименование исходной системы.
Настроить нужно четыре группы параметров:
● Исходная ОС. Для какой системы предназначен сценарий.
● Блокеры. Условия, при которых переход запрещается.
● Параметры установки. Режим AML, имя образа, репозитории Astra Linux и фактор открытия защищённых служебных данных.
● Параметры целевой ОС. Пароль локального администратора, дополнительные пакеты и интеграция с внешними системами.
У целевой системы поддерживается режим загрузки dual boot: после миграции на АРМе остаются две операционные системы, и администратор при необходимости может выбрать Windows в загрузчике. Для обычных пользователей самостоятельный выбор отключён.
Для dual boot в Astra Linux монтируется раздел с домашним каталогом Windows — данные становятся доступны из новой ОС сразу после миграции и открываются через файловый менеджер.
Этот механизм снижает риск потери привычной структуры данных, но не заменяет резервное копирование. До миграции сохраните критичные файлы отдельно и проверьте, какие каталоги действительно попадут в область доступа Astra Linux. Перенос данных не гарантирует сохранение настроек каждой программы или совместимость форматов документов.
Dual boot выступает как механизм контролируемого отката или аварийного доступа, а не как вариант выбора системы при каждом запуске для простого пользователя.
В Astra Migration для целевой ОС можно указать дополнительные пакеты, например fly-scan или другое ПО для рабочей группы. Также предусмотрена интеграция с другими решениями группы «Астра» — Astra Configuration Manager, Active Directory и Astra Linux Directory (ALD Pro).
Astra Migration переносит не только пользовательские данные, но и часть настроек исходной системы: сетевые настройки, параметры VPN, защищённые Wi-Fi-сети, часовой пояс и системную локаль. Это не полное клонирование профиля Windows, а выбранный набор параметров, делающих переход и первое включение Astra Linux менее болезненным.
Блокеры: миграция должна остановиться заранее
Блокеры нужны AMA для определения готовности рабочей станции к переходу. Механизм выясняет проблему до миграции и изменения разметки диска или перезагрузки. Блокеры делятся на обязательные и настраиваемые. Примеры обязательных блокеров, включенных сценарий:
● не менее 50 ГБ свободного места для установки AML;
● отсутствие Dirty bit на целевом разделе NTFS;
● отсутствие съёмных носителей;
● подключённое питание ноутбука;
● включённый режим UEFI;
В настраиваемых блокировках администратор может, например, запретить миграцию при обнаружении конкретного ПО, оборудования USB или PCI, определённых моделей и серийных номеров материнской платы, чипсетов, производителей и типов шасси. Для сравнения доступны условия «равно», «не равно», «содержит» и «не содержит».
Практический сценарий: организация заранее проверяет список рабочих приложений и периферии, а затем добавляет в сценарий нужные правила. Например, можно остановить переход на компьютерах с конкретной док-станцией или с приложением, для которого ещё нет замены в Astra Linux.
Блокеры не решают задачу совместимости полностью. Они работают с теми параметрами, которые описаны в решении и доступны агенту. Перед запуском всё равно придётся провести отдельный тест оборудования, периферии и прикладного ПО. В руководстве администратора прямо рекомендуется проверить наличие актуальных драйверов и совместимость оборудования с целевым дистрибутивом.
Три режима AML
В Astra Migration Linux предусмотрено три режима миграции:
1. «Миграция». Штатный автоматический режим без расширенного вывода и доступа к консоли.
2. Debug. Режим с расширенной регистрацией событий. После завершения журналы и конфигурационные файлы сохраняются на рабочем столе первого вошедшего пользователя Astra Linux.
3. Developer. Режим для разработчика и диагностики. После загрузки AML можно переопределять функции, редактировать конфигурацию установщика и запускать интерактивную оболочку.
Для стандартной миграции волны подходит обычный режим. Debug — для выявления проблем на пилотных или тестовых средах. Developer даёт больше возможностей, но увеличивает риск неконтролируемого изменения процесса.
Волна миграции: от пилота к массовому переходу
Волна — основной механизм планирования массового перехода. Она объединяет АРМ, общую дату, временной интервал и сценарий. При создании волны администратор задаёт название, назначенный сценарий, даты начала и окончания, время запуска по местному времени и процент неудач, при достижении которого волна автоматически остановится.
Период начала и окончания волны важен не только для планирования миграции. В его пределах пользователь может самостоятельно выбрать другую дату миграции.
Порог неудач особенно полезен для поэтапного внедрения. Если в небольшой группе обнаружилась системная проблема, нет смысла продолжать миграцию всего парка. Порог превращает волну в управляемый эксперимент: после превышения заданной доли ошибок процесс останавливается, и команда может разобраться в причине.
Например, выбираем пороговое значение 10%. При достижении этой доли неудачных переходов волна автоматически остановится. Конкретное значение зависит от масштаба пилота: для маленькой группы даже одна ошибка может быть достаточным основанием для паузы.
В новую волну добавляются только АРМ, которые уже появились в системе благодаря AMA. Пока волна в статусе «Не активна», список устройств можно редактировать. После активации добавление и удаление рабочих мест становится недоступным.
В интерфейсе с помощью статусов Администратор может видеть в реальном времени, какие рабочие места уже обработаны, где возникли проблемы и какие устройства требуют внимания.
Как проходит миграция технически
Пользовательский сценарий начинается с приветственного уведомления Astra Migration App. После истечения 15-минутного таймера агент начинает подготовку файловой системы, настраивает образ установщика, распаковывает загрузчик Astra Linux и передаёт ему управление.
Затем выполняются дополнительные операции, предусмотренные сценарием. В демонстрационном процессе к ним относились интеграция с Astra Configuration Manager, ввод в домен AD или ALD Pro и отправка результата на Astra Migration Server.
После перезагрузки запускается Astra Linux. По умолчанию пользователь попадает в новую систему, доступ к Windows остаётся у администратора. После входа пользователь может открыть файловый менеджер, перейти в Basic Data Partition и получить доступ к перенесённым данным.
Процесс состоит не только из установки пакетов. Он включает подготовку, смену загрузочного сценария, установку целевой системы, первичную настройку, интеграцию с внешними сервисами, передачу отчёта и подготовку пользовательского окружения.
Поведение при возникновении ошибок
В Astra Migration предусмотрен сценарий, при котором техническая ошибка прерывает миграцию. В этом случае выполняется восстановление исходной Windows, её данных и настроек. После устранения причины администратор назначает новую дату.
Для диагностики в портале нужно открыть проблемную волну, перейти к конкретному АРМ, посмотреть сработавшие блокеры и лог ошибки. Если требуется повторить попытку, рабочее место исключается из неудачной волны, после чего его можно добавить в новую.
Такая модель безопаснее безусловного повторного запуска: каждая новая попытка получает отдельный контекст и может выполняться после корректировки сценария или состояния оборудования. Но регламент должен предусматривать ручную проверку — восстановление ОС не отменяет необходимости убедиться в сохранности данных, работоспособности загрузчика и корректности состояния диска.
Ограничения и вопросы к внедрению
У решения есть ряд ограничений, которые следует учитывать до закупки и проектирования миграции.
Узкая матрица поддерживаемых ОС и режимов. Миграция доступна для Windows 10 на Astra Linux SE 1.8, а единственный режим установки — dual boot. Если нужен сценарий полной замены Windows или переход с другой версии, это необходимо отдельно подтверждать по актуальной версии решение.
Зависимость от состояния BIOS и железа. Secure Boot должен быть отключён, требуется UEFI, отключены сон и гибернация, съёмные носители должны отсутствовать. Для ноутбуков обязательны питание от сети и открытая крышка. В крупной инфраструктуре эти требования могут стать отдельным этапом подготовки через политики управления устройствами.
Отсутствие функции удаления сценария. В текущей версии сценарий можно редактировать, но удалить нельзя. Это может привести к накоплению тестовых и устаревших записей. Администратору понадобится собственная схема именования и правила жизненного цикла объектов.
Как бы я настроил тестовую среду
Для тестового стенда не стоит сразу выбирать случайные рабочие места. Лучше сформировать репрезентативную группу: разные модели компьютеров, ноутбуки, устройства с док-станциями, разные варианты периферии, типовые прикладные программы и несколько пользователей с различными профилями.
Практический порядок:
Развернуть AMS из комплекта поставки с помощью скрипта на отдельном сервере Astra Linux. Скрипт импортирует образы AMS, при необходимости загружает образы PostgreSQL, MinIO и RabbitMQ, а затем запускает контейнеры с помощью Docker Compose.
Настроить централизованное распространение AMA через групповые политики или используемую систему управления программами.
Установить AMA на пилотные АРМ и дождаться поступления инвентаризационных данных.
Проверить оборудование, драйверы, разметку дисков, BIOS и прикладное ПО.
Создать сценарий с минимальным набором дополнительных изменений.
Добавить в него блокеры для заведомо неподдерживаемого оборудования и программ.
Отдельно проверить, какие сетевые настройки, VPN-параметры, Wi-Fi-сети, локаль и часовой пояс должны быть перенесены.
Сформировать небольшую волну с низким порогом автоматической остановки.
Провести миграцию в режиме «Миграция», а при проблемах повторить на тестовом АРМ в режиме Debug или Developer.
Проверить вход пользователя, доступ к данным, доменную интеграцию, установку пакетов и возможность административной загрузки Windows.
Зафиксировать результаты и только после этого масштабировать волну.
Пилот нужен не только для успешных миграций. Он поможет собрать перечень несовместимых устройств и приложений, фактическое время перехода, обращения пользователей, результаты восстановления, сохранность настроек и требования к службе поддержки. Иначе успешная техническая миграция может оказаться неудачным проектом эксплуатации. Пилот надо по максимуму приблизить к боевой системе.
Заключение
Astra Migration закрывает самую трудоёмкую часть перехода с Windows на Astra Linux: централизованное планирование, проверку готовности, информирование пользователей, доставку конфигураций и контроль результата. Решение хорошо ложится на сценарий поэтапной миграции корпоративного ИТ‑парка, где важно управлять не отдельным компьютером, а группами рабочих мест.
Оптимальная стратегия — начать с небольшого пилота, использовать блокеры как формализованный список требований, отдельно проверять перенос настроек и данных. Режимы Debug и Developer использовать для диагностики. В таком виде решение превращает миграцию из разрозненных действий в понятный алгоритм: централизованное развертывание агента, инвентаризация, проверка работоспособности, уведомление пользователя, запуск, контроль и разбор результата.
Спасибо за прочтение!
