Работая в одном из крупнейших банков страны, передо мной стояла задача оценить эффективность использования ресурсов примерно 16 тысяч серверов.
Задача была сформулирована предельно просто — необходимо было разработать методику оценки показателей загрузки серверов за период. В идеале загрузку сервера за период следует оценивать по одному или нескольким (не более 8) числам.
Несколько слов об особенностях использования виртуальных серверов
Крупные организации (особенно банки) имеют пестрый зоопарк устаревших приложений, развернутых на разных серверах с использованием различных технологий виртуализации.Частное облако — многообещающая технология, но реальность такова, что крупные организации будут продолжать использовать различные платформы виртуализации для развертывания самых разных приложений в течение длительного времени.
По мере развития платформ виртуализации наступает момент, когда никто в компании не может понять, насколько эффективно используются ресурсы.
Даже самые продвинутые инструменты мониторинга не дают ответа на этот вопрос из-за различных сценариев использования серверов.
Например, в отделе может быть сервер отчетов, который будет полностью загружен только в течение ограниченного периода времени.
Допустим, 3-4 часа в конце месяца.
В реальных сценариях никто динамически не выделяет ресурсы для таких серверов — это технически и организационно сложно.
Ресурсы выделяются специально под максимальную периодическую нагрузку сервера, хотя это случается нечасто.
Подводя итог, в крупных организациях ресурсы виртуальных ферм расходуются крайне неэффективно.
Ниже я предлагаю методику, с помощью которой можно легко обосновать увеличение и уменьшение ресурсов, выделяемых виртуальному серверу, независимо от сценария работы.
Методология
Для оценки загрузки ресурса необходимо собирать статистику с различных счетчиков; Для оценки загрузки ресурсов будут использоваться различные метрики.Условно счетчики можно разделить на 2 типа (по скорости изменения): «быстрые» и «медленные».
Хорошим примером «быстрого» счетчика является счетчик загрузки ЦП (%CPU).
Примером медленного счетчика является процент свободного места на жестком диске (%FreeSpace).
Оценка медленных счетчиков включает в себя вычисление экстремального (минимального или максимального) значения метрики за период. Такой подход позволяет (например, при оценке свободного дискового пространства) оценить свободный ресурс и при необходимости выделить дополнительные тома или уменьшить текущие.
Для быстрых счетчиков используется другой подход. Хорошо описаны недостатки использования простых интегральных показателей (среднего, максимума, минимума и медианы) для оценки динамики таких счетчиков.
Здесь .
К общим недостаткам можно отнести отсутствие информации о повышенных нагрузках (средних и пиковых).
Если принять за интегральный показатель максимальное значение за период, то наличие выбросов (например, мгновенная загрузка процессора до 100% при запуске программы) не даст объективной информации.
В статья Для оценки быстрой метрики предлагается использовать квантиль 0,9 (это значение, указывающее уровень, ниже которого находится наблюдаемое значение в 90% выборок).
Если нагрузка на серверы равномерна, то с помощью этой метрики можно адекватно оценить среднюю загрузку процессора.
Но у этого подхода есть те же недостатки – отсутствие информации о повышенных нагрузках (средних и пиковых).
Ниже в качестве иллюстрации приведен еженедельный и дневной график счетчика % ЦП.
Максимальное значение счетчика на графиках составило 100%.
На графике видно, что в указанный период наблюдается всплеск нагрузки, продолжающийся примерно 3 часа.
Для этого счетчика рассчитывались различные метрики за неделю.
Из графика 2 видно, что медиана (зеленая линия, значение 5%), среднее значение (желтая, значение 12%) и квантиль 0,9 (красная, значение 27%) фильтруют изменение нагрузки и информация о нем теряется.
В качестве развития идеи квантилей я хотел бы предложить идею движущегося квантиля.
Это аналог скользящее среднее , но в качестве оконной функции использует квантиль 0,9. Причем для оценки уровня счетчика мы будем использовать 2 скользящих квантиля – быстрый с коротким периодом (1 час) и медленный с длинным периодом (24 часа).
Быстрый квантиль отфильтрует непосредственные выбросы и предоставит информацию о пиковых нагрузках.
Медленный квантиль позволит оценить среднюю нагрузку.
Как видно из графиков, скользящие квантили 0,9 являются динамическими характеристиками (коричневый – быстрый, фиолетовый – медленный).
Для удобства оценки состояния счетчика предлагается использовать в качестве метрик следующие показатели:
- максимальное значение квантиля с периодом 1 час, которое показывает максимальную непрерывную нагрузку сервера за период,
- среднее значение квантиля с периодом 24 часа, которое показывает среднюю нагрузку сервера за период.
Таким образом, при анализе нагрузки на ресурсы сервера (по счетчику %CPU), если принять за показатель среднемесячный показатель (12%), можно принять ошибочное решение о сокращении выделяемых ресурсов.
Двойной квантильный показатель быстрого/медленного перемещения (85 и 30%) показывает, что выделенных ресурсов достаточно, но излишков нет.
Решение
Реализация оценки эффективности использования ресурсов была разделена на 3 задачи:- Сбор данных
- разработка методики оценки
- внедрение методологии в текущую архитектуру
Сбор данных осуществлялся в базе данных ClickHouse. Эта столбчатая СУБД идеально подходит для хранения данных временных рядов.
Подробно это обсуждалось на Встреча ClickHouse 5 сентября 2019. Вы можете увидеть сравнение ClickHouse с другими СУБД временных рядов.
Здесь .
В результате сбора данных мы сформировали несколько таблиц, в которых данные были организованы построчно (значения каждого счетчика записывались в отдельную строку).
И, конечно, были проблемы с исходными данными.
Первая проблема — неравномерное расстояние между записями счетчиков.
Например, если стандартный период записи счетчика составлял 5 минут, то иногда возникали перерывы и следующая запись отставала от предыдущей более чем на 5 минут (до 20 минут).
Вторая проблема заключается в том, что иногда данные счетчика приходили 2 и более раз (с разными значениями) с одной и той же меткой времени.
И третья проблема – в ClickHouse нет оконных функций.
Для решения первой проблемы вы можете использовать АСОФ ПРИСОЕДИНЯЙТЕСЬ .
Идея довольно проста — для каждого счетчика каждого сервера создать таблицу равномерно с равномерно заполненными временными интервалами.
Использование ASOF JOIN позволит вам заполнить значения в новой таблице ближайшими по времени значениями из таблицы необработанных данных (можно настроить параметры заполнения, аналогичные ffill и bfill).
Решение второй проблемы — агрегирование с выбором максимального значения в данный момент времени.
Для решения третьей проблемы было рассмотрено несколько решений.
Сначала скрипт Python был отклонен из-за недостаточной производительности.
Второе решение — копирование необработанных данных в базу данных MSSQL, расчет метрик и копирование обратно — показалось слишком сложным в реализации.
MSSQL также имеет оконные функции, но не имеет необходимой агрегатной функции.
Вы можете растеряться и написать свою собственную функцию SQL CLR. Но этот вариант был отвергнут из-за чрезмерной сложности.
Рабочим решением может стать SQL-скрипт для ClickHouse. Пример этого скрипта показан ниже.
Для простоты я рассматривал расчет быстрого квантиля только для одного счетчика на нескольких серверах.
Решение выглядит не очень простым и не очень удобным, но оно работает. В результате в тестовом режиме в PowerBI был создан отчет для демонстрации методологии.
Заключение
В заключение хотелось бы поразмышлять над развитием решения.Если посмотреть на решение с точки зрения хранилищ данных, то можно увидеть, что таким образом решается проблема создания хранилища данных (Data Warehouse) из слоя необработанных данных (Staging Area).
Об архитектуре можно рассуждать, но для ClickHouse как столбцовой базы нормализация не критична (а может быть даже вредна).
Дальнейшее развитие хранилища видится в создании агрегатных таблиц (день\неделя\месяц) с разным временем жизни (TTL).
Это предотвратит чрезмерное вздутие хранилища.
Следующим шагом может стать использование данных для прогнозной аналитики.
P.S. Код и данные для тестирования размещены Здесь .
Теги: #ИТ-инфраструктура #Большие данные #sql #clickhouse #timeseries
-
Как Восстановить Поврежденные Файлы Dbx?
19 Oct, 24
