Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Московский физико-технический институт (государственный университет)

Факультет управления и прикладной математики

Кафедра Теоретической и прикладной информатики

(Направление подготовки 010900 «Прикладные математика и физика», Магистерская программа 010956 «Математические и информационные технологии»)

Выпускная квалификационная работа

Балансировка нагрузки высокопроизводительного кластера

студента 873 группы

Петрова Дмитрия Игоревича

Научный руководитель

д.ф.-м.н. Тормасов А.Г.

г. Долгопрудный 2014

Оглавление

• Введение
• Понятие о виртуальной памяти
• Физическая память
• Виртуальная память
• Страничная адресация
• Сегментная модель
• Пейджинг9
• TLB Кэш
• Аппаратно-независимая оптимизация работы с памятью
• Алгорим FIFO
• Алгоритм LRU
• Алгоритм NFU
• Эвристика «рабочее множество процесса»
• Пробуксовка
• Формализация
• Релизация модели «Рабочее множество»
• Виртуализация
• Типы виртуализации
• Виртуализация аппаратуры
• Виртуализация рабочего места
• Виртуализация программного обеспечения
• Безопасность виртуализации
• Контейнерная виртуализация
• Обзор технологии
• Миграция контейнеров
• Реализация
• Методы балансировки и результаты
• Distributed resource management
• Метод оценки Process working set (PWS)
• Заключение
• Список публикаций автора
• Список литературы
• Приложение. Вычисление PWS

Введение

виртуальный память оптимизация программный

Проблема распределения нагрузки в высокопроизводительных вычислительных систем стоит весьма остро уже несколько десятилетий. Особенно интересна данная задача в применении к современным виртуальным сервисам. Переход от реального железа к виртуализованному позволяет решать сразу несколько важнейших задач. Нет необходимости в физической машине, её техническому обслуживанию, обеспечению электричеством, охлаждения. Снижается плата за аренду площадей под дата-центры. Кроме того, в рамках одной реальной машины («хоста») могут сосуществовать несколько машин на различных операционных систем. [5]

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

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

Понятие о виртуальной памяти

Прежде чем рассматривать вопросы виртуализации и балансировки стоит рассмотреть абстракцию «виртуальная память», принятую во многих современных операционных системах. Прежде всего, мы рассматриваем семейство GNU/Linux, как одну из самых распространённых хостовых ОС. Организация этой подсистемы имеет непосредственное отношение к вопросам балансировки.

Физическая память

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

Наравне с центральным процессом, память является важнейшей частью фон-неймановской архитектуры, начиная с 40-х годов XX века. Имеет иерархическую структуру: начиная с процессорных регистров (самая быстрая и дорогая память), один или более уровней кэшей, и заканчивая, собственно, оперативной памятью. Часто эту иерархию продолжают и до внешних запоминающих устройств, как-то: жёсткие диски, флэш-память, компакт-диски и т.п. (см. рис. 1)

Рис. 1. Иерархия памяти.

В дальнейшем под этим термином будем понимать динамическую память с произвольным доступом (DRAM), -- которая в настоящее время используется в качестве ОЗУ персонального компьютера.

Задачей компьютерной памяти является хранение в своих ячейках состояния внешнего воздействия, запись информации. Эти ячейки могут фиксировать самые разнообразные физические воздействия (см. ниже). Они функционально аналогичны обычному электромеханическому переключателю и информация в них записывается в виде двух чётко различимых состояний -- 0 и 1 («выключено»/«включено»). Специальные механизмы обеспечивают доступ (считывание, произвольное или последовательное) к состоянию этих ячеек.

Процессор взаимодействует с памятью, выполняя машинные команды; к примеру, MOV (загрузка данных из ОЗУ в регистр или наоборот).

Виртуальная память

Хотя физическая память имеет довольно простую структуру, а именно, пронумерованный массив данных, в многозадачных ОС могут возникнуть определённые трудности. Действительно, одним из важнейших свойств процессов является их изоляция, которую крайне соблюсти в случае совместного пользования ОЗУ. Эту проблему можно разбить на несколько более простых подзадач.

1. Защита данных одного процесса от возможных изменений другими работающими процессами.

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

3. Возможность использовать больший объём памяти, использую внешнюю память.

4. Оптимизация использования ОЗУ: хранить только те данные, которые реально требуются системе.

