РЕД ОС 9.2 против Astra Linux SE 2.15: сравниваем на контейнерах, Ansible и свежем железе

В мае оба ведущих отечественных серверных дистрибутива обновились почти одновременно: РЕД ОС 9.2 вышла в начале месяца, Astra Linux SE 2.15 - в середине. Оба релиза позиционируются как обновления системных компонентов без структурных ломающих изменений. У нас накопилась тестовая нагрузка, которую мы давно хотели прогнать одинаково на обоих - и майская пауза в плановых апгрейдах дала для этого время.

Контекст: мы используем оба дистрибутива у разных заказчиков. РЕД ОС чаще идёт на серверные роли в смешанных инфраструктурах, Astra Linux SE - там где нужна сертификация по классу защищённости или есть требование к мандатному управлению. Иногда выбор ОС диктуется не нами, а закупкой или политикой. Так что сравнение честное - не «какую купить», а «что учесть при работе с каждой».

Стенд и нагрузка

Две идентичные ВМ на одном гипервизоре: 8 vCPU, 32 ГБ RAM, NVMe-том. Одна - РЕД ОС 9.2 с минимальной установкой плюс docker и podman из штатного репозитория. Вторая - Astra Linux SE 2.15, тот же набор пакетов, Parsec в режиме enforcing.

Нагрузка состоит из трёх частей: запуск набора контейнерных сервисов через Compose, применение набора Ansible-плейбуков из нашей общей коллекции, и синтетический тест IO на NVMe с параллельными потоками. Ничего экзотического - это то, с чем мы работаем каждый день.

Контейнеры: разный стартовый уровень

РЕД ОС 9.2 обновила podman до актуального патча-релиза пятой ветки - то, что мы разбирали после 9.1 в февральском посте. Compose-манифесты запустились без изменений, crun работает штатно, rootless-режим ведёт себя предсказуемо. В 9.2 появилась более свежая версия buildah, что важно для тех, кто собирает образы прямо на серверах без отдельного CI.

У Astra Linux SE 2.15 ситуация другая. Docker здесь присутствует, но его взаимодействие с Parsec по-прежнему требует внимания. При запуске контейнера с bind-mount на каталог с ненулевым мандатным уровнем получаем AVC-отказ - поведение знакомое по 2.14, мы его касались в январском обзоре. В 2.15 добавили документированный механизм маппинга мандатных меток для контейнеров, что технически правильно, но настройка занимает время. Из восьми сервисов в нашем Compose-наборе шесть запустились без правок. Два потребовали явного задания контекста через переменные окружения и метки в юнит-файлах.

Для задач, где контейнеры работают без пересечения с мандатной иерархией - например, полностью изолированные сервисы без монтирований в защищённые каталоги - Astra Linux SE 2.15 работает нормально. Но как только появляется интеграция с файловой системой хоста и Parsec включён, нужно планировать время на настройку.

Ansible: где коллекции работают, а где нет

Мы гоняли один набор плейбуков из нашей коллекции для управления серверами: конфигурация sshd, управление пользователями, деплой systemd-юнитов, настройка logrotate и базовый hardening. Все плейбуки работают через community.general и ansible.posix без вендорских модулей.

На РЕД ОС 9.2 всё прошло без единой ошибки. Это RHEL-производная с предсказуемым расположением конфигурационных файлов и стандартным поведением systemd - Ansible с такими системами дружит давно.

На Astra Linux SE 2.15 плейбуки выполнились, но с нюансами. Задачи, работающие с файлами через copy и template, в нескольких случаях получили неожиданное поведение из-за Parsec: файл записывался, но с не той меткой, и последующий сервис его не видел. Проявляется это не ярко - задача завершается как changed, ошибок нет, а сервис потом не может прочитать конфиг. Диагностируется через pdp-ls на целевых файлах.

Решение - либо явно задавать метки через pdp-chml в отдельной задаче после copy/template, либо убедиться, что плейбук запускается в контексте с нужным уровнем. Второй вариант чище, но требует доработки плейбуков под конкретную Astra-среду. Для нашей общей коллекции мы добавили Astra-специфичные задачи в отдельный опциональный тег parsec_labels - применяем только там, где он нужен.

Несколько модулей из ansible.posix работали не совсем корректно с SELinux-контекстами на Astra - там собственная подсистема, и часть модулей, ориентированных на стандартный SELinux, читает типы контекстов иначе. Не блокирует, но надо держать в голове.

Поддержка железа: обновление ядра

РЕД ОС 9.2 поставляется с обновлённым ядром из 6.6 LTS, в котором закрыт ряд проблем с драйверами RAID-контроллеров и NVMe на новых чипсетах. На нашем тестовом стенде разница не была видна - железо стандартное. Но у одного из заказчиков с недавно поставленными серверами на Elbrus-compatible шине эта деталь принципиальна: на 9.1 у них были прерывистые таймауты IO, на 9.2 - нет.

Astra Linux SE 2.15 тоже обновила ядро - до 6.6 LTS, что выравнивает ситуацию с железом. Это закономерно: обе ОС сейчас идут на одном ядерном треке, и hardware-совместимость у них примерно одинакова. Исключение - драйверы, специфичные для конкретных российских производителей: здесь у каждого вендора своя история, и лучше проверять по конкретной модели, а не полагаться на общую логику.

Где что уместно

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

РЕД ОС 9.2 - дистрибутив, с которым стандартный серверный инструментарий работает без сюрпризов. Если вы управляете серверами через Ansible с обычными коллекциями, используете контейнеры в rootless-режиме, и вам не нужен мандатный контроль доступа - это предсказуемая, хорошо управляемая RHEL-подобная система.

Astra Linux SE 2.15 - правильный выбор там, где сертификация и мандатный контроль доступа не опция, а требование. Parsec работает, его можно настроить под контейнеры и Ansible - но это отдельная работа, которую нужно закладывать в оценку проекта. На объектах КИИ с требованиями ФСТЭК к классу защищённости выбор в пользу Astra часто не технический, а регуляторный.

Обе ОС получили в мае обновления, которые актуальны - свежее ядро, закрытые CVE, исправленные пакеты. Это хорошо. Но при выборе между ними стоит честно ответить на вопрос: есть ли у вас требование к мандатному контролю, или вы берёте Astra «на всякий случай»? Во втором случае дополнительная сложность не добавляет безопасности - только работы.