Подход, основанный на регистрации профилей потребностей в ресурсах для работы приложений, позволяет эффективно предсказывать будущую потребность в вычислительной мощности.

Развитие виртуализации серверов, сетей и устройств хранения позволяет сегодня создавать пулы серверных ресурсов, где множество приложений могут совместно использовать любой сервер в пуле. В данной статье предложен и охарактеризован процесс управления вычислительной мощностью, позволяющий автоматизировать эффективное использование таких пулов при хостинге большого количества сервисов. Наш подход к управлению мощностью на основе регистрации профилей опирается на 1) определение понятия требуемой мощности, 2) описание паттернов потребностей в мощности для различных нагрузок, 3) создание имитирующих нагрузок, с помощью которых на основе паттернов прогнозируют будущие потребности в мощности, и 4) сервис рекомендаций по размещению нагрузки. Исследование, выполненное на примере данных за шесть месяцев, отражающих использование ресурсов 139 нагрузками в корпоративном центре обработки данных, демонстрирует эффективность предложенного процесса управления мощностью. Наши результаты показывают, что при консолидации на

восьмипроцессорных системах мы предсказывали будущую потребность в мощности в расчете на сервер с точностью до одного процессора 95% всего времени. С помощью данного подхода удалось сократить использование процессоров на 35% по сравнению с лучшей на сегодня практикой размещения нагрузки.

Введение

В теперь уже далеком прошлом центры обработки данных (ЦОД) состояли из малого числа больших ЭВМ, или мэйнфреймов, на каждом из которых исполнялось несколько прикладных задач со множеством пользователей. Специалисты по планированию мощности отвечали за то, чтобы достаточная совокупная мощность была доступна именно в то время, когда она была нужна. С появлением распределенных вычислений новые нагрузки приложений стали назначаться каждая на отдельный небольшой сервер. Наращивание мощности для небольших серверов обходилось гораздо дешевле, чем на мэйнфреймах. Часто планировщики могли прогнозировать нагрузку, создаваемую некоторым приложением, на два года вперед и вводить новый сервер достаточной мощности с упреждением, так чтобы нагрузка "дорастала" до него. Однако взрывной рост корпоративных вычислений и вычислений через Интернет привел к разрастанию вычислительных центров. Корпоративные ЦОД, как правило, состоят из множества слабо используемых серверов, что влечет за собой высокую стоимость владения (включая затраты на аренду и электроэнергию для вычислений и охлаждения), лицензий на ПО и администрирования с участием операторов.

Web-сервисы и сервисно-ориентированные архитектуры еще больше обостряют проблемы роста числа серверов. В сервисно-ориентированной архитектуре может быть множество сервисов, которые требуется администрировать либо как рабочие нагрузки, исполняемые на серверах, либо как сервисы, совместно использующие один образ операционной системы. В нашем контексте предполагается, что сервисы имеют крупное разбиение, — таков, например сервис базы данных, входящий в состав сервиса управления взаимоотношениями с клиентами (CRM), который обслуживает множество пользователей. Мы исходим из того, что потребности в ресурсах для каждого сервиса соответствуют прикладной нагрузке.

Многие корпорации начинают теперь использовать "пулы" серверных ресурсов совместно с механизмами виртуализации, что позволяет исполнять на каждом сервере множество приложений. Для корпораций главные стимулы для перехода на такие технологии — это увеличение гибкости, возможность быстро перенацелить серверную мощность, чтобы она лучше соответствовала потребностям владельцев приложений, и снижение общей стоимости владения. К сожалению, сложность этих сред создает дополнительные проблемы при администрировании. Имеется много нагрузок, на каждый сервер можно назначить некое конечное их число, и каждая нагрузка имеет требования по мощности, которые могут часто меняться в зависимости от потребностей бизнеса. И пока не существует способов администрирования мощности, позволяющих управлять такими пулами оптимальным по соотношению стоимость/эффективность образом.

Цель нашей работы — предложить процесс управления вычислительной мощностью для пулов ресурсов, который позволил бы специалистам по планированию мощности привести в соответствие предложение мощности ресурсов и потребность в них, причем точно в нужное время. При управлении пулами ресурсов возникает множество вопросов управления мощностью, на которые нужно ответить, чтобы убедиться, что ресурсы используются эффективно. Например: какая мощность необходима для обслуживания текущих нагрузок? Какие нагрузки следует назначить каждому ресурсу? Как влияет на производительность планировщик нагрузки и/или установленные политики, управляющие совместным использованием ресурсов? Как следует назначать нагрузки, чтобы сделать планирование нагрузки и/или настройки политик наиболее эффективными? Что делать, если мощности ресурса недостаточно, чтобы удовлетворить потребности его нагрузок? Какой объем ресурсов будет нужен в перспективе?

Рассматривая эти вопросы, мы используем подход, основанный на построении профилей. Он опирается на: 1) определение понятия требуемой мощности, 2) выяснение характеристик паттернов потребности в ресурсах для нагрузок, 3) создание имитирующих нагрузок, которые на основе паттернов прогнозируют будущие потребности в ресурсах и 4) сервис рекомендаций по размещению нагрузки. Наш процесс автоматизирует этапы сбора и анализа данных, позволяющих решить эти вопросы. В итоге он дает операторам возможность решать эти вопросы быстрее, с более высокой точностью и с меньшими трудозатратами.

Чтобы продемонстрировать эффективность предложенного нами подхода, мы взяли данные за шесть месяцев из корпоративного центра обработки данных. Эти данные описывают меняющиеся во времени потребности в ресурсах для 139 корпоративных приложений. На этом примере мы показываем влияние различных формулировок определений требуемой мощности и демонстрируем эффективность сервиса прогнозирования потребности. Результаты показывают, что при консолидации на восьмипроцессорных системах мы смогли предсказать требуемую мощность в расчете на сервер с точностью до одного процессора 95% всего времени, если прогноз делался на пять недель вперед, что позволило на 35% снизить использование процессора по сравнению с лучшей на сегодня практикой размещения нагрузки. Ниже в статье наши результаты описаны более подробно.