Наиболее частым решение этой проблемы является использование абстракции «виртуальной памяти». Виртуальная память - это сочетание памяти ОЗУ и временного хранилища на жестком диске. Если памяти ОЗУ недостаточно, данные из оперативной памяти помещаются в хранилище, которое называется файлом подкачки. Перемещение данных в файл подкачки и из него освобождает достаточно оперативной памяти для выполнения операции.

Как правило, чем больше объем установленного в компьютере ОЗУ, тем быстрее работают программы. Если нехватка оперативной памяти замедляет работу компьютера, то для ее восполнения можно увеличить размер виртуальной памяти. При этом необходимо учитывать, что чтение данных из ОЗУ выполняется значительно быстрее, чем с жесткого диска, поэтому в качестве решения больше подойдет добавление ОЗУ.

В большинстве современных операционных систем виртуальная память организуется с помощью страничной адресации. Оперативная память делится на страницы: области памяти фиксированной длины (например, 4096 байт), которые являются минимальной единицей выделяемой памяти (то есть даже запрос на 1 байт от приложения приведёт к выделению ему страницы памяти). Процесс обращается к памяти с помощью адреса виртуальной памяти, который содержит в себе номер страницы и смещение внутри страницы. Процессор преобразует номер виртуальной страницы в адрес соответствующей ей физической страницы при помощи буфера ассоциативной трансляции. Если ему не удалось это сделать, то требуется обращение к таблице страниц (так называемый Page Walk), что может сделать либо сам процессор, либо операционная система (в зависимости от архитектуры). Если страница выгружена из оперативной памяти, то операционная система подкачивает страницу с жёсткого диска (см. свопинг). При запросе на выделение памяти операционная система может «сбросить» на жёсткий диск страницы, к которым давно не было обращений. Критические данные (например, код запущенных и работающих программ, код и память ядра системы) обычно находятся в оперативной памяти (исключения существуют, однако они не касаются тех частей, которые отвечают за обработку аппаратных прерываний, работу с таблицей страниц и использование файла подкачки).

Представление о том, как это работает, можно получить из рис. 2 на примере двух процессов: fileA.exe и fileB.exe. У каждого из них есть своё собственное непрерывное виртуальное адресное пространство (закрашенные прямоугольники - занятые страницы) и общее физическое. Часть виртуальных страниц транслируются в страничные кадры ОЗУ, другая часть выгружена в кэш. Логика работы процессов основывается на предположении о том, что других процессов в системе нет, а память имеет вид массива.

Рис. 2. Пример организации виртуальной пАМЯТИ

СТРАНИЧНАЯ АДРЕСАЦИЯ

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

Сегментная модель

На уровне сегментов адрес преобразуется из виртуального в линейный. По виртуальному адресу вычисляется сегмент и смещение в сегменте. Большинство современных операционных систем, однако, используют так называемую плоскую модель памяти (flat model). При этом все сегменты начинаются с нулевого адреса, и фактически на этом уровне преобразование становится тождественным. В архитектуре x86-64 при включенном 64-битном режиме сегментация не используется.

Пейджинг

На уровне пейджинга адрес преобразуется из линейного в физический. Пейджинг можно отключить, в таком случае преобразование будет тождественным. В архитектуре Intel существует три режима пейджинга: 32BIT, PAE, EM64-T. Всех их объединяет следующая общая схема: есть несколько уровней пейджинговых структур (paging structure), элементы которых содержат физические адреса страниц, в том числе это может быть, например, адрес, содержащий другую (или даже ту же) пейджинговую структуру. Кроме физического адреса в элементах пейджинговых структур хранятся различные флаги. Среди них флаги, отвечающие за права доступа, за совместное использование страниц (для мультипроцессорных систем), флаги, устанавливаемые при произведении доступа к странице.

Таким образом, получается некий ориентированный граф, в котором вершины - это пейджинговые структуры и пользовательские страницы памяти, а ребра задаются элементами этих структур (paging structure entries). Структура верхнего уровня - одна, ее адрес содержится в специальном регистре (CR3). Линейный адрес задает путь в этом графе от структуры верхнего уровня до некоторой страницы. Делается это следующим образом: линейный адрес делится на несколько частей. Первая часть задает номер элемента (ребра графа) в первой вершине (структуре первого уровня), так определяется вторая вершина пути. Вторая часть линейного адреса дает номер ребра во второй вершине и так далее до конечной физической страницы, в которую и отображается заданная нашим виртуальным адресом страница виртуальной памяти (смещение внутри страницы остается неизменным при преобразовании). Этот процесс проще понять, глядя на следующий рисунок.

