От ручных настроек к автоматизации, или как мы адаптировали Basis Dynamix под наши задачи

Хабр, привет! Меня зовут Роман Лагуткин, я руковожу командой виртуализации динамических платформ в «РТК-ЦОД». Мы отвечаем за эксплуатацию почти 3 тысяч физических серверов и более 30 тысяч виртуальных машин, в общем, приличных размеров инфраструктура со своими особенностями, накопленными за годы эксплуатации.

История, которую я хочу рассказать, началась несколько лет назад, когда перед нами была поставлена задача развернуть на наших площадках отечественную платформу виртуализации Basis Dynamix Enterprise. Закончилась же эта история внедрением качественно нового подхода к эксплуатации. Но обо всем по порядку.

Находим предел масштабирования ручных настроек

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

Началось все с того, что к списку наших ключевых платформ добавилась Basis Dynamix Enterprise. Цель пополнения — строить на ее основе масштабируемые виртуальные инфраструктуры, которые можно использовать в крупных инсталляциях, и при этом быть в тренде импортозамещения. С самого начала инсталляции Basis Dynamix развивались относительно независимо: у площадок появлялись свои параметры, версии ОС и локальные настройки. Но постепенно даже одинаково собранные кластеры расходились: на одной площадке менялась конфигурация ssh, на другой multipath, на третьей появлялось локальное исправление мониторинга и т.д. Поэтому решение, проверенное на одном кластере, уже нельзя было без дополнительной проверки перенести на другую площадку. А при наших масштабах виртуальной инфраструктуры любое расхождение в конфигурации влияет на скорость развёртывания, стабильность кластеров, количество инцидентов и возможности развивать инфраструктуру без пропорционального роста команды.

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

Выбираем единую конфигурацию как основу воспроизводимости

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

Мы решили пересмотреть сам подход к эксплуатации и перейти к модели Infrastructure as Code. В рамках этой модели конфигурация кластеров должна быть формализована в коде, храниться централизованно, версионироваться и проходить обязательную проверку перед применением. Однотипные узлы должны настраиваться одинаково, а допустимые различия между кластерами — задаваться в конфигурационных данных, а не возникать в результате ручных изменений.

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

Начинаем работу над конфигурацией

Первым шагом стал облегчённый установочный образ Astra Linux. Исходный образ объёмом около 10 Гбайт мы сократили примерно до 1 Гбайт, оставив только необходимые пакеты и функции. Во время загрузки образа автоматически определяются доступные диски и выбирается подходящий вариант: установка на один диск, аппаратный RAID или виртуальный MDRAID. После первого запуска сервер определяется по адресу IPMI или серийному номеру, а сетевые параметры берутся из заранее подготовленного описания площадки. Если сервер в конфигурации отсутствует, включается интерактивный режим и запрашиваются только минимально необходимые данные.

Отдельно стандартизировали репозитории. Вместо полного набора пакетов Astra Linux объёмом около 35 Гбайт сформировали компактный репозиторий APT примерно на 1,5 Гбайт с пакетами, необходимыми для Basis Dynamix Enterprise. Это ускорило доставку ПО и позволило зафиксировать согласованный набор версий системных пакетов и библиотек.

Для того, чтобы одинаковый код Ansible не зависел от версий Python и библиотек на разных площадках, подготовили контейнеризированную среду с фиксированной версией Ansible и всеми необходимыми зависимостями. Так окружение выполнения стало одинаковым, а риск несовместимости снизился.

Описание инфраструктуры формируется из стандартной конфигурации Basis Dynamix Enterprise и дополнительного файла YAML для конкретного кластера. В нём хранятся локальные учётные записи, настройки защиты и аудита, мониторинг, параметры сетевых интерфейсов и подключения СХД, а также настройки ssh, ntp, Docker, Kubernetes, iSCSI и multipath. На основе этих данных формируется динамический inventory, который описывает особенности площадки, а роли Ansible содержат общую логику настройки.

В результате у нас появились единый источник истины, контроль изменений и воспроизводимый процесс развёртывания.

Эффект от новой модели проще всего прочувствовать на цифрах:

• Полный цикл подготовки типовой площадки сократился примерно с недели до одного-двух дней.

• Установка ОС на один сервер теперь занимает около 10 минут вместо двух часов. Процесс можно запускать на нескольких серверах параллельно, поэтому группа узлов подготавливается примерно за 20 минут.

• Раньше развёртывание и настройка управляющего кластера Kubernetes занимали весь день, теперь — от одного до трёх часов.

• Обновление сертификатов Kubernetes теперь занимает менее пяти минут вместо трёх-четырёх часов.

• Доля ошибок при первоначальной настройке, которая раньше могла доходить до 15%, стала практически нулевой.

Автоматизируем повседневные процессы эксплуатации

После подготовки конфигурационного файла system config первичная инсталляция Basis Dynamix Enterprise выполняется как единый управляемый процесс. IaC довольно быстро перестал быть исключительно инструментом пусконаладочных работ, теперь он неотъемлемая часть повседневных процессов эксплуатации.

Особое внимание мы уделили операциям с СХД, ведь любая ошибка при отключении пула, путей или сессии iSCSI может привести к потере доступа виртуальных машин к данным. У Basis Dynamix Enterprise есть механизмы мониторинга состояния путей и самозащиты от деструктивных операций, перед критическими действиями система автоматически проверяет состояние инфраструктуры и наличие фоновых процессов. При обслуживании SAN одновременно контролируем идентификаторы IQN и WWN, состояние multipath, блочные устройства и активные сессии iSCSI. По результатам проверки определяем, можно ли безопасно удалить пул или отключить СХД.

Что это дало? Скорость — например, удаление пула теперь выполняется примерно в пять раз быстрее — и снижение тех самых операционных рисков, о которых я упомянул выше. Мы также автоматизировали восстановление дисков после их некорректного удаления с портала платформы и повторный ввод сервера в платформу после переустановки ОС. В последнем случае время восстановления сократилось с двух–трех часов до 15 минут, что позволило значительно быстрее возвращать узел в рабочее состояние.

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

Оцениваем состояние инфраструктуры за минуту

IaC описывает, как должна быть настроена площадка. Однако для эксплуатации не менее важно быстро понимать её реальное состояние. Совместно с «Базисом» мы разработали диагностический инструмент, который за один запуск собирает целостную картину инфраструктуры: проверяет модели серверов, процессорные ресурсы и память, локальные диски, ошибки портала, Open vSwitch, MTU, пропускную способность сетей, состояние СХД, подключения iSCSI и multipath, а также управляющий кластер Kubernetes.

Сейчас инструмент выполняет 27 ключевых проверок и формирует общую картину состояния инфраструктуры менее чем за минуту. Благодаря этому мы сразу получаем необходимые данные и можем переходить к локализации проблемы без дополнительного ручного сбора информации. Время реакции на неисправность удалось сократить примерно с двух часов до 30 минут.

Еще один отдельный инструмент мы создали для инвентаризации. Он собирает сведения о виртуальных машинах, дисках, образах, сетях, системах хранения, аккаунтах, адресах IP, VLAN и лимитах IOPS. Итоговый отчет выгружается в Excel с фильтрами, подсветкой и даже отдельными листами для разных подразделений эксплуатации.

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

CLI как один ответ на несколько вопросов

Для повседневного администрирования мы разработали собственный интерфейс командной строки на Go. С его помощью мы управляем сущностями Basis Dynamix прямо с управляющих узлов и без постоянного переключения между браузером, Swagger’ом и консолью.

CLI вообще дал нам массу возможностей: мы получаем состояние объектов, создаем и настраиваем виртуальные машины, работаем с узлами управления и вычисления, выполняем миграции, получаем результаты Health Checks и формируем последовательности операций для дальнейшей интеграции с Ansible. Уже реализовано 84 команды, проведено более 55 тестовых сессий, а время выполнения рутинных задач в среднем сократилось наполовину. Например, создание виртуальной машины занимает несколько десятков секунд, а перезапуск виртуального VNF в одном из типовых сценариев — несколько секунд.

