В предыдущей части кейса мы рассказали о внедрении Службы каталогов Dynamic Directory – отечественного аналога Active Directory, который позволил заменить MS AD и решить задачи централизованного управления учетными записями и политиками. Однако для зрелой распределенной инфраструктуры этого недостаточно: необходим инструмент централизованного управления жизненным циклом рабочих станций и серверов – тот самый функционал, который в Windows‑мире обеспечивают Microsoft System Center Configuration Manager (SCCM) и Windows Server Update Services (WSUS). В этой статье речь пойдет о том, как мы в рамках пилота внедрили платформу РОСА Центр управления (РОСА ЦУ) и с ее помощью заменили WSUS и SCCM в инфраструктуре заказчика.

Напомним, инфраструктура компании‑заказчика очень разноплановая: более 10 000 автоматизированных рабочих мест (АРМ) в пяти регионах – от Москвы до Новосибирска – под управлением самых разных ОС: Astra Linux, RED OS, РОСА Хром, а также Windows 7/10. Серверная часть тоже гетерогенна (Windows Server, RHEL, виртуализация на VMware vSphere и Hyper‑V), да и сеть филиалов неоднородна по качеству каналов связи. После успешного пилота по замене AD возник логичный вопрос: как столь разношерстным хозяйством эффективно управлять из единого центра, отказавшись от иностранных инструментов? Ниже опишем требования к системе управления, наш подход к ее реализации и результаты, которые в итоге получил заказчик.

Требования к системе централизованного управления

Перед началом работ мы совместно с ИТ‑службой заказчика сформулировали ключевые требования к будущей системе оркестрации и управления конфигурациями. Она должна была обеспечить:

Кроссплатформенность. Поддержка разных операционных систем на рабочих местах и серверах. В филиалах использовались разные отечественные дистрибутивы Linux (Astra, RED, РОСА) и сохранялась часть узлов на Windows, поэтому инструмент должен одинаково эффективно работать во всех этих средах.

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

Совместимость с сервисом каталогов. Поскольку ранее была внедрена служба каталогов с механизмом групповых политик (аналог GPO), новая система не должна с ними конфликтовать. Политики, применяемые через каталог (Dynamic Directory), и политики/скрипты системы оркестрации должны дополнять друг друга, не «борясь» за узлы.

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

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

Модель с агентом (pull‑модель). Для управления рабочими станциями предпочтителен подход, при котором сами узлы периодически запрашивают задачи и политики с сервера (pull), а не получают команды напрямую (push). Это повышает надежность в условиях спящих/мобильных АРМ и экономит трафик. Тем не менее, хотели сохранить возможность использования и push‑подхода для отдельных задач.

Совместимость с существующими практиками администрирования. У заказчика уже были наработки по автоматизации управления серверами (например, плейбуки Ansible). Новая система должна была вписаться в эту экосистему, позволяя при необходимости использовать и сторонние инструменты (например, запускать роли Ansible на узлах наряду с модулями Puppet).

Управление установкой и миграцией ОС. Поскольку стояла цель перейти с Windows на отечественные ОС, система должна уметь развертывать новые операционные системы «с нуля» (в том числе удаленно по сети) и автоматизировать миграцию пользовательских данных и настроек с Windows на Linux.

Управление настройками и ПО узлов. Требовалось централизованно управлять любыми аспектами конфигурации конечных ОС: устанавливать необходимое ПО (и удалять лишнее), настраивать это ПО и системные параметры, применять необходимые политики безопасности (например, отключение устройств, паролей и пр.).

Управление репозиториями пакетов. Актуализация софта на рабочих местах должна осуществляться централизованно. Желательно иметь собственный репозиторий обновлений для каждой используемой ОС (аналоги WSUS для Windows и репозиториев для Linux), чтобы не зависеть от внешних источников и контролировать, какие обновления когда устанавливаются.

Интеграция с мониторингом и журналированием. Одно из требований — единое окно мониторинга и логирования по всей инфраструктуре. То есть новая система должна отображать данные корпоративного мониторинга (например, Zabbix) и обеспечивать сбор/просмотр логов изменений на узлах (например, на базе OpenSearch). По возможности все это — из того же интерфейса управления.

Гибкая ролевая модель доступа. У заказчика несколько групп администраторов: локальные ИТ‑специалисты в филиалах (они должны администрировать свои узлы), центральная служба ИБ (нужен доступ для контроля и применения политик безопасности) и служба техподдержки (с ограниченным доступом для выполнения рутинных задач). Система должна поддерживать разграничение прав по ролям и областям управления.

Приемлемая стоимость владения. Лицензирование и общие затраты на решение должны вписаться в бюджет. Здесь мы учитывали как прямую стоимость лицензий, так и косвенные вещи: использование открытого ПО, наличие отечественных сертификатов (реестр Минцифры, ФСТЭК), техническую поддержку и др. Грубо говоря, заказчику нужна была максимальная функциональность, но без «ценника», как у зарубежных продуктов.