Рис. 3. Пример многоуровневой страничной адресации

TLB Кэш

Обращение к памяти - очень частая операция, поэтому выполняться она должна быстро. Каждый раз при доступе к странице просчитывать страничные преобразования заново не экономично. Поэтому процессор сохраняет найденный физический адрес вместе с необходимыми флагами в специальный кэш - TLB (Translation lookaside buffer - кэш страничных преобразований). TLB кэш является ассоциативной памятью, поиск в нем страницы по виртуальному адресу занимает в 10-60 раз меньше времени, чем обход таблиц страниц. При добавлении в граф пейджинга новых страниц (мапировании) TLB кэш подстраивается автоматически. Действительно, при обращении к новой странице процессор не найдя в TLB нужной записи обойдет таблицы страниц и добавит новую страницу в TLB. При удалении страниц, или более серьезном изменении дерева пейджинга (например, при переключении между процессами в операционной система) необходимо уведомить процессор о том, что одна или несколько записей в TLB стали недействительны. Это может быть, например, инструкция INVLPG, указывающая на недействительность записи с конкретным виртуальным адресом. Также, кэш TLB автоматически сбрасывается при переключении регистра CR3 [6].

Схематично логика работы TLB изображена на рис. 4.

РИС. 4. ЛОГИКА РАБОТЫ TLB

Аппаратно-независимая оптимизация работы с памятью

До сих пор мы рассматривали реализацию виртуальной память на уровне аппаратного обеспечения. Однако на уровне операционной системы доступны некоторые дополнительные механизмы оптимизации. Прежде всего, это касается механизма своппинга (выгрузки страниц физической памяти). В самом деле, скорость доступа к оперативной памяти отличается от скорости доступа к диску на порядки, поэтому целесообразно минимизировать время использования HDD. Система обращается к своп-файлу при возникновении исключительной ситуации “пропуск страницы” (page fault, pf). Задача оптимизации времени работы заключается в минимизации числа этих ситуаций. Для этого необходимо выбрать грамотную стратегию выгрузки страниц. Несложно представить идеальный алгоритм откачки: достаточно убирать ту страницу, которую меньше всего будут использовать. Проблема заключается в отсутствии «оракула», который бы предсказывал дальнейшую судьбу страниц в памяти.

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

Алгорим FIFO

Одним из простых в реализации является алгоритм FIFO (first in, first out - первым вошёл, первым вышел). Нужно просто вытеснять самую долгоживущую в памяти страницу. При этом не делается никаких предположений о важности замещённой памяти, и велик риск отгрузить на диск активно используемую страницу.

Алгоритм LRU

Более привлекательным выглядит алгоритм “least recently used”. В отличие от предыдущего, он проверяет не только время загрузки страницы, но и время её использования.

Действительно, если выделенная память давно не использовалась, то велика вероятность того, что она и дальше не будет востребована. Таким образом, будущее аппроксимируется настоящим.

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

Алгоритм NFU

Упрощением предыдущего метода является алгоритм “Not frequently used”. Страницам присваиваются счётчики обращений. После прерывания нужно увеличить счётчик страницы, к которой обращались и вытеснить ту, у которой он самый маленький.

Очевидным недостатком является наличие страниц с высоким числом обращений, но которые затем перестали быть нужными. Иными словами, алгоритм ничего «не забывает».

Эвристика «рабочее множество процесса»

В основе данного подхода лежит предположение о том, что процесс использует ограниченное количество активно используемых страниц.

Пробуксовка

Действительно, будем уменьшать количество доступных страничных кадров для процесса и замерим частоту page fault'ов. Результат представлен на графике. Как проинтерпретивать этот результат? Его можно понять следующим образом. У процесса есть некое множество важных часто используемых страниц. Если это множество не помещается целиком в физической памяти, система начинает часто обращаться к диску за выгруженными страницами. Эта ситуация называется «пробуксовкой» (иначе «трэшинг», англ. «trashing»), она сильно снижает производительнось системы. Особенность трешинга в том, что его наличие не зависит от выбранного алогоритма замещения страница. Это значит,что это явление полностью связано с поведением процесса и выделенному его месту в физической памяти.



