Было время, когда все было под контролем у небольшой команды админов и всегда можно было спросить — а чье это и для чего. Но времена меняются. Когда у вас несколько тенантов в Cloud Director, с десяток VDC и куча администраторов, каждый из которых делает что хочет, плюс микс из собственных VMware-кластеров и мощностей у провайдеров, разобраться в этой каше без 100 грамм просто нереально. Наливать мы вам, конечно, не предлагаем (на работе все-таки). А вот системный подход тут необходим как воздух.
Эта статья вторая в серии из трех, посвященных FinOps применительно к Cloud Director. В части 1 мы разобрали теоретическую модель тегирования. Теперь посмотрим, как эту модель применить в VMware Cloud Director и как нам в этом помогут metadata.
Дисклеймер: статьи предназначены для новичков, как в FinOps, так и в Cloud Director.
Как организовать ресурсы через Cloud Director: vApp, имена и теги
В том, что тегирование и разметка работают, сомнений нет. Подтверждающих это кейсов просто навалом. Но, чтобы разобраться, кто сколько тратит на инфраструктуру, сначала надо понять, как вообще можно организовать ресурсы. В VMware Cloud Director для этого есть три основных способа:
Структура каталогов (VDC и vApp)
Осмысленные имена виртуалок
Теги
Это три разные вещи, и работают они по-разному. Но, если инфраструктура небольшая, хватит и первых двух. Раскидали ресурсы по VDC и vApp, как по папкам, и назвали виртуалки так, чтобы было понятно. Все логично, все работает, все довольны.
Проблемы начинаются при росте. Например, может вылезти какой-нибудь проект, который крутится сразу в трех VDC. Почему так происходит? Да мало ли почему. В одном не хватило ресурсов, во втором хранение дешевле, в третьем сеть быстрее. А как считать, сколько этот проект стоит? Вопрос риторический.
Или возьмем виртуалку с названием app-server-prod-01. Из названия понятно, что это продакшен. А что дальше? Кто за нее платит? К какому отделу она относится и в интересах какого клиента работает? Ворожить по имени, наверное, весело, но неэффективно. Да, можно запихнуть всю информацию в имя типа marketing-client-alfa-app-server-prod-01-critical. Но спойлер: админам это не понравится.
Хотя, в целом, подход вполне рабочий и, если он вам близок, рекомендую статью на английском.
Поэтому почти все облака давно используют теги. Это такие пары ключ-значение, которые можно навешивать на ресурсы как стикеры. Department: Marketing. Project: Alfa. Environment: Production. В Cloud Director это называется metadata. С ними даже неважно, в каком VDC живет конкретная виртуалка. Тег есть — значит, можно найти и посчитать.
Впрочем, что выбрать, зависит от ваших вводных:
Подход |
Плюсы |
Минусы |
Когда работает |
Каталоги (VDC/vApp) |
Наглядно, привычно, просто понять структуру |
Жесткая иерархия, ресурс не может быть в двух местах одновременно |
Небольшая инфраструктуры с четким разделением по проектам |
Нейминг |
Не требует доп.действий, сразу видно в списке |
Длинные имена, сложно менять, информация быстро устаревает |
Стабильные проекты с понятной структурой |
Теги |
Гибкость, множественная категоризация, легко менять |
Требует дисциплины и спец.инструментов, нужно поддерживать |
Растущая инфраструктура, сложная структура проектов |
Как видите, у каждого варианта свой контекст применения. Хотя на практике лучше всего работает гибридный подход: базовое разделение по VDC дает структуру, нормальные имена помогают быстро понять, что это за ресурс, а теги показывают то, что нельзя показать через папки или имя. Именно теги дают ту гибкость, которой не хватает двум первым подходам…
Metadata в Cloud Director: что это вообще такое
Теги, ключи, значения – на бумаге все это звучит довольно абстрактно. Поэтому давайте посмотрим, как оно работает в реальном Cloud Director.
В VMware Cloud Director есть встроенная штука — metadata. Это как раз то, что позволяет цеплять теги на виртуалки и vApp, а потом фильтровать их, сортировать и вообще как-то с ними работать.
В metadata есть два типа данных, и они немного по-разному работают.
Обычные теги — это пары ключ-значение, которые мы уже упоминали. Значение может быть текстом, числом, датой или булевым true/false. Пример: project: tomsk_retail или criticality: high. Вот именно эти теги мы и будем использовать для учета затрат. С ними и работаем дальше.
Бэйджи — по сути, просто цветные метки. Красный, желтый, зеленый. Они нужны в большей степени для визуализации. Вроде мелочь, но это удобно, поскольку позволяет быстро оценить критичность ресурса одним взглядом, не читая текст.
Ничего сложного. Но тут очень важно иметь в виду два момента:
Во-первых, не путать metadata и security tags, потому что это совершенно разные вещи. Security tags используются для политик безопасности и файрволов, а для FinOps нужны именно metadata. Если начнете их мешать, будет весело, но недолго.
Во-вторых, система позволяет навесить на виртуалку или vApp довольно много тегов. Но это не значит, что надо использовать все доступные слоты. Помните про правило не более 7-10 ключей — оно тут работает как нигде.
Как начать размечать инфраструктуру
Сотрудники, которые будут тегировать ресурсы, должны иметь достаточно прав в нужных VDC. Потребуется либо роль Organization Administrator, либо специальная кастомная роль. Без прав вы просто не сможете добавлять или менять теги.
Дальше — разведка. Узнайте у администраторов и владельцев ресурсов, используют ли они уже какие-то теги. Может, там уже что-то есть для автоматизации или отчетов, и вы просто не в курсе.
Допустим, есть скрипт, который каждую ночь ищет все ресурсы с тегом environment:prod и делает их бэкап. Вы приходите, видите разнобой (где-то prod, где-то production), решаете навести порядок и меняете все на единый стандарт env:production. Получается красиво. Только на завтра вдруг выясняется, что резервные копии перестали создаваться, потому что скрипт ищет старый тег, а его больше нет.
Во избежание таких казусов лучше уточните, применяются ли теги для автоматизации. Если да — не ломайте существующую систему. Просто дополните ее своими тегами, а не заменяйте полностью.
Лучше потратить пару часов на подготовку, чем потом разгребать последствия.
Постройте разные выборки по фильтрам, посмотрите, все ли ресурсы попали куда надо. Можно использовать выгрузки из Cloud Director, можно — командную строку. Тут уж, как говорится, up to you.
Чек-лист внедрения системы тегов
Вот вам практический план на первые 2-4 недели.
Неделя 1: Планирование
Выпишите 5-10 вопросов, на которые хотите получить ответы через теги.
Определите 7-10 ключевых тегов, которые закроют эти вопросы.
Для каждого ключа напишите список возможных значений (начните с топ-5).
Договоритесь о правилах написания (латиница, строчные, подчеркивания).
Проверьте документацию Cloud Director на ограничения.
Уточните у провайдера лимиты на количество тегов.
Неделя 2: Подготовка
Проверьте права доступа у тех, кто будет тегировать.
Узнайте у админов, какие теги уже используются.
Выясните, завязана ли автоматизация на существующие теги.
Создайте документ с правилами тегирования (разместите в базе знаний).
Проведите короткое обучение для команды (30 минут хватит).
Договоритесь, кто за какие VDC отвечает.
Неделя 3: Пилот
Выберите один VDC или проект для пилота.
Проставьте теги на всех ресурсах в тестовой зоне.
Постройте первый срез в инструменте учета (Cloudmaster или аналог).
Проверьте, все ли ресурсы попали куда надо.
Соберите обратную связь от команды.
Исправьте очевидные косяки в правилах.
Неделя 4+: Массовое внедрение
Запустите тегирование остальной инфраструктуры.
Делайте кросс-проверки каждые 2-3 дня.
Стройте срезы по разным измерениям.
Анализируйте нераспределенные группы.
Дорабатывайте правила тегирования.
Начните принимать решения на основе данных.
Дальше система должна заработать сама. Главное поддерживать дисциплину: новые ресурсы сразу тегируются, старые периодически проверяются.
В следующей и заключительной статье мы посмотрим, как использовать результаты этой серьезной работы, чтобы повысить осознанность потребления облачных ресурсов командами.
А как вы справляетесь с аллокацией затрат в облаках? Используете теги, папки, нейминг? Делитесь опытом в комментариях.
Я и мои коллеги в Cloudmaster принимаем участие в развитии комьюнити FinOps практики в России. Если темы эффективности затрат на инфраструктуру для вас актуальны, присоединяйтесь к нам в Telegram