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

Текст из файла (страница 3)

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

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

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

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

Можно привести следующий пример. Виртуализация широко применяется при изучении вредоносного программного обеспечения (например, компаниями, разрабатывающими антивирусы). При этом необходимо, чтобы программа, запущенная под виртуальной машиной не могла испортить данные в хостовой системе или нарушить ее работу. Кроме того, нужно чтобы программа функционировала под виртуальной машиной также как и на реальной аппаратуре. Ошибки и не точности в реализации виртуальных машин могут привести к нарушению этих двух требований. Доказательством этого служит существование так называемых “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

Характеристики

Список файлов ВКР