Рис. 5. Зависимость частоты страничных исключений от количества доступных страничных кадров процесса

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

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

Формализация

Итак, зафиксируем два момента времени работы процесса t и T, t > T. Рабочим множеством W(t, T) называется совокупность страниц, на которые ссылается процесс в интервал времени (t-T, T)

Зафиксируем t = k и будем увеличивать длину временного интервала. Результат представлен на рис. 6. [1]

Рис. 6. Изменение рабочего множеста от длины временного промежутка

Быстрый начальный рост графика обусловлен тем, что в начале работы у процесса ещё нет в памяти всех нужных ему страниц. В этот период происходят частые page faults.

Стоит отметить, что рабочий набор может меняться с течением времени. Например, из-за вызова подпрограмм. При этом велика вероятность возврата к старому множеству при частом переключении процедур. Можно сказать, что working set определяется совокупностью программного кода и программных данных.

Тем не менее, можно полагать, что PWS не будет сильно меняться на небольших временных интервалах в силу принципа локальности, принятого при проектировании операционных систем. [2]

Релизация модели «Рабочее множество»

«Лобовая» реализация данного подхода продемонстрирована на рис. 7.



Рис. 7. Алгоритм «Рабочее множество»

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

Модификацией этого алгоритма является алгоритм WSClock [1].

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

Виртуализация.

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

Все эти достоинства приводят к неуклонному росту использования виртуализационных решений в бизнесе и других областях

Типы виртуализации.

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

Виртуализация аппаратуры.

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

Далее будут рассмотрены некоторые подтипы аппаратной виртуализации.

Эмуляция.

Полностью программная эмуляция оборудования. Такой подход ведет к большим потерям производительности, так как в действительности, на одну инструкцию кода гостевой операционной системы (или другой выполняемой на виртуальной машине программы) приходится 100, а то и 1000 инструкций физического процессора. Существование полной эмуляции оправдывается возможностью на одной архитектуре эмулировать совершенно другую (архитектура), пусть и с потерями производительности. [6]

Полная виртуализация.

При полной виртуализации (full virtualization) значительная часть гостевого кода исполняется на реальном процессоре напрямую. Это дает огромную выгоду по производительности, практически мы получаем возможности в real time работать с операционной системой в виртуальной машине почти как с исполняющейся на настоящем железе. Естественно, такой подход накладывает свои ограничения и сложности. В частности, нельзя напрямую исполнять все инструкции. Гостевая операционная система не должна получить прямого доступа к аппаратным ресурсам, из соображений безопасности и просто потому, что аппаратные ресурсы разделяются между несколькими операционными системами. Роль программной прослойки, управляющей предоставлением ресурсов виртуальным машинам, решающей какие инструкции выполнять напрямую, а какие эмулировать выполняет, так называемый, гипервизор.

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

Нужно заметить, что в некоторых источниках под полной виртуализацией понимается только то, что гостевое программное обеспечение не требует никаких изменений, то есть мы получаем полноценную систему (виртуальную). При таком подходе полная эмуляция может быть подвидом полной виртуализации (если конечно выполнено указанное требование). [4]

Аппаратная виртуализация.

По сути своей, является полной виртуализацией, но огромную часть работы берет на себя оборудование. В настоящее время существуют технологии аппаратной виртуализации процессора (VT-x у Intel, AMD-V у AMD), виртуализации памяти (так называемый “nested paging”, будет рассмотрен далее), виртуализации сетевых карт и других устройств. Аппаратная виртуализация значительно упрощает труд разработчиков виртуализационного программного обеспечения, приводит к увеличению производительности, фактически, в результате получаем производительность, приближающуюся к производительности реальных машин. Впрочем, такой подход требует еще более жесткой привязки к архитектуре, в том смысле, что, например, используя Intel vt-x, мы ограничиваемся хостовыми машинами с поддержкой Intel vt-x и гостевыми машинами с совместимыми процессорами.

Паравиртуализация.

