Как приручить виртуальные машины
…и попутно воспитать сотрудников
«Чисто не там, где убирают, а там где не гадят» © Некий автор.
Всем привет! Хочу поделиться опытом борьбы с большим «зоопарком» гипервизоров и виртуальных машин (далее — ВМ), а точнее историей по созданию внутреннего сервиса по контролю за виртуальными машинами, благодаря которому нам в IT стало сильно проще работать с нашим зоопарком, а сотрудники стали присылать информацию по удалению неактуальных ВМ.
Начал было с длинной предыстории, как у нас в компании всё развивалось в части виртуализации последние 10+ лет, с какими «детскими болячками» столкнулись, но потом понял, что это долго, много текста и мало толку.
Коротко: мы столкнулись с проблемами перегрузки дисковой подсистемы, нюансами SAS-дисков разных объемов в пулах с их производительностью и траблшутинг vmware-гипервизоров для решения этих проблем. Добавлю, что для администрирования гипервизора важно обращать внимание не только на такие параметры, как CPU, RAM, объем дисковой подсистемы, но и обязательно учитывать утилизацию дисковой подсистемы по Input/Output.
Когда мы только начали развивать виртуализацию, мы использовали vCenter Essentials с лицензией на три хоста, но очень быстро этого перестало хватать и мы начали плодить отдельные гипервизоры на базе vmware vsphere, а потом и вовсе перешли на Proxmox-виртуализацию. Это породило большое количество серверов виртуализации и сложности с поиском нужной ВМ для ее администрирования. Для решения задачи поиска нужной ВМ на конкретном гипервизоре мы использовали не совсем стандартный ход — использование готового решения по инвентарному учету в компании для задач инвентаризации ВМ. Алгоритм был следующим:
в системе инвентарного учета создаем рабочее место с именем ВМ и добавляем туда «виртуальные ресурсы» этой ВМ: CPU, RAM, HDD, описание ВМ, IP-адрес, сам хост гипервизора, где находится ВМ, а также ответственных за неё;
Проводим инвентаризацию и добавляем в систему все ВМ со всех гипервизоров;
Через запросы к БД через встроенный функционал получаем удобную табличку со всеми виртуальными машинами: сколько ресурсов каждая занимает, к какому проекту относится и, самое главное, на каком гипервизоре находится.
В 2018 году, устав от ручной инвентаризаци большого количества виртуальных машин, мы решили попробовать автоматизировать все это дело на базе PHP-скрипта и используемой в отделе DokuWiki:
Автоматизация сбора информации по ВМ через PHP
Автоматизация сбора информации по ВМ через PHP
Скрипт подключался к гипервизорам по API, получал нужную информацию, формировал это в синтаксисе dokuwiki и подкладывал итоговый файлик в нужную директорию на dokuwiki-сервере. Это было ещё далеко от желаемого вида, но оно работало!
Честно признаться, скрипт работал не очень хорошо, в какой-то момент мог просто перестать выполняться, долго отрабатывал из-за «классного кода» и неопытности «программиста». Идеи и желания нас переполняли, поэтому взвесив все «за и против» текущего подхода, мы решили, что пришел черед переехать на то, что мы сможем поддерживать и развивать командой, а не одним человеком. Выбор пал на python«овский framework Django.
Кодовое название нашего внутреннего инструмента — VMList. Его основная задача схожа с идеей инвентаризации — простой поиск по любому атрибуту ВМ сервиса + дата окончания ВМ, но об этом чуть позже.
Архитектура работы на текущий момент:
Архитектура работы VMList
Ядро сервиса через модули сопряжения подключается к API гипервизоров и дальше на конкретной ВМ правит её Description (то есть на текущий момент Description в виртуалке нужен для работы сервиса и писать его нужно в строгом формате). В бэклоге уже есть задачка на изменение этой логики и хранение всей информации в БД, но пока Description ВМ выглядит как-то так: «Description: Jabber server; Department: PS; Division: IT; Project: None; Ticket: 979; Hostname: jabber; IP:172.16.10.52; CreateDate:2022–01–14; ValidTill:2023–12–25; FirstOwner: ivanov.i@tecomgroup.ru; SecondOwner: sidorov.s@tecomgroup.ru; Action: None»;
Ключевым параметром в описании является ValidTill. Это информация о дате, до которой нужна ВМ. По нашему регламенту, который выстрадан и написан кровью разработчиков активность ВМ не может превышать 6 месяцев. Дальше происходит информирование ответственных сотрудников о том, что необходимо принять решение о дальнейшей судьбе ВМ. Именно благодаря этому параметру мы начали экономить ресурсы и деньги, так как периодическое ревью позволяет отсеивать ненужные виртуальные машины.
Расшифровка остальных параметров:
Description: для чего используется данная ВМ. Мы внимательно следим за информацией в описании при создании машин, чтобы всем участникам, работающим с ВМ, было понятно, для чего она, а руководитель любого из подразделений понимал, что у него в отделе происходит в части виртуальных мощностей;
Department/Division/Project: к какому Направлению/Отделу/Проекту относится данная ВМ — неоходимо для группировки, сортировки, статистики и ролевой модели доступа;
Ticket: в рамках какого тикета создавалась данная ВМ. В этом тикете можно найти всю необходимую информацию + всю переписку по задаче между сотрудниками IT-отдела и инициатором тикета;
Hostname: если на гипервизоре стоят vmtools, то мы подтягиваем эту информацию автоматически, в противном случае заполняем руками через сервис;
IP: также подтягиваем все IP-адреса виртуальной машины через vmtools, в противном случае заполняем руками;
CreateDate: дата создания ВМ;
FirstOwner: основной ответственный;
SecondOwner: вспомогательный ответственный;
Action: что мы можем сделать с ВМ: продлить, удалить или забэкапить и удалить. Пользователь сам выбирает нужное действие, после чего сервис автоматически создает тв системе тех.поддержки IT тикеты, в которых прописываются все необходимые действия с конкретными ВМ.
Ну, а вот, что у нас вышло
На примере демо-стенда со сгенерированными данными покажу как выглядит сервис сейчас, сохранили структуру по направлениям компании, чтобы показать удобство при работе с системой.
Список всех ВМ. Сводная табличка по всем ВМ без группировок.
VMList. Список всех ВМ
Группировка по направлениям. Здесь мы можем быстро перейти к списку ВМ, посмотреть статистику и детальные графики изменения ресурсов ВМ по конкретному направлению/отделу/проекту.
VMList. Список всех ВМ с группировкой по направлениям
VMList. Список всех ВМ с группировкой по направлениям (раскрыто направление)
Группировка по гипервизорам. Сюда мы вывели версию гипервизоров, чтобы было легче поддерживать единую версионность, а так же количество выделенных ресурсов (именно количество выделенных ресурсов на все ВМ, а не загруженность текущих ресурсов). На скриншоте ниже есть гипервизор с 36Gb RAM при имеющихся на хосте 31Gb. Это означает, что если все ВМ начнут утилизировать всю выделенную им ОЗУ по максимуму, то хост просто уйдет в swap и всем станет немножко грустно.
VMList. Группировка по гипервизорам
На текущий момент на боевой системе у нас заведен 41 гипервизор с общим количеством ВМ — 506 шт.
Администрирование гипервизорами/направлениями/ролевой моделью. Тут целый блок можно вставить, но, думаю, особого смысла показывать его тут нет, так как это же не поноценный обзор системы, а демонстрация наработок.
Действия с ВМ. Сюда попадают ВМ, у которых криво заполнено описание или с которыми необходимо выполнить действия. Как раз по ним и создаются автоматизированные тикеты для системных администраторов.
VMList. Действия с ВМ
Ну и одна из самых удобных фич в сервисе — это, конечно, поиск. На текущий момент мы ищем по всему вхождению (а-ля grep), но скоро добавим и возможность фильтровать по конкретным параметрам.
VMList. Поиск
Например, можно поставить галочку справа от строки поиска и посмотреть все «просроченные ВМ».
VMList. Поиск ВМ с истекшим сроком
За время существования сервиса мы реализовали достаточно много удобных плюшек, таких как статус работы ВМ, калькуляция стоимости ВМ, массовое редактирование, автоматическое создание тикетов в нашем helpdesk’е по проблемам с ВМ, уведомления ответственных и многое другое. А сколько еще в бэклоге лежит идей по развитию, ууууу.
Подводя итог и оглядываясь назад могу уже смело сказать, что на текущий момент сервис уже помог оптимизировать затраты компании благодаря регулярному аудиту ВМ по всем гипервизорам, ведь никто и никогда не приходит к нам и не говорит: «Ой, вот эта виртуалка больше не нужна». Кроме одного сотрудника из 150+. Саша, если ты это читаешь, знай, я о тебе помню :) А отделу IT сервис стал огромным подспорьем, так как менеджмент парка ВМ больше не зависит от объединения гипервизоров в кластеры, теперь мы делаем это с целью настройки HighAvailability для ВМ или же для переноса её с одного гипервизора на другой.
Буду дико благодарен за обратную связь. Надеюсь, первый блин не будет прям большим комом :-) И спасибо, что дочитали!