Процесс управления мощностью

Предлагаемый нами процесс управления вычислительной мощностью опирается на комбинацию подпроцессов, реализующих различные сценарии использования ресурсов для операторов пула ресурсов. В числе этих сценариев могут быть следующие:

  • определить вычислительную мощность пула ресурсов, необходимую для поддержки нескольких рабочих нагрузок;
  • добавить/удалить нагрузку в пул/из пула ресурсов;
  • добавить/удалить вычислительную мощность к пулу/из пула ресурсов;
  • заново сбалансировать нагрузки по всем ресурсам пула;
  • снизить рабочую нагрузку на сервер из пула ресурсов, рекомендовав переместить некоторые из выполняемых на нем нагрузок;
  • составить отчет о значительных изменениях в характере поведения потребности в ресурсах;
  • скорректировать прогнозы по каждой нагрузке, тенденции или требования к качеству обслуживания (QoS).

Чтобы поддерживать такие сценарии, следует начать с определения понятия требуемой мощности. Требуемая мощность есть минимальная величина вычислительной мощности, необходимая, чтобы удовлетворить потребности нагрузок на серверном ресурсе. В следующем разделе дано более формализованное определение и обоснование для нашего конкретного способа выражения требуемой мощности. Исходя из определения требуемой мощности, мы реализуем:

  • сервис управления допуском к ресурсам;
  • сервис размещения рабочей нагрузки;
  • сервис прогнозирования потребностей нагрузки.

Сервис управления допуском к ресурсам решает, имеется ли в пуле достаточно ресурсов, чтобы принять новую нагрузку. Если да, то он сообщает, какому серверу будет назначена нагрузка. Мы рассматриваем нагрузки, использующие множество ресурсов, как набор отдельных нагрузок, возможно, имеющих ограничения по размещению, которые должна учитывать служба размещения нагрузки.

Сервис размещения нагрузки, которым мы пользуемся [13], рекомендует, как разместить нагрузки приложений на серверах в пуле, чтобы уменьшить число используемых серверов или сбалансировать рабочие нагрузки по всем серверам. Этот сервис использует основанный на профилях подход для определения потребностей в ресурсах и для выработки рекомендаций. В общих чертах каждая нагрузка описывается меняющимся во времени профилем потребности в ресурсах для главных показателей мощности, таких, как уровни использования процессора и памяти. Сервис размещения нагрузки включает «жадные» алгоритмы для консолидации нагрузок на небольшом числе серверов и для балансирования рабочих нагрузок внутри некоторого фиксированного числа серверов. Кроме того, сюда входит оптимизирующий поиск на основе генетического алгоритма, имеющий целью улучшить «жадные» решения. В каждом случае алгоритмы моделируют множество сценариев распределения. В каждом сценарии рассматривается размещение нескольких нагрузок — нуля или более — на каждом сервере. Совокупная потребность нагрузок, назначенных серверу, описывается с помощью профиля, который представляет собой сумму меняющихся во времени потребностей по каждой нагрузке. Требуемая мощность для меняющихся во времени совокупных потребностей сравнивается с мощностью ресурса, чтобы решить, соответствуют ли ей нагрузки. Сервис рекомендует лучший из тех вариантов размещения нагрузки, который удается найти по всем серверам, будь то для консолидации или выравнивания нагрузки. Наконец, сервис учитывает дополнительные ограничения на размещение нагрузки, которые включают родственность нагрузок (например, следует или не следует помещать нагрузки на один и тот же физический сервер) и родственность между нагрузками и списком из одного или более конкретных серверов.

Сервис прогнозирования потребности для нагрузки имеет три цели. Он:

  • помогает выяснить, значительно ли меняются потребности нагрузки во времени;
  • поддерживает генерацию имитирующих профилей, которые отражают будущие потребности для каждой рабочей нагрузки, давая возможность моделировать планирование мощности;
  • предоставляет удобную модель, которую можно использовать для составления модельных прогнозов. Этот сервис реализует методики выявления паттернов, описанные в разделе «Прогнозирование потребности в ресурсах».

В основе процесса управления мощностью лежит ключевая концепция плана управления мощностью. План управления мощностью представляет собой хранилище данных на базе календаря, который хранит предысторию для: 1) величин нагрузок, прогнозов и требований к качеству обслуживания для доступа к ресурсам, 2) ресурсов, которые связаны с пулом, и 3) распределения нагрузок по ресурсам. Предыстория такой информации хранится как функция даты и времени и используется при планировании мощности.

Рис. 1 иллюстрирует несколько аспектов наших процессов управления мощностью. Вариант «Сконфигурировать размер пула ресурсов» используется, чтобы уменьшить фрагментирование мощности посредством периодического переназначения, т. е. консолидации нагрузок в пуле. «Найти размещение» обеспечивает балансирование нагрузок, т. е. делит рабочую нагрузку равномерно на все ресурсы. Это делается в два этапа. Если ни один ресурс не способен удовлетворить получающиеся в результате требования по мощности, тогда мы можем либо попытаться заново сбалансировать нагрузки в более крупном масштабе, либо скорректировать требования качества обслуживания для нагрузок, либо сочетать оба подхода. Вариант «Добавить нагрузку» сообщает, можно ли обеспечить размещение для новой нагрузки.

Суммируя, можно сказать, что процесс управления мощностью в нашем представлении полагается на описанные выше подпроцессы. Некоторые из шагов могут потребовать вмешательства оператора пула ресурсов или владельца нагрузки или же могут управляться политиками. Мы ожидаем, что такие процессы обеспечат поддержку крупной платформы предоставления услуг Information Technology [10].