При паравиртуализации подразумевается встраивание кода, отвечающего за виртуализацию аппаратных ресурсов в саму гостевую систему. При этом отпадает необходимость, как при полной виртуализации определять какие инструкции являются безопасными и допускаются к прямому запуску на процессоре, а какие не безопасны и требуют эмуляции. В измененной нужным образом гостевой операционной системе и не будет небезопасных инструкций, в место них возможны вызовы API гипервизора. Минус паравиртуализции в том, что она требует изменения кода гостевой системы, то есть, фактически, кроме привязки к конкретной архитектуре мы привязаны еще и к гостевой операционной системе. Здесь уже не идет речи о том, что гостевая операционная система не знает, что выполняется на виртуальной машине. С другой стороны по производительности паравиртуальные машины приближаются к реальным. [4]

Гипервизор.

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

Гипервизор предоставляет возможности по отдельному отключению или включению машин, подключению к ним различного эмулированного оборудования, а также и «проброс» реального оборудования в виртуальную машину (например, клавиатуры и мыши, или даже сетевой карты и cd-привода).

Гипервизоры разделяют на два типа: запускаемые на аппаратуре как операционные системы (на “bare metal”) и запускаемые под обычной операционной системой.

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

Гипервизоры второго типа работают под некоторой операционной системой, такой как Windows или Linux. Такой вариант более доступен обычным пользователям, кроме того исчезает необходимость в драйверах устройств, так как низкоуровневая работа с устройствами в данном случае ложится на плечи хостовой операционной системы.

Вернемся теперь к рассмотрению остальных типов виртуализации.

Виртуализация рабочего места.

Концепцией виртуализации рабочего места является отделение логического рабочего места от физической машины. Примером такой виртуализации является VDI (virtual desktop infrastructure - инфраструктура виртуального рабочего стола), при которой вместо того, чтобы оперировать с хостовым компьютером используя подключенные к нему клавиатуру, мышь и монитор, пользователь взаимодействует с ним используя другой компьютер или мобильное устройство, которое связано с хостом с помощью компьютерной сети. При этом на хостовом компьютере может быть одновременно запущенно несколько виртуальных машин для разных пользователей. Такой подход может быть рассмотрен как надстройка над описанной выше виртуализацией аппаратуры. [4]

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

Виртуализация программного обеспечения.

Сюда включаются три подтипа:

1) Виртуализация уровня операционной системы

2) Виртуализация приложений

3) Виртуализация сервисов

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

Виртуализация уровня приложения тесно связана с понятием переносимости программ. В данном случае приложение абстрагируется (в той или иной степени) от операционной системы, на которой оно выполняется. Сюда относится, например, возможность запуска одной и той же программы (без перекомпиляции) в разных версиях Windows. Также сюда можно отнести такие технологии как flash или java, требующие для запуска приложений специального модуля, который уже может быть различным для разных операционных систем, но сами приложения при этом переносимы.

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

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

Безопасность виртуализации.

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

Можно привести следующий пример. Виртуализация широко применяется при изучении вредоносного программного обеспечения (например, компаниями, разрабатывающими антивирусы). При этом необходимо, чтобы программа, запущенная под виртуальной машиной не могла испортить данные в хостовой системе или нарушить ее работу. Кроме того, нужно чтобы программа функционировала под виртуальной машиной также как и на реальной аппаратуре. Ошибки и не точности в реализации виртуальных машин могут привести к нарушению этих двух требований. Доказательством этого служит существование так называемых “red pills” - программ, умеющих определять, выполняются они на виртуальной машине или на реальной. [2]

Причинами уязвимостей становятся ошибки и недоработки разработчиков программного обеспечения, поэтому большое внимание уделяется тестированию продукта.

Контейнерная виртуализация

Особую распространённость в последнее время получил тип виртуализации, не попадающий под классификацию, приведённую выше. Он получил особое распространение на «облачных» серверах, так как позволяет экономить ресурсы кластера без потери производительности. Речь идёт о так называемых контейнерах.

Обзор технологии

Рассмотрим на наглядном примере. «Классический» виртуальных хост можно схематически изобразить так (рис. 8.)

Имеется сервер с реальным железом и установленной операционной системой. Внутри ОС существуют виртуальные машины, которые используют виртуальное аппаратное обеспечение.

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

Решение заключается в отказе от полного воссоздания аппаратного обеспечения для виртуальных машин и слияние их ядер с ядром хоста.



Рис. 8. «Классический виртуальный хост»

Легко видеть, что при таком подходе все виртуальные машины, по сути, являются одной и той же операционной системой. Это делает хост некроссплатформенным, но даёт замечательные результаты в плане изоляции и производительности.