CLI не просто повторяет отдельные методы API: он объединяет несколько запросов в одну управляемую операцию и позволяет выполнять массовые действия с контролем параллелизма.

Работаем над ошибками

Параллельно с автоматизацией мы формировали набор собственных исправлений для используемых версий Basis Dynamix Enterprise: устранили проблемы, вызывавшие ложные срабатывания Zabbix, ошибки в вычислительных и сетевых компонентах, а также недостатки операций с пулами хранения. Важной частью работы стало взаимодействие с разработчиками Basis Dynamix Enterprise. Мы передали им на анализ наши исправления и предложения по развитию платформы, а также сложные дефекты, найденные в ходе эксплуатации.

Всего удалось закрыть 16 регулярно проявлявшихся проблем. По нашим внутренним наблюдениям, среднее время стабильной работы кластеров выросло примерно на 50%, а количество обращений по известным ошибкам сократилось с 25 до одного. Время презентации пула хранения уменьшилось с двух-трёх часов до 5-10 минут.

Совместными усилиями с «Базисом» мы доработали резервное копирование управляющего кластера: формируется резервная копия, создаётся архив, который передаётся во внешнюю систему хранения и отправляет результат выполнения в мониторинг. Цель в том, чтобы иметь понятный механизм полного восстановления управляющей инфраструктуры с нуля. IaC заново формирует конфигурацию узлов, а резервная копия сохраняет данные и состояние компонентов, которые невозможно восстановить только из git’а.

Также мы серьёзно переработали мониторинг состояния платформы. Исключили неиспользуемые триггеры, объединили дублирующие проверки и добавили метрики, которые отражают действительно важные эксплуатационные состояния управляющего кластера и платформы виртуализации. Всего команда разработала около 50 значимых триггеров для кластеров Kubernetes, путей и портов СХД, неактивных сессий iSCSI, multipath, виртуальных сетевых интерфейсов, свободных IP-адресов и признаков перегрузки ресурсов. По внутренней оценке, эффективность мониторинга выросла примерно на 30%.

Статистика показывает, что нам удаётся своими силами устранить около 99% инцидентов. А обратную связь по нетиповым случаям отправляем «Базису», коллеги учитывают её при работе над следующими версиями.

Находим границы автоматизации

Централизованная автоматизация снижает количество ручных ошибок, однако создаёт риски другого рода — одна неверная правка потенциально может затронуть сразу много серверов. Поэтому у нас весь код хранится в git’е, а изменения проходят через merge request и проверку тимлидов. Чувствительные данные в открытом виде не храним. Пароли доступа к СХД шифруются, пользовательские пароли хэшируются, а алгоритмы выбираются применительно к конкретной ОС. Различия между площадками хранятся в inventory, а не в отдельных копиях ролей. Это позволяет сохранять единую кодовую базу и не допускать постепенного расхождения сценариев.

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

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

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

Подводим итоги

Что дало команде внедрение IaC?

• Воспроизводимую модель платформы.

• Высвобождение ресурсов для поддержки новых инфраструктур.

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

• Типовая площадка разворачивается за один-два дня, диагностика и сбор инвентарных данных занимают несколько минут.

• Эксплуатационный опыт хранится не только в документации и памяти отдельных сотрудников, но и в git’e.

Это позволяет проверять накопленные знания на корректность и делает их доступными для всей команды. 

И несколько выводов.

Первое, не затевайте переход к IaC с выбора инструмента. Ansible, Python, Bash или Go сами по себе не устраняют конфигурационный дрейф. Определите для начала целевое состояние платформы, согласуйте допустимые различия между площадками и выберите единый источник истины.

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

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

Что дальше?

Для нас переход к Infrastructure as Code начинался с простой задачи — перестать вручную перепечатывать команды из инструкций. В итоге мы коренным образом пересмотрели подход к эксплуатации инфраструктуры и внедрили новый. Теперь площадка под управлением Basis Dynamix Enterprise в «РТК-ЦОД» — это не только серверы, сеть, системы хранения и установленная платформа. Это ещё и версия кода, которая описывает, как все эти компоненты должны быть настроены и работать вместе.

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