Решение зрело уже давно, но постоянно получал один ответ: «Не трогай, работает же». Но на этот раз, когда цифры перерасхода уже были выведены жирным шрифтом и показаны директору Бизнес-центра (БЦ), ситуация изменилась. Нам дали зеленый свет на «оптимизацию».
С одной стороны, всегда стоит задача по мониторингу ресурсов серверов, где необходимо обнаружить и устранить проблемы, а также оптимизировать работу самих серверов. С другой стороны, каждый сервер — это деньги, которые выделяются на его ресурсы и обслуживание и т.д (если, конечно, вы не закупили самостоятельно в личное владение 100500 серверов различных мощностей).
Меня зовут Александр Архипов — Devops-инженер Департамента информационных технологий «БАРС Груп», помогает мне, Ксения Ершова — руководитель Отдела проектной разработки БЦ BI «БАРС Груп». В этой статье мы рассмотрим, почему важно отслеживать объем расхода ресурсов виртуальных машин, а также методы их оптимизации для экономии бюджета без ущерба для производительности серверов.
Наблюдение за тем, что показатели CPU и RAM не превышают 40%, – это как раз один из ключевых сигналов, который указывает на возможное неэффективное использование ресурсов
Взять глыбу мрамора и отсечь от нее все лишнее...
Отслеживание ресурсов ВМ
Первостепенная задача перед разработкой любого кода и началом работы — это выделение мощностей. Виртуальные машины, словно живые организмы, требуют определенного объема ресурсов для стабильной и эффективной работы.
Вспомните эти ситуации: когда вас просят выделить мощности под какой-то проект, задачу, без разницы под что, вы берете общепринятые ресурсы из расчета очень сильно усредненных показателей нагрузки на проект. Вот вы выделили эти «стандартные» ресурсы, сервера работают, время идет. Потом это происходит ГОДАМИ...
Если нет просадки, сомнительно, что кто-то задумается урезать мощности сервера. Обычно это работает только в одну сторону - видишь просадки —-> увеличиваешь мощности. А просадок нет, жалоб нет - вообще в мониторинг не заглядываешь.
Почему важно отслеживать ресурсы виртуальных машин? Многие упускают из вида следующее:
Выделение чрезмерного количества ресурсов — процессорного времени, оперативной памяти и дискового пространства — приводит к их нерациональному использованию и, как следствие, к увеличению затрат. Когда в компании 1—2 сервера — это не сильно заметно в бюджете, а если их уже десятки, то за год можно сэкономить огромные суммы денег на ресурсах, которые «простаивают». Конечно, уходить в крайности не стоит, потому что недостаток ресурсов может вызвать сбои в работе приложений, а это негативно скажется на продуктивности и приведет к жалобам со стороны пользователей.
Оптимизация ресурсов ВМ
С чего начать?
Стоит начинать с виртуалок, которые явно прозябают без дела. К ним относятся веб-серверы для старых демо-проектов и файловые хранилища с нулевой активностью. Это будет первая волна по высвобождению серверов.
Во вторую волну рекомендуем выделить проекты, у которых в системе либо зарегистрировано мало пользователей, либо они редко туда заходят. За этими проектами закреплено N серверов, мы точно знаем, что нагрузка на них невысокая из-за низкой активности. Это потенциальные кандидаты для внесения в мониторинг, чтобы сэкономить бюджет. В идеальном сценарии — все ваши сервера всегда мониторятся. Поэтому третья волна — это оставшиеся сервера. Их тоже надо потихоньку (и каждый!) анализировать.
Итак, начнем с old-серверов. Первым делом мы выписали в блокнот IP-серверов кандидатов на нетипичный мониторинг. Почему нетипичный?
Казалось бы, сервера работают отлично, нигде нет просадок, тогда зачем трогать то, что уже работает?
Наша задача — определить, сколько ресурсов простаивает и сэкономить на них. Ломаем изречение «работает — не трогай!». После сформированного списка, мы начали понемногу урезать их ресурсы, словно опытные садовники, подрезающие лишние побеги у деревьев.
Метрики до урезания мощностей:
— Оперативка?
— Минус гигабайт.
— Процессор?
— Уберем пару ядер, посмотрим, как будет.
— Дисковая квота?
— Кого волнуют эти старые архивы, урежем и их.
Ночь пролетела незаметно. Графики, словно проснувшись от спячки, начали показывать более осмысленные значения. Постепенно "слоны" начали занимать отведенное им пространство, не разбрасываясь ресурсами попусту. Некоторые, правда, немного взбрыкнули, выдавая сообщения об ошибках, но мы были к этому готовы.
Перезагрузки, перенастройки, еще немного оптимизации – и вот, к рассвету, системный администратор Саня сидел, гордый собой, словно скульптор, высекавший из камня нечто прекрасное.
Стало на следующий день:
Следующий этап — проверка общей загрузки ресурсов.
У нас глаза полезли на лоб от удивления – загрузка серверов выросла вдвое если не больше, но при этом ни один из сервисов не свалился! «Слоны» вдруг стали словно котики, которые умеют занимать ровно столько места, сколько нужно, не создавая лишнего шума.
Какие показатели анализа важны?
1. Загрузка процессора (CPU):
Средняя загрузка: Средний процент использования CPU за определенный период (например, 5 минут, час, день, неделя, месяц).
Пиковая загрузка: Максимальный процент использования CPU в течение определенного периода.
Время простоя: Время, в течение которого CPU был практически неактивен.
2. Использование оперативной памяти (RAM):
Использованная RAM: Объем оперативной памяти, фактически используемой процессами.
Свободная RAM: Объем доступной оперативной памяти.
Кэшированная RAM: Объем оперативной памяти, используемой для кэширования данных (может быть использована при необходимости).
3. Дисковый ввод/вывод (Disk I/O):
Операции чтения и записи: Количество операций чтения и записи на диск в секунду.
Время ожидания диска: Время, которое процессы проводят в ожидании доступа к диску.
IP-сервер | CPU (было) | стало | RAM(было) | стало | Итог(CPU) | Итог(RAM) |
ip1 | 8 |
| 32 | 24 | -4 | -8 |
ip2 | 16 | 8 | 64 | 54 | -8 | -10 |
ip3 | 8 | 4 | 16 | 8 | -4 | -8 |
ip4 | 4 | 4 | 8 | 4 | 0 | -4 |
ip5 | 8 | 4 | 32 | 16 | -4 | -16 |
ip6 | 16 | 8 | 64 | 16 | -8 | -48 |
ip7 | 16 | 8 | 32 | 16 | -8 | -16 |
ip8 | 8 | 4 | 16 | 8 | -4 | -8 |
ip9 | 16 | 8 | 16 | 8 | -8 | -8 |
ip10 | 8 | 4 | 16 | 8 | -4 | -8 |
Я вздохнул с облегчением. Экономия бюджета была, конечно, важна, но не меньшее значение имело признание моей работы. Теперь я знал, что мои «слоны» превратились в эффективных «котиков», и готов был продолжить следить за их поведением, но теперь уже с большей уверенностью и, главное, меньшими затратами. Ведь за окном уже начинался новый рабочий день, и стадо виртуальных машин, как всегда, требовало внимания и заботы.
Следующий этап — подсчет экономии. Этот этап лег на плечи руководителя отдела разработки — пусть считает рубль и каждый занимается своей областью деятельности. Как раз — командная работа дает о себе знать. Чтобы увидеть конечный результат — нужно поработать совместно.
Для более наглядной картины мы приведем здесь расчет лишь по некоторым серверам (понятно, конечно, что их гораздо больше). И по CPU/RAM, чисто чтоб показать выхлоп на 10 серверах.
Если абстрагироваться от жесткого диска и взять примерные стоимости
1гб RAM - 80р/мес
1 CPU - 250р/мес
то получим примерно следующую картину:
| стоимость в день (руб) | стоимость в мес (руб) | экономия (руб) | ||||
| было | стало | было | стало | в день | в мес | в год |
ip1 | 152 | 97,33 | 4560 | 2920 | -54,67 | -1640 | -19680 |
ip2 | 304 | 210,67 | 9120 | 6320 | -93,33 | -2800 | -33600 |
ip3 | 109,33333 | 54,67 | 3280 | 1640 | -54,67 | -1640 | -19680 |
ip4 | 54,666667 | 44 | 1640 | 1320 | -10,67 | -320 | -3840 |
ip5 | 152 | 76 | 4560 | 2280 | -76 | -2280 | -27360 |
ip6 | 304 | 109,33 | 9120 | 3280 | -194,67 | -5840 | -70080 |
ip7 | 218,66667 | 109,33 | 6560 | 3280 | -109,33 | -3280 | -39360 |
ip8 | 109,33333 | 54,67 | 3280 | 1640 | -54,67 | -1640 | -19680 |
ip9 | 176 | 88 | 5280 | 2640 | -88 | -2640 | -31680 |
ip10 | 109,33333 | 54,67 | 3280 | 1640 | -54,67 | -1640 | -19680 |
Итого | -790,67 | -23720 | -284640 | ||||
Итого только на 10 серверах мы сэкономили на CPU и RAM 284 640 рублей за год!
А если у вас тысячи серверов?
Только представьте, какие деньги вы расходуете впустую!
Профит очевиден, поэтому нашим кейсом можно поделиться с сообществом. В ближайшее время проведем мониторинг и по другим серверам второй и третьей волны. Эффективность доказана, можно и директору показать. Работа проделана не зря.
Когда экономия оправдана
Старые сервера — «архивники», что-то древнее, но удалять нельзя.
Если сервер нужен только для внутренних задач (обучение, тестирование, разработка, показы) нет смысла переплачивать за большое количество ресурсов. Даже урезанные варианты будут работать нормально для подобных целей.
Маленькие проекты с ограниченной аудиторией, небольшие сайты или веб-приложения с низким трафиком и нагрузкой могут работать хорошо и на урезанных ресурсах. Здесь важно отслеживать нагрузку, чтобы внезапно мелкий проект не стал крупным.
Проблема перерасхода ресурсов
Основные причины, почему многие компании сталкиваются с проблемой перерасхода ресурсов ВМ, это:
Недостаток мониторинга
Отсутствие постоянного мониторинга использования ресурсов приводит к тому, что многие машины остаются недогруженными, потребляя при этом выделенные им ресурсы.
Инерция
Однажды выделенные ресурсы могут годами оставаться неизменными, даже если потребность в них снизилась.
«Запас прочности»
Администраторы часто выделяют больше ресурсов, чем реально требуется, «на всякий случай», либо следуя каким-то стандартным рекомендациям, накопленным годами, что приводит к их нерациональному использованию.
Сложность ручного управления
Управление ресурсами большого парка ВМ вручную является сложной и трудоемкой задачей.
Методы оптимизации ресурсов ВМ
1. Внедрение постоянного мониторинга:
Используйте инструменты мониторинга (например, Prometheus, Grafana, Zabbix) для отслеживания загрузки процессора, оперативной памяти, дискового ввода/вывода и сетевого трафика каждой ВМ.
Настройте оповещения, чтобы получать уведомления о нетипичном использовании ресурсов.
2. Идентификация неиспользуемых и малоиспользуемых ресурсов:
Регулярно анализируйте данные мониторинга, чтобы выявлять ВМ, которые длительное время работают с низкой загрузкой.
Определите ВМ, которые могут быть оптимизированы, или, при необходимости, вообще выключены.
3. Динамическое выделение ресурсов:
Используйте инструменты облачных провайдеров (например, autoscaling) для динамического увеличения или уменьшения ресурсов ВМ в зависимости от текущей нагрузки.
Настраивайте автоматическое масштабирование для оптимизации ресурсов в периоды спада и пиковой нагрузки.
4. Правильный выбор типов ВМ
Выбирайте типы ВМ, которые соответствуют потребностям ваших приложений.
Не переплачивайте за избыточные ресурсы, которые не используются.
5. Использование специализированных образов:
Применяйте оптимизированные образы операционных систем и приложений для уменьшения использования ресурсов.
Используйте контейнеризацию (например, Docker) для более эффективного управления ресурсами.
6. Регулярная чистка и дефрагментация дисков:
Очищайте дисковое пространство от временных и неиспользуемых файлов.
Проводите дефрагментацию дисков для повышения производительности.
7. Оптимизация программного обеспечения:
Следите за производительностью приложений и оптимизируйте их код.
Используйте эффективные алгоритмы и структуры данных.
Важно и не стоит забывать
Оптимизация ресурсов виртуальных машин — это не индивидуальная задача, а командная игра, требующая эффективного взаимодействия между различными отделами и специалистами. Чтобы добиться максимальной экономии и производительности, необходимо наладить четкое взаимодействие между системными администраторами, разработчиками, бизнес-аналитиками и руководством.
Оптимизация ресурсов — это постоянный процесс. Внедрение мониторинга, автоматизации и регулярного анализа данных позволит выявить и устранить нерациональное использование ресурсов, снизить затраты и повысить эффективность вашей облачной инфраструктуры. Помните, что грамотное управление ресурсами – это не только экономия средств, но и залог стабильной и производительной работы вашего бизнеса.