С такими поправками схема будет выглядеть следующим образом (рис. 9)

Виртуальные машины являются изолированными контейнерами, работающие на общем ядре (ядре операционной системы-хозяина). Иными словами, Контейнерная виртуализация не использует виртуальные машины, а создает виртуальное окружение с собственным пространством процессов и сетевым стеком. Экземпляры пространств пользователя (часто называемые контейнерами или зонами) с точки зрения пользователя полностью идентичны реальному серверу, но они в своей работе используют один экземпляр ядра операционной системы. Для linux-систем, эта технология может рассматриваться как улучшенная реализация механизма chroot. Ядро обеспечивает полную изолированность контейнеров, поэтому программы из разных контейнеров не могут воздействовать друг на друга.

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

Рис. 9. Контейнерный виртуальный хост

Миграция контейнеров

Важным преимуществом контейнерного подхода к виртуализации является способность свободного перемещения контейнеров от одного хоста к другому без существенных потерь в производительности.[15, 16] Это позволяет гибко проводить балансировку нагрузки на вычислительных узлах (рис.10).

Рис. 10. Миграция контейнеров.

Разделяют два типа миграции

Checkpointing и live-migration.

· Live-migration - миграция контейнера с одной HardwareNode на другую без выключения контейнера. Время простоя системы составляет, обычно, несколько секунд. На новую HardwareNode восстанавливается дамп памяти контейнера (с запущенными процессами)

· Checkpointing - технология, позволяющая заморозить контейнер, и восстановить его состояние из дампа памяти. Удобно, например, для создания бэкапа контейнера, интенсивно работающего с базой данных, транзакции которой не могут быть оборваны некорректно

Реализация

В большинстве Linux-системах контейнеры реализованы посредством механизма cgroups. Таким способом организованы, к примеру, следующие технологии контейнерной виртуализации: OpenVZ, Linux-VServer, LXC.

Control groups (сокращённо - cgroups) -- механизм ядра Linux, который ограничивает и изолирует вычислительные ресурсы (процессорные, сетевые, ресурсы памяти, ресурсы ввода-вывода) для групп процессов. Механизм позволяет образовывать иерархические группы процессов с заданными ресурсными свойствами и обеспечивает программное управление ими.

По своей сути, cgroups - это набор процессов, объединённых по некоторым признакам, группировка может быть иерархической с наследованием ограничений и параметров родительской группы. Остаётся вопрос об управлении cgroups. Можно использовать несколько методов.

· Прежде всего, для cgroups создана своя виртуальная файловая система, которая называется cgroup. Этот процесс аналогичен отслеживанию информации о процессах через /proc.

· Можно использовать библиотеку libcgroup и её утилиты, как-то: cgcreate, cgexec, cgclassify.

· Существует так называемый демон механизма правил (rules engine daemon). После его конфигурирования, он автоматически перемещает процессы определённых пользователей, групп или команд в cgroups.

· Прочие непрямые методы, так или иначе обращающиеся к cgroups.

Управляющие группы удобно использовать для создания контейнеров по ряду причин. Они предоставляют такой функционал, как:

· Введение ограничения на использование ресурсов, например, виртуальной памяти

· Введение приоритетов. Разным группам можно выделять ресурсы с определёнными ограничениями.

· Изоляция. Каждая группа «живёт» в своём пространстве имён и не имеет доступа к файлам и сетевым соединениям другой

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

Методы балансировки и результаты

В данной работе рассматриваются два метода балансировки: Distributed resource management и анализ Process working set.

Distributed resource management

В данной главе рассматриваются результаты разработок, полученных на основе технологии DRM от VMWare. Прежде всего, разберёмся с терминологией.

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

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

• Для собственно балансировки вводятся следующие параметры, смысл которых будет разъяснён ниже.

Ш Reservation, R (нижняя граница). Число, характеризующее минимально необходимое количество ресурса для работы виртуальной машины

Ш Limit, L (верхняя граница). Максимально потребное значение ресурса

Ш Shares, S(“вес”). Показывает приоритетные виртуальные машины при распределении ресурсов

• Resource pool (RP) - поименованная совокупность виртуальных машин и/или других pool'ов. Образуют иерархическую структуру согласно бизнес-логике.

Наша система будет иметь примерно следующий вид (рис. 11)



Рис. 11 ПРимер организации виртуальных машин в DRM

