…и попутно воспитать сотрудников
«Чисто не там, где убирают, а там где не гадят» © Некий автор.
Всем привет! Хочу поделиться опытом борьбы с большим «зоопарком» гипервизоров и виртуальных машин (далее – ВМ), а точнее историей по созданию внутреннего сервиса по контролю за виртуальными машинами, благодаря которому нам в 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 тикеты, в которых прописываются все необходимые действия с конкретными ВМ.
Ну а вот, что у нас вышло
На примере демо-стенда со сгенерированными данными покажу как выглядит сервис сейчас, сохранили структуру по направлениям компании, чтобы показать удобство при работе с системой.
-
Список всех ВМ. Сводная табличка по всем ВМ без группировок.
VMList. Список всех ВМ
-
Группировка по направлениям. Здесь мы можем быстро перейти к списку ВМ, посмотреть статистику и детальные графики изменения ресурсов ВМ по конкретному направлению/отделу/проекту.
VMList. Список всех ВМ с группировкой по направлениям
-
Группировка по гипервизорам. Сюда мы вывели версию гипервизоров, чтобы было легче поддерживать единую версионность, а так же количество выделенных ресурсов (именно количество выделенных ресурсов на все ВМ, а не загруженность текущих ресурсов). На скриншоте ниже есть гипервизор с 36Gb RAM при имеющихся на хосте 31Gb. Это означает, что если все ВМ начнут утилизировать всю выделенную им ОЗУ по максимуму, то хост просто уйдет в swap и всем станет немножко грустно.
VMList. Группировка по гипервизорам На текущий момент на боевой системе у нас заведен 41 гипервизор с общим количеством ВМ - 506 шт.
Администрирование гипервизорами/направлениями/ролевой моделью. Тут целый блок можно вставить, но, думаю, особого смысла показывать его тут нет, так как это же не поноценный обзор системы, а демонстрация наработок.
-
Действия с ВМ. Сюда попадают ВМ, у которых криво заполнено описание или с которыми необходимо выполнить действия. Как раз по ним и создаются автоматизированные тикеты для системных администраторов.
VMList. Действия с ВМ -
Ну и одна из самых удобных фич в сервисе – это, конечно, поиск. На текущий момент мы ищем по всему вхождению (а-ля grep), но скоро добавим и возможность фильтровать по конкретным параметрам.
VMList. Поиск
Например, можно поставить галочку справа от строки поиска и посмотреть все “просроченные ВМ”.
За время существования сервиса мы реализовали достаточно много удобных плюшек, таких как статус работы ВМ, калькуляция стоимости ВМ, массовое редактирование, автоматическое создание тикетов в нашем helpdesk'е по проблемам с ВМ, уведомления ответственных и многое другое. А сколько еще в бэклоге лежит идей по развитию, ууууу.
Подводя итог и оглядываясь назад могу уже смело сказать, что на текущий момент сервис уже помог оптимизировать затраты компании благодаря регулярному аудиту ВМ по всем гипервизорам, ведь никто и никогда не приходит к нам и не говорит: «Ой, вот эта виртуалка больше не нужна». Кроме одного сотрудника из 150+. Саша, если ты это читаешь, знай, я о тебе помню :) А отделу IT сервис стал огромным подспорьем, так как менеджмент парка ВМ больше не зависит от объединения гипервизоров в кластеры, теперь мы делаем это с целью настройки HighAvailability для ВМ или же для переноса её с одного гипервизора на другой.
Буду дико благодарен за обратную связь. Надеюсь, первый блин не будет прям большим комом :-) И спасибо, что дочитали!
Комментарии (21)
grumbler70
25.10.2023 12:40+1Описание решения в статье это хороший пример, когда инструмент: 1) по средствам 2) соответствует задаче.
Thomas_Hanniball
25.10.2023 12:40+2А теперь описание того, как это работает в крупном Enterprise бизнесе.
Всего 3 000 VMs, распределённых по 3-м датацентрам. В каждом датацентре установлен свой экземпляр VMware vCenter. Все 3 vCenter соединены в Enhanced Linked Mode (https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-vcenter-installation/GUID-4394EA1C-0800-4A6A-ADBF-D35C41868C53.html), благодаря чему, зайдя в любой vCenter можно увидеть сразу все виртуальные машины со всех 3-х vCenter сразу. Отличный поиск, разбиение на кластеры, папки, а также тэги для VM работают из коробки, т.к. это штатный функционал vCenter.
Если хочется экспортировать данные по всем VM в CSV (Excel), то есть Global Inventory Lists, где все виртуалки даны единым списком и доступны опции экспорта в csv.
Из плюсов: никакой самодеятельности, скриптов или запиленных на коленке сервисов, которые может поддерживать только их создатель. Всё работает штатно из коробки и является базовым функционалом в VMware vCenter.
Из минусов: Лицензии для VMware vCenter и гипервизоров Esxi стоят денег.
orokhovatskiy Автор
25.10.2023 12:40+1Полностью поддерживаю, путь enterprise всегда хорош, но только когда есть на это деньги))) Мы в свое время купили одну лицензию на vcenter/vsphere essential kit на 3 хоста, да, работает шикарно, аудит, тэги, все ВМ видишь насквозь по хостам, но как дальше развивать этот парк? Бесплатно в части ПО - ставить vspher'ы или же покупать еще один такой пак и ставить рядом? Тогда смысл теряется или же покупать уже полноценные лицензии для объединения в кластер, но они уже будут стоить сильно дороже, чем стартовый пак, верно?
Я в статье скрыл нашу историю по развитию нашей системы виртуализации, где подробно все расписывал, но мы когда только начинали свой путь и была необходимость в серверах, то мы каждый месяц покупали по одному игровому ПК на базе AMD Ryzen 1920x с 128Gb RAM и на нем уже разворачивали нужные нам виртуальные машины, потом еще такой же ПК покупали и таких ПК у нас образовалось 10 штук (конечно же ставили в стойку благодаря negorack-корпусам). На всех них крутились Proxmox'ы, ведь путь enterprise это не только купить софт, но и купить нормальные стоечные двухпроцессорные сервера или blade-сервера, чтобы оправдать купленную лицензию vmware, в нашем же случае мы крутились как могли, набивали шишки и наверное, в том числе поэтому пошли по данному пути.
А как на базе vCenter решается вопрос с регулярным аудитом виртуальных машин и самое главное - пользователи проводят ли какой-нибудь аудит?
Thomas_Hanniball
25.10.2023 12:40По поводу аудита. Насколько я понял, речь про срок жизни VM. Мы для этого используем Custom Attributes и Tags. Вся нужная информация есть в Tags, а в Custom Attributes она дублируется, т.к. ходят слухи, что от Tags VMware хочет избавиться в будущих релизах vSphere.
Tags заполняются автоматически при разворачивании новой VM через тикеты в Jira. В самой Jira есть тикеты, которые люди создают, чтобы получить новую виртуальную машину. Далее идут апрувы от руководителей разных групп (бюрократия в чистом виде), после чего заявка поступает на исполнение в группу виртуализации. Там происходит магия, благодаря которой создаётся VM, а информация из тикета попадает в Tags.
В Tags содержатся следующие данные:
- Номер тикета, по которому была создана VM.
- Ответственная группа, которая заказала VM. В этом случае увольнение сотрудников нас мало волнует, пока в компании существует эта группа и её руководитель. Если нужно узнать конкретного сотрудника, то по номеру тикета можно посмотреть в Jira, кто конкретный заказывал эту VM.
- Имя сервиса, к которому относится эта виртуальная машина.
- Срок жизни виртуалки. Максимально можно заказать на 3 года. Ограничение по сроку сделано в тикете Jira специально, чтобы не было вечноживущих VM. Когда срок истекает, то виртуализаторы отправляют письмо в группу, что числится владельцем этой VM с вопросом, нужна VM или нет. Если да, то просят создавать тикет на продление срока её жизни.
- Дата последнего бэкапа. Система резервного копирования, после того, как успешно заканчивает бэкап виртуалки, меняет в Tags срок её последнего бэкапа. Таким образом через vCenter можно узнать, стоит VM на резервном копировании или нет. Если да, то насколько свежий бэкап для неё имеется. Очень полезная штука особенно перед ночными работами с этой VM.
У VMware есть PowerCLI, поэтому можно через PowerShell туда подключаться и выгружать список виртуалок, у которых скоро закончится срок жизни и ответственную группу, чтобы потом отправлять им "письма счастья".
Thomas_Hanniball
25.10.2023 12:40Так как мы суровый Enterprise, то у нас есть ещё и настоящие внутренние и внешние аудиторы (из Big 4), которые следят, чтобы всё было сделано правильно, согласно всем нужным законам и постановлениям, поэтому не дай бог что-то сделать без тикета или неправильно его оформить, загрызут сразу. :)
Thomas_Hanniball
25.10.2023 12:40Касательно классных и интересных штук, могу упомянуть вопросы лицензирования разного ПО, например, Microsoft Server, Microsoft SQL, Oracle DB, Redhat. Это ПО недостаточно просто купить, нужно ещё и правильно лицензировать, т.к. лицензии там по сокетам или ядрам, а значит, виртуалки с конкретной ОС или DB нужно привязывать к конкретным хостам виртуализации в кластере.
Например, кластер содержит 16 хостов виртуализации, а софт залицензирован лишь на 4 сокета, т.е. 2 хоста виртуализации. В этом случае можно использовать у VMware опции VM/Host Groups и VM/Host Rules. Тогда виртуалки, привязанные к ним, могут мигрировать только между этими двумя хостами. Иными словами, виртуалки не будут бегать по всему кластеру, а только по тем хостам виртуализации, для которых мы лицензировали ПО.
Если такую привязку не делать, то приходит вендор, видит кластер из 16 хостов по 2 сокета каждый и говорит, вы должны тогда залицензировать все 32 сокета, ведь ваша VM может быть на любом из них. А когда у тебя всё ПО лицензионное и его много, то суммы получаются с 6 нулями в иностранной валюте. Так что приходится ограничивать миграцию VM с конкретной ОС или софтом списком только лицензируемых хостов виртуализации.
orokhovatskiy Автор
25.10.2023 12:40+1Как круто все организовано и реализовано, снимаю шляпу! Получается мы к этому идем, только путем малого бизнеса))) Взял на заметку себе информацию по рабочему процессу, значит верной дорогой идем. Большое спасибо за детальное описание!
Thomas_Hanniball
25.10.2023 12:40Описание flow, которое есть у нас в Jira.
Человек хочет создать VM, поэтому он идёт в jira, находит там нужный проект и заполняет все поля:
Имя новой VM (srv-xxxx-xx, например, srv-myserver-01). Максимум 15 символов.
количество CPU, RAM, Disk
выбирает из выпадающего списка шаблон VM, который ему нужен.
Шаблоны - это заранее преднастроенные виртуалки (VM templates), внутри которых находятся все корпоративные настройки, последние обновления, сервисные аккаунты, стоят основные пакеты, репозитории и прочее. Шаблоны делятся на 2 категории: OS only и OS + DB. Шаблоны основываются только на LTSB\LTSC версиях, т.е. где срок поддержки от вендора 10 лет, поэтому нельзя заказать Ubuntu 23.10, но можно Ubuntu 22.04. Шаблоны OS only содержат 1 диск с ОС - 50 ГБ для Linux и 100 ГБ для Windows. Шаблоны OS + DB содержат 2 диска: 1 диск для OS - 50 ГБ для Linux и 100 ГБ для Windows, второй диск - для DB на 100 ГБ.
Если нужно что-то кастомное, чего нет в шаблонах (что бывает очень редко), то заявитель тикета должен обосновать свой выбор, иначе заявка будет отклонена. Если заявка принята, то заявителю создадут пустую VM, а ОС и софт он будет туда ставить самостоятельно. После чего отправит админам пароль от Администратора или рута, чтобы админы ранбуками создали там свои сервисные учётки и ввели всё это безобразие в домен.
указывает имя сервиса, к которому будет относиться виртуалка. Если это новый сервис, то отдельным тикетом в Jira он этот сервис создаёт, из-за чего в AD создаётся сервисная группа для этого сервиса, куда будет входить владелец сервиса и все, кто ему будет помогать в его эксплуатации.
указывает сервисную группу, которой будет дан админский доступ внутри новой VM.
Обоснование, откуда для этой VM будут браться ресурсы. 1 раз в год все группы пишут свои пожелания, сколько и каких ресурсом им понадобится в след. году. Это называется годовым планированием. Оно нужно, чтобы отдел закупок знал, сколько и чего закупать у вендоров. Заказать сразу 30 серверов и СХД на сдачу будет стоить заметно дешевле, чем 10 раз заказывать по 3 сервера. Если ресурсы для нового сервера в план закупок не записали, то есть 2 варианта:
Разобрать что-то старое, чтобы из его ресурсов собрать новую VM. Под разобрать здесь понимается, удаление старых VM, чтобы их ресурсы использовать для новых VM.
Второй вариант - использовать ресурсы в долг, поклявшись, что эти ресурсы будут вписаны в новый годовой план, чтобы компенсировать их перерасход в этом году.Краткое описание, зачем нужна эта виртуалка.
Сетевые настройки, которые дали сетевики. Сетевые настройки запрашиваются в отдельном тикете Jira, за который отвечают сетевики (ip planning).
Выбор дополнительного тэга. Prod, Preprod или Test.
Срок жизни виртуалки. Максимум 3 года.
.............................
Тикет создан, после чего начинается бюрократия:
Апрув руководителя, чей сотрудник создал заявку.
Апрув человека из планирования ресурсов, который собирает 1 раз в год хотели по ресурсам на след. год.
Если в запланированных ресурсах ничего нет, то в тикете нужен дополнительный апрув владельца бюджета, который должен разрешить взять ресурсы в долг.
Апрув руководителя, который отвечает за железо (серверы + СХД) и всю виртуализацию.
Апрув руководителя, который отвечает только за виртуализацию.
Назначение на исполнителя из группы виртуализации, который создаёт VM.
Апрув руководителя админов.
Назначение на исполнителя из группы админов, который донастраивает VM, вводит её в домен и предоставляет сервисной доменной группе создателя тикета админский доступ.
Если это OS only шаблон, то готовая виртуалка отдаётся создателю тикета. Если OS + DB, то процесс идёт дальше.
Апрув руководителя DBA (админов баз данных)
Назначение на исполнителя из группы DBA, который донастраивает на уровне DB и даёт доступ сервисной доменной группе создателя тикета админский доступ.
VM готова, можно использовать.
Между желанием создать VM и получением готовой VM проходит около 5-7 рабочих дней. Причём чисто техническая работа по настройке занимает суммарно 1 день и выполняется исполнителями с помощью ранбуков, скриптов, накаткой из gitlab и прочее. 90% времени занимает движение тикета по статусам и сбор всех апрувов.
Ещё 1 важный момент. Тикет на создание VM становится родительским в Jira. Если кто-то хочется с этой VM что-то сделать, то он создаёт Sub-task в jira к этому родительскому тикету, т.е. делает подтаск (подзадачу), где описывает, что ему нужно, например, добавить место, новой группе дать доступ или починить сломавшуюся VM.
Благодаря этому, можно открыть только родительский тикет и видеть, когда и какие задачи были выполнены для этой VM. Это намного удобнее, чем по Jira искать все тикеты. Хотя для Jira есть как отличные поисковые фильтры, так и модуль для PowerShell, поэтому по умолчанию можно искать в Jira лишь по конкретному полю с именем сервера. Но иметь родительский тикет всё таки приятнее.
P.S. В домен мы вводим все новые серверы, т.е. не только Windows, но и Linux, чтобы давать там админский доступ доменным учёткам будущих владельцев сервисов. В этом случае они имеют права, чтобы самостоятельно администрировать свои сервисы без привлечения наших админов. Также это избавляет от проблем, когда сотрудник увольняется. Нового сотрудника просто добавляют в те же доменные группы, в которых состоял старый, поэтому новый сотрудник автоматически получит доступ к нужным ему серверам, т.е. на самих серверах админам ничего менять не нужно в случае увольнения сотрудника и прихода нового. Только вот эти 2 меры позволили сильно уменьшить объём нагрузки на наших админов, иначе админы уже бы давно "порвались".
Foggy4
25.10.2023 12:40У меня от таких цифр - 4 дня на согласования + целый день(!?) на создание какой то виртуальной машины волосы дыбом на голове :)
Thomas_Hanniball
25.10.2023 12:40+1В маленьких компаниях достаточно 1 админа, чтобы сделать техническую часть, 1 бухгалтера, чтобы купить сервер и 1 директора, чтобы выделить на это бюджет.
В больших компаниях существует специализация, поэтому любой процесс затрагивает сразу много разных людей, а это тянет за собой бесконечные митинги, километровые переписки и кучу бюрократических процедур и ритуалов.
Бюджет надо выделить (руководитель управления + экономисты), составить тендерные документы (тех. спецы + отдел закупок), провести тендер (тендерный отдел), выбрать поставщика (отдел закупок + тендерный отдел), привезти сервер (логисты), выбрать место в ЦОД (отдел планирования в ЦОД), смонтировать в стойку и подключить питание (техники ЦОД), настроить iLO (сетевики + группа поддержки оборудования), добавить сервер в кластер виртуализации (группа виртуализации), подключить LUN c СХД (группа поддержки оборудования + группа виртуализации), выделить нужные лицензии (группа software asset management), протянуть до оборудования нужные VLAN и сети (сетевики + группа виртуализации). И вот только после этого появляется возможность создать виртуальную машину. :)
И это только небольшая часть, т.к. даже для пункта "Бюджет надо выделить" там будет свой большой процесс, который включает сбор данных для формирования бюджета, постановка целей, защита бюджета перед советом директоров, куча переговоров и попыток его отстоять, презентация для ТОП менеджеров, как эти траты помогут компании получить +5% выручки на след. год и прочее.
И это я ещё сюда не добавлял "подковёрные игры", "политические баталии", "перетягивание одеяла одним управлением на себя", "амбиции менеджеров по своему продвижению в компании" и прочие прелести, которые тоже негативно влияют на скорость многих процессов внутри компании.
Однако все эти ужасы компенсируются деньгами, когда можно купить нормальные серверы, а не самосбор с Aliexpress, получить нормальную техническую поддержку (после 2022 с этим стало сложнее), купить готовые продукты, которые закрывают почти все твои потребности, купить отдельные компании или команды, чтобы получить недостающие компетенции. Надёжность сервисов часто достигается не глубоким знанием систем, а просто возможностью многие проблемы залить деньгами.
V-core
25.10.2023 12:40+1Кстати карманную инвентаризацию VMware отлично делает RVtools - экспорт в Excel.
igolikov
25.10.2023 12:40Получилась у вас специфическая DCIM система. Похожую проблему, только в облаке, у нас тоже решали через два тега: владелец, и время жизни.
ky0
Чего только не придумают - лишь бы не юзать IaaC с Терраформом...
orokhovatskiy Автор
Спасибо за комментарий, частично справедливый. Только это не решает проблему аналитики и "истечению срока жизни ВМ". Ведь IaaC хорош, но только для админов, а дальше все равно все это нужно будет распарсить и потом где-то отобразить для удобной фильтрации и работы. А как обычные пользователи будут иметь отношения к терраформу? То есть предложенный инструмент сути существующей проблемы не решает.
ky0
Кто такие "обычные пользователи", заказывающие себе вируталки? Окей, они не разворачивают ВМ сами - но когда машины готовы, на них нужно ещё ОС развернуть/настроить, сервисы поднять и всё такое. Это кто делает?
Имхо, достаточно просто периодически натравливать заинтересованных лиц на вебморду гипервизора, чтобы они могли глазами посмотреть и сказать - "о, это уже не нужно".
Ваша идея понятна и в целом я её приветствую, но кажется, что конструктивнее процессы выстроить таким образом, чтобы неактуальные машины не оставались болтаться.
orokhovatskiy Автор
Да, все верно говорите, но это может быть особенность нашей компании? К нам в IT приходят запросы от 10+ отделов, как устроен процесс:
В helpdesk'е по регламенту сотрудник (Интегратор, QA, Dev, Руководитель проекта) создает тикет с указанием необходимых параметров по ВМ, как правило мы очень редко отказываем в этом, так как задача IT в данном случае планировать ресурсы и выделять их для проектных необходимостях. Забегая вперед скажу, что был случай, когда мы на 12 офисных ПК ставили Proxmox и разворачивали там запрашиваемые ВМ;
Силами IT разворачиваем на данной ВМ операционную систему, включаем SSH и отписываемся в тикет с доступами до машины;
ВМ поступает в эксплуатацию инициатору тикета.
Зачастую ВМ может сильно утилизировать дисковую подсистему или ответственный сотрудник за ВМ запрашивает расширение ресурсов по CPU/RAM, а на данном гипервизоре этих ресурсов нет, приходится ВМ мигрировать на другой хост и получается, что мы в этом случае должны следить на каком гипервизоре у кого есть доступ к конкретной виртуальной машине. На минуточку, у нас 41 гипервизор)))
Аудит по правам доступов это еще более интересная задачка))) А что делать, когда сотрудник увольняется? Тогда нужно ходить по всем гипервизорам и искать данных ответственных и переназначать на нового? Тут столько подводных камней, которые мы хапнули, поэтому пока не было системы - мы неплохо справлялись с этими задачами через систему инвентаризации. Запрашиваешь отчет по человеку, смотришь где он назначен на какие ресурсы и потом все эти ресурсы переназначаешь на нового ответственного. Тут сложность была в том, что вести эту систему уж больно удручающе для IT и опять же - доступ в нее был только у IT'шников.
Сейчас же - когда срок подходит к концу - ответственному сотруднику приходит письмо в почту (официальный способ коммуникации), он автономно заходит в сервис по LDAP и на своих виртуалках отмечает какое действие нужно с ВМ выполнить, после чего автоматически формируется тикет для IT по действиям с данной ВМ.
На самом деле данный сервис это результат того, что у нас много Proxmox-кластеров отдельных друг от друга (не спроста), ряд vsphere, vCenter на 3 хоста и с этим нужно как-то жить и в идеале, работать в одном окне, не тратить лишние силы на документацию в системе инвентаризации, а если еще добавить сюда, что пользователи начали нам помогать с актуализацией, то для нас это маленькая победа по выстраиванию системы работы с виртуализацией не в рамках IT-отдела, а в рамках компании.
grumbler70
Поддерживаю. Не обращайте внимания на попытки недо-девопосов всё подстроить под свой идеальный мир и надменно разнести живущих и решающих реальные задачи в реальном мире.
Насмотрелся на подобных. Когда надо что-то действительно решить и реализовать, такие начинают на ровном месте ненужные абстракции городить и систематизировать несистематизируемое инструментами, кроме которых ничего не знают и не умеют. Например, монолиты в контейнера в кубере навязывать. )
Вы всё правильно сделали. Будет рост - будут другие решения.
shrum
Edge ноды опенстека отлично в кубе крутятся, да и сам опенстек тоже хорошо себя чувствует в кубе уже лет 6, про антипаттерны монолита в кубе сходите в детском саду расскажите.