Методика определения неиспользуемых ресурсов виртуальных машин и автоматизация действий с ними
•Download as PPTX, PDF•
0 likes•758 views
1. Методика 2. Практика 3. Перспективы
Recommended
Recommended
More Related Content
What's hot
What's hot (18)
Similar to Методика определения неиспользуемых ресурсов виртуальных машин и автоматизация действий с ними
Similar to Методика определения неиспользуемых ресурсов виртуальных машин и автоматизация действий с ними (20)
More from Positive Hack Days
More from Positive Hack Days (20)
Методика определения неиспользуемых ресурсов виртуальных машин и автоматизация действий с ними
- 1. Методика определения неоптимально используемых ресурсов Мирошниченко Дмитрий Инженер по автоматизации dmiroshnichenko@ptsecurity.com
- 3. История проблемы 2012 2015 2016 2017 История
- 4. Проблемы Завис сервис Не стартует VM Сборочный сервер тормозит Кончилось место на сторе ПричинаПроблема Disk, CPU, MEM Disk CPU, MEM Disk
- 5. Цель разработки Методики 1. Решить проблему постоянной нехватки ресурсов инфраструктуры R&D не путем наращивания машинных ресурсов, а оптимизацией потребления этих ресурсов 2. Подтвердить гипотезу, что значительная часть данных ресурсов используется неоптимально
- 6. DoD 1. Сформулированы критерии неоптимальности использования ресурсов 2. Разработана методика определения неиспользуемых ресурсов инфраструктруры, без необходимости ручных действий 3. Разработан скрипт, реализующий эту методику, который можно передать вне отдела DevOps
- 7. Инфраструктура HW HW HW Clouds • Двадцать команд • Десятки проектов • Тысячи VM
- 8. Первичная оптимизация • Рассылка сообщений в команде • Ручная отпимизация
- 9. Реализация
- 10. Первичный анализ •VMware operations manager •OpenStack
- 11. Метрики •Owner •TTL •TTL Action •ESX_swap •Snapshot_count •CPU_usage_avg •MEM_usage_avg •Disk_type
- 12. TTL TTL — дата, по достижению которой с VM производится действие Требуемые значения: ISO 8601 (Basic) или -1 Пример: 20171030 Триггер: выполняем действие из TTL Action Несоответствие требуемым значениям: отправляем письмо owner'у TTL
- 13. TTL Action TTL Action — действие, которое производится с VM по достижению даты в TTL Требуемые значения: ключевые слова Пример — выключение: shutdown || halt Пример — удаление: remove || delete || destroy Пример — перемещение: archive || mv Триггер: вспомогательный атрибут Несоответствие требуемым значениям: отправляем письмо owner'у
- 14. Owner Owner — владелец или ответственный за VM Требуемые значения: имя доменной учетки или группа рассылки, допустимо несколько значений Пример — dmiroshnichenko || isimqa; knikolaev Триггер: вспомогательный атрибут Несоответствие требуемым значениям: контактируем с лидами и находим исполнителя который заполнит значения
- 15. ESX_swap ESX_swap — объем памяти, которую Vmkernel перевел на диск Требуемое значение: 0 MB Триггер: превышение требуемого значения Несоответствие требуемому значению: отправляем письмо owner'у. Перезагружаем/выключаем ВМ
- 16. Snapshot_count Snapshot_count — число снапшотов у VM Требуемое значение: 0 Триггер: превышение требуемого значения Несоответствие требуемому значению: отправляем письмо owner'у с просьбой удалить снапшоты
- 17. CPU_usage_avg & MEM_usage_avg *_usage_avg — cреднее значение по загрузке за 4 часа Рекомендованные значения: загрузка > 60% Триггер: превышение рекомендованного значения Несоответствие рекомендованным значениям: оповещаем owner'а о чрезмерном потреблении ресурсов
- 18. Disk_type Disk_type — тип диска Требуемые значения: Thick Provision Lazy/Eager Zeroed Триггер: превышение допустимого значения Несоответствие требуемым значениям: отправляем письмо owner'у с просьбой конвертировать диск и количеством «неправильных» дисков
- 19. Данные: создаем и наполняем
- 21. Items & Triggers
- 22. Оповещения
- 23. Выводы
- 24. Положительные результаты • DoD достигнут: критерии неоптимальности определены, методика и скрипты разработаны • Переходим на парадигму Infrastructure as Code • Единые сборочные пулы • Навели порядок и сэкономили • Приблизились к созданию единого ресурсного пула
- 27. CPU_usage_avg & MEM_usage_avg Как представляли:
- 28. Что дальше
- 29. Планы • Построение цикла жизни VM • Дополнительные проверки перед созданием VM • Агрегация VM по Load class • UI • Оповещения об «осиротевших» VM
- 31. Спасибо! Вопросы? Мирошниченко Дмитрий Инженер по автоматизации dmiroshnichenko@ptsecurity.com
Editor's Notes
- Рассказать о целях
- Года сделать анимацией В начале 12-13 столкнулись с нехваткой ресурсов порядке 100 ВМ. Написали скрипт который по апи собирал информацию по загрузке и на выходе выдавал статические страницы (автор Арсен Адамян сегодня здесь). Продвижением тулзы никто не занимался, с уходом Арсена она загнулась. Начало 2015 – начали писать новую систему тестирования для Макспторол, увеличилось количество тестовых машин. проекты АИ, ВАФ, вебенжин начали активно тестироваться. Проблема опять проявилась. Пришлось докупать железо (в каждую команду отдельно). 2016 Проблема никуда не делась Железо мониторится департаментом ИТ, наладили оповещения о нехватки места на сторах. В конце 2016 была четко сформулированая задча.
- Дать определение Методики Методика определения неиспользуемых ресурсов инфраструктруры: Это последовательность действий: Python-скрипт, запускаемый автоматически, выполняет сбор метрик Python-скрипт выполняет проверку каждой метрики на превышение значений В случае несоответствия фактических значений метрики допустимым уровням, выполняются действия, указанные в Таблице 1. Периодичность запуска проверки и сбора метрик - еженочно
- 20 комманд, исторически у каждой свое железо, все хотели не зависеть от соседей, чтобы ничего не тормозило. Тысячи ВМ. IaaS сопровождается департаментом ИТ ВМ не имеют жизненого цикла (собираются вручную, не обновляются, могут удалятся из инвентори, но занимать место на диске). Отсутствует жизненый цикл ВМ Часть проектов живет в облаке. Раньше был Крок, сейчас переходим на cloud4y, но все это не удобно после AWS и Azure
- Рассылка писем в команде через Outlook – с просьбой выключить не используемые ВМ. Миграция через сферу. Из-за разности в железе не всегда можно собрать кластер, для атоматической миграции.
- vmware operations manager -- vRealize Operations
- Критерии неоптимальности используемых ресурсов на Сфере: В ячейках таблицы указаны граничные критерии, после превышения которых работа машины будет считаться неоптимальной и несоответствующей текущему TTL, после чего будут предприняты действия. Превышение показателей по метрикам для различных классов по Uptime, является критерием неоптимальности использования.
- Человек или группа людей, которые будут получать уведомления о десвтиях производимых с ВМ
- Файл свапа лежит в директории с VM Это плохо, т.к. он не знает (в отличие от ОС), какие страницы нужно складывать в своп, поэтому кладет все подряд.
- В качестве примера можно привести тот факт, что при аллокации блоков снапшота происходит блокировка LUN (в этом режиме он доступен только одному хосту, остальные ждут). Когда снапшот делается - машина подвисает из-за сброса памяти на диск. Куча ограничений по атоматизации при наличии снапшота. На сервере VMware vCenter можно настроить алармы на снапшоты виртуальных машин. Veeam Backup бывает создает невидимые в vSphere Client снапшоты (Helpers) которые остаются на хранилище По словам Best practices for using snapshots in the vSphere environment (1025279), большое колл-во снапшотов ведет к падению производительности ВМ и стора. Кулл стори про гитлаб и 255 снапшотов вимбэкапа
- Есть тимплейт который цепляется к тимплейтам вмвари тимплейтов от забикса Под каждую метрику есть айтемы и тригры Переделать картинки, оставить по 3 строчки из тригеров и айтемов, за счет челог увеличатся Про логику тут (слайд со скриптами удалил)
- У писем есть маркер [vmvalidator]
- Обязательно сделать Выводы: 1) Помогла ли Методика решить проблемы, озвученные во введении? После внедрения Методики: при первичной диагностике (уточнить сколько ВМ подключено) мы обнаружили, что у большинства ВМ выделено чрезмерно CPU и Memory, нашли бесхозные ВМ (уточнить количество), нашли ВМ с большим числом снапшотов (количество?), начали вовлекать команды в решение общей проблемы с ресурсами, а также Методика стала точкой соприкосновения с ИТ по вопросам консолидации ресурсов. 2) как людям применять Методику? Внешним сказать, что скрипты скоро будут выложены в DevOpsHQ(ссылку на слайде)
- В крупных задачах не видно конца, только следующий шаг.
- Единый вычислительный пул (цпу, мем), сторы отдельно
- Не учли оптимизации на сторах. Ругаемся, если Thin Provision, т.к. такие диски наименее производительны (выделение нового блока и его очистка), однако наиболее оптимальны со стороны экономии пространства на системе хранения данных, что оказалось важнее.
- Не осилили написать свой оркестратор :D
- Создание ВМ через наш UI (смотрим, что есть(pt-virt или внешние проекты) или пишем свое (фронт + salt-cloud как бэк)) Как пользоваться Методикой: Скрипты выложим в паблик, дать ссылку на девопсHQ