На рисунке представлено «ушедшее в облако» предприятие. Resource-pool'ы представляют в данном случае подразделения этой компании. Каждому узлу поставлено в соответствие тройка параметров <R, L, S>, причём у нетерминального узла эти значения суть сумма соответствующих параметров дочерних узлов.

Распределение ресурсов происходит в два этапа. На первом листовые вершины дерева (собственно, виртуальные машины) посылают запрос наверх, своему resource pool'у на данный ресурс. RP агрегирует запрос и посылает вышестоящему RP. Процесс повторяется вплоть до корневого RP.

На втором этапе происходит расчет потребных ресурсов для узлов, и импульс идёт уже сверху-вниз.

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

Для памяти применяется другой метод, похожий на алгоритм PWS для вытеснения страницы физической памяти. Эвристически устанавливается промежуток времени t, в течение которого отслеживается, какая доля страниц памяти в виртуально машине была использована. Так, например, если всего у виртуальной машины 8 Гб памяти, а за время t было задействовано 25% страниц, то запрос составит 8 x 0,25 = 2 ГБ

При прохождении наверх запрос уточняется по формулам

Таким образом, параметры R и L выступают в роли ограничителей.

На втором этапе происходит, собственно, распределение ресурсов по следующим правилам:

1. Среди потомков ресурсы выделяются пропорционально параметру Shares.

2. Каждый потомок получает не меньше чем его параметр Reservation

3. Потомок получает не более чем его параметр Limit.

При этом возможен пересчёт параметра Limit:

Пример распределения ресурсов приведён на рис. 12.

Рис. 12. Пример распределения ресурсов по алгоритму DRM

Ниже приведён график загруженности процессора при данном алгоритме. Пики соответствуют окончанию второй фазы процесса распределения ресурсов.



Метод оценки Process working set (PWS)

Данный метод основан на следующих эмпирических соображениях. Для вычислительного узла требуется ввести метрику его загруженности. При достижении её критического значения приминается решение о миграции одного или более контейнеров на менее загруженный узел (куда именно решается алгоритмом «Упаковка рюкзака»).

В качестве такой метрики можно было бы выбрать загрузку оперативной памяти, но тут возникают сложности с собственно определением «загруженности» (см. ниже). Поэтому стоит использовать более пригодный для экспериментального определения параметр. На эту роль подходит загруженность своп-файла (swap-rate). Действительно, его высокое значение говорит о высокой частоте page fault'ов и, соответственно, необходимости частого обращения к диску. Практика показывает, что при занятости файла подкачки на 40% наблюдается сильное падение в производительности. Это значение было выбрано в качестве порогового.

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

Как мы выяснили в главе «Аппаратно-независимая оптимизация виртуальной памяти», процессы имеют склонность удерживать в физической памяти некий минимальный набор страниц, к которым идёт самое частое обращение (модель рабочего множества процесса). PWS хорошо оценивает долю памяти, занимаемую процессом. Мы можем ввести величину рабочего множества контейнера (CWS) как сумму рабочих множеств его процессов c учётом общей памяти. Такая величина уже будет оценивать вес контейнера на кластере. При необходимости миграции будут отгружаться контейнеры с самым высоким CWS.

Остаётся вопрос о практическом подсчёте PWS и статистике page fault'ов. С этим нам поможет виртуальная файловая система /proc, которая содержит информацию о процессах системы. Особый интерес представляет файл /proc/meminfo c общей информацией об использовании памяти и файл /proc/[pid]/statm. Эта информация нам и даёт нам резидентные страницы памяти (т.е. страницы, находящиеся в pws) (см. Приложение).

Соответственные замеры памяти для контейнеров дают нам



Так же была определена статистика страничных исключений



Заключение

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

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

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

В качестве альтернативы мы предлагаем использовать сравнительно молодую технологию контейнерной виртуализации. Были рассмотрены её особенности и способы реализации в системе GNU/Linux на основе механизма ядра cgroups.

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

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

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

На основе проведённого теоретического и практического анализа были предложены способы оценки загрузки контейнерного сервера и его балансировки. В перспективе планируется внедрение этих идей в промышленные приложения и технологии Open Source.

Список публикаций автора

