Собираем полигон для пилота — или тестовая среда для РЕД АДМ в песочнице

Привет, Хабр! На связи Евгений, ведущий инженер отдела технического сопровождения РЕД АДМ. Особое место в сердце любого инженера занимает пилотирование, когда всё, что может пойти не по плану, «вылезает» в тестовой среде: ошибки, баги и мрачное наследие древних цивилизаций, успевших обосноваться в недрах домена.

Чтобы техноересь не попала в прод, мы отлавливаем её в тестовой среде. И сегодня я расскажу вам, как собрать песочницу для проведения ритуалов очищения пилотирования РЕД АДМ Промышленной редакции.

Каков план?

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

Шагов шесть, но — дисклеймер — они широкие. Итак, погнали.

Шаг 1. Готовим инфраструктуру

Вот список ресурсов, который понадобится для тестирования РЕД АДМ Промышленная редакция 2.1.0:

Все серверные виртуальные машины ставятся на РЕД ОС 8.0 Сервер минимальный (без графики), за исключением клиентских станций. Доступ к локальному или интернет-репозиторию обязателен.

Собираем виртуальную машину в РЕД Виртуализации

Заходим в админку РЕД Виртуализации. Нам понадобится раздел Хранилище > Диски.

Сюда нужно загрузить ISO-образы основных действующих лиц: РЕД ОС 8.0, Windows Server нужных версий для поднятия копий-имитаций продовых сервисов, образ с драйверами и гостевыми дополнениями для операционных систем (чтобы они могли полноценно функционировать с виртуализацией. Не будем показывать пальцем, но в основном это нужно для ОС, начинающихся на Wi- и заканчивающихся на -ows).

Теперь создаём шаблон виртуальной машины для серверных ролей (это сэкономит время при массовом развёртывании). Ориентируйтесь на таблицу выше. Я буду часто ссылаться на эту таблицу в статье :)

И ещё несколько рекомендаций, которые могут пригодиться в процессе развёртывания:

Таблица имён и DNS. Чтобы упросить себе жизнь, составьте таблицу соответствия ролей, имён хостов и IP до создания виртуальных машин.

Объём дисков. Для репозитория потребуется как минимум 350 ГБ памяти. Если планируете хранить установочные образы операционной системы или большие файлы, то лучше расширить диск заранее.

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

Резервирование ресурсов. Стенд потребует приличного такого объёма RAM и дисков. Проверьте, что хосты виртуализации и хранилище выдержат пиковую нагрузку при одновременном запуске всех виртуалок во избежание экстерминатуса.

Шаг 2. Подготовка сетевого окружения

Как осознанный и порядочный сотрудник изолируем тестовый стенд от продового домена, иначе есть риск получить USN-rollback или конфликт SID на всю инфраструктуру.

Стенд можно назвать изолированным, если он имеет:

• Отдельный VLAN или выделенный сегмент сети

• Firewall-правила, разграничивающие доступ между стендом и продом

• Двустороннюю недоступность — как из стенда в прод, так и наоборот

• Интернет, проброшенный только через контролируемый шлюз с NAT и фильтрацией

Зафиксировали, пойдём теперь настраивать.

Настройка VLAN

Вот пример сетевой топологии стенда — можете сделать по аналогии:

Возвращаемся в РЕД Виртуализацию: раздел Сеть > Сети, жмём «Создать».

Создаём логические сети стенда. Первая будет называться sand-ВМ-network: в поле «Метка VLAN» указываем 200 и оставляем флаг «Сеть ВМ» — по этой сети будут ходить виртуальные машины.

Сетевые профили vNIC. Для каждой логической сети создаём профиль (Сеть > Профили vNIC > «Создать»). Именно профиль вы потом выберете в настройках сетевого адаптера виртуальной машины. Здесь же при необходимости ограничьте скорость через QoS, чтобы стенд не «съел» весь канал хоста.

Привязка к хостам. Идём в «Виртуализация» > «Хосты», открываем «Хост» > вкладка «Сетевые интерфейсы» > кнопка «Установка сетей узла» — и перетаскиваем созданные логические сети на физический интерфейс или bond, который смотрит в нужные VLAN. Повторяем для всех хостов кластера, где могут жить ВМ стенда. Если где-то сеть не привязана, ВМ останется без сети при миграции на этот хост.