Требуемая мощность

Определение понятия требуемой мощности задает уровень избыточной нагрузки на пул ресурсов, т. е. показывает, до какой степени, по оценкам, потребность в вычислительной мощности может превышать имеющуюся в наличии мощность. Потребности могут превышать предложение, если мы разместим множество нагрузок на общем сервере и сумма пиковых потребностей каждой нагрузки превысит мощность сервера. Алгоритмы распределения нагрузки используют определение требуемой мощности, чтобы решить, подходит ли данный ресурс для группы нагрузок. Ресурс считается подходящим, если по всем параметрам мощность его достаточна, чтобы удовлетворить совокупные потребности нагрузок.

Наши определения построены на понятии единицы мощности. Размер этой единицы до некоторой степени произволен, но она должна быть такой, чтобы с ее помощью можно было последовательно (единообразно) выражать потребности в ресурсах и имеющиеся мощности. Для процессоров за единицу мощности мы принимаем 1% уровня загруженности процессора*. Тогда n-процессорный сервер будет иметь мощность в n сотен единиц. Для памяти мы определяем единицу мощности как 1 Мбайт. Аналогичным образом мы можем ввести единицы потребности для других характеристик мощности. Под уровнем загруженности мы понимаем здесь потребность, деленную на предложение, за некоторый период времени. Рассмотрим один параметр мощности. Определим функцию потребностей в ресурсах для некоторой нагрузки L как N последовательно измеренных значений данного параметра за интервалы времени постоянной длительности d. Пусть tn — это время, которое соответствует интервалу n в L, а l(tn) — измеренная потребность в единицах мощности. Тогда мы можем записать: L = (l(tn))1≤n≤N

Наши определения понятия требуемой мощности основаны на фиксированном и скользящем окнах интервалов. Мы определяем профиль с фиксированным окном, имеющим c смежных интервалов на каждое окно с длительностью окна s = c*d, как LFs = (lFs(tn)), Где lFs(tn) есть средняя потребность по всему окну длительностью s.

Мы определяем профиль со скользящим окном, имеющим c смежных интервалов на каждое окно с длительностью окна s = c*d, как LSs = (lSs(tn))1≤n≤N-c+1, где lSs есть средняя потребность для окон длительностью s.

Фиксированные окна и вероятности

Фиксированные окна позволяют интуитивно понятным способом выразить ограничения, налагаемые на требуемую мощность. При таком подходе мы можем сформулировать множество одновременных ограничений для фиксированных окон с разным размером. Рассмотрим Z ограничений, имеющих вид (si, Ui, Pi) для i = 1…Z, где:

  • si — фиксированное окно, имеющее ci интервалов длительностью d, так что si=ci*d;
  • Ui — предельный процент загруженности мощности для окна;
  • Pi— процент окон, которым разрешается иметь загруженность, превышающую Ui.

Найдем требуемую мощность, которая будет удовлетворять самому жесткому ограничению. Например, пусть s0= 30 мин, U0= 100% и P0= 100% или же s1= 5 мин., U1= 100% и P1= 95%. Первое ограничение включает в себя интуитивно понятное требование, чтобы потребность в мощности не превышала предложение слишком надолго, например, не более 30 мин. Второе ограничение указывает, как часто потребность может превышать предложение на короткий срок, например, 5 мин. Оно ограничивает влияние перегруженности ресурсов на работу приложений в короткие периоды времени.

Недостаток этого подхода в том, что он не ограничивает явным образом влияние на какую-либо потребность, которая не удовлетворена в данном интервале времени. Например, для тех пятиминутных интервалов, где потребность превысила наличие ресурсов, мы не знаем, насколько именно потребность была больше, чем предложение. Более того, поскольку это подход с фиксированным окном, то результат расчета требуемой мощности будет зависеть от того, с какого интервала начинается первое фиксированное окно. Рассмотрим теперь подход со скользящим окном.

Простое скользящее окно

Наше определение простого скользящего окна для требуемой мощности определяет требуемую мощность, выраженную неким ее параметром, как минимальное число единиц мощности, необходимое для того, чтобы потребность в мощности не превышала предложение мощности больше, чем на период перегрузки s, выраженный в минутах. Если единица потребности не удовлетворяется, потому что потребность превышает предложение (т. е. имеет место перегрузка), тогда эта единица потребности продвигается вперед во времени, пока не появится достаточная мощность, чтобы удовлетворить эту потребность. Для среды, где критична производительность, s можно выбрать равным нулю — это означает, что любая потребность должна быть всегда удовлетворена. Для более типичного центра обработки данных, где уровни обслуживания могут контролироваться ежечасно, целесообразно выбрать s = 30 мин. Мы принимаем требуемую мощность равной такой минимальной мощности, при которой ни в какой период времени потребность не превышает предложение в течение более чем s минут подряд. Таков подход со скользящим окном, где период перегрузки понимается как длительность окна s.

Скользящее окно «на единицу потребности»

Теперь мы рассмотрим предпочтительное определение требуемой мощности, в которой также используется скользящее окно. В соответствии с этим подходом мы находим такую наименьшую мощность, чтобы ни одна единица потребности не передвигалась из какого-то интервала в следующий на время, большее чем s минут. Кроме того, мы вводим вероятность доступа к ресурсу θ — это вероятность того, что единица потребности будет удовлетворена немедленно, «по требованию», следовательно, не будет передвигаться дальше. Это прямо связывает определение понятия требуемой мощности с его влиянием на потребности нагрузок.