1. Петров Д.И., Тихомиров П.О. Разработка прототипа программно-аппаратной системы быстрого реагирования автоматизированного сбора и публикации информации от разнообразных датчиков в Internet и децентрализованных сетей ZigBee для последующего резервирования данных // Труд 54-й научной конференции МФТИ «Проблемы фундаментальных и прикладных естественных и технических наук в современном информационном обществе». Управление и прикладная математика. Т. 2. 2011. С. 68.

2. Петров Д.И. Обеспечение масштабируемости и отказоустойчивости программной системы хранения данных на сверхбольших объёмах данных // Труды 55-й научной конференции МФТИ «Проблемы фундаментальных и прикладных естественных и технических наук в современном информационном обществе». Управление и прикладная математика. 2012. Т. 2. С. 130-131.

3. Петров Д.И. Распределённое управление ресурсами высокопроизводительных систем // Труды 56-й научной конференции МФТИ «Проблемы фундаментальных и прикладных естественных и технических наук в современном информационном обществе». Управление и прикладная математика. 2013. Т. 2. С. 160.

Список литературы

1. Э. Танненбаум. Современные операционные системы. 3-е изд.// Спб.: Питер, 2010. - 1120 с.

2. В.Е. Карпов, К.А. Коньков. Основы операционных систем. Курс лекций. Учебное пособие. 2-е изд.// М.: ИНТУИТ.РУ, 2011. - 536 с.

3. VMWare, Inc. «Software and Hardware Techniques for x86 Virtualization», 2009

4. «Virtualization», Wikipedia: The Free Encyclopedia

5. Петров Д.И. Распределённое управление ресурсами высокопроизводительных систем // Труды 56-й научной конференции МФТИ «Проблемы фундаментальных и прикладных естественных и технических наук в современном информационном обществе». Управление и прикладная математика. 2013. Т. 2. С. 160.

6. Нил Макалистер. Виртуализация серверов // InfoWorld, 2007

7. Advanced Micro Devices, Inc. «AMD-V^TM Nested Paging», July, 2008

8. Intel^®, «Intel^® 64 and IA-32 Architectures Software Developer's Manual»

9. «Буфер ассоциативной трансляции», Wikipedia: The Free Encyclopedia

10. “Virtualize Your IT Infrastructure”. VMWare. 2011.

11. М. Тим Джонс, «Виртуальный Linux. Обзор методов виртуализации, архитектур и реализаций», 2007

12. Петров Д.И. Обеспечение масштабируемости и отказоустойчивости программной системы хранения данных на сверхбольших объёмах данных // Труды 55-й научной конференции МФТИ «Проблемы фундаментальных и прикладных естественных и технических наук в современном информационном обществе». Управление и прикладная математика. 2012. Т. 2. С. 130-131.

13. Tatu Yl onen, «Shadow Paging Is Feasible», 1994

14. «CPU Cache», Wikipedia: The Free Encyclopedia

15. «Parallels Virtuozzo Containers» http://www.parallels.com/ru/products/pvc/

16. Тихомиров П.О. Live-миграция приложений в CRIU // Труды 56-й научной конференции МФТИ «Проблемы фундаментальных и прикладных естественных и технических наук в современном информационном обществе». Управление и прикладная математика. 2012. Т. 2.

17. Плотник Н.С. Динамическое планирование ресурсов // Труды 56-й научной конференции МФТИ «Проблемы фундаментальных и прикладных естественных и технических наук в современном информационном обществе». Управление и прикладная математика.

Приложение. Вычисление PWS

#include <unistd.h>

#include <sys/resource.h>

#include <stdio.h>

/**

* Returns the peak (maximum so far) resident set size (physical

* memory use) measured in bytes

*/

size_t getPeakRSS( )

{

struct rusage rusage;

getrusage( RUSAGE_SELF, &rusage );

}

/**

* Returns the current resident set size (physical memory use) measured

* in bytes, or zero if the value cannot be determined on this OS.

*/

size_t getCurrentRSS( )

{long rss = 0L;

FILE* fp = NULL;

if ( (fp = fopen( "/proc/self/statm", "r" )) == NULL )

return (size_t)0L;/* Can't open? */

if ( fscanf( fp, "%*s%ld", &rss ) != 1 )

{

fclose( fp );

return (size_t)0L;/* Can't read? */

}

fclose( fp );

return (size_t)rss * (size_t)sysconf( _SC_PAGESIZE);

}

Размещено на Allbest.ru