Физические коммутаторы. Порты, к которым подключены хосты РЕД Виртуализации, переводим в режим trunk и разрешаем VLAN 100 (делается до запуска виртуализации), 200. Порту в сторону шлюза указываем trunk с VLAN 200 и 300.

Шлюз стенда — потребуется отдельная ВМ или сетевое оборудование. На нём поднимаем:

• Интерфейсы для VLAN 200 и VLAN 100/300 (внутренний и внешний соответственно).

• NAT из VLAN 200 во VLAN 100/300 — стенд получит доступ в интернет, а снаружи останется один адрес шлюза.

• Firewall: нужно запретить трафик из VLAN 200 в продовые сети и разрешить только DNS, NTP, локального репозитория и обновлений. Также надо выдать разрешение администраторам RDP/SSH из VLAN 100 во VLAN 200.

Необязательный пункт — перерыв на зарядку для глаз.

Обязательный пункт — проверка изоляции. Запускаем тестовую ВМ во VLAN 200 и пробуем достучаться до продовых адресов — должно быть недоступно. Обратите внимание что ICMP может быть закрыт и пинг не пройдёт, поэтому проверяем подключение к типовым продовым портам (443, 445, 636). Затем проверяем обратное направление: со стороны VLAN 300/прода инициируем соединение во VLAN 200 — должно быть отклонено. Затем проверяем доступ в интернет и к локальному репозиторию.

Если прод доступен, то этот стенд не изолирован. Возвращаемся в начало шага 2 и смотрим, где и что упустили.

Шаг 3. Клонирование продового домена

Эксперимент должен быть чистый, поэтому нам понадобится точный клон продового домена с теми же конфигурациями, версиями ПО, DNS-зонами, DHCP-диапазонами и идентичной структурой объектов с групповыми политиками. Есть несколько способов получить копию продового контроллера, и мы разберём все три.

Способ 1. Копирование виртуальной машины контроллера домена

1. Выключите ВМ контроллера домена.

2. Скопируйте файлы дисков ВМ на промежуточное хранилище.

3. Не включайте копию в продовой сети! Это может привести к конфликтам SID/IP и репликации.

4. Конвертируйте диски в qcow2 с помощью утилиты qemu-img:

qemu-img convert -f vmdk -O qcow2 prod-dc.vmdk sand-dc.qcow2

СОВЕТ: Укажите реальный формат исходного диска (vmdk, raw, vhdx)- он зависит от системы виртуализации, из которой копируется машина, и совпадает с форматом диска полученного в пункте 2 способа 1. При неверном формате команда не сработает.

Способ 2. Восстановление контроллера из резервной копии через WBAdmin

1. Создайте резервную копию на проде при помощи WBAdmin:

   wbadmin start backup -backupTarget:D: -include:C: -allCritical -quiet

2. Скопируйте файлы резервной копии на стенд. WBAdmin сохраняет данные в VHD (Windows Server 2012 и старше) или VHDX (2012 R2 и новее). Внутри папки бэкапа будут:

   — основной системный диск (обычно самый большой VHD/VHDX);

   — загрузочный / System Reserved-диск (для BIOS/UEFI);

   — EFI-раздел (для UEFI-систем).

3. Конвертируйте каждый диск отдельно, сохраняя порядок подключения:

   qemu-img convert -f vhd -O qcow2 backup-disk.vhd sand-ДК-system.qcow2
qemu-img convert -f vhdx -O qcow2 backup-disk.vhdx sand-ДК-system.qcow2

   Альтернатива: восстановите систему напрямую через Windows Recovery Environment. Этот процесс займёт больше времени, но зато не потребуется ручная конвертация + сохраните загрузочные записи в корректном виде.

Способ 3 (в лоб). Создать чистый тестовый домен

Если перенос продового домена невозможен или не требуется:

1. Создайте ВМ Windows Server 2016+ на стенде.

2. Поднимите роль AD DC с новым лесом и доменом (например, sand.corp).

3. Создайте OU, пользователей, группы и GPO по образу прода — вручную или через PowerShell DSC / Ansible.

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

