Comments 23
Чего только не придумают - лишь бы не юзать IaaC с Терраформом...
Спасибо за комментарий, частично справедливый. Только это не решает проблему аналитики и "истечению срока жизни ВМ". Ведь IaaC хорош, но только для админов, а дальше все равно все это нужно будет распарсить и потом где-то отобразить для удобной фильтрации и работы. А как обычные пользователи будут иметь отношения к терраформу? То есть предложенный инструмент сути существующей проблемы не решает.
Кто такие "обычные пользователи", заказывающие себе вируталки? Окей, они не разворачивают ВМ сами - но когда машины готовы, на них нужно ещё ОС развернуть/настроить, сервисы поднять и всё такое. Это кто делает?
Имхо, достаточно просто периодически натравливать заинтересованных лиц на вебморду гипервизора, чтобы они могли глазами посмотреть и сказать - "о, это уже не нужно".
Ваша идея понятна и в целом я её приветствую, но кажется, что конструктивнее процессы выстроить таким образом, чтобы неактуальные машины не оставались болтаться.
Да, все верно говорите, но это может быть особенность нашей компании? К нам в IT приходят запросы от 10+ отделов, как устроен процесс:
В helpdesk'е по регламенту сотрудник (Интегратор, QA, Dev, Руководитель проекта) создает тикет с указанием необходимых параметров по ВМ, как правило мы очень редко отказываем в этом, так как задача IT в данном случае планировать ресурсы и выделять их для проектных необходимостях. Забегая вперед скажу, что был случай, когда мы на 12 офисных ПК ставили Proxmox и разворачивали там запрашиваемые ВМ;
Силами IT разворачиваем на данной ВМ операционную систему, включаем SSH и отписываемся в тикет с доступами до машины;
ВМ поступает в эксплуатацию инициатору тикета.
Зачастую ВМ может сильно утилизировать дисковую подсистему или ответственный сотрудник за ВМ запрашивает расширение ресурсов по CPU/RAM, а на данном гипервизоре этих ресурсов нет, приходится ВМ мигрировать на другой хост и получается, что мы в этом случае должны следить на каком гипервизоре у кого есть доступ к конкретной виртуальной машине. На минуточку, у нас 41 гипервизор)))
Аудит по правам доступов это еще более интересная задачка))) А что делать, когда сотрудник увольняется? Тогда нужно ходить по всем гипервизорам и искать данных ответственных и переназначать на нового? Тут столько подводных камней, которые мы хапнули, поэтому пока не было системы - мы неплохо справлялись с этими задачами через систему инвентаризации. Запрашиваешь отчет по человеку, смотришь где он назначен на какие ресурсы и потом все эти ресурсы переназначаешь на нового ответственного. Тут сложность была в том, что вести эту систему уж больно удручающе для IT и опять же - доступ в нее был только у IT'шников.
Сейчас же - когда срок подходит к концу - ответственному сотруднику приходит письмо в почту (официальный способ коммуникации), он автономно заходит в сервис по LDAP и на своих виртуалках отмечает какое действие нужно с ВМ выполнить, после чего автоматически формируется тикет для IT по действиям с данной ВМ.
На самом деле данный сервис это результат того, что у нас много Proxmox-кластеров отдельных друг от друга (не спроста), ряд vsphere, vCenter на 3 хоста и с этим нужно как-то жить и в идеале, работать в одном окне, не тратить лишние силы на документацию в системе инвентаризации, а если еще добавить сюда, что пользователи начали нам помогать с актуализацией, то для нас это маленькая победа по выстраиванию системы работы с виртуализацией не в рамках IT-отдела, а в рамках компании.
Поддерживаю. Не обращайте внимания на попытки недо-девопосов всё подстроить под свой идеальный мир и надменно разнести живущих и решающих реальные задачи в реальном мире.
Насмотрелся на подобных. Когда надо что-то действительно решить и реализовать, такие начинают на ровном месте ненужные абстракции городить и систематизировать несистематизируемое инструментами, кроме которых ничего не знают и не умеют. Например, монолиты в контейнера в кубере навязывать. )
Вы всё правильно сделали. Будет рост - будут другие решения.
Описание решения в статье это хороший пример, когда инструмент: 1) по средствам 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 стоят денег.
Полностью поддерживаю, путь enterprise всегда хорош, но только когда есть на это деньги))) Мы в свое время купили одну лицензию на vcenter/vsphere essential kit на 3 хоста, да, работает шикарно, аудит, тэги, все ВМ видишь насквозь по хостам, но как дальше развивать этот парк? Бесплатно в части ПО - ставить vspher'ы или же покупать еще один такой пак и ставить рядом? Тогда смысл теряется или же покупать уже полноценные лицензии для объединения в кластер, но они уже будут стоить сильно дороже, чем стартовый пак, верно?
Я в статье скрыл нашу историю по развитию нашей системы виртуализации, где подробно все расписывал, но мы когда только начинали свой путь и была необходимость в серверах, то мы каждый месяц покупали по одному игровому ПК на базе AMD Ryzen 1920x с 128Gb RAM и на нем уже разворачивали нужные нам виртуальные машины, потом еще такой же ПК покупали и таких ПК у нас образовалось 10 штук (конечно же ставили в стойку благодаря negorack-корпусам). На всех них крутились Proxmox'ы, ведь путь enterprise это не только купить софт, но и купить нормальные стоечные двухпроцессорные сервера или blade-сервера, чтобы оправдать купленную лицензию vmware, в нашем же случае мы крутились как могли, набивали шишки и наверное, в том числе поэтому пошли по данному пути.
А как на базе vCenter решается вопрос с регулярным аудитом виртуальных машин и самое главное - пользователи проводят ли какой-нибудь аудит?
По поводу аудита. Насколько я понял, речь про срок жизни 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 туда подключаться и выгружать список виртуалок, у которых скоро закончится срок жизни и ответственную группу, чтобы потом отправлять им "письма счастья".
Так как мы суровый Enterprise, то у нас есть ещё и настоящие внутренние и внешние аудиторы (из Big 4), которые следят, чтобы всё было сделано правильно, согласно всем нужным законам и постановлениям, поэтому не дай бог что-то сделать без тикета или неправильно его оформить, загрызут сразу. :)
Касательно классных и интересных штук, могу упомянуть вопросы лицензирования разного ПО, например, Microsoft Server, Microsoft SQL, Oracle DB, Redhat. Это ПО недостаточно просто купить, нужно ещё и правильно лицензировать, т.к. лицензии там по сокетам или ядрам, а значит, виртуалки с конкретной ОС или DB нужно привязывать к конкретным хостам виртуализации в кластере.
Например, кластер содержит 16 хостов виртуализации, а софт залицензирован лишь на 4 сокета, т.е. 2 хоста виртуализации. В этом случае можно использовать у VMware опции VM/Host Groups и VM/Host Rules. Тогда виртуалки, привязанные к ним, могут мигрировать только между этими двумя хостами. Иными словами, виртуалки не будут бегать по всему кластеру, а только по тем хостам виртуализации, для которых мы лицензировали ПО.
Если такую привязку не делать, то приходит вендор, видит кластер из 16 хостов по 2 сокета каждый и говорит, вы должны тогда залицензировать все 32 сокета, ведь ваша VM может быть на любом из них. А когда у тебя всё ПО лицензионное и его много, то суммы получаются с 6 нулями в иностранной валюте. Так что приходится ограничивать миграцию VM с конкретной ОС или софтом списком только лицензируемых хостов виртуализации.
Как круто все организовано и реализовано, снимаю шляпу! Получается мы к этому идем, только путем малого бизнеса))) Взял на заметку себе информацию по рабочему процессу, значит верной дорогой идем. Большое спасибо за детальное описание!
Описание 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 меры позволили сильно уменьшить объём нагрузки на наших админов, иначе админы уже бы давно "порвались".
У меня от таких цифр - 4 дня на согласования + целый день(!?) на создание какой то виртуальной машины волосы дыбом на голове :)
В маленьких компаниях достаточно 1 админа, чтобы сделать техническую часть, 1 бухгалтера, чтобы купить сервер и 1 директора, чтобы выделить на это бюджет.
В больших компаниях существует специализация, поэтому любой процесс затрагивает сразу много разных людей, а это тянет за собой бесконечные митинги, километровые переписки и кучу бюрократических процедур и ритуалов.
Бюджет надо выделить (руководитель управления + экономисты), составить тендерные документы (тех. спецы + отдел закупок), провести тендер (тендерный отдел), выбрать поставщика (отдел закупок + тендерный отдел), привезти сервер (логисты), выбрать место в ЦОД (отдел планирования в ЦОД), смонтировать в стойку и подключить питание (техники ЦОД), настроить iLO (сетевики + группа поддержки оборудования), добавить сервер в кластер виртуализации (группа виртуализации), подключить LUN c СХД (группа поддержки оборудования + группа виртуализации), выделить нужные лицензии (группа software asset management), протянуть до оборудования нужные VLAN и сети (сетевики + группа виртуализации). И вот только после этого появляется возможность создать виртуальную машину. :)
И это только небольшая часть, т.к. даже для пункта "Бюджет надо выделить" там будет свой большой процесс, который включает сбор данных для формирования бюджета, постановка целей, защита бюджета перед советом директоров, куча переговоров и попыток его отстоять, презентация для ТОП менеджеров, как эти траты помогут компании получить +5% выручки на след. год и прочее.
И это я ещё сюда не добавлял "подковёрные игры", "политические баталии", "перетягивание одеяла одним управлением на себя", "амбиции менеджеров по своему продвижению в компании" и прочие прелести, которые тоже негативно влияют на скорость многих процессов внутри компании.
Однако все эти ужасы компенсируются деньгами, когда можно купить нормальные серверы, а не самосбор с Aliexpress, получить нормальную техническую поддержку (после 2022 с этим стало сложнее), купить готовые продукты, которые закрывают почти все твои потребности, купить отдельные компании или команды, чтобы получить недостающие компетенции. Надёжность сервисов часто достигается не глубоким знанием систем, а просто возможностью многие проблемы залить деньгами.
Не все минусы. Из свежих:
Критическая уязвимость vCenter Server — CVE-2023-34048 https://internet-lab.ru/vcenter_CVE-2023-34048
Обновление KB5031364 для Windows Server 2022 вызывает BSoD на гипервизорах VMware ESXi https://habr.com/ru/news/773364/
Есть же Netbox
Кстати карманную инвентаризацию VMware отлично делает RVtools - экспорт в Excel.
Получилась у вас специфическая DCIM система. Похожую проблему, только в облаке, у нас тоже решали через два тега: владелец, и время жизни.
Как приручить виртуальные машины