Рассмотрим вычисление θ, которое проводится для подхода «на единицу потребности» во время моделирования процессов размещения нагрузки. Пусть A есть число рассматриваемых профилей потребности для нагрузки. Каждый профиль наблюдается в течение W недель с T интервалами за день при измерениях через каждые d минут. Без потери обобщения мы используем неделю как период времени для проверки соглашений об уровне обслуживания (можно также использовать другие периоды времени). Время суток учитывает, что по своему характеру интерактивные корпоративные нагрузки приходятся на дневное время (например, те, с которыми пользователи работают напрямую); мы отмечали, что в некоторые интервалы времени нагрузка может быть существенно больше, чем в другие. При пятиминутных интервалах измерения мы имеем T = 288 интервалов за день. Обозначим каждый интервал индексом так, что 1 ≤ t ≤ T. В любой день x из семи дней недели для каждого интервала t проводится наблюдение. При каждом наблюдении измеряются значения всех параметров мощности, рассматриваемых в нашем анализе.

Для определения θ рассмотрим один параметр, имеющий предельное значение мощности, равное R единицам потребности. Пусть Dw,x,t есть сумма потребностей по данному параметру со стороны A нагрузок для недели w, дня x и интервала t. Мы определяем измеренное значение θ как: θ = minWw=1 minTt=1 Σ7x=1 min (Dw,x,t,R) / Σ7x=1 Dw,x,t.

Таким образом, θ описывается как минимальная вероятность доступа к ресурсу, которая может быть получена в любую неделю для любого из T интервалов времени за день.

Далее, пусть R' есть требуемая мощность по данному параметру. Требуемая мощность R' — это наименьшее значение мощности, R' ≤ R, позволяющее предложить такую вероятность θ', что θ' ≥ θ, а те потребности, которые не удовлетворены по запросу, Dw,x,t— R' > 0, удовлетворяются в пределах периода перегрузки, равного s минут.

Главное преимущество этого подхода по сравнению с фиксированным окном в том, что потребность, не удовлетворяемая внутри интервала, моделируется как передвинутая в следующий интервал. По сравнению с подходом с простым скользящим окном условия перегрузки задаются с учетом неудовлетворенных единиц потребности, а не просто как число смежных периодов перегрузки. Было показано, что такое значение θ можно использовать для того, чтобы выбрать настройки планировщика для средств управления нагрузкой, поддерживающих два приоритета обслуживания [6]. С помощью этого подхода можно автоматически делить потребности нагрузки между двумя приоритетами планирования и управлять рисками совместного использования ресурсов по каждой нагрузке. Более высокий приоритет можно рассматривать как гарантированный класс обслуживания, а более низкий приоритет — как класс обслуживания, предлагающий ресурс мощности со статистической гарантированностью θ.

Прогнозирование потребности в ресурсах

В этом разделе описаны методы, которые мы использовали для прогнозирования потребности в ресурсах для нагрузки. В первой части раздела описано выделение паттернов и трендов для рабочей нагрузки, а во второй они используются для построения профилей имитирующих нагрузок.

Паттерны и тренды для рабочей нагрузки

Для выявления возможных паттернов для нагрузки мы использовали трехэтапный подход. На этапе анализа находят множество гипотетических паттернов. На втором этапе вычисляют тренды. Наконец, в ходе третьего этапа оценивают гипотетические паттерны и выдают рекомендацию о наиболее вероятном паттерне, или характере поведения нагрузки. В рекомендации может быть указано, что это периодическая нагрузка с определенной длительностью цикла либо апериодическая, так что определенной длительности цикла для нее не установлено.

Исходя из ретроспективного профиля нагрузки L = (l(tn))1≤n≤N, который представлен N последовательными значениями потребности l(tn), получаем паттерн P = (p(tm))1 ≤ m ≤ M,M ≤ N/2 с M последовательными значениями потребности p(tm) ) в допущении, что нагрузка носит циклический характер. Справедливость этого допущения оценивается позднее, на стадии классификации. Согласно классической модели аддитивных составляющих, последовательность значений во времени состоит из составляющей тренда, циклической составляющей и остатка, характеризующего, например, влияние шума. Тренд представляет собой монотонную функцию, моделирующую общее возрастание или снижение потребности.

Чтобы выявить циклическую составляющую, которая описывает периодические характеристики нагрузки, зададим для паттерна пока неизвестную длительность M. Для этого выполним совместную оценку периодограммы и автокорреляции [4], задавая таким образом набор гипотетических длительностей для паттерна. Для рабочих нагрузок в корпоративных центрах данных обычно характерна периодичность, кратная часам, дням, неделям и т. д. Ввиду неизбежных вычислительных погрешностей и влияния нерегулярных событий и шума, длины волн могут слегка отклоняться от этих типичных периодов. Таким образом, мы проводим сравнение с конкретными календарными периодами и находим для каждого предполагаемого варианта длины волны наиболее подходящий множитель для часов, дней и недель. После этого мы выбираем наиболее подходящую длину волны λ' из набора вариантов. Более подробно расчет вариантов длин волн и выбор наилучшего варианта описаны в [17]. Длительность шаблона M задается как λ'/d интервалов, где d — длительность каждого интервала.

Выбранное значение длины шаблона в M интервалов используется при расчете паттерна для нагрузки: P = (p(tm))1≤m≤M.

Сначала мы задаем число вхождений событий для паттерна, а затем значения потребности в ресурсах для этого паттерна p(tm). Зная M, мы делим нагрузку L на N/M полных вхождений и, возможно, одно частичное вхождение. Пусть O есть количество вхождений шаблона для o ≤ N/M + 1. Тогда вхождение o есть субпрофиль профиля L со значениями lo(tm) = l(tm+o*M) для каждого 1 ≤ m ≤ M. Для каждого интервала tm в паттерне мы вычисляем взвешенное среднее p(tm) для интервала. Взвешенное среднее рассчитывается с использованием интервалов tm из вхождений O данного паттерна. Мы определяем вес для каждого вхождения o и интервала m как: wo,m = lo(tm) / Σolo(tm).