Шаг 4. Поднятие клонированных машин и адаптация к стенду

Теперь нужно запустить копии виртуальных машин в нашей песочнице. На этом этапе всплывают неочевидные моменты: конфликты IP, зависимость от внешних сервисов, жёстко прописанные пути, сертификаты или лицензии, настройки безопасности, которые блокируют запуск на новом «железе». Морально готовимся к открытиям и надеемся на лучшее:

Запуск копии домена

Создайте ВМ из qcow2-образа в РЕД Виртуализации: Хранилище > Диски > Загрузить, затем прикрепите диск к новой ВМ.

Первый запуск делаем с отключённым или изолированным сетевым адаптером. VLAN защищает стенд от прода, но клонированная ВМ при первом запуске начнёт рассылать широковещательные запросы, искать партнёров репликации, пытаться обновить DNS и всячески буянить (об этом подробнее расскажу позже). Поэтому отключите адаптер, чтобы спокойно адаптировать копию до первого сетевого контакта.

Затем запустите ВМ и дождитесь загрузки Windows. Если система не загружается, проверьте настройку системной логики (Legacy/EFI), порядок загрузки и контроллер диска (IDE/SATA/VirtIO).

Адаптация копии

Пункт про экзистенциальное. Наша копия ничего не знает о том, что она — копия. И запустится она со всем набором параметров и содержимым каталога домена, который был в проде. Чтобы разрешить этот когнитивный диссонанс, нужно заняться адаптацией копии:

1. Зайдите в систему под доменным администратором.

2. Смените IP-адрес на адрес из диапазона стенда (берём из шага 1).

3. Проверьте роли FSMO и DNS командой:

   samba-tool fsmo show

   dcdiag /v

   Внимание — USN-rollback! AD использует внутренние счётчики изменений — USN. Каждый контроллер домена запоминает, какой USN он видел у партнёров по репликации. Если вы запустите копию работающего контроллера домена, у неё будут те же USN, что и у оригинала на момент снятия копии. Копия начнёт увеличивать эти номера дальше, и если она каким-то образом свяжется с другими контроллерами, они подумают, что уже видели эти изменения, и не заберут новые. База AD рассинхронизируется, репликация сломается, данные могут потеряться.

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

4. Удалите отсутствующие контроллеры домена в песочнице из оснасток Active Directory.

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

Если мы удалили все эти КД из оснасток, но есть попытки взаимодействия с ними, идём в оснастку «ADSI» и проверяем, не остались ли там записи об этих контроллерах.

Подключение к сети и проверка

1. Включите сетевой адаптер в сети sand-ВМ-network.

   

2. Проверьте, что ВМ видит другие машины стенда и не видит прод.

3. Настройте DNS-зону для домена sand.corp (или вашего тестового домена).

   Проверьте, что Name Servers в зоне, соответствует текущим ip адресам песочницы, а не продового домена. Удалить пересылки DNS запросов безусловные и для зон (оставляем только те, с которыми мы реально будем работать в песочнице)

4. Проверьте работоспособность: вход пользователей, разрешение имён в DNS, выдачу адресов по DHCP (если роль настроена), репликацию между контроллерами (если их несколько).

F5 - F8. Создаём точку отката на всякий случай

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

Что нужно зафиксировать:

• Конфигурации виртуальных машин (XML/OVF-описания в РЕД Виртуализации)

• Диски и системные разделы (qcow2-файлы, снапшоты)

• Базы данных (если развёрнуты СУБД на стенде)

• Настройки сетевого оборудования (конфиги коммутаторов, firewall-правила)

• Документацию по стенду (таблицы IP, пароли, схемы сети)

В правой руке — снапшоты

Перед каждым крупным или критическим изменением делаем снапшот ВМ: нужно открыть виртуальную машину > вкладка «Снимки» > «Создать». Подписывайте снапшоты понятно («до установки РЕД АДМ», «после настройки DNS») — будущий вы скажете спасибо.

В левой руке — бэкап

Также регулярно делаем полные резервные копии на отдельное хранилище, физически изолированное от стенда. В РЕД Виртуализации есть плагин для бэкапирования, находится во вкладке Дополнительно > Резервные копии. Сначала нужно добавить «Домен хранения» на соответствующей вкладке, указав имя, сетевой путь к NFS и параметры подключения (если необходимы).