Необходимо отметить, что на российском рынке не так много решений, удовлетворяющих сразу всем перечисленным требованиям. По результатам анализа было принято решение в качестве основы для пилотного внедрения выбрать платформу РОСА Центр управления. Эта система изначально создавалась как замена WSUS/SCCM на базе отечественных разработок и open source‑технологий – именно она в полной мере закрывала требования заказчика. Ниже рассмотрим архитектуру и технологии РОСА ЦУ и расскажем о нашем опыте ее внедрения.

Используемые технологии РОСА ЦУ

РОСА Центр управления – это платформа, объединяющая несколько проверенных временем технологий с единым веб‑интерфейсом. В ее основе лежит известная open‑source система Foreman с плагином Katello, которые отвечают за управление конфигурациями и пакетами. По сути, РОСА ЦУ включает в себя функциональность, аналогичную Red Hat Satellite: управление хостами (через Puppet‑агенты или Ansible), оркестрацию развертывания новых систем, а также контент‑менеджмент для репозиториев (обновления, ПО) с возможностью их версионного контроля (Lifecycle Environment, Content View и др., как в Katello).

Для обеспечения непрерывной работы агентов на конечных узлах мы используем Puppet – на каждом управляемом сервере или рабочей станции установлен puppet‑агент, который регулярно обращается на сервер за инструкциями (политиками). Puppet обеспечивает декларативное описание состояния узла (какие пакеты должны быть установлены, какие конфиги и сервисы активны и др.) и автоматическое приведение системы к заданному состоянию. Это позволяет гарантировать единообразие конфигураций и снизить влияние человеческого фактора. При этом, как отмечалось, РОСА ЦУ допускает и использование Ansible – например, для одноразового применения playbook по требованию. В нашей реализации мы интегрировали существующие сценарии заказчика в общий процесс (Foreman умеет запускать Ansible‑роли наряду с Puppet‑манифестами).

Важной частью платформы является система управления обновлениями и репозиториями. Katello (в составе Foreman) отвечает за синхронизацию пакетов из внешних источников, хранение их в локальных репозиториях и раздачу на клиенты. Можно гибко контролировать, какие обновления и когда попадают на конкретные группы машин с помощью версионирования контента (аналог «кольцевого» развертывания: сначала протестировать, потом в продакшн). Благодаря Katello РОСА ЦУ фактически заменяет WSUS для Linux‑узлов, а при должной доработке может выполнять роль и сервера обновлений для Windows (хотя изначально упор делался на миграцию Windows → Linux, о чем ниже).

Дополнительно платформа включает инструменты мониторинга и логирования. Мы интегрировали Zabbix для мониторинга состояния узлов (доступность, загрузка, ключевые метрики) с построением дашбордов в Grafana – в интерфейсе РОСА ЦУ администратор может видеть актуальный статус всех систем практически в режиме реального времени. Для журналирования событий и изменений используется стек OpenSearch (форк Elasticsearch) – логи с узлов и самих серверов управления централизованно собираются и доступны для поиска и анализа через web‑интерфейс Центра управления (например, можно быстро найти, когда и на какой машине применилось то или иное изменение конфигурации). Интеграцию с OpenSearch мы уже обкатывали на службе каталогов (в первой части пилота логи контроллеров домена отправлялись в единый центр), здесь же подобный принцип распространили и на журналы управления конфигурациями.

Наконец, РОСА ЦУ обладает собственной ролевой моделью. Foreman изначально поддерживает разграничение доступа на основе ролей, мы же связали это с оргструктурой заказчика. Администраторы филиалов в системе видят только «свои» узлы (например, через разделение по организациям/локациям), сотрудники службы ИБ получают права только на чтение логов и применение отдельных политик безопасности и др. Аутентификация пользователей при этом интегрирована с нашим Dynamic Directory, поэтому единый аккаунт администратора в домене может быть использован и для входа в Центр управления (не нужно заводить отдельные учетные записи).

Стоит добавить, что использование в основе открытого ПО не означает отказа от поддержки или безопасности – платформа использует лучшие практики разработки ПО. Заказчик получает решение «под ключ», эквивалентное по функциональности зарубежным, но при этом независимое от западных вендоров и с полноценной 24/7 поддержкой от НТЦ ИТ РОСА.

Архитектура пилотного развертывания