С этими весовыми коэффициентами мы вычисляем взвешенную среднюю потребность для каждого интервала tm как p(tm) = Σowo,m*lo(tm).

Мы используем взвешенное среднее, чтобы подчеркнуть важность более высоких значений по сравнению с низкими для управления мощностью.

На втором этапе мы анализируем тренд нагрузки. Для этого мы вычисляем общее отклонение каждого вхождения паттерна от исходной нагрузки L. Пусть com есть разность между p(tm) и величиной потребности для интервала tm во вхождении o. Мы определяем co как совокупную разность в потребности для вхождения o относительно значения паттерна P:  co = Σ1 ≤ m ≤ M (p(tm) — lo(tm)).

Далее, мы определяем тренд τ как градиент линейной аппроксимации методом наименьших квадратов [7] всех значений co для вхождений O во временной последовательности. Тренд τ оценивает скорость изменения потребности во времени относительно паттерна.

Наконец, на стадии классификации мы решаем, какие нагрузки носят периодический характер. Классификация основана на двух показателях качества паттерна. Первый показатель, ρ', представляет собой среднее значение из множителей для λ' в функции автокорреляции. Более высокие значения ρ' означают лучшее качество аппроксимации. Второй показатель характеризует различие между вхождениями O и паттерном. Разность между ними вычисляется как средняя абсолютная погрешность
ζ = Σ1 ≤ m ≤ M,o |p(tm) — lo(tm)| / N
между исходной нагрузкой и паттерном P. Меньшая разность означает лучшее качество паттерна. Чтобы охарактеризовать качество паттернов для большого числа нагрузок, мы используем алгоритм группировки k средних [9] с параметрами группировки ζ и ρ'. С помощью этого алгоритма паттерны делятся на три группы, которые мы интерпретируем как имеющие сильный, средний или слабый паттерн. Слабые паттерны рассматриваются как апериодические, поскольку в их профиле нельзя выявить никакого явного цикла.

Генерация профилей имитирующей нагрузки и прогноз

Теперь мы рассмотрим процесс генерации модельного профиля, с помощью которого можно будет представить профиль будущей потребности в ресурсах нагрузки L' для некоторого периода времени. Как правило, мы генерируем профили, отражающие потребности на несколько недель или месяцев вперед. Цель моделирования профиля — охватить пики и «провалы» потребности и непрерывные участки последовательности. Они критичны для моделирования способности нагрузки совместно использовать мощность ресурсов с другими нагрузками и для моделирования необходимой ей мощности.

Генерируя вхождение o' для L', мы опираемся на вхождения ретроспективного паттерна O. Величина lo'(tm) выбирается случайным образом из соответствующих значений tm из O. Учитывая достаточно большое количество будущих вхождений O', мы получим то же самое распределение потребностей во времени, что и для O. Это дает нам паттерн потребностей, описывающий пики и «провалы» потребности репрезентативным образом. Чтобы лучше моделировать требуемую мощность, мы должны принять во внимание порядок следования смежных участков потребности в профиле L. Это достигается путем случайного выбора блоков по b интервалов tm,t<m+1,…,tm+b в данный момент времени из вхождений O. Более того, следует отметить, что вхождения могут иметь тренд τ. Для последовательности вхождений ретроспективного паттерна мы нормализуем значения потребности, чтобы исключить тренд относительно последнего вхождения, прежде чем строить O'.

Значения потребностей lo'(tm) в имитирующем профиле следует увеличить, чтобы отразить тренд τ. Мы принимаем аддитивную модель. Для каждого будущего вхождения o' мы вычисляем абсолютное значение на основе τ, которое следует добавить ко всем значениям потребности во вхождении o'. Чем дальше o' отстоит во времени, тем больше будет изменение по сравнению с ретроспективными данными, при условии что τ не равно нулю.

В процессе управления мощностью мы повторяем эти шаги анализа, используя множество случайным образом сгенерированных экземпляров L', чтобы лучше описать диапазон возможного поведения для системы в целом. Множество экземпляров лучше характеризует взаимное влияние потребностей для множества нагрузок.

Наконец, паттерн рабочей нагрузки P предоставляет удобный способ сформировать сценарии «что, если…» и бизнес-прогнозы, которые мы не можем наблюдать исходя из ретроспективных данных. Допустим, мы имеем паттерн P с числом вхождений O, и нам требуется изменить этот паттерн. Тогда мы можем задать это изменение один раз для паттерна P, а не отдельно для каждого из вхождений, которых может быть достаточно много.

Пример использования

Чтобы оценить эффективность наших методов и процессов, мы получили данные для построения профиля рабочей нагрузки за шесть месяцев для 139 нагрузок приложений, исполняемых в центре обработки данных. Этот центр специализируется на хостинге корпоративных приложений, таких, как системы управления взаимодействием с клиентами (CRM) и управления цепочками поставок, для малого и среднего бизнеса. Каждая нагрузка была размещена на своем собственном сервере, поэтому мы могли использовать измеренные значения потребности в ресурсах для сервера, чтобы характеризовать профиль потребности нагрузки. Измерения исходно проводились с помощью vmstat и sar. Каждый профиль описывает уровень использования ресурса (например, процессора), измеряемый через каждые 5 мин начиная с 1 января 2006 г.

В нашем примере рассматривается:

  • влияние различных определений понятия требуемой мощности;
  • общие результаты для центра обработки данных с использованием результатов метода анализа паттернов потребности для рабочей нагрузки;
  • проверка правильности методик выявления трендов и генерации имитирующей нагрузки;
  • тестовый прогноз, использующий методы сопоставления с паттерном, построения трендов и генерации имитирующей нагрузки.

Требуемая мощность

Теперь сравним следующие методы вычисления требуемой мощности, описанные в разделе «Требуемая мощность»:

  • на основе определения с простым скользящим окном с периодом перегрузки s = 30 мин;
  • 100, 99 и 95 процентили потребности (как оценки для требуемой мощности);
  • расчет с фиксированным окном с единственным ограничением U = 100%, P = 100% и s = 30 мин;
  • расчет со скользящим окном на единицу потребности с s = 30 мин.

Для метода расчета на единицу потребности мы не вводим ограничений для значения вероятности доступа к ресурсу θ. Мы включаем процентили потребности, чтобы оценить влияние периода перегрузки.

В таблице приведены результаты из подмножества данных, собранных за пять недель, для восьми нагрузок w1…w8 и двух совокупных нагрузок w1…4 и w5…8 в которые входят нагрузки w1…w4 и w5…w8 соответственно. Мы рассматриваем здесь совокупные нагрузки, поскольку при моделировании процесса выработки рекомендаций по размещению нагрузки нам приходится вычислять требуемую мощность и для совокупных нагрузок.
Требуемая мощность в единицах потребности
НагрузкаПростое скользящее окно100-p99-p95-pФиксированное окноСкользящее окно «на единицу потребности»
w1848946769621855839
w2538580402296553533
w375757574,77575
w43251,640,49,23622
w1…411931356103682712401164
w5464539406317449444
w6180180180179180180
w7414738,726,14040
w87712062518170
w5…8581672528431607558

Во втором столбце таблицы приведены результаты для метода простого скользящего окна, которое передвигает во времени неудовлетворенные потребности.

100-я процентиль — это пиковая потребность нагрузки; она всегда превышает другие оценки. Хотя 99-я и 95-я процентили часто малы по сравнению с результатами подхода со скользящим или фиксированным окном, они не дают никакого представления о продолжительности любых результирующих периодов перегрузки. Процентильный подход обычно недооценивает требуемую мощность и в результате не может предложить контролируемый уровень перегрузки.

Подход с фиксированным окном обычно приводит к завышенным значениям требуемой мощности, т. е. избыточному предоставлению ресурсов по сравнению с определением со скользящим окном. Это вызвано тем, что фиксированное окно накладывает больше ограничений, чем скользящее окно; когда P = 100%, все потребности должны быть удовлетворены в пределах каждого фиксированного окна. Ни процентильный, ни подход с фиксированным окном не учитывают влияние периодов перегрузки на единицы потребности. Однако такой учет полезен и необходим при выборе параметров настройки планировщика в диспетчере нагрузки [6].

Как и ожидалось, подход со скользящим окном на единицу потребности обычно приводит к слегка заниженным значениям требуемой мощности, т. е. более эффективному использованию мощности, чем определение с простым скользящим окном, так как он допускает более длительные периоды перегрузки — до тех пор, пока ни одна единица потребности не останется неудовлетворенной по истечении s = 30 мин. Более того, мы можем наблюдать значение θ, типичное для размещения нагрузок в центре обработки данных. Оператор пула ресурсов может предложить это как часть гарантии уровня обслуживания для данного пула.

Для нагрузки w4 подход на единицу потребности дает значительно заниженную оценку значения требуемой мощности, т. е. более эффективную мощность для пользователя. Данная конкретная нагрузка весьма неравномерна, периодически создавая пики потребности, о чем говорит также сравнительно большая разница между ее 99 и 95 процентилями потребности. На рис. 2 показаны расчетные значения требуемой мощности для w4 по сравнению с профилем потребности для нагрузки. Интересно, что разброс результатов, полученных разными методами, столь велик. Подход со скользящим окном на единицу потребности, очевидно, допускает для этой неравномерной нагрузки более длительные периоды перегрузки, чем подход с простым скользящим окном. Это может быть приемлемо, если явно циклические всплески потребности соответствуют пакетным заданиям и если требования пакетных заданий к времени выполнения допускают дополнительную задержку. Если в пуле ресурсов есть средства управления нагрузкой, обеспечивающие множество классов обслуживания, то владелец нагрузки может выбрать более высокий класс обслуживания для этих нагрузок с потребностями, которые нельзя отсрочить [6]. Учитывая эти дополнительных преимущества в производительности и гибкости, из всех определений требуемой мощности мы остановились на формулировке на единицу потребности и в дальнейших исследованиях использовали именно ее.

Тестовый прогноз

В этом разделе мы используем сервис прогнозирования потребности для нагрузки как часть процесса управления вычислительной мощностью. Мы проводим тестовое прогнозирование (walk forward test) на основе данных за шесть месяцев, чтобы оценить, насколько успешно наш процесс управления мощностью мог бы работать в центре обработки данных в течение этих шести месяцев.

  • Начиная с первой недели, окно с данными за w недель используется, чтобы рекомендовать для системы консолидированную конфигурацию C1 (т. е. каждая нагрузка назначена конкретному серверу). Конфигурация указывает ожидаемые значения требуемой мощности для каждого сервера в ней.
  • Затем для C1 данные за следующие y недель. Такое моделирование дает действительную требуемую мощность на следующие y недель.
  • Разность между оценкой мощности сервера и действительным значением требуемой мощности дает абсолютную погрешность для оценки требуемой мощности. Отрицательные погрешности указывают на «недооцененную» мощность, а положительные погрешности соответствуют «переоцененной». Мы используем специальную интегральную функцию распределения (CDF), которая отражает оба типа погрешности для теста прогнозирования.
  • На следующих итерациях шаги в тесте прогнозирования повторяются для данных за w недель, но теперь уже начиная с недели 2, 3 и т. д.
  • Пусть i — это номер шага в тесте прогнозирования. На шаге i вычисляется новая конфигурация Ci и новый набор разностей между оценкой и действительным значением требуемой мощности для каждого сервера.