После этого вы сможете выполнять бэкапирование как ручное (при нажатии кнопки Бэкап в быстрых действиях конкертной ВМ или по плану резервного копирования, который можно нужно задать в плагине «Резервное копирование» на вкладке Виртуальные машины: жмём «Создать план», задаем понятное имя, выбираем добавленный выше домен хранения и определяем частоту и время выполнения).

После этого мы сможем выполнять бэкапирование как ручное как при нажатии кнопки Бэкап в быстрых действиях конкертной ВМ, так и по плану резервного копирования, который можно (нужно) задать в плагине Резервное копирование на вкладке Виртуальные машины, жмём «Создать план»: задаём понятное имя, выбираем добавленный выше домен хранения и определяем частоту и время выполнения.

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

Шаг 5*. Задача со звёздочкой: добавляем смежные системы

Редкая инфраструктура состоит из одного-единственного домена. Наверняка ещё подключены почтовые серверы, SIEM, DLP, СУБД, облачные сервисы, системы аутентификации и единого входа, самописные биллинги и прочее. Если ваш пилот влияет на взаимодействие с этими системами, то их тоже нужно добавить на стенд.

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

• SIEM — забирает логи напрямую с ДК или через syslog-прокси?

• DLP — интегрируется с LDAP для получения списка пользователей?

• Система резервного копирования — использует доменную аутентификацию?

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

Чисто для удобства можно также зафиксировать какие порты, протоколы и учётные записи используются между РЕД АДМ и смежными системами. Можно нарисовать карту взаимодействий как блок-схему, собрать таблицу, даже сгодится обычный лист и шариковая ручка — что вам удобнее. Всё это очень пригодится при переносе в прод и при составлении firewall-правил.

Шаг 6*. Параллельное импортозамещение на примере Exchange

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

Что развернуть перед настройкой

• Exchange Server на ВМ с Windows Server из шага 1. Версию берём ту же, что в и проде, а имя используем новое, не как в проде. Установщик при развертывании увидит существующую организацию в копии продуктовых контроллеров и просто добавит в неё новый сервер.

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

• Тестовые почтовые ящики (по паре ящиков на каждом сервере). Продовые данные на стенд не берём.

• Клиенты: клиентская ВМ с Windows и Outlook (клиентская станция из таблицы ресурсов, шаг 1), браузер для веб-почты и, если есть возможность, мобильное устройство, подключённое к тестовому Wi-Fi стенда.

Порядок настройки параллельной работы и тесты

DNS. На контроллере домена стенда открываем оснастку DNS (dnsmgmt.msc) и создаём A-записи: mail.sand.corp > IP Exchange, mail-new.sand.corp > IP нового сервера. Позже сможете переключить MX-запись.

Маршрутизация почты. В Exchange идём в Центр администрирования Exchange (EAC) > «Поток обработки почты» > «Соединители отправки» и добавляем коннектор на mail-new.sand.corp. На новом сервере настраиваем ретрансляцию неизвестных ящиков обратно на Exchange — точные шаги смотрим в документации вендора. После этого проверяем доставку писем между серверами в обе стороны.

Тестовые ящики: на Exchange — user1@sand.corp, user2@sand.corp; на новом сервере — user1-new@sand.corp, user2-new@sand.corp.

Тестим базовые сценарии:

• отправка и получение внутри одного сервера;

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

• отсутствие дублирования и потерь;

• работа вложений, подписей, шифрования.

Клиенты:

• Outlook — настройте профиль, переключите на новый сервер, проверьте адресную книгу и календарь.

• Веб-почта — откройте оба интерфейса.

• Мобильные — подключите к тестовому Wi-Fi стенда.

Календари и задачи. Создайте встречи, пригласите пользователей с другого сервера. Проверьте отклики и напоминания.

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

И отработка отката. Возвращаем MX-запись на Exchange и проверяем, что почта снова идёт через старый сервер. Важно убедиться, что ящики остаются доступными.

Пара слов для тех, кто готов пробовать

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

Есть ли ещё что-то, что вам интересно было бы узнать об импортозамещении систем централизованного управления? Пишите в комменты, буду разбираться.