«Чисто не там, где убирают, а там где не гадят» © Некий автор. Всем привет! Хочу поделиться опытом борьбы с большим «зоопарком» гипервизоров и виртуальных машин (далее – ВМ), а точнее историей по созданию внутреннего сервиса по контролю за виртуальными машинами, благодаря которому нам в IT стало сильно проще работать с нашим зоопарком, а сотрудники стали присылать информацию по удалению неактуальных ВМ. Начал было с длинной предыстории, как у нас в компании всё развивалось в части виртуализации последние 10+ лет, с какими «детскими болячками» столкнулись, но потом понял, что это долго, много текста и мало толку. Коротко: мы столкнулись с проблемами перегрузки дисковой подсистемы, нюансами SAS-дисков разных объемов в пулах с их производительностью и траблшутинг vmware-гипервизоров для решения этих проблем. Добавлю, что для администрирования гипервизора важно обращать внимание не только на такие параметры, как CPU, RAM, объем дисковой подсистемы, но и обязательно учитывать утилизацию дисковой подсистемы по Input/Output. Когда мы только начали развивать виртуализацию, мы использовали vCenter Essentials с лицензией на три хоста, но очень быстро этого перестало хватать и мы начали плодить отдельные гипервизоры на базе vmware vsphere, а потом и вовсе перешли на Proxmox-виртуализацию. Это породило большое количество серверов виртуализации и сложности с поиском нужной ВМ для ее администрирования. Для решения задачи поиска нужной ВМ на конкретном гипервизоре мы использовали не совсем стандартный ход – использование готового решения по инвентарному учету в компании для задач инвентаризации ВМ. Алгоритм был следующим: в системе инвентарного учета создаем рабочее место с именем ВМ и добавляем туда “виртуальные ресурсы” этой ВМ: CPU, RAM, HDD, описание ВМ, IP-адрес, сам хост гипервизора, где находится ВМ, а также ответственных за неё; Проводим инвентаризацию и добавляем в систему все ВМ со всех гипервизоров; Через запросы к БД через встроенный функционал получаем удобную табличку со всеми виртуальными машинами: сколько ресурсов каждая занимает, к какому проекту относится и, самое главное, на каком гипервизоре находится. В 2018 году, устав от ручной инвентаризаци большого количества виртуальных машин, мы решили попробовать автоматизировать все это дело на базе PHP-скрипта и используемой в отделе DokuWiki: Автоматизация сбора информации по ВМ через PHP Скрипт подключался к гипервизорам по API, получал нужную информацию, формировал это в синтаксисе dokuwiki и подкладывал итоговый файлик в нужную директорию на dokuwiki-сервере. Это было ещё далеко от желаемого вида, но оно работало! Честно признаться, скрипт работал не очень хорошо, в какой-то момент мог просто перестать выполняться, долго отрабатывал из-за "классного кода" и неопытности "программиста". Идеи и желания нас переполняли, поэтому взвесив все "за и против" текущего подхода, мы решили, что пришел черед переехать на то, что мы сможем поддерживать и развивать командой, а не одним человеком. Выбор пал на python’овский framework Django. Кодовое название нашего внутреннего инструмента - 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 тикеты, в которых прописываются все необходимые действия с конкретными ВМ. На примере демо-стенда со сгенерированными данными покажу как выглядит сервис сейчас, сохранили структуру по направлениям компании, чтобы показать удобство при работе с системой. Список всех ВМ. Сводная табличка по всем ВМ без группировок. Группировка по направлениям. Здесь мы можем быстро перейти к списку ВМ, посмотреть статистику и детальные графики изменения ресурсов ВМ по конкретному направлению/отделу/проекту. Группировка по гипервизорам. Сюда мы вывели версию гипервизоров, чтобы было легче поддерживать единую версионность, а так же количество выделенных ресурсов (именно количество выделенных ресурсов на все ВМ, а не загруженность текущих ресурсов). На скриншоте ниже есть гипервизор с 36Gb RAM при имеющихся на хосте 31Gb. Это означает, что если все ВМ начнут утилизировать всю выделенную им ОЗУ по максимуму, то хост просто уйдет в swap и всем станет немножко грустно. На текущий момент на боевой системе у нас заведен 41 гипервизор с общим количеством ВМ - 506 шт. Администрирование гипервизорами/направлениями/ролевой моделью. Тут целый блок можно вставить, но, думаю, особого смысла показывать его тут нет, так как это же не поноценный обзор системы, а демонстрация наработок. Действия с ВМ. Сюда попадают ВМ, у которых криво заполнено описание или с которыми необходимо выполнить действия. Как раз по ним и создаются автоматизированные тикеты для системных администраторов. Ну и одна из самых удобных фич в сервисе – это, конечно, поиск. На текущий момент мы ищем по всему вхождению (а-ля grep), но скоро добавим и возможность фильтровать по конкретным параметрам. Например, можно поставить галочку справа от строки поиска и посмотреть все “просроченные ВМ”. За время существования сервиса мы реализовали достаточно много удобных плюшек, таких как статус работы ВМ, калькуляция стоимости ВМ, массовое редактирование, автоматическое создание тикетов в нашем helpdesk'е по проблемам с ВМ, уведомления ответственных и многое другое. А сколько еще в бэклоге лежит идей по развитию, ууууу. Подводя итог и оглядываясь назад могу уже смело сказать, что на текущий момент сервис уже помог оптимизировать затраты компании благодаря регулярному аудиту ВМ по всем гипервизорам, ведь никто и никогда не приходит к нам и не говорит: «Ой, вот эта виртуалка больше не нужна». Кроме одного сотрудника из 150+. Саша, если ты это читаешь, знай, я о тебе помню :) А отделу IT сервис стал огромным подспорьем, так как менеджмент парка ВМ больше не зависит от объединения гипервизоров в кластеры, теперь мы делаем это с целью настройки HighAvailability для ВМ или же для переноса её с одного гипервизора на другой. Буду дико благодарен за обратную связь. Надеюсь, первый блин не будет прям большим комом :-) И спасибо, что дочитали! Директор направления Professional Services