Мы рассматриваем непрерывный процесс, где нагрузки повторно консолидируются на некотором количестве мощных серверов. Серверы имеют по восемь процессоров. В целом консолидация требует 13 или 15 серверов в каждый момент времени. Чтобы оценить эффективность методов прогнозирования потребности для нагрузки, мы рассматриваем несколько разных сценариев генерации имитирующих нагрузок. Эти сценарии включают:

  • анализ паттернов использования и выявление трендов;
  • один лишь анализ паттернов использования;
  • все нагрузки ассоциируются с ежедневным паттерном;
  • все нагрузки ассоциируются с 30-часовым паттерном (специально выбранным как некорректный).

В данном исследовании мы взяли w = 5 недель ретроспективных входящих данных для процесса и прогнозируем требуемую мощность на y = 1 неделю и y = 5 недель вперед. На рис. 3 и 4 показаны функции распределения погрешности прогнозов требуемой мощности для разных сценариев по всему тесту прогнозирования в целом. Отрицательная погрешность предполагает, что метод дает более низкое значение мощности, чем действительно требуется для сервера.

Рис. 3 иллюстрирует результаты прогноза на неделю вперед. Сценарии a) и b) дают почти неразличимые кривые. Построение трендов позволяет избежать двух больших, но близких отрицательных погрешностей. Фиксированный ежедневный паттерн без трендов, сценарий c), дает несколько больших по величине отрицательных погрешностей, чем вариант a), т. е. значений меньших -1 процессора. Явно некорректный 30-часовой паттерн из сценария d) приводит к грубым ошибкам.

Как видно из рис. 4, результаты прогнозирования требуемой мощности на пять недель вперед весьма сходны. Единственное различие состоит в том, что погрешности оказались чуть ниже для сценария b), т. е. без трендов, чем в варианте a) с трендами. И это вполне объяснимо: нашего ретроспективного окна в пять недель, по-видимому, недостаточно, чтобы прогнозировать тренды на пять недель вперед для всех нагрузок на всех шагах в тесте прогнозирования.

В обоих прогнозах, на неделю и на пять недель, сценарий a) оценивает требуемую мощность в расчете на сервер с точностью до одного процессора (из восьми) 95% всего времени.

Лучшая на сегодня в отрасли практика консолидации серверов определяет пиковую потребность каждой прикладной нагрузки и консолидирует приложения на небольшом количестве серверов таким образом, чтобы сумма пиковых потребностей приложений на каждом сервере была меньше, чем мощность сервера. Если мы сочтем нужным рекомендовать размещение нагрузок на основе пиковых потребностей каждого из приложений, нам потребуется 23 восьмипроцессорных сервера. При использовании метода на основе профилей, описанного в данной статье, потребуется лишь 15 серверов. Данный подход позволяет на 35% снизить использование процессоров по сравнению с размещением рабочей нагрузки, которое исходит только из пиковой потребности приложений. Точность прогнозов требуемой мощности предполагает, что такая экономия ресурсов достигается с небольшим риском.

Другие исследования

Мы используем подход на основе профилей, чтобы моделировать совместное использование вычислительной мощности внутри пулов ресурсов. Многие группы исследователей использовали такие методы для детальной оценки производительности процессорных архитектур [11]. Они также подходят для поддержки управления мощностью на основе более грубых данных, например, уровней использования ресурсов, регистрируемых каждые 5 мин.

В ряде ранних работ, посвященных оценке эффективности центра обработки данных, на основе профилей потребностей рабочих нагрузок прогнозировали возможности совместного использования ресурсов в корпоративных центрах обработки данных [1]. Рассматриваемый нами метод позволяет прогнозировать потребности на дни, недели и месяцы вперед. Мы видим различие между нашими методами и теми, которые обычно служат для прогнозирования потребности на несколько секунд или минут вперед. В методиках краткосрочных прогнозов чаще используются другие подходы, например, модели ARMA [4] или GARCH [8, 3]. Хотя эти подходы и годятся для очень коротких периодов времени, на интересующих нас временных промежутках такие прогнозы быстро сходятся к среднему значению. В работе [17] также описаны методы прогнозирования паттернов потребности в ресурсах, использующие периодограммы и автокорреляцию. Они сходны с теми методами, которые предлагаем мы, но не рассматривают тренды и генерацию имитирующей нагрузки, описанные в этой статье.

Профили были использованы в анализе «что, если…», в котором рассматривалось назначение нагрузок на консолидированные серверы. AOG [2] и TeamQuest [16] предлагают продукты, в которых методы на основе профилей используются для решения задач консолидации. AutoGlobe [14] предлагает самоорганизующуюся инфраструктуру, где имеющееся оборудование виртуализовано, сведено в пулы и постоянно отслеживается. Они представили контроллер на основе нечеткой логики, который контролирует все сервисы, исполняемые на аппаратной платформе. Если контроллер распознает исключительную ситуацию, он автоматически запускает действия, исправляющие ситуацию. В дополнение к нему предлагается модуль статической оптимизации, который использует ретроспективные данные о потребности для расчета рекомендаций по размещению нагрузки. При расчете рекомендаций используются эвристика «жадного» алгоритма.

Мы полагаем, что использованный нами сервис размещения нагрузки имеет преимущества перед другими описанными выше подходами. Он поддерживает сервисы консолидации и балансировки нагрузки, необходимые во всеобъемлющем процессе управления мощностью, и опирается на генетический алгоритм, стремящийся улучшить "жадные" решения размещения нагрузки. Более того, наши методы размещения нагрузки идут дальше, чем другие методы, затрагивая такие вопросы, как классы обслуживания и ограничения по размещению.

