Алгоритм динамического распределения ресурсов в облачной инфраструктуре (1187394), страница 4
Текст из файла (страница 4)
Для того чтобыисключить влияние тестовой нагрузки на обработку результатов,управление тестом и наоборот, был использован дополнительный сервер.Выбор полезной нагрузкиВ рамках данной работы было решено отойти от традиционногоподхода оценки серверных платформ на основе отдельных параллельныхприложений или тестов (TPC-C, TPC-E, TPC-W, SPECjbb, SPECjappserverи NAS [16]) в качестве целевых нагрузок. Анализ результатов тестовпроизводительности сервера сам по себе представляет собой серьезнуюзадачу, поскольку эталонные тесты имеют сложное поведение, требуютмножественных клиент-серверных систем и трудны для запуска на28полнофункциональных симуляторах.
Тем не менее, отраслевые иакадемические исследователи справились с этой проблемой, разработавсимуляции. Поскольку центры обработки данных начали использоватьвиртуализацию как средство консолидации нескольких приложений насервере,становитсякритическиважным,корректнооценитьпроизводительность как виртуализационных технологий, так и средствуправления ними.Отраслевыми эталонами для решения этой проблемы являютсяvConsolidate [17] и SPECvirt [21].
Одно из них предоставил комитет SPECзанимающийся стандартизацией бенчмарков.Основные соображения при моделировании производительностивиртуальных машин (ВМ) можно резюмировать следующим образом:1. Производительность виртуальной машины зависит не только отее собственных характеристик, но также зависит от помех,вызываемых другими виртуальными машинами, работающими наодной платформе с ней.2. Вышеуказанные помехи могут быть вызваны:a. использованием общих ресурсов (например, машинноговремени, оперативной памяти), которое можно отследитьчерез счетчики производительностиb. использованием общих ресурсов (кэш-памяти, пропускнойспособности межпроцессорной шины, шины памяти и т.д.),которые невидимы для операционной системы, посколькуони являются прозрачными ресурсами, управляемымиаппаратным обеспечением.293. Особенноститехнологиивиртуализацииидисциплиныпланирования, принятые монитором виртуальной машины, могутбыть совершенно разными на любой данной платформе.
Подходмоделирования должен учитывать технологию виртуализации, атакже требуемую эвристику планирования.Таким образом, выбранный подход к моделированию долженпринимать во внимание как видимые, так и невидимые факторы влиянияресурсов на производительность.В соответствии со всем вышесказанным в качестве полезнойнагрузки использовались vConsolidate и SPECvirt.Тест vConsolidate состоит из вычислительной интенсивной рабочейнагрузки, рабочей нагрузки базы данных и рабочей нагрузки веб-сервера.Каждая из этих рабочих нагрузок выполняется в собственной виртуальноймашине.
Для эмуляции среды реального мира в микс добавляетсяпростаивающая виртуальная машина, поскольку центры обработкиданных не используются полностью все время.Симуляция каждого типа нагрузки выполняется на отдельнойвиртуальной машине:● интенсивные вычисления эмулируются на VM с набором тестовSPECjbb;● нагрузку на память и диск создаёт VM с тестом Sysbench;● за нагрузку на сеть отвечает VM с тестом Webbench;● отдельная виртуальная машина находится в состоянии “простоя”,когда исполняется только рутинные задачи гостевой операционнойсистемы.30Обычно, SPECjbb – это интенсивная загрузка процессора, котораяпотребляет столько CPU, сколько возможно. Однако в этой среде, аименно vConlidate, SPECjbb был изменен, чтобы потреблять примерно75% процессора, вставляя в случайное время простоя каждые несколькомиллисекунд.ТестWebbench,используетApacheWebserver.Конфигурация, как описано выше, с 4 ВМ, работающими с разнымирабочими нагрузками, включает консолидированный стековый блок(consolidated stack unit) или CSU.
Отдельно стоит отметить, что в нашемтестовом стенде клиент и канал для запросов на веб-сервер быливыделены отдельные для снижения влияния состояния внутренней сети наизмерения.SPECvirts – первая сравнительная оценка производительности SPECдля серверов, предназначенных для работы в центрах обработки данных сиспользованиемнескольковиртуализированныхсуществовавшихранеесред.Внагрузок,тестеиспользуетсяразработанныхSPEC,представляющих приложения, которые являются общими задачами,решаемыми серверами в центрах обработки данных.
Эти рабочие нагрузкиявляютсямодифицированнымиверсиямиSPECweb2005,SPECjAppServer2004 и SPECmail2008. Консолидированный стековый блок(consolidated stack unit) или CSU в SPECvirt состоит из шести виртуальныхмашин, каждая из которых выполняет определенную рабочую нагрузку.Существуют тесты производительности семейства VMmark [22],разработанные компанией VMware. Тесты версии 1.х [19] запускают нафизической машине наборы виртуальных машин с запущенными внутритестами. Оценка теста производится также, как и в тесте VConsolidate:оценкадостигаетсяспособности,путемдостигаемойизмерениясовокупнойпропускнойнесколькими31рабочиминагрузками,выполняемыми одновременно на платформе виртуализации;далеевычисляется среднее геометрическое для нормированных индивидуальныхоценок по блокам виртуальных машин, а показания по этим блокам затемсуммируются.Набор из шести конкретных рабочих нагрузок, каждый на своейсобственной виртуальной машине, запускается в течение определенногопериода времени.
Эти шесть виртуальных машин рабочей нагрузкисовместно определяются как плита VMmark (от англ. tile). В дополнение кэтому счету, каждый результат VMmark также включает в себя количествоплиток VMmark, используемых в эталонном прогоне. Отчет VMmarkтакже включает исходные и нормализованные результаты для каждойосновной рабочей нагрузки, а также полную информацию о конфигурацииплатформы виртуализации.Плитка представляет собой набор из шести разнообразных рабочихнагрузок,одновременновыполняющихопределенноепрограммноеобеспечение. Работая на одной из двух отдельных операционных систем,каждая рабочая нагрузка запускается на собственной виртуальной машинеи выполняет приложения, найденные во всех мировых центрах обработкиданных.
В одну плиту входят:● веб-сервер● файловый сервер● почтовый сервер● база данных● java-сервер32● незанятая машинаКаждая виртуальная машина в плитке настроена на использованиетолько доли общих ресурсов системы.Плитка VMmark 2.х [20] представляет собой группу из восьмивиртуальныхмашин,одновременновыполняющихколлекциюразнообразных рабочих нагрузок. Каждая из этих рабочих нагрузокпредставляет собой общую рабочую нагрузку приложения, найденную всовременных центрах обработки данных.
В каждую плитку входят:● почтовый сервер● база данных Web 2.0● веб-система, связанная с этой базой данных (3 реплики)● база данных электронной коммерции● интерфейсный веб-уровень, связанный с этой базой данных● незанятая машина.Таким образом, одна плитка состоит из двух рабочих нагрузокодноуровневого приложения, двух рабочих нагрузок многоуровневыхприложений и четырех рабочих нагрузок на уровне инфраструктуры.VMmark 2.x был спроектирован как тест, запускаемый на сервере.Он отражает типичное современное использование виртуализованнойинфраструктуры.Более высокая оценка VMmark 2.x означает, что платформавиртуализации способна поддерживать большую пропускную способностьв смешанной среде консолидации рабочей нагрузки, одновременно33работая в центрах обработки данных в фоновом режиме.
Большееколичество плиток VMmark 2.x, используемых для создания эталона,означает, что платформа поддерживала большее количество виртуальныхмашин на несколькиххостах во время тестового теста.В дополнение к измерению производительности в предыдущихверсиях VMmark, VMmark 2.5 добавляет возможность измерения какабсолютного потребления энергии, так и энергоэффективности серверов ихранилищ, используемых в тестовых тестах. Это позволяет приниматьрешения о покупке не только абсолютной производительности, но ипроизводительности на киловатт, что становится все более значительнымфактором общей стоимости владения вычислительными ресурсами.Хотя данное семейство тестов покрывает больший функционал, онизаточены под использование с виртуализационными средствами компанииVMware. Целью данных тестов является оценка производительностисерверов, а не виртуализационных уровней.Данное ограничение не позволяет использовать данное семействотестов для исследования, проводимого в работе.Описание алгоритмаДля выбора NUMA узла при первичном размещении виртуальныхмашин используется приближенное решение задачи о многомерномрюкзаке«первыйподходящий».Вкачестверазмероврюкзакаиспользуется объём оперативной памяти и доступные для использованияфизические процессоры.
Это необходимо для соблюдения локальностиданных и вычислителя, что повышает производительность на системах сNUMA архитектурой. Однако это не всегда возможно, например, как в34случае, приведённом в обзоре существующих алгоритмов.Для того чтобы восстанавливать локальность данных, не допускатьпростоя вычислительных мощностей и исключить накладные расходы,которые не приводят к улучшению производительности системы в целом,введём понятие потребления ресурса.
Потреблением ресурса будемназывать отношение использованного ресурса (машинного времени,оперативнойпамяти,каналамежпроцессорнойшины)кобщемуколичеству доступного ресурса для использования в рамках указанногоNUMA узла.При каждом изменении состояния виртуальной машины (запуск,остановка, пауза и т.д.) или раз в несколько минут выполняетсябалансировка потребления ресурсов виртуальными машинами междуNUMA узлами:1.Вычисление потребления ресурсов каждой ВМ в рамкахкаждого NUMA узла.2.Формирование списка ВМ, для которых не выполняетсяусловие локальности (данные размещены в рамках двух илиболее NUMA узлов) и межпроцессорная шина использоваласьслишком активно.3.Далее из списка узлов выбирается наиболее загруженный инаименее загруженный узлы (те у которых выше или ниже чему остальных сумма потребленной памяти соответственно).4.Далеедлякаждойвиртуальноймашиныизсписка,составленного на 2 шаге, проверяется гипотеза, что её привязкак узлу с меньшим потреблением приведёт к уменьшению суммы35квадратов отклонения от средней загрузки узлов.5.Если на 4 шаге было найдено несколько ВМ, удовлетворяющихусловию, привязывается ВМ с наименьшим суммарнымпотреблением памяти не на узле назначения для уменьшениянакладных расходов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
