Новости

Миграция АЛРОСА на Astra Linux: что заложить в серверы для ALD Pro

Дмитрий Потоцкий 1 мин чтения
Миграция АЛРОСА на Astra Linux: что заложить в серверы для ALD Pro

АЛРОСА развернула ALD Pro в Москве, Новосибирске и Мирном, подготовила около 100 групповых политик и разделила миграцию пользователей на три волны. Рабочие станции компания планирует перевести до конца 2027 года. Но для ИТ-руководителя здесь важна не марка оборудования: кейс показывает, что серверную платформу нужно считать после проверки приложений и проектирования службы каталога, а не до них.

Если ты готовишь закупку под Astra Linux и ALD Pro, сначала зафиксируй площадки, схему резервирования и совместимость оборудования. Только потом выбирай процессоры, память и поставщика. Иначе серверы приедут раньше, чем станет понятно, можно ли на них собрать рабочий контур.

АЛРОСА сначала проверила ПО, затем начала перевод пользователей

До массовой миграции АЛРОСА спроектировала инфраструктуру всей компании, проверила совместимость прикладного ПО с Astra Linux и составила план перехода. Параллельно компания развернула ALD Pro на трёх площадках и настроила централизованное управление компьютерами, пользователями и групповыми политиками. Интеграция со смежными системами ещё продолжается — это следует из сообщения «Группы Астра» от 8 сентября 2026 года.

Перенос компьютеров между рабочими зонами

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

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

ALD Pro нужно считать как отдельную нагрузку

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

Руководство по установке контроллера домена ALD Pro задаёт минимум для одного экземпляра: 8 ядер процессора, 16 ГБ оперативной памяти и SSD на 50 ГБ. Тот же документ описывает установку резервного контроллера. Это нижняя граница запуска, а не конфигурация промышленной системы под известное число пользователей.

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

Для двух площадок нижняя граница — четыре контроллера

Возьмём компанию с двумя площадками. На каждой нужен основной и резервный контроллер: всего четыре экземпляра. Это наше проектное допущение; АЛРОСА свою серверную конфигурацию не раскрывала.

Минимальный резерв ресурсов считается напрямую:

  • процессор: 4 × 8 = 32 ядра;
  • память: 4 × 16 = 64 ГБ;
  • SSD: 4 × 50 = 200 ГБ.

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

Для одной площадки с двумя контроллерами нижняя граница составит 16 ядер, 32 ГБ памяти и 100 ГБ SSD. Для трёх площадок при той же схеме — шесть контроллеров, 48 ядер, 96 ГБ и 300 ГБ SSD.

Число пользователей в этом расчёте не меняет минимум отдельного контроллера. Оно влияет на итоговую конфигурацию после нагрузочного испытания: тогда появятся данные о загрузке процессора, памяти, каталога и сети. До испытания в закупочном документе нужно прямо назвать 8 ядер, 16 ГБ и 50 ГБ нижней границей, а не обещанной мощностью.

Отказ одного хоста меняет расчёт вдвое

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

В штатном режиме каждый хост держит по два контроллера: 16 вычислительных ядер и 32 ГБ памяти. После отказа соседа оставшийся узел должен принять все четыре. Значит, на каждом хосте нужно оставить под ALD Pro не меньше 32 ядер и 64 ГБ памяти сверх ресурсов, занятых другими ВМ.

С дисками действует та же логика. Четырём контроллерам нужны минимум 200 ГБ полезной ёмкости. Удваиваем её до 400 ГБ под обновления, журналы и временные снимки — это наше допущение для закупки, а не требование разработчика. Поэтому на каждом хосте закладываем зеркальный массив SSD с полезной ёмкостью от 400 ГБ.

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

Совместимость отсекает платформы раньше характеристик

АЛРОСА проверила прикладное ПО до массового перехода. При выборе железа стоит применить тот же порядок: сначала подтвердить поддержку Astra Linux 1.8, затем сравнивать серверы.

В перечень проверки входят дисковый и сетевой контроллеры, гипервизор, средство резервного копирования и удалённое управление сервером. Подтверждение нужно получить для конкретной модели и аппаратной ревизии. Фраза поставщика «работает с Linux» ничего не говорит о нужной версии ОС, драйверах и процедуре восстановления.

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

Спецификация под задачу

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

Компонент одного хостаЧто заложитьПочему столько
ПроцессорОт 32 физических ядерЧетыре контроллера по 8 ядер после отказа второго хоста
Память128 ГБ ECC RDIMM64 ГБ под четыре контроллера, ещё 64 ГБ — запас под ОС хоста, рост и результаты испытаний
ХранилищеДва SSD в RAID1, от 400 ГБ полезной ёмкостиМинимум четырёх контроллеров — 200 ГБ; ещё 200 ГБ закладываем под журналы, обновления и снимки
СетьДва независимых порта, по одному на каждый коммутаторОдин порт или один коммутатор оставит общую точку отказа; скорость сверяем с сетью площадки
ПитаниеДва блока горячей замены, каждый держит полную нагрузку хостаОтказ одного блока не выключит все контроллеры площадки
КорпусСтоечный 1U или 2U под глубину существующей стойкиФорм-фактор не влияет на ALD Pro, но должен подходить к площадке и охлаждению
Запас на расширениеНе меньше двух свободных слотов памяти и одного PCIeПамять или сетевой адаптер можно добавить без замены платформы

128 ГБ памяти — расчётный выбор, а не минимум ALD Pro. Если испытание покажет, что четыре контроллера вместе занимают больше 64 ГБ, увеличивай память так, чтобы после отказа второго хоста оставалось не меньше 25% свободного объёма.

Эта конфигурация дороже пары ВМ, которым выдали ровно по минимуму. Доплата покупает возможность пережить отказ физического узла. Если такой сценарий бизнес допускает, можно оставить по 16 ядер и 32 ГБ памяти на хост, но тогда резервный контроллер защищает только от сбоя отдельной ВМ, а не от потери сервера или площадки.

Что зафиксировать в закупочных требованиях

Новость АЛРОСА не даёт основания покупать конкретную марку сервера. Она задаёт порядок решения: приложения и площадки, затем топология ALD Pro, ресурсы, резервирование и поставщик.

Перед выпуском закупочного задания проверь пять пунктов:

  • число площадок и контроллеров указано явно;
  • минимум 8 ядер, 16 ГБ памяти и 50 ГБ SSD записан для каждого контроллера;
  • отказ хоста учтён в ресурсах оставшегося узла;
  • поддержка Astra Linux 1.8 подтверждена для конкретных контроллеров и гипервизора;
  • типовые и специализированные приложения проходят разные этапы испытаний.

Если этих данных ещё нет, рано выбирать модель сервера. Но уже можно закрепить архитектуру и нижнюю границу ресурсов — так закупка не опередит миграцию.