И наконец, предложенный нами подход к прогнозу требуемой мощности улучшает другие известные нам подходы, применяемые для пулов ресурсов. Он предусматривает вероятность доступа к ресурсу, исходя из которой можно разделить потребности каждой нагрузки между двумя классами обслуживания [6]. Некоторые исследователи предлагают ограничить требования мощности для прикладной нагрузки до процентили от ее потребности [15]. Но этот подход не учитывает влияния на работу пользователя постоянного падения производительности со временем, как это делает наше ограничение скользящего окна. Другие исследователи рассматривают только цели для ресурсов как целого [14] вместо того, чтобы разрешить каждой нагрузке иметь независимо установленную цель.

Выводы и дальнейшая работа

Мы описали процесс управления мощностью для пулов ресурсов. Процесс опирается на сервисы, автоматизирующие и упрощающие администрирование для операторов пулов ресурсов. В центре нашей работы были определения понятия требуемой мощности и методы прогнозирования потребности в ресурсах для нагрузки. Мы оценили эффективность наших методов на примере, в котором использовались данные о потребности в мощности для 139 корпоративных приложений за шесть месяцев работы. Автоматизированные методы предсказывали требуемую мощность для серверов, несущих нагрузку, с точностью до одного процессора из восьми 95% всего времени при прогнозировании на пять недель вперед, сократив при этом совокупные требования к процессорной мощности на 35% без значительных рисков. Используя такие методы предсказания, операторы пулов ресурсов могут решать, следует ли вводить дополнительные мощности в их пулы.

Сервис прогнозирования потребности для нагрузки опирается на методы выявления паттернов и трендов. Проведенная нами проверка на конкретном примере показывает, что прогнозирование трендов может быть полезным до тех пор, пока мы не слишком преувеличиваем глубину периода времени, на который, как мы полагаем, эти тренды сохранятся в будущем. Мы считаем, что методы прогнозирования потребности для нагрузки полезны для процесса управления мощностью. Они выявляют нетиповые варианты поведения, которые в будущем могут влиять друг на друга (например, трехдневные и пятидневные образы могут накладываться каждые 15 дней), и могут помочь выяснить, когда потребности нагрузки, по-видимому, отклоняются от ее поведения в прошлом.

Наша дальнейшая работа предполагает: разработку онлайновых автоматических методов мониторинга и отчетности о незапланированных изменениях параметров рабочей нагрузки; улучшенное использование уведомлений о достоверности и рисках в прогнозах требуемой мощности на будущее; лучшую интеграцию с бизнес-прогнозами для внесения изменений в наш подход. Кроме того, необходима дальнейшая работа по описанию характеристик паттернов потребности нагрузки для корпоративных служб, выступающих как Web-сервисы. Паттерны использования для этих сервисов могут отличаться от паттернов, описанных в данной статье.

* В этой статье мы не обсуждаем масштабирование потребностей в мощности между серверами с разной частотой процессоров или разными архитектурами.

Литература

  1. A. Andrzejak, J. Rolia and M. Arlitt, Bounding Resource Savings of Utility Computing Models, HPLabs Technical Report HPL-2002-339.
  2. http://www.aogtech.com.
  3. T. Bollerslev. Generalized Autoregressive Conditional Heteroskedasticity. Journal of Econometrics, 31:307—327, 1986.
  4. G. E. P. Box, G. Jenkins and G. Reinsel. Time Series Analysis: Forecasting and Control. Prentice Hall, Upper Saddle River, NJ, USA, third edition, 1994.
  5. I. Chakravarti, R. Laha, J. Roy.Handbook of Methods of Applied Statistics. Vol. I, John Wiley and Sons, pp. 392—394, 1967.
  6. L. Cherkasova and J. Rolia: R-Opus: A Composite Framework for Application Performability and QoS in Shared Resource Pools. Proc. of the Intl. Conf. on Dependable Systems and Networks (DSN’2006), Philadelphia, USA, 2006.
  7. N. R. Draper and H. Smith. Applied Regression Analysis. John Wiley & Sons, New York, NY, USA 1998.
  8. R. F. Engle. Autoregressive Conditional Heteroscedasticity with Estimates of the Variance of United Kingdom Inflation. Econometrica, 50(4):987—1008, 1982.
  9. J .A. Hartigan and M. A. Wong. A K-Means Clustering Algorithm. In Applied Statistics, vol. 28, pp. 100—108, 1979.
  10. ITIL: IT Infrastructure Library. www.itil.com.uk.
  11. J. Pieper, A.Mellan, J. Paul, D. Thomas and F. Karim. High Level Cache Simulation for Heterogeneous Multiprocessors. Proc. of the 41st Annual Conference on Design Automation, San Diego, CA, 2004.
  12. J. Rolia, X. Zhu, M. Arlitt and A. Andrzejak, Statistical Service Assurances for Applications in Utility Grid Environments. Performance Evaluation Journal, vol. 58, 2004.
  13. J. Rolia, L. Cherkasova, M. Arlitt and A. Andrzejak. A Capacity Management Service for Resource Pools. Proc. of the 5th Intl. Workshop on Software and Performance (WOSP’2005), Spain, 2005.
  14. S. Seltzsam, D.Gmach, S. Krompass and A. Kemper. Auto-Globe: An Automatic Administration Concept for Service-Oriented Database Applications. Proc. of the 22nd Intl. Conference on Data Engineering (ICDE’2006), Industrial Track, Atlanta, GA, 2006.
  15. B. Urgaonkar, P. Shenoy and T. Roscoe. Resource Overbooking and Application Profiling in Shared Hosting Platforms. Proc. of the 5th Symp. on Operating System Design and Implementation (OSDI’2002), Boston, MA, December, 2002.
  16. http://www.teamQuest.com
  17. M.Wimmer, V. Nicolescu, D. Gmach,M.Mohr, A. Kemper and H. Krcmar. Evaluation of Adaptive Computing Concepts for Classical ERP Systems and Enterprise Services. Proc. of the Joint Conference on E-Commerce Technology and Enterprise Computing, E-Commerce and E-Services (CEC’06 and EEE’06), San Francisco, CA, 2006.