При проектировании решения особое внимание мы уделили распределенной архитектуре, чтобы обеспечить и кроссплатформенность, и отказоустойчивость на уровне площадок. РОСА Центр управления был развернут в виде одного главного сервера и нескольких подчиненных (в каждом крупном филиале). Главный сервер РОСА ЦУ установлен в центральном ЦОД и отвечает за координацию всей системы (единую базу данных конфигураций, веб‑интерфейс, централизованное хранилище контента, сертификационный центр и др.). В филиалах (на территориальных площадках) установлены подчиненные серверы ЦУ – их задача непосредственно обслуживать конечные узлы на местах: они выступают локальными Puppet‑серверами для своих АРМ, кешируют репозитории пакетов и могут выполнять роль PXE‑серверов для установки ОС. Главный и подчиненные серверы связаны между собой и синхронизируются (конфигурации, пакеты и др.), но при этом подчиненные способны работать автономно, если связь с главным прервана.

Помимо серверов ЦУ, инфраструктура включает несколько вспомогательных узлов. Во‑первых, это сервер репозиториев в каждом ЦОД – локальное хранилище всех необходимых пакетов и обновлений для соответствующих ОС. В центральном узле репозиторный сервер синхронизируется с внешними источниками (репозитории Linux‑дистрибутивов, KB‑файлы обновлений и др.), а филиальные реплики уже берут контент с центрального, минимизируя нагрузку на межфилиальные каналы. Во‑вторых, выделены серверы медиаисточников (один на центральной площадке и по одному в филиалах) – по сути, это серверы, хранящие образы установочных ISO и раздающие загрузочные образы по сети. Они нужны для автоматической установки ОС на голое железо. Например, в пилоте 10 тестовых машин с ОС РОСА Хром были успешно установлены по сети силами Центра управления.

Отдельно отмечу компонент, отвечающий за миграцию рабочих станций. Мы развернули сервер миграции – специализированный узел (в каждом филиале), на котором выполняются скрипты переноса пользовательских данных. Алгоритм миграции выглядел так: агент на Windows‑станции автоматически собирает данные пользователя (профиль, документы, необходимые настройки) и отправляет их на сервер миграции; затем через интерфейс РОСА ЦУ администратор инициирует переустановку ПК – машина перезагружается и получает по PXE установочный образ отечественной ОС (Астра, РЕД или РОСА); после развертывания новой ОС на ней автоматически устанавливается необходимый набор приложений и настроек ОС (например, ввод АРМ в домен, установка СПО); напоследок агент миграции восстанавливает сохраненные пользовательские данные обратно на ПК. В результате переход с Windows на Linux для конечного пользователя проходит максимально прозрачно – все его файлы и даже личные настройки сохраняются, просто вместо Windows он получает обновленное рабочее место на защищенной отечественной системе. В рамках пилота мы доработали ряд модулей Puppet, реализующих миграцию, под особенности инфраструктуры заказчика – например, добавили перенос некоторых специфичных профилей и учетных данных, использовавшихся в его среде.

Архитектура решения представлена на схеме ниже (условно, без привязки к конкретным адресам). Главный сервер РОСА ЦУ находится в основном дата‑центре. В каждом филиале – локальный (подчиненный) сервер ЦУ, свой репозиторий, PXE‑сервер и сервер миграции. Все ПК в филиале настроены в первую очередь обращаться к своему локальному серверу; если же он временно недоступен, агент автоматически переключится на резервный сервер – либо главный ЦУ, либо соседний филиал (ближайший доступный). Такая многоуровневая схема обеспечила высокую живучесть системы управления: даже при сбоях в одном из ЦОДов остальные филиалы продолжат нормально функционировать, а «осиротевшие» узлы переподключатся к доступным серверам.

Еще один важный момент внедрения – совместное использование групповых политик (GPO) и Puppet‑конфигураций. На этапе пилота у заказчика уже действовали групповые политики Dynamic Directory для управления некоторыми настройками Windows‑станций и импортозамещенных АРМ (например, запрет съемных носителей, прокси и пр. применялись через каталог). Мы тщательно проанализировали возможные конфликтующие области между GPO и Puppet и развели их по сферам ответственности. Так, политики безопасности пользователей и компьютеров (блокировки устройств, сложность паролей, сетевые политики и прочее) остались на стороне Dynamic Directory – агент dd‑client применяет их на хостах. А вот такие задачи, как установка программного обеспечения, обновление пакетов, управление сервисами ОС, настройка параметров, не охваченных GPO, – возложены на механизмы Центра управления (Puppet). Такой подход позволил избежать управления одним и тем же объектом из ЦУ и DD. Например, если через GPO запрещены USB‑порты, Puppet‑модуль не будет менять эту настройку, и наоборот – Puppet может, скажем, настраивать файрвол или VPN‑клиент, чего нет в GPO. В итоге Dynamic Directory и РОСА ЦУ работают в тандеме, каждый по своему направлению.

Что в итоге получил заказчик

Внедрение связки Dynamic Directory + РОСА Центр управления позволило заказчику полностью заменить иностранные системы (AD, WSUS, SCCM) на отечественные решения и получить целый ряд преимуществ:

Единая система установки и миграции ОС. Теперь ИТ‑отдел может удаленно устанавливать операционные системы на сотни рабочих станций «с нуля» (по сети, автоматически) и так же массово мигрировать существующие Windows‑АРМ на Linux. Переход проходит быстро и централизованно – пользовательские данные переносятся автоматически, нужный софт сразу разворачивается на новом рабочем месте.

Универсальное управление узлами независимо от ОС. Через единый веб‑интерфейс администраторы управляют всеми рабочими станциями и серверами – будь то Windows или любой дистрибутив Linux. Отпала необходимость держать разрозненные инструменты под каждую платформу. Все узлы «видны» в одном центре и доступны для операций (инвентаризация, обновление, изменение конфигурации и др.).

Прозрачность и контроль состояния каждого узла. Благодаря агентам на АРМ и интеграции с мониторингом ответственная команда в любой момент времени знает, что происходит на каждой машине. Видно, какие пакеты установлены, какие обновления применены, нет ли отклонений от целевой конфигурации, все ли сервисы работают корректно. Это значительно облегчает поддержку: практически исчез «звонковый» принцип, когда о проблеме узнают только от пользователя, – теперь про сбой или отклонение система сигнализирует сама (алертами Zabbix/Grafana).

Стандартизация пользовательских окружений. С введением централизованного управления компания навела порядок в конфигурациях рабочих мест. Были определены типовые профили для групп пользователей – например, «Бухгалтерия», «Разработчики», «Отдел ИБ», «Департамент X». Для каждой группы задается набор ПО, системных параметров и политик. После добавления машины (или пользователя) в определенную группу автоматически применяются все требуемые настройки, характерные для этой роли. Такой подход избавил от ситуации, когда на двух однотипных ПК обнаруживаются разные настройки или версии ПО. Теперь «как положено» конфигурируется и поддерживается любой из 10 000+ узлов. Администрировать тысячу одинаковых систем намного проще, чем десяток разнонастроенных.

Оперативное реагирование на инциденты ИБ. Интеграция с централизованным журналированием и единообразие настроек позволили существенно сократить время реакции на угрозы. Например, при получении бюллетеня безопасности о наличии уязвимости в каком‑либо пакете (от регулятора или ГосСОПКА) администраторы могут быстро получить сведения о том, присутствует ли такой пакет в системе, и, если да, сформировать управляющее воздействие (удаление/обновление) через РОСА ЦУ и распространить его на нужные узлы (при этом контролируя, на каких машинах уже применено). Или другой пример: вышло предписание отключить какое‑то ПО на всех станциях – через Центр управления эта политика распространяется повсеместно в считанные часы. Все это существенно повышает уровень безопасности и соответствия нормативным требованиям.

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

Гибкость обновления ПО и снижение нагрузки на сеть. Заказчик получил удобный механизм управляемого обновления программного обеспечения. Обновления ОС и приложений можно раскатывать волнообразно: сперва на тестовую группу машин, затем поэтапно на остальные. Например, критичные серверы получают патчи только после отработки на тестовом стенде. Рабочие станции можно обновлять партиями, избегая скачков нагрузки на сеть и сервисы. Инструмент позволяет задать расписание установки, учесть рабочее время пользователей и другие нюансы. В итоге процесс обновления стал предсказуемым и управляемым, что тоже повышает стабильность работы бизнеса.

Оптимизация затрат и лицензирования. Переход на отечественные решения позитивно сказался на бюджете. Во‑первых, исчезли расходы на лицензии Windows Server CAL, SCCM и прочие иностранные продукты (РОСА ЦУ лицензируется по серверному принципу, заметно дешевле в пересчете на 10 000+ узлов). Во‑вторых, уменьшились операционные затраты: с централизованным управлением ИТ‑специалисты тратят меньше времени на рутинные настройки, их продуктивность выросла (по оценкам – на 30%). В‑третьих, наличие официальной поддержки НТЦ ИТ РОСА снижает риски и издержки при проверках, интеграции в реестр ПО и др. Таким образом, решение получилось не только технически эффективным, но и экономически обоснованным.

По завершении пилотного проекта было принято решение о масштабировании системы на всю организацию. Заказчик перевел проект в промышленную эксплуатацию: начато полномасштабное развертывание Dynamic Directory и РОСА Центр управления. Планируется миграция более 3 000 рабочих станций на отечественные ОС в текущем году и еще ~7 000 – в следующем, с поэтапным отказом от оставшихся серверов MS AD, WSUS и SCCM. Фактически компания выстраивает новый ИТ‑ландшафт, полностью основанный на российских решениях. Наш пилот доказал, что отечественные продукты могут бесперебойно координировать и эффективно управлять даже очень большой и распределенной инфраструктурой, не уступая по функциональности привычным иностранным системам.