3 Формулирование возможных направлений решения задачи по

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
имени М.В.ЛОМОНОСОВА
НАУЧНО-ИССЛЕДОВАТЕЛЬСКИЙ ИНСТИТУТ ЯДЕРНОЙ ФИЗИКИ
имени Д.В.СКОБЕЛЬЦЫНА
УДК 004.75
Инв. № 105832/07
УТВЕРЖДАЮ
Директор НИИЯФ МГУ
______________ М.И. Панасюк
«____ » ___________ 2007 г.
ОТЧЕТ
О НАУЧНО-ИССЛЕДОВАТЕЛЬСКОЙ РАБОТЕ
Исследование и разработка технологического задела по запуску в
грид-инфраструктуру заданий, подготовленных для различных сред
исполнения
(промежуточный)
по теме:
Теоретические исследования поставленных перед НИР задач
Руководитель работ
________
подпись, дата
Москва 2007 г.
В.А.Ильин
СПИСОК ИСПОЛНИТЕЛЕЙ
Руководитель работ, д-р физико_________________ В.А.Ильин (Введение, Заключение)
математических наук
подпись, дата
Исполнители
_________________ А.П.Крюков (раздел 3, 4, Реферат)
подпись, дата
А.П.Демичев (разделы 2, 3, 4,
_________________
Приложение А )
подпись, дата
_________________ Л.В.Шамардин (раздел 4)
подпись, дата
_________________ Е.Г.Боос (разделы 5, 6 )
подпись, дата
Реферат
отчета по теме:
Теоретические исследования поставленных перед НИР задач
Отчет: 59 с., 18 рис., 2 таблицы, 47 источников, 1 приложение
Ключевые слова: распределенные вычисления, грид, среда исполнения, виртуализация
ресурсов.
Объектом
исследования
являются
распределенные
вычислительные
ресурсы грид-инфраструктур в условиях их применения для решения задач,
подготовленных для различных сред исполнения.
Целью работы является интеграция новых технологий виртуализации
2
вычислительных ресурсов в большие системы распределенных вычислений и
обработки данных (в первую очередь, в международную грид-инфраструктуру
EGEE) для повышение эффективности их использования путем существенного
расширения класса прикладных задач, которые могут быть решены с их
помощью.
В процессе работы проводились
 анализ научно-технической литературы, нормативно-технической
документации и других материалов, относящихся к разрабатываемой
теме;
 формулирование возможных направлений решения задачи по
созданию технологии запуска заданий в грид-системы с различными
вычислительными средами исполнения и их сравнительная оценка;
 выбор
и
обоснование
принятого
архитектурного
решения,
алгоритмов работы модулей системы и способов их реализации;
 сопоставление ожидаемых показателей новой продукции после
внедрения результатов НИР с существующими показателями
изделий-аналогов или с действующей нормативно-технической
документацией;
 разработка общей методики проведения исследований;
 реализация мероприятий по достижению технико-экономических
показателей, зафиксированных в Техническом задании.
В рамках поставленной задачи систематизирована и проанализирована
информация о существующих решениях для виртуализации вычислительных
ресурсов. Отобраны варианты, наиболее подходящие для интеграции в гридинфраструктуры, и на этой основе сформулированы направления решения
задачи создания система запуска заданий в грид-систему, подготовленных для
различных сред исполнения.
На основе полученных результатов разработаны: общее архитектурное
решение, алгоритмы работы модулей системы и методика проведения
3
исследований на последующих этапах работы.
В рамках реализации мероприятий по достижению технико-экономических
показателей, зафиксированных в Техническом задании, подготовлен и сделан
доклад на Международной конференции "XXI International Symposium on
Nuclear Electronics & Computing NEC'2007" (Болгария, Варна, 10-17 сентября,
2007 г.): A.Kryukov and I.Gorbunov
"First experience of submission to the
EGEE/RDIG Grid of jobs prepared for non standard OS's by means virtualization"
("Первый
опыт
запуска
заданий,
подготовленных
для
исполнения
в
нестандартных ОС, в грид EGEE/РДИГ на основе виртуализации").
Содержание
Определения…………………………………………………………………………6
Обозначения и сокращения…………………………………………………………9
1 Введение ................................................................................................................ 8
2 Анализ научно-технической литературы, нормативно-технической
документации и других материалов, относящихся к разрабатываемой теме ..... 11
2.1
Анализ существующих проектов предоставления сред исполнения .......................... 12
2.2
Проект Globus Workspace ................................................................................................ 14
2.2.1
Общая схема работы VW-сервиса .......................................................................... 15
2.3
Анализ существующих виртуальных машин ................................................................ 19
2.3.1
Типы виртуализации ................................................................................................ 19
2.3.1.1 Эмуляция оборудования ...................................................................................... 20
2.3.1.2 Полная виртуализация ......................................................................................... 20
2.3.1.3 Паравиртуализация .............................................................................................. 21
2.3.1.4 Виртуализация уровня операционной системы ................................................ 22
2.3.1.5 Анализ проектов виртуализации для Linux ....................................................... 23
2.3.2
Поддержка полной виртуализации и паравиртуализации процессорами .......... 28
2.3.3
Выбор типа и реализации виртуальной машины для рабочих узлов грида ....... 29
3 Формулирование возможных направлений решения задачи по созданию
технологии запуска заданий в грид-системы с различными вычислительными
средами исполнения и их сравнительная оценка. .................................................. 32
4 Выбор и обоснование принятого архитектурного решения, алгоритмов
работы модулей системы и способов их реализации. ........................................... 34
4.1
Краткое описание архитектуры грид-инфраструктуры, частью которой будет
создаваемая система запуска заданий в различных средах исполнения ................................ 35
4.2
Архитектура системы запуска заданий в грид-систему, подготовленных для
различных сред исполнения ........................................................................................................ 38
4.2.1
Общий алгоритм работы системы запуска заданий, подготовленных для
различных сред исполнения .................................................................................................... 40
5 Сопоставление ожидаемых показателей новой продукции после внедрения
результатов НИР с существующими показателями изделий-аналогов или с
действующей нормативно-технической документацией. ..................................... 44
4
6 Разработка общей методики проведения исследований ................................ 47
7 Заключение .......................................................................................................... 48
8 Список использованных источников ............................................................... 51
Приложение А. Характеристики виртуальных машин………………………… 55
Определения
В
настоящем
отчете
о
НИР
применяют
следующие
термины
с
соответствующими определениями:
Аппаратная технология виртуализации - набор инструкций процессора Intel
VT-x или AMD-V для упрощения и ускорения переключения контекста
между гостевой и хостовой операционными системами.
Вычислительный
элемент
-
в
контексте
грид-технологий
термин
"вычислительный элемент", используется для обозначения интерфейса
ресурсного центра для запуска заданий на рабочие узлы.
Виртуальная машина - программная или аппаратная среда, в той или иной
степени имитирующая работу реального компьютера. На виртуальную
машину, так же как и на реальный компьютер можно инсталлировать
операционную систему, у виртуальной машины так же есть BIOS,
оперативная память, жёсткий диск (выделенное место на жёстком диске
реального компьютера), могут эмулироваться периферийные устройства.
На одном компьютере может функционировать несколько виртуальных
машин.
Грид-инфраструктура – инфраструктура, обеспечивающая пользователям
грида
прозрачный,
унифицированный,
безопасный
доступ
к
географически распределенным вычислительным ресурсам и ресурсам
хранения данных через открытые компьютерные сети.
Гостевая операционная система - операционная система, работающая внутри
виртуальной машины.
Инфраструктура
безопасности
грида
5
-
компонента
промежуточного
программного обеспечения грида; основывается на понятии открытого
ключа, входит в инструментальный пакет Globus.
Кластер компьютерный - доступная по сети группа рабочих узлов (при
необходимости вместе с головным узлом), размещённая на некотором
сайте. Другими словами, кластер это "контейнер", который группирует
вместе компьютерные узлы или подкластеры.
Монитор виртуальных машин (гипервизор) - программный уровень
абстракции,
разделяющий
аппаратную
платформу
на
несколько
виртуальных машин; в более узком смысле - часть ядра хостовой
операционной
системы,
ответственная
за
хостинг
и
управление
виртуальными машинами; работает непосредственно с оборудованием.
Мониторинг/грид-мониторинг - грид-мониторинг подразумевает сбор, анализ
и публикацию информации от распределенной инфраструктуры с целью
определения статуса грид-ресурсов и хода выполнения заданий.
Приложение – любая компьютерная программа, предназначенная для решения
конкретной задачи пользователя из некоторой прикладной области. В
данном контексте рассматриваются грид-приложения, т.е. приложения,
использующие грид-инфраструктуру для получения результата.
Промежуточное программное обеспечение/ППО - слой программного
обеспечения, состоящий из агентов, являющихся посредниками между
различными компонентами крупного приложения. Зачастую ППО
используется
в
распределённых
приложениях,
причём
агентов,
составляющих этот слой, может быть несколько.
Ресурсный центр грид-инфраструктуры - может включает два типа ресурсов
(или один из них): вычислительные ресурсы, на которых выполняется
обработка данных; ресурсы хранения данных, которые обеспечивает
хранение и транспортировку данных между аналогичными ресурсами
и/или данным ресурсом и пользователем.
6
Рабочие узлы грид-системы - отдельный хост кластера; информация о
вычислительном узле может быть видима гриду, но может быть и не
видима - это зависит от способа администрирования кластера.
Сайт - используемое для администрирования логическое имя, обозначающее
конкретный, стабильный, уникально идентифицируемый и тестируемый
набор служб и ресурсов (вычислительных и ресурсов хранения данных).
Сервис/служба
-
абстрактный
ресурс,
представляющий
возможность
выполнения задач, которые имеют четкие функции с точки зрения
поставщиков
и
потребителей.
Чтобы
службой
можно
было
воспользоваться, она должна быть реализована конкретным агентом
поставщика. В данном тексте термины "сервис" и "служба" используются
как эквивалентные.
Хостовая операционная система - операционная система, в которой работает
платформа виртуализации, исполняющаяся непосредственно на хосте
Хостовая система (хост) - компьютер, на котором работает платформа
виртуализации.
Элемент хранения - любой ресурс хранения данных, зарегистрированный в
информационной подсистеме грида и обеспечиваеющий доступ к
удаленным сайтам посредством грид-интерфейса; элемент хранения
может управлять большими массивами на дисках, системами хранения
сверхбольшой ёмкости и подобными им системами.
Обозначения и сокращения
ВМ
виртуальная машина
МВМ
монитор виртуальных машин (гипервизор)
ОС
операционная система
ПО
программное обеспечение
ППО
промежуточное программное обеспечение
7
РДИГ
Российский грид для интенсивных операций с данными
РЦ
ресурсный центр
СПСИ
служба предоставления сред исполнения
CE
вычислительный элемент (Computing Element)
EGEE
развертывание грид-систем для e-науки (The Enabling Grids for EsciencE)
GT4
набор инструментальных средств Globus версии 4 (Globus Toolkit 4)
CLI
интерфейс командной строки (Command Line Interface)
gLite
промежуточное программное обеспечение проекта EGEE
(Lightweight Middleware for Grid Computing)
GSI
система безопасности (Grid Security Infrastructure)
JDL
язык описания задания (Job Description Language)
KVM
Linux Kernel Virtual Machine -
PBS
портируемая система пакетной обработки (Portable Batch System)
RB
сервис распределения ресурсов (Resource Broker)
SE
элемент хранения; ресурс хранения данных (Storage Element)
UI
интерфейс пользователя (User Interface)
UML
User-mode Linux
VMM
монитор виртуальных машин (Virtual Machines Monitor)
VW
виртуальное рабочее пространство (Virtual Workspace)
VWS
служба виртуального рабочего пространства (Virtual Workspace
Service)
менеджер загрузки (Workload Manager)
WM
1 WN
рабочий узел (Working Node)Введение
Данный отчет отражает результаты, полученные в результате выполнения
работ по государственному контракту 02.514.11.4072 на первом этапе “Выбор
направления исследований”.
Основными целями работы являются:
 существенное расширение класса прикладных задач, решаемых в
8
глобальных грид-инфраструктурах, на основе технологии запуска и
обработки
заданий,
подготовленных
для
различных
сред
исполнения, и, тем самым, повышение эффективности и обеспечение
возможности широкого коммерческого использования грида;
 выполнение международных обязательств, зафиксированных в
контракте No. 031688 c Европейской Комиссией по Европейскому
проекту EGEE (“Enabling Grids for E-sciencE”).
Технология, которая позволит обеспечить выполнение прикладных
заданий в грид среде независимо от среды их разработки, основана на понятии
виртуальных машин (компьютеров).
В настоящее время виртуализация
ресурсов является одним из основных
использования
компьютерных и
подходов к проблеме оптимизации
сетевых ресурсов. В общем смысле
виртуализация — это «отрыв», отчуждение логических ресурсов и логического
представления от их физического носителя с помощью средств преобразования
логического представления в физическое и обратно. Необходимо отметить, что
помимо возможности исполнения приложений, подготовленных для разных
ОС, в единой грид-системе, технология виртуализации может использоваться
для защиты информации и управления правами процессов, запущенных
пользователями. Это может существенно повысить безопасность использования
грида – как с точки зрения защищенности данных и результатов пользователей,
так и с точки зрения несанкционированного использования самой гридсистемы. Обеспечение безопасности при работе в гриде является одной из
наиболее актуальных задач развития распределенных вычислительных систем.
Дополнительное потребление вычислительных ресурсов, связанное с
развертыванием собственно виртуальной машины (ВМ) не превышает
нескольких процентов. Время исполнения заданий также увеличивается
незначительно по сравнению с их исполнением без использования ВМ. С
другой стороны, качество услуг, предоставляемых пользователям грид-систем,
существенно улучшается за счет расширения класса выполняемых задач и
повышения уровня безопасности.
9
В результате должна быть создана виртуально-гетерогенная грид-система,
которая обеспечивает простоту использования для конечного пользователя:
инструментарий
пользователя
должен
обеспечивать
запуск
заданий
с
различными вычислительными средами при самых минимальных знаниях
пользователя о грид-системе.
На первом этапе выполнения работ по контракту систематизирована и
проанализирована информация о существующих решениях для виртуализации
вычислительных ресурсов. Отобраны варианты, наиболее подходящие для
интеграции в грид-инфраструктуры, и на этой основе сформулированы
направления решения задачи создания системы запуска заданий в грид-систему
для различных сред исполнения.
На основе полученных результатов разработаны: общее архитектурное
решение для системы запуска заданий в грид-систему для различных сред
исполнения, алгоритмы работы модулей системы и методика проведения
исследований на последующих этапах работы. В рамках реализации
мероприятий
по
достижению
технико-экономических
показателей,
зафиксированных в Техническом задании, подготовлен и сделан доклад [47] на
Международной конференции "XXI International Symposium on Nuclear
Electronics & Computing NEC'2007" (Болгария, Варна, 10-17 сентября, 2007 г.).
В
соответствии
с
Календарным
планом
проведены
патентные
исследования, в результате которых не обнаружено каких-либо материалов,
которые бы препятствовали использованию результатов работ в Российской
Федерации.
Проведенный анализ научно-технической литературы и нормативнотехнической документации, а также результаты патентных исследований,
показывает, что разрабатываемая система запуска заданий в грид-систему для
различных сред исполнения в настоящее время не имеет прямых аналогов.
Наиболее
близким
по
функциональному
назначению
является
грид-
инструментарий Globus Virtual Workspace, рассматриваемый в разд. 1.2.
10
Однако, этот инструментарий предназначен для интерактивного режима работы
с виртуальной средой удаленных компьютеров, который не является
оптимальным для использования ресурсов больших грид-инфраструктур.
Поэтому эта разработка не может быть непосредственно интегрирована в гридинфраструктуры EGEE и РДИГ, что определено Техническим заданием
настоящего контракта. Исследования в области виртуализации грид-ресурсов,
близкие к целям настоящего контракта, проводятся также в рамках проектов
CoreGRID и Amazon Elastic Compute Cloud (EC2). Однако, и эти исследования,
как показано в разд. 5, не отвечают полностью целям и задачам настоящего
проекта. В частности, весьма важно, что предлагаемый в настоящем проекте
подход отличается от существующих разработок интеграцией модулей запуска
заданий в произвольной среде исполнения в другие подсистемы грида, а также
конкретной направленностью на последующее использование в крупнейшей
международной грид-инфраструктуре для научных исследований EGEE и в ее
российском сегменте РДИГ.
Таким образом, в целом планируемый научно-технический уровень
разработки в рамках данного контракта соответствует передовым мировым
разработкам в области виртуализации вычислительных ресурсов, а по
конкретным функциональным возможностям, определенным в Техническом
задании, и уровню интеграции в грид-систему не имеет аналогов в мире. Такая
оценка
уровня
разработки
подтверждается,
в
частности,
большой
заинтересованностью в результатах настоящих исследований со стороны
партнеров по крупнейшему международному грид-проекту EGEE.
2 Анализ научно-технической литературы, нормативнотехнической документации и других материалов,
относящихся к разрабатываемой теме
В настоящее время необходимость использования различных сред
исполнения
в
грид-инфраструктурах
общего
назначения
является
общепризнанной. Это может достигаться различными средствами. Одна
возможность - объединение в рамках одной грид-инфраструктуры рабочих
11
узлов, работающих под управлением различных операционных систем,
обеспечивая тем самым некоторый набор возможных сред исполнения заданий.
Большим недостатком такого подхода является малая гибкость системы
(фиксированный и, как правило, небольшой набор сред), а также то, что
задания могут исполняться только на части грид-ресурсов (с соответствующей
средой исполнения).
Существенно более предпочтительным является подход, основанный на
виртуализации ресурсов. Необходимо отметить, что в ряде аспектов подход
виртуализации уже сейчас используется и в грид-технологии. В частности,
необходимость виртуализации является одним из основных принципов
Открытой архитектуры грид-сервисов (Open Grid Services Architecture, OGSA)
[1]. Например, чтобы не иметь дело с особенностями каждого индивидуального
устройства хранения данных, каждый включенный в грид-инфраструктуру
ресурс хранения данных должен реализовывать стандартный интерфейс
(например,
так
называемый
Storage
Resource
Manager,
SRM,
http://sdm.lbl.gov/srm-wg). Тем самым клиенты этих ресурсов имеют дело с их
фиксированным
логическим
представлением,
а
не
с
разнообразными
физическими носителями каждого из ресурсных центров грида.
Различные
варианты
виртуализации
вычислительных
ресурсов
и
представления на этой основе различных сред исполнения также обсуждаются
в литературе и разрабатываются в рамках ряда проектов. Анализ предлагаемых
подходов представлен в следующем подразделе.
2.1 Анализ существующих проектов предоставления сред
исполнения
Анализ показывает, что в текущей научно-технической литературе
обсуждаются два основных подхода к решению задачи предоставления сред
исполнения
по
запросам
пользователей.
динамическом
создании
пула
пользователей
(учетных
записей),
Первый
формальных
причем
подход
(виртуальных)
различные
основан
на
локальных
группы
таких
пользователей имеют доступ к учетным записям с различными средами
12
исполнения (в частности, такое направление развивается в рамках проекта
Globus [2]). Второй подход основан на использовании виртуальных машин
(ВМ) [3]. Оба подхода обеспечивают исполнение заданий в изолированной
среде, но уровень виртуализации оказывается различным, поэтому каждый из
них лучше подходит для достижения различных целей [4]. Решение,
основанное
на
динамически
создаваемых
виртуальных
локальных
пользователях является более простым с точки зрения реализации, его легче
интегрировать в существующие грид-инфраструктуры. Подход, основанный на
ВМ является более сложным с точки зрения его реализации и требует
существенной адаптации существующего промежуточного программного
обеспечения (ППО) для поддержки этого вида виртуализации ресурсов.
Последнее в особенности относится к подсистемам запуска заданий,
мониторинга и учета использования ресурсов в грид-инфраструктурах. Однако,
такой подход дает более сильную изоляцию среды от сред исполнения других
пользователей грида, большую гибкость (с точки зрения пользователя),
возможность "замораживания" выполнения задания на промежуточном этапе и
перемещения работы на другой ресурс, поддержку системы соглашений между
пользователями и провайдерами по уровню обслуживания и ряд других
функциональных преимуществ.
Анализ показывает, что подход, основанный на динамическом создании
виртуальных
учетных
записей,
не
позволяет
достичь
показателей,
установленных в Техническом задании настоящего контракта. В частности,
этот метод не позволяет запускать на рабочих узлах грид-системы, работающей
под одной операционной системой (ОС), задания, подготовленные для
исполнения в другой ОС. Поэтому в дальнейшем будем рассматривать только
подход, основанный на виртуальных машинах.
Благодаря превосходным свойствам изоляции сред исполнения различных
пользователей,
удобным средствам управления ресурсами и возможности
развертывать различные среды исполнения заданий, это направление в
последнее
время
привлекает
повышенное
13
внимание
различных
исследовательских групп [5, 6]. Например, в рамках проекта In-Vigo [7, 8]
разрабатывается распределенная грид-инфраструктура на основе ВМ в качестве
ресурсов. В проекте COD
развертывания
рабочего
[7] разрабатывался способ динамического
пространства
для
авторизованных
удаленных
пользователей. В проектах Virtuoso [9] and Violin [10] исследуются сетевые
проблемы, связанные с использованием виртуальных машин в грид-среде.
Кроме
того,
обширные
исследования
были
посвящены
инструментам
конфигурации грид-ресурсов [11, 12], а также резервирования и динамического
обеспечения доступа грид-клиентов к существующим исполнительным средам
[13-16].
Наиболее разработанным среди таких проектов и наиболее близким к
целям
настоящей
работы
является
проект
Virtual
Workspaces
[3],
осуществляемый в рамках сообщества Globus Alliance [18], разработчика
известного инструментария для построения грид-систем Globus Toolkit. На
анализе этого проекта мы остановимся подробнее.
2.2 Проект Globus Workspace
В рамках проекта Globus [18] создается специализированный грид-сервис
Virtual Workspace (VW) [3] для разворачивания и конфигурирования
виртуальных
машин
на
рабочих
узлах
грид-системы,
а
также
для
взаимодействия с ними авторизованных пользователей и администрирования со
стороны локальных грид-администраторов.
Этот грид-сервис создан на основе Globus Toolkit версии 4 (GT4) и
соответствует спецификациям WSRF [19]. Общая структура его следующая: на
один
или
несколько
физических
серверов
устанавливается
монитор
виртуальной машины Xen [20], ядро инструментария Globus Toolkit и серверная
служба VW. Для запуска виртуальных машин (основанных на Xen) с
отдельного компьютера необходимо установить Globus Toolkit и клиентскую
службу VW. Можно также использовать готовые виртуальные приложения с
VW-клиентом на основе Xen и VMware. При удаленном запуске ВМ на один из
14
серверов необходимо указывать требования к ресурсам. В рамках проекта
разрабатывается также некий аналог каталога (репозитарий) с виртуальными
приложениями.
На текущий момент доступна тестовая версия Virtual Workspace 1.2.3
(Technology Preview), проект еще находится в стадии, так называемого, Globusинкубатора.
2.2.1 Общая схема работы VW-сервиса
VW-сервис имеет WSRF-совместимый внешний интерфейс для загрузки
виртуальных машин на компьютеры кластера и управления процессом их
работы. При этом управление может осуществляться как одной, так и целым
набором ВМ (кластером ВМ).
Для полномасштабной инсталляции сервиса требуется два выделенных
компьютера и набор компьютеров, выполняющих роль рабочих узлов гридсистемы (при инсталляции в тестовых целях набор компьютеров можно
сократить вплоть до одного). Один выделенный компьютер служит как
файловый сервер - хранилище (репозитарий) образов ВМ. На втором
выделенном компьютере устанавливаются
 сервер Workspace Service;
 базовые компоненты GT4:
o GT4 Java Core,
o Grid Security Infrastructure (GSI).
На каждом рабочем узле должно быть установлено следующее ПО
 монитор ВМ (Xen),
 специальный скрипт, обеспечивающий взаимодействие с VWS,
 вспомогательное ПО:
o ISC's DHCP server,
o ebtables
Общая схема запуска виртуальной машины удаленным клиентом показана
на рис. 1. В грид-инфраструктуре такой клиент должен запускаться
15
подсистемой распределения заданий, а требуемые свойства ВМ указываются
пользователем грида в файле описания задания (на модифицированном языке
описания заданий).
.
Рис. 1 Общая схема запуска виртуальной машины (ВМ) с заданными
свойствами удаленным клиентом
На компьютере пользователя должна быть установлена клиентская
программа VWS. С ее помощью пользователь посылает запрос "фабрике" VWсервисов на развертывание виртуальной машины с требуемой средой
исполнения и создание собственного экземпляра службы для управления этой
ВМ и получение информации о ее состоянии. Вместе с запросом посылаются
два набора конфигурационных данных: метаданные - общие параметры ВМ (не
зависят от деталей конкретного запуска ВМ) и запрос на развертывание детальные параметры текущего запуска ВМ. Общая схема запуска ВМ с
помощью VW-сервиса приведена на рис. 2.
Рис. 2 Общая схема запуска ВМ с помощью VW-сервиса.
Конфигурационные данные представляют собой XML-файлы. Структура
16
файла метаданных представлена на рис. 3.
Рис. 3 Структура конфигурационного файла метаданных.
Наиболее важным разделом этого файла является "definition".
Его
структура приведена на рис. 4.
Рис. 4. Структура раздела "definition" файла метаданных.
XML-элемент "disk" определяет образ диска гостевой системы, а "bindings"
- параметры монтирования виртуальной файловой системы.
Раздел "deployment logistics" конфигурационного файла метаданных
определяет, в частности, сетевые параметры (в текущей версии поддерживается
только динамический способ получения сетевого адреса (DHCP) виртуальной
машиной) и возможные требования к использованию сертификатов. Для
примера структура одного из его подразделов приведена на рис. 5.
Рис. 5 Структура одного из подразделов раздела "deployment logistics" файла
метаданных.
Общая структура XML-файла с запросом на развертывание приведена на
17
рис. 6.
Рис. 6 Общая структура XML-файла с запросом на развертывание.
Элемент "ResourceAllocation element" в этом файле определяет запрос на
выделение ВМ определенного объема оперативной памяти, доли ЦПУ и других
ресурсов рабочего узла, а элемент "WorkspaceState" определяет желательное
конечное состояние ВМ.
Состояния виртуальной машины определяются местонахождением ВМ
(репозитарий, рабочий узел), режимом работы (в том числе, режимы
выполнения,
паузы,
ошибки)
и
формой
представления
(например,
сериализованная форма пригодна для передачи задания внутри ВМ для
выполнения на другой рабочий или даже другой грид-сайт).
После создания экземпляра VW-сервиса и развертывания ВМ клиент
получает извещение (XML-файл) с сетевым адресом ("endpoint reference")
данного экземпляра службы в формате, представленном на рис. 7.
Рис. 7 Формат извещения о создании экземпляра VW-сервиса.
Используя информацию из этого извещения пользователь может управлять
своим экземпляром VW-сервиса используя WSRF-совместимые операции. В
частности, такими операциями являются:
18
 getResourceProperties - для получения информации о текущем статусе
грид-сервиса и ВМ;
 start - для запуска ВМ;
 shutdown - для прекращения работы ВМ.
Параметром операции shutdown является состояние в которое должна
перейти ВМ после прекращения работы: Normal, Pause, Serialize, Reboot, Trash,
and ReadyForTransport.
Необходимо отметить, что VW-сервис является источником извещений об
изменении своего состояния (Notification Producer), а поставляемый клиент
может подписаться на извещения об таких изменениях.
Важно подчеркнуть, что используя полученный сетевой адрес ВМ,
пользователь может интерактивно взаимодействовать со своей ВМ во время ее
работы.
2.3 Анализ существующих виртуальных машин
В настоящее время
на рынке имеется достаточно большой выбор
виртуалных машин. Одними из наиболее известных реализаций являются:
Bochs, QEMU, VMWare, Xen, KVM и ряд других. Однако, не все эти решения
могут быть использованы для достижения поставленных в Техническом
задании настоящего проекта целей. Выбор наиболее подходящей из них
является важным этапом исследования. Для этого на данном этапе работы было
проведено сравнительное изучение различных типов и реализаций виртуальных
машин.
2.3.1 Типы виртуализации
Существует не единственный способ осуществления виртуализации
вычислительных
ресурсов.
В
этом
разделе
будут
проанализированы
относительные преимущества и недостатки четырех методов виртуализации в
Linux (поскольку в соответствии с Техническим заданием, рабочие узлы
должны работать под управлением хостовой операционной системы Linux, мы
ограничимся только таким вариантом виртуализации ресурсов).
19
2.3.1.1 Эмуляция оборудования
Самая сложная и глубокая виртуализация обеспечивается эмуляцией
аппаратных средств [41]. В этом подходе ВМ аппаратных средств создается на
хост-системе, чтобы эмулировать необходимое оборудование для гостевой ОС,
как показано на рис. 8.
Рис. 8. Схема виртуализации с помощью эмуляции оборудования
При эмуляции полностью виртуализуется все аппаратное обеспечение при
сохранении гостевой операционной системы в неизменном виде.
В рамках этого подхода можно эмулировать различные аппаратные
архитектуры. Например, гостевые системы для x86-процессоров на платформах
с другой архитектурой (RISC-сервера компании Sun и т.п.). Чаще всего
эмуляцию применяют для низкоуровневой отладки операционных систем.
Основной минус этой технологии - эмулируемое аппаратное обеспечение
существенно замедляет быстродействие гостевой системы. Примеры продуктов
для создания эмуляторов: Bochs [21], PearPC [22], QEMU [23] (без ускорения),
Hercules Emulator [24].
2.3.1.2 Полная виртуализация
Полная
виртуализация
использует
виртуальную
машину
для
осуществления связи между гостевой операционной системой и аппаратными
средствами хоста, см. рис. 9. Монитор виртуальных машин (МВМ)
осуществляет посредничество между гостевой операционной системой и
собственно оборудованием. Внутри МВМ должна быть установлена и
настроена определенная защита, потому что основные аппаратные средства не
принадлежат операционной системе, а разделяются гипервизором.
20
Рис 9. Схема полной виртуализации
Полная виртуализация работает быстрее, чем эмуляция оборудования, но
производительность меньше, чем у просто оборудования из-за посредничества
гипервизора. В этой технологии ВМ виртуализует лишь необходимое
количество
аппаратного
обеспечения,
чтобы
могла
быть
запущена
изолированно. Наибольшее преимущество полной виртуализации состоит в
том, что в гостевую операционную систему не вносится изменений.
Единственное ограничение состоит в том, что операционная система должна
поддерживать основные аппаратные средства.
К минусам данного вида виртуализации можно отнести зависимость
виртуальных машин от архитектуры аппаратной платформы. Примеры МВМ
для полной виртуализации являются: VMware (Workstation, Server, ESX Server)
[25], Virtual Iron [26], Virtual PC [27], VirtualBox [28], Parallels Desktop [29].
2.3.1.3 Паравиртуализация
Паравиртуализация имеет некоторое сходство с полной виртуализацией
поскольку
тоже
использует
гипервизор
для
разделяемого
доступа
к
оборудованию. Однако код виртуализации в этом случае включается в саму
гостевую операционную систему, см. рисунок 10. Этот подход позволяет
избежать
любой
перекомпиляции
или
перехвата
команд,
поскольку
операционная система сама участвует в процессе виртуализации. Вместо этого
используется специальный программный интерфейс (API) для взаимодействия
с гостевой операционной системой (API-вызовы к гостевой системе,
называются «hypercalls» - гипервызовы).
21
Рис. 10. Паравиртуализация разделяет процесс с гостевой операционной
системой
Недостатком
метода
является
то, что
паравиртуализация
требует
модификации гостевой операционной системы. Большое преимущество производительность
при
(невиртуализированной)
одновременно
могут
паравиртуализации
системы.
Как
поддерживаться
операционные системы. Примеры:
и
при
почти
как
полной
у
реальной
виртуализации,
многочисленные
различные
Xen [20], User-mode Linux (UML) [30],
Denali [31].
2.3.1.4 Виртуализация уровня операционной системы
Виртуализация на уровне операционной системы, использует технику,
отличную
от
предыдущих.
Эта
техника
виртуализирует
серверы
непосредственно над операционной системой (см. рис. 11). При этом
поддерживаются только идентичные с хостовой гостевые операционные
системы и назначение этого типа виртуализации - просто изолировать
независимые серверы друг от друга.
Рис. 11. Виртуализация уровня операционной системы изолирует серверы
Основная цель, которую преследуют при использовании этого метода создание нескольких защищенных виртуализованных серверов на одном
22
физическом. Такая виртуализация часто применяется при организации систем
хостинга, когда на одном ЦПУ требуется поддерживать несколько виртуальных
серверов клиентов. Другими словами, в этом случае ВМ представляет собой
окружение
для
приложений,
запускаемых
изолированно.
Примеры
виртуализации уровня ОС: Linux-VServer [32], Virtuozzo [33], OpenVZ [34],
Solaris Containers [35] и FreeBSD Jails [36].
2.3.1.5 Анализ проектов виртуализации для Linux
Для того, чтобы выбрать наиболее подходящий для целей, определенных в
Техническом задании контракта, тип виртуализации и его конкретную
реализацию, в данном разделе будут кратко проанализированы наиболее
распространенные проекты по созданию и поддержке виртуализации в среде
ОС Linux, указанные в таблице 1. Для всестороннего сравнения и выбора
наиболее подходящего кандидата для виртуализации рабочих узлов гридсистемы в Приложении 1 приведена таблица важнейших характеристик
большинства существующих средств виртуализации для хостовой ОС Linux.
Таблица 1. Наиболее распространенные проекты виртуализации для Linux
Проект
Bochs
QEMU
VMware
z/VM
KVM
Xen
UML
Linux-VServer
OpenVZ
Тип
Эмуляция
Эмуляция
Полная виртуализация
Полная виртуализация
Полная виртуализация
Паравиртуализация
Паравиртуализация
Виртуализация уровня операционной системы
Виртуализация уровня операционной системы
Лицензия
LGPL
LGPL/GPL
Проприетарное
Проприетарное
GPL
GPL
GPL
GPL
GPL
Bochs (тип: эмуляция)
Bochs -- это x86-компьютерный имитатор, который является переносимым
и работает на разнообразных платформах, включая x86, PowerPC, Alpha,
SPARC и MIPS. При этом Bochs
моделирует не только процессор, а весь
компьютер, включая периферийные устройства типа клавиатуры, мыши,
графического и видео оборудования и карт сетевого интерфейса (NIC).
Используя эмулятор Bochs, вы можете управлять любым дистрибутивом
23
Linux на Linux, Microsoft® Windows® 95/98/nt/2000 (и многообразием
приложений) на Linux и даже операционной системой Berkeley Software
Distribution (BSD), FreeBSD, OpenBSD и так далее на Linux.
QEMU (тип: эмуляция)
QEMU поддерживает два режима работы:
 режим полной эмуляции системы;
 режим пользовательской эмуляции.
Первый режим похож на работу Bochs, когда компьютер эмулируется
целиком, вместе с процессором и периферией. Этим способом с разумной
скоростью имитируется множество различных архитектур процессоров, таких
как x86, x86_64, ARM, SPARC, PowerPC и MIPS. Этим способом вы можете
эмулировать операционные системы Windows (включая XP) и Linux на Linux,
Solaris и FreeBSD. Поддерживается также и множество других комбинаций
операционных систем (см. Приложение 1).
Во втором режиме, который осуществим только на Linux, можно запускать
бинарные файлы для разных архитектур. Это позволяет, например, выполнить
бинарный файл для архитектуры MIPS на Linux, запущенном на x86. Другие
архитектуры, поддерживаемые при таком режиме, включают ARM, SPARC и
PowerPC (некоторые варианты поддержки архитектур еще находятся в стадии
разработки).
VMware (тип: полная виртуализация)
VMware - коммерческое решение для полной виртуализации. Гипервизор
находится между гостевой операционной системой и непосредственно
оборудованием как слой абстрагирования. Этот слой абстрагирования
позволяет любой операционной системе работать на аппаратных средствах, не
имея информации о какой-либо другой гостевой операционной системе.
VMware
также
виртуализирует
в
гипервизоре
доступные
устройства
ввода/вывода и соответствующие драйверы для высокоэффективных устройств.
24
Вся виртуализированная среда сохраняется как файл, и это означает, что
полная система (включая гостевую операционную систему, VM и виртуальное
оборудование) может быть легко и быстро перенесена на другой сервер для
распределения загрузки.
z/VM (тип: полная виртуализация)
z/VM - гипервизор операционный системы для IBM System z™. Его ядром
является
программа
управления,
которая
обеспечивает
виртуализацию
физических ресурсов для гостевых операционных систем, в качестве которой
может
выступать,
например,
Linux.
При
этом
имеется
возможность
виртуализировать многопроцессорные системы и другие виды ресурсов для
различных гостевых операционных систем.Система z/VM может также
виртуально моделировать работу гостевой локальной вычислительной сети
(ЛВС)
для
тех
гостевых
операционных
систем,
которые
хотят
взаимодействовать друг с другом. ЛВС моделируется полностью в гипервизоре,
что обеспечивает высокий уровень безопасности.
Linux Kernel Virtual Machine - KVM (тип: полная виртуализация)
KVM - это реализация варианта полной виртуализации, превращающая
ядро Linux в гипервизор за счет подключения соответствующего модуля ядра.
Этот модуль позволяет запускать другие гостевые операционные системы в
пользовательском пространстве базового ядра Linux. Модуль KVM в ядре
предоставляет виртуализированное оборудование посредством символьного
устройства. Гостевая операционная система взаимодействует с модулем KVM
через
модифицированный
процесс
QEMU
для
эмуляции
аппаратного
обеспечения. Модуль KVM добавляет к ядру новый режим исполнения. Если
раньше ядра поддерживали режим ядра и режим пользователя, KVM вводит
режим гостя. Гостевой режим используется для выполнения всех инструкций,
не связанных с вводом-выводом, а операции ввода-вывода для гостевых систем
исполняются в обычном пользовательском режиме.
25
Использование KVM на аппаратном обеспечении, поддерживающем
виртуализацию (см. раздел 1.3.16), позволяет запускать гостевые операционные
системы Linux и Windows .
Xen (тип: паравиртуализация)
Свободное
решение
с
открытыми
кодами,
реализующее
паравиртуализацию уровня операционной системы, при которой и гипервизор,
и операционная система участвуют в процессе виртуализации. В связи с этим
требуется модификация гостевой ОС. Поэтому с точки зрения обеспечения
широты поддержки (особенно ОС, не придерживающихся принципа открытых
кодов), это очевидный недостаток. Однако большим достоинством Xen
является обеспечение почти естественной производительности.
Windows можно запускать как гостевую систему на Xen, но только если он
запущен на процессорах типа Intel VT (IVT, Intel Vanderpool) или AMD
virtualization (AMD-V, AMD Pacifica). Кроме того, Xen поддерживает другие
операционные системы, включая Minix, Plan 9, NetBSD, FreeBSD и OpenSolaris.
User-mode Linux (тип: паравиртуализация)
User-mode
Linux
(UML)
позволяет
запускать
в
пользовательском
пространстве одной операционной системы Linux другой экземпляр ОС Linux.
При этом каждая гостевая Linux-система существует внутри процесса,
запущенного на базовой операционной системе Linux. Это обеспечивает
возможность одновременного исполнения нескольких ядер Linux (с их
собственными
пользовательскими
пространствами)
в
контексте
одного
(базового) ядра Linux. Кроме того, обеспечивается виртуализация устройств.
Это позволяет гостевой операционной системе получать доступ к имеющимся
физическим устройствам, таким как блочные устройства (флоппи, CD-ROM и
файловые системы, например), к консоли, сетевым устройствам, звуковому
оборудованию и так далее.
26
Linux-VServer (тип: виртуализация уровня операционной системы)
Linux-VServer изменяет ядро Linux таким образом, что образуется
множество
пользовательских
пространств,
называемых
виртуальными
частными серверами, исполняющимися независимо один от другого.
В Linux-VServer обеспечивается также изоляция корневой директории для
каждого пользовательского пространства, при этом в рамках данного
пользовательского пространства невозможно выйти за пределы назначенного
ему корневого каталога. Кроме изолированного корневого каталога каждое
пользовательское пространство имеет собственный список пользователей и
отдельный пароль суперпользователя (root).
Linux-VServer может работать на платформах x86, x86-64, SPARC, MIPS,
ARM и PowerPC.
OpenVZ (тип: виртуализация уровня операционной системы)
OpenVZ представляет собой модифицированное ядро Linux, которое, как и
Linux-VServer, поддерживает изолированные пользовательские пространства, и
имеет набор пользовательских утилит для управления.
Для
управления
процессами
в
OpenVZ
включен
двухуровневый
планировщик задач ЦПУ. Этот диспетчер, во-первых, определяет, какое
пользовательское пространство должно получить доступ к ЦПУ. Когда это
сделано, планировщик второго уровня запускает процесс на выполнение,
устанавливая для него стандартные для Linux приоритеты.
Кроме того, средствами OpenVZ можно определить набор параметров,
определяющих
выделение
межпроцессорного
ресурсов
взаимодействия)
(в
частности,
памяти,
средств
для
заданного
пользовательского
пространства.
Важной особенностью OpenVZ является возможность "замораживать"
пользовательское пространство в определенных контрольных точках, сохранять
его в файле и перемещать на другой компьютер, где оно может быть
восстановлено и запущено в работу с той же точки. OpenVZ поддерживает
27
различные типы аппаратных архитектур, включая x86, x86-64 и PowerPC.
2.3.2 Поддержка полной виртуализации и паравиртуализации
процессорами
С точки зрения виртуализации процессорная архитектура IA-32 (x86)
создает несколько проблем. Некоторые инструкции привилегированного
режима не могут быть перехвачены. Другие возвращают различные результаты
в зависимости от того, в каком режиме они выполняются. Очевидно, что это
вызывает проблемы и крупнейшие производители компьютерных процессоров
разработали несколько новых проектов [37], которые поддерживают и
ускоряют виртуализацию.
Фирма Intel разработала новую технологию виртуализации, которая будет
поддерживать гипервизоры как для архитектуры x86 (VT-x), так и для Itanium®
(VT-i). VT-x поддерживает две новых формы операций, одна - для МВМ (root),
а вторая - для гостевых операционных систем (non-root). Первая форма (root
form) выполняется с полными привилегиями, а вторая лишена части
привилегий. Эта архитектура, кроме того, позволяет гибко определять
инструкции, которые приводят к выходу ВМ (гостевой ОС) в МВМ и
сохранению состояния процессора, а также предоставляет ряд других
возможностей.
Фирма AMD тоже разработала аппаратно-поддерживаемую технологию
виртуализации под названием Pacifica. Среди других особенностей Pacifica
поддерживает блок управления для гостевой операционной системы, который
сохраняется
при
выполнении
специальных
команд.
Возможность
конфигурирования позволяет МВМ определять уровень привилегий для каждой
из гостевых систем. Кроме того, Pacifica контролирует преобразование адресов
в таблицах блоков управления памятью базовой и гостевой систем.
Эти новые технологии могут быть использованы в различных реализациях
виртуализации, обсуждавшихся выше, включая Xen, VMware, User-mode Linux
и других.
Очень важным является то, что эти технологии аппаратной поддержки
28
виртуализации позволяют запускать широкий спектр немодифицированных
гостевых ОС даже в рамках паравиртуализации (то есть, при сохранении
производительности, близкой к производительности хостовой ОС).
2.3.3 Выбор типа и реализации виртуальной машины для рабочих
узлов грида
Выбор типа виртуализации и конкретной реализации виртуальной машины
можно сделать на основе параметров создаваемой системы запуска заданий в
грид-систему для различных сред исполнения, определенных в Техническом
задании контракта и характеристик существующих ВМ, представленных в
предыдущем разделе и Приложении 1.
Для определения наиболее подходящих реализаций виртуальных машин
наиболее важными характеристиками системы являются:
1. Созданная система должна обеспечивать возможность запуска на рабочие
узлы, работающие под управлением операционной системы (ОС)
Scientific Linux (стандартная ОС для ППО gLite), заданий в среде
следующих ОС:

WindowsXP;

Fedora Core;

Ubuntu.
2. Дополнительные (накладные) расходы рабочих узлов грид-системы на
развертывание "гостевой" среды исполнения для типичных задач не
должны превышать:

для ЦПУ - 15%;

для оперативной памяти - 30%.
3. Время выполнения задания на рабочем узле с "гостевой" средой
исполнения не должны превышать для типичных вычислительных задач
времени исполнения того же задания на аналогичном компьютере, где
указанная среда является основной на 15% .
4. Разрабатываемый технология должна быть тиражируемой и обеспечивать
настройку к локальным условиям для использования в крупных
корпоративных, региональных и межрегиональных распределенных
системах интенсивной обработки данных.
Первое условие фактически сразу выводит из числа возможных
кандидатов все ВМ на основе виртуализации уровня операционной системы:
29
такие ВМ позволяет запускать гостевые ОС только того же типа, что и
хостовая ОС (в нашем случае это Scientific Linux). В настоящее время этот тип
виртуализации
применяется
главным
образом
для
так
называемой
консолидации серверов (см., например, [38]). Дело в том, что как правило
приложения, работающие на серверах в IT-инфраструктуре компаний, создают
небольшую нагрузку на аппаратные ресурсы серверов (в среднем 5-15
процентов). Виртуализация позволяет мигрировать с этих физических серверов
на виртуальные и разместить их все на одном физическом сервере, увеличив
его загрузку до 60-80 процентов и, повысив тем самым коэффициент
использования аппаратуры, что позволяет существенно сэкономить на
аппаратуре, обслуживании и электроэнергии.
Эмуляция оборудования является слишком громоздким решением и
потребляет значительные ресурсы [39], что не соответствует требованиям пп. 2
и 3. Чаще всего этот тип виртуализации используется при разработке и
тестировании приложений. Соответствующие ВМ позволяют запускать
несколько различных операционных систем одновременно, позволяя тем самым
разработчикам
и
тестерам
программного
обеспечения
тестировать
их
приложения на различных платформах и конфигурациях. Кроме того, удобные
средства по созданию «снимков» текущего состояния системы одним кликом
мыши и такого же простого восстановления из этого состояния, позволяют
создавать тестовые окружения для различных конфигураций, что существенно
повышает скорость и качество разработки.
Полная виртуализация хорошо отвечает требованиям пункта 1, но тоже
потребляет достаточно много ресурсов и, что даже более существенно, как
правило продукты (МВМ), обеспечивающие полную виртуализацию не
являются свободно распространяемыми (см. Приложение 1). Это может
существенно затруднить тиражируемость разрабатываемой технологии и
обеспечение легкой настройки к локальным условиям, что зафиксировано в
Техническом задании (см. выше, п. 4). Однако, представляется разумным не
отвергать полностью этот тип виртуализации и провести исследования
30
возможности и преимуществ его использования в рамках экспериментальных
исследований (этапы 2 и 3 Календарного плана). Особенно это касается таких
продуктов как VMware, VirtualBox и KVM.
Таким образом, на этом этапе исследований наиболее предпочтительным
типом
виртуализации
для
достижении
целей
проекта
и
параметров,
определенных Техническим заданием, является паравиртуализация. С одной
стороны, поскольку, как отмечено в разделе 1.3.1.3, значительную часть работы
по взаимодействию с хостовой платформой в этом подходе берет на себя
гостевая ОС, производительность ВМ незначительно отличается от хостовой
ОС. С другой стороны, благодаря быстро развивающейся технологии
аппаратной
поддержки
виртуализации
(раздел
1.3.1.6)
в
рамках
паравиртуализации возможно разворачивания различных ОС, в том числе ОС
Windows.
Среди продуктов, обеспечивающих паравиртуализацию, наиболее зрелым
продуктом
представляется
Xen
[20].
Дополнительное
потребление
вычислительных ресурсов, связанное с развертыванием этой виртуальной
машины не превышает нескольких процентов. Время исполнения заданий
также увеличивается незначительно по сравнению с их исполнением без
использования ВМ, как показано на рис. 12 [40].
Рис. 12 Время исполнения тестового задания на реальном компьютере и ВМ
Сетевой интерфейс ВМ Xen также является вполне удовлетворительным и
по показателям производительности незначительно отличается от хостового
интерфейса. В частности, при выполнении тестовых параллельных (MPI)
31
заданий (при котором обмен MPI-сообщениями занимает ~ 10% времени
выполнения задания) на виртуальном и физическом кластере рабочих узлов
время исполнения отличается на 2-3% (рис. 13).
Рис. 13 Время исполнения тестового параллельного задания на виртуальном и
физическом MPI-кластерах
Исходя из приведенных аргументов, основным кандидатом на роль MВМ,
на котором будет основана система запуска заданий в грид-систему для
различных сред исполнения, является Xen. Однако на этапе экспериментальных
исследований предполагается исследовать также возможность других МВМ
типа
полной
виртуализации
и
паравиртуализации,
причем
наиболее
предпочтительными кандидатами являются VMware, VirtualBox и KVM. Будет
также исследован OpenVZ для сравнения с производительность систем
виртуализации уровня операционной системы (хотя они и не обеспечивают
возможности запуска широкого спектра гостевых ОС).
3 Формулирование возможных направлений решения
задачи по созданию технологии запуска заданий в гридсистемы с различными вычислительными средами
исполнения и их сравнительная оценка.
Как указано выше (разд. 1.1), в настоящее время в рамках различных
проектов
ведется
разработка
отдельных
модулей
для
подготовки
и
развертывания различных сред исполнения на рабочих узлах. Был представлен
(разд. 1.2) один из подходов (в рамках проекта Globus) к архитектурному
32
решению, основанный на создании грид-сервиса развертывания ВМ и
специальных репозитариев сред исполнения в ресурсных центрах грид-систем.
В любом случае общей основой предоставления различных сред
исполнения являются виртуальные машины реализующие паравиртуализацию
или полную виртуализацию. Но в отношении метода предоставления гридресурсов с требуемой средой возможны два принципиально отличающихся
подхода
В первом подходе (Globus Virtual Workspace, описанный в разд.1.2,
соответствует этому подходу) пользователь указывает в описании задания,
направляемого в грид, необходимую среду исполнения и при наличии такой
среды
в
репозитарии
специальный
грид-сервис
разворачивает
ее
на
соответствующем рабочем узле. Достоинством этого подхода является
сравнительная простота для пользователя при использовании готовых ВМ из
репозитария. Однако, такой подход может оказаться недостаточно гибким так
как при появлении нового класса задач подходящей среды может не оказаться в
репозитарии и, наоборот, какие-то варианты сред могут долгое время храниться
в репозиториях без использования. Другая проблема указанного подхода
связана с лицензионными ограничениями: для обеспечения широкого спектра
сред исполнения провайдер вынужден иметь лицензии на большое (и не всегда
легко прогнозируемое) число копий коммерческого программного обеспечения
(ПО), что может казаться невыгодным или даже невозможным с финансовой
точки зрения. Кроме того, требуются значительные усилия для интеграции
этого решения в общую инфраструктуру грида.
В другом подходе основной упор делается на разработку специального
инструментария, который позволяет пользователю самому готовить задание в
подходящей среде, то есть подходящим образом упакованный набор (tarball),
включающий:
 само задание внутри соответствующей ОС,
 виртуальную машину,
 набор специальных скриптов, управляющий развертыванием ВМ.
33
Это набор должен быть подготовлен таким образом, что он может быть
направлен и задание выполнено на рабочих узлах грида, где установлен
подходящий МВМ. Этот подход обеспечивает максимальную гибкость грида с
точки зрения сред исполнения, а все лицензионные вопросы, касающиеся
использования прикладного ПО, переносит на сторону пользователя, который
может точно определить требуемый объем и условия лицензирования для
решения своих задач. Недостатками этого подхода являются:
 высокий уровень требований к пользователю и его большие трудозатраты

необходимость специального инструментария для облегчения процесса
создания пакетов с заданием и ВМ.
Как видно, оба подхода имеют свои достоинства и недостатки. Поэтому
представляется
оптимальным
исследовать
возможность
создания
грид-
инфраструктуры, реализующей обе возможности - по выбору пользователя:
 первый подход (специализированный сервис и репозитарий готовых
образов ВМ) используется для запуска массовых задач в обычных,
широко распространенных средах пользователями, которые не являются
экспертами в технологии виртуализации;
 второй подход используется для запуска заданий опытными
пользователями при необходимости использовать очень специальные
среды исполнения и/или в случае лицензионных проблем со стороны
провайдера грид-ресурсов.
В определенной степени такой комбинированный подход используется в
успешном бизнес-проекте Amazon Elastic Compute Cloud (Amazon EC2) [42].
Необходимо,
однако,
подчеркнуть,
что
Amazon
EC2
не
является
полномасштабной грид-системой.
4 Выбор и обоснование принятого архитектурного
решения, алгоритмов работы модулей системы и
способов их реализации.
Выбранное архитектурное решение для системы запуска заданий,
подготовленных для различных сред исполнения, должно удовлетворять
требованиям Технического задания контракта. Главным является требование
обеспечения запуска заданий на распределенные ресурсы грид-инфраструктуры
34
и их выполнения в среде, характеристики которой заданы в описании задания.
При выборе архитектуры системы необходимо учитывать, что в больших гридсистемах основным (а чаще всего - единственно возможным) режимом является
пакетный запуск заданий. Это связано с тем, что только в таком режиме
возможно эффективное планирование и оптимальное распределение гридресурсов. Другой вариант - интерактивное взаимодействие пользователей с
ресурсами - приводит к большим проблемам при планировании выделения
ресурсов, высоким требованиям к уровню обслуживания (Quality of Service,
QoS), обеспечению резервирования ресурсов и т.п. Хотя грид-системы с
интерактивным взаимодействием рассматриваются в литературе и исследуются
в ряде проектов, но такие грид-системы предполагаются сравнительно
небольшими и специализированными для выполнения узкого круга задач, для
выполнения которых интерактивность является обязательным условием.
В рамках данного проекта, в соответствии с требованиями Технического
задания (в частности, совместимости с ППО gLite [43] и грид-инфраструктурой
EGEE/РДИГ [44], [45]) будет развиваться система запуска заданий с
предоставлением среды исполнения по запросу при работе в пакетном
режиме.
Отметим также, что решения для интерактивного варианта предоставления
среды (без интеграции в грид-среду) хорошо развиты в рамках описанного
выше проекта Globus Virtual Workspace [3] и Amazon EC2 [42].
4.1 Краткое описание архитектуры грид-инфраструктуры,
частью которой будет создаваемая система запуска заданий
в различных средах исполнения
Грид-система включает в себя
следующие основные структурные
компоненты:
 совокупность компьютеров с установленными на них интерфейсами
пользователя;
 совокупность Ресурсных центров, включающих в себя
o вычислительные ресурсы;
35
o ресурсы хранения данных;
 набор базовых грид-сервисов.
Обобщенная схема грид-инфраструктуры представлена на рис. 14.
Рис.14 Обобщенная схема структуры грида
Интерфейс
пользователя
(User
Interface,
UI)
предназначен
для
обеспечения доступа пользователя к ресурсам грида. Через UI пользователь
 осуществляет запуск заданий на выполнение;
 пересылает данные с одного ресурса хранения данных на другой;
 контролирует процесс выполнения задания;
 получает результат выполнения задания.
Ресурсный центр может включать два типа ресурсов (или один из них):
 Вычислительный ресурс, на котором выполняется обработка данных;
служба, представляющая вычислительный ресурс в гриде, называется
Вычислительный элемент (Computing Element, CE).
 Ресурс хранения данных (Storage Element, SE), который обеспечивает
хранение и транспортировку данных между аналогичными ресурсами
и/или данным ресурсом и пользователем.
36
Базовые грид-службы обеспечивают работу всей грид-системы в целом;
они подразделяются на следующие подсистемы:
 подсистема управления загрузкой (Workload Management System, WMS),
o центральной является служба распределения заданий - брокер
ресурсов (Resource Broker, RB);
 подсистема управления данными (Data Management System, DMS)
o к базовым службам этой подсистемы относятся службы каталогов:
 служба файлового каталога,
 служба каталога метаданных;
 подсистема информационного обслуживания и мониторинга гридсистемы (Information System, IS)
o служба регистрации и учета ресурсов грида,
 подсистема безопасности и контроля прав доступа (Grid Security
Infrastructure, GSI)
o служба выдачи и поддержки сертификатов (Certificate Authority,
CA),
o служба регистрации виртуальных организаций и пользователей,
o служба управления виртуальными организациями и выдачи проксисертификатов (Virtual Organization Membership Service, VOMS),
o служба продления действия прокси-сертификата (MyProxy Service,
MP);
 подсистема протоколирования (Logging and Bookkeeping, LB)
o служба отслеживания статуса выполняемых заданий,
 подсистема учета (Accounting Subsystem, AS)
o служба учета использования грид-ресурсов.
Благодаря ППО множество географически распределенных компьютерных
ресурсов представляется пользователям единым ресурсом. Его роль в гриде
может быть сравнена с ролью операционной системы в обычном персональном
компьютере. Разумеется, для запуска прикладных задач в грид пользователь
должен знать основы работы (команды, утилиты, форматы ввода/вывода) с
этим ППО.
37
4.2 Архитектура системы запуска заданий в грид-систему,
подготовленных для различных сред исполнения
Система запуска заданий в различных средах исполнения взаимодействует
с большинством подсистем грид-инфраструктуры, а именно:
 Интерфейс пользователя (UI)
 Брокер ресурсов (RB)
 Вычислительный элемент (CE)
 Элемент хранения данных (SE)
 Информационная система (IS)
 Рабочий узел (WN)
Кроме того, эта система взаимодействует со следующими компонентами,
формально не являющимися частью грид-инфраструктуры (компоненты
ресурсных центров):
 Локальная система управления пакетными заданиями, например, PBS
 Монитор виртуальных машин (МВМ) на рабочем узле
Субъектами, участвующими в запуске заданий со средой исполнения по
запросу являются
 Задания (jobs)
 Описания заданий (JDL)
 Образы ВМ
o Общедоступные (образы, созданные заранее и доступные всем
авторизованным пользователям грида)
o Персональные (образы, созданные самим пользователем и
доступные либо только данному пользователю, либо группе,
которой данный пользователь предоставил такое право).
Новыми
компонентами
грид-инфраструктуры,
обеспечивающими
развертывание требуемой для задания среды исполнения являются, как
показано на рис. 15, собственно служба предоставления сред исполнения
(СПСИ), разворачиваемая в ресурсных центрах, хранилище готовых образов
дисков с виртуальными машинами (средами исполнения) и специальный
сценарий (скрипт), управляющий развертыванием и работой ВМ.
Важной особенностью выбранной архитектуры системы запуска заданий в
38
грид-систему, подготовленных для различных сред исполнения, является то,
что
управление
вводом/выводом
данных
задания,
выполняющегося
в
виртуальной среде, в хост-систему рабочего узла осуществляется изнутри ВМ.
Поэтому подготовка образа диска со средой исполнения должна удовлетворять
определенным правилам, обеспечивающим такой ввод/вывод. Этот ввод/вывод
осуществляется с помощью ftp-сервера, развертываемого с посредством СПСИ
на хост-машине одновременно с ВМ.
Рис. 15 Архитектура системы запуска заданий со службой предоставления сред
исполнения
Поскольку по условиям Технического задания, СПСИ должна быть
совместима
с
gLite,
является
важным
максимально
использовать
функциональные возможности этого ППО, сохраняя при этом возможность
портирования разрабатываемой технологии предоставления сред исполнения
по запросам в другие грид-системы. В частности, информационная система
любой грид-системы (в том числе, gLite/EGEE/РДИГ) должна содержать
сведения не только об аппаратной конфигурации ресурсных центров, но и о
39
программном обеспечении, доступном на данном грид-сайте - так называемые
ПО-теги (ярлыки). Вычислительные элементы (СЕ) ресурсных центров,
которые имеют СПСИ и могут предоставлять среды по запросам, должны
содержать специальный ПО-тег (на рис. 15 он имеет значение "МВМ" и его
имеет ресурсный центр под номером 1).
Используя эту информацию,
полученную от информационной системы, брокер ресурсов сможет направить
задания, в описании которых содержится запрос на выполнения в специальной
среде (отличной от хостовой среды рабочих узлов грид-системы), только в
ресурсные центры, имеющие в своем составе СПСИ. Задания, которые могут
выполняться в хостовой среде рабочих узлов, могут распределяться обычным
образом - на любой грид-сайт, имеющий свободные ресурсы (на рис. 15 такой
ресурсный центр имеет номер N).
Все компоненты системы запуска заданий в грид-систему для различных
сред
исполнения
должны
взаимодействовать
на
основе
стандартных
протоколов, используемых в грид-инфраструктуре EGEE (SOAP, GridFTP,
протоколы аутентификации/авторизации GSI) для обеспечения, в соответствии
с требованиями Технического задания, совместимости создаваемой системы с
грид-инфраструктурой EGEE.
4.2.1 Общий алгоритм работы системы запуска заданий,
подготовленных для различных сред исполнения
Общий алгоритм работы системы запуска заданий, подготовленных для
различных сред исполнения, представлен на рис.16.
Для упрощения блок-схемы алгоритма, на рисунке указаны лишь блоки,
связанные с работой собственно СПСИ и не указаны стандартные действия
компонентов грид-инфраструктуры связанные с запуском, мониторингом и
доставкой результатов заданий.
В соответствии с этим алгоритмом сценарий использования системы
запуска заданий, подготовленных для различных сред исполнения, является
следующим:
 Пользователь в описании задания (в случае ППО gLite для описания
40
используется
язык JDL) указывает
необходимости развертывания ВМ;
ПО-тег,
соответствующий
 RB с помощью информационной системы находит ресурсный центр и CE,
имеющий такой ПО-тег и свободные рабочие узлы и направляет туда
задание;
 на CE задание обрабатывается с участием службы предоставления сред
исполнения (СПСИ)
(со специальной (отдельной) очередью) и
"обертывается" специальным скриптом;
 при необходимости СПСИ инициирует передачу (репликацию) на
локальный SE нужного образа ВМ с требуемой средой с удаленного SE;
 при запуске на рабочем узле с установленным монитором виртуальных
машин (МВМ) обертывающий скрипт, сгенерированный СПСИ:
41
Рис.16 Общий алгоритм работы системы запуска заданий, подготовленных для
различных сред исполнения
o копирует образ диска с SE на локальный диск,
o запускает ВМ и инсталлирует гостевую ОС,
o запускает на хосте ftp-сервер,
o после окончания выполнения задания и выгрузки результатов из
ВМ в хост-систему, скрипт останавливает ВМ и уничтожает образ
на локальном диске.

результаты задания доставляются пользователю стандартными
средствами gLite.
На рис. 17 этот сценарий представлен в виде диаграммы временной
42
последовательности.
Рис. 17 Сценарий использования СПСИ в виде диаграмы временной
последовательности.
Необходимо отметить, что в этом сценарии подразумевается, что в гридсистеме (хотя бы на одном SE) находится образ диска с требуемой средой. Это
может быть как общедоступный образ, или образ, специально приготовленный
пользователем для выполнения данного задания. Такой образ должен быть
выложен на один из SE, с помощью стандартными средствами системы
управления данными в грид-среде и зарегистрирован в распределенных
файловых каталогах.
На рис. 18 в виде диаграммы временной последовательности представлен
сценарий работы системы в случае, когда в момент запроса на выполнения
задания на одном из рабочих узлов грид-системы уже развернута ВМ с
требуемой средой исполнения.
43
Рис. 18 Диаграмма временной последовательности развернутой ВМ на рабочем
узле
При реализации этой архитектуры системы запуска заданий важно
обеспечить
безопасность
грид-среды,
с
точки
зрения
возможности
несанкционированных действий недобросовестных пользователей. Возможные
проблемы связаны с тем, что как правило запуск ВМ осуществляется от имени
привилегированного пользователя хост-системы. Это будет сделано на основе
инфраструктуры
безопасности
грида
Globus
GSI.
В
соответствии
с
Календарным планом работ по контракту, детальная проработка решения этой
проблемы будет выполнена на втором этапе выполнения работ.
5 Сопоставление ожидаемых показателей новой
продукции после внедрения результатов НИР с
существующими показателями изделий-аналогов или с
действующей нормативно-технической документацией.
Разрабатываемая система запуска заданий в грид-систему для различных
сред исполнения в настоящее время не имеет прямых аналогов. Наиболее
близким по функциональному назначению является подробно описанный в
разд. 1.2 грид-инструментарий Globus Virtual Workspace [3]. Однако, как
указано в разд.1.2.1, этот инструментарий предназначен для интерактивного
режима работы с виртуальной средой рабочих узлов. Такой режим не является
44
оптимальным для эффективного использования ресурсов больших гридинфраструктур и поэтому эта разработка не может непосредственно
использоваться для интеграции в такие грид-инфраструктуры как EGEE и
РДИГ, что определено Техническим заданием настоящего контракта.
Исследования в области виртуализации грид-ресурсов, близкие к целям
настоящего контракта, проводятся в рамках европейского проекта CoreGRID
[46]. Однако, исследования носят пока предварительно-теоретический характер
[4] и не вышли на стадию реализации конкретной цельной архитектуры,
алгоритмов работы и создания действующей системы. На последующих этапах
работы
по
настоящему проекту предполагается
учитывать возможное
дальнейшее развитие работ по данному проекту.
Amazon Elastic Compute Cloud (EC2) [42] обеспечивает масштабируемое
развертывание
приложений.
В
настоящее
время
пользователи
имеют
возможность (за установленную плату) создавать, запускать и останавливать
экземпляры сервера по запросам (это объясняет слово elastic (упругий) в
названии). EC2У использует ВМ Xen. Каждая виртуальная машина является
"эквивалентом" системы с x86 процессора с частотой 1.7 Ghz, 1.75 GB
оперативной памяти, 160 GB на локальном диске и 250 Mb/s сетевой
пропускной способности. Эта разработка к настоящему времени выходит на
стадию реально действующего бизнес-проекта по предоставлению платных
вычислительных услуг и некоторые решения могут быть полезны при
дальнейшей работе по данному контракту. Однако, в целом EC2 не является
грид-инфраструктурой и поэтому не может рассматриваться как аналог и
конкурент
системе
предоставления
сред
исполнения
по
запросам,
разрабатываемой в рамках настоящего контракта.
Таким образом, предлагаемый в настоящем проекте подход отличается от
существующих разработок комплексностью (интеграцией модулей запуска
заданий в произвольной среде исполнения в другие подсистемы грида) и
конкретной направленностью на последующее использование в крупнейшей
международной грид-инфраструктуре для научных исследований EGEE [44] и,
45
в частности, в ее российском сегменте РДИГ [45], существенно расширив ее
функциональные
возможности
и
обеспечив
тем
самым
возможность
использования эти грид-инфраструктур для решения широкого спектра научноинженерных и инновационно-промышленных задач.
Предполагается поэтапное расширение масштаба реализации результатов –
начиная
с
грид-инфраструктуры
РДИГ
(сотни
процессоров,
десятки
пользователей). При успешной реализации в рамках РДИГ технология будет
распространена на всю крупнейшую в настоящее время грид-инфраструктуру
EGEE (десятки тысяч процессоров, тысячи пользователей). Это обеспечит
достижение целей НИР (зафиксированных в Техническом задании) по
выполнению международных обязательств РФ в рамках Европейского проекта
EGEE.
В дальнейшем возможно внедрение данной технологии в другие гридинфраструктуры. Поэтому эффект от внедрения данной технологии ожидается
весьма масштабным, причем особенно - для промышленных и коммерческих
приложений. В частности, как правило, рабочие узлы распределенных
вычислительных систем находятся под управлением ОС Linux (что связано с
особенностями эксплуатационно-технических характеристик этой ОС). С
другой стороны, многие прикладные задачи разрабатывается для операционной
системы
MS
Windows.
Поэтому
эффект
от
внедрения
технологии
виртуализации рабочих узлов грида ожидается весьма масштабным, причем
особенно - для промышленных и коммерческих приложений.
Разработка подобной технологии является критически важной при
создании грид-инфраструктур, предоставляющих компьютерные услуги для
решения вычислительных задач и задач по анализу и обработке данных в
различных научных и прикладных исследованиях таких как нанотехнологии,
термоядерная энергетика, биомедицина, науки о Земле и дистанционное
зондирование Земли и другие. Широкий спектр требований, предъявляемых к
предоставляемым
вычислительным
услугам
со
стороны
пользователей,
работающих в этих областях, может быть удовлетворен с помощью внедрения
46
технологии виртуализации в современную инфраструктуру грид. Это явится
важным шагом в развитии грид-технологии и выходом ее на уровень
коммерческого применения.
6 Разработка общей методики проведения исследований
Основным подходом к проведению исследований по теме настоящего
контракта является тесное сочетание теоретических и экспериментальных
исследований.
Теоретические исследования по выбору наилучшего решения для
интеграции виртуализации в грид и оптимизации параметров реализованного
решения должны использовать:




теорию операционных систем,
системный анализ,
теорию вычислительных сетей,
техническую документацию на виртуальные машины, ППО gLite, ОС
Linux и Windows,
 нормативные документы по использованию лицензионного ПО в
распределенной вычислительной среде.
При необходимости могут быть использованы
 методы теории массового обслуживания,
 имитационное моделирование.
Каждый этап теоретических исследований должен сопровождаться этапом
экспериментальных исследований:
 построением специальных полигонов,
 тестированием,
 на заключительном этапе - апробацией в реально действующей гридинфраструктуре EGEE/РДИГ.
Экспериментальные исследования должны определить:
 правильность выбора оптимальной виртуальной машины для
создания виртуальной среды исполнения,
 правильность выбора общей архитектуры системы запуска заданий,
подготовленных для различных сред исполнения, и способа ее
47
интеграции в грид-инфраструктуру,
 корректность работы разработанных алгоритмов,
 способы оптимизации "накладных расходов" при использовании
средств виртуализации,
 уровень устойчивости работы системы,
 удобство и надежность инструментария для пользователей.
Кроме того, тестовые образцы компонент системы должны способствовать
оптимальной реализации компонент создаваемой системы запуска заданий с
учетом языков программирования, определенных в Техническом задании
(C/C++, perl, bash, Python, Java, MySQL).
На заключительном этапе работы эффективность работы системы запуска
заданий, подготовленных для различных сред исполнения, может быть
проведен опрос пользователей грид-инфраструктуры EGEE/РДИГ для оценки
эффективности и удобства использования системы.
7 Заключение
Таким образом, на первом этапе выполнения работ по контракту был
проведен анализ и систематизация научно-технической документации в
области технологии виртуализации вычислительных ресурсов и возможных
путей интеграции этой технологии в распределенные системы вычислений и
обработки данных. Отобраны варианты, наиболее подходящие для реализации
в рамках грид-инфраструктур, и на этой основе сформулированы направления
решения задачи создания системы запуска заданий, подготовленных для
различных сред исполнения.
На основе полученных результатов разработаны:
 общее архитектурное решение системы запуска заданий в грид-систему
для различных сред исполнения,
 общие алгоритмы работы системы запуска,

методика проведения исследований на последующих этапах работы.
Проведено сопоставление ожидаемых показателей новой продукции после
внедрения результатов НИР с существующими показателями изделий-аналогов.
48
В рамках реализации мероприятий по достижению технико-экономических
показателей, зафиксированных в Техническом задании, подготовлен и сделан
доклад [47] на Международной конференции "XXI International Symposium on
Nuclear Electronics & Computing NEC'2007" (Болгария, Варна, 10-17 сентября,
2007 г.).
В результате проделанной работы получены следующие основные выводы:
 основой предоставления различных сред исполнения в грид-среде
являются виртуальные машины;
 наиболее подходящим типом виртуализации для создания системы
запуска заданий в грид, подготовленных для различных сред исполнения,
является паравиртуализация;
 среди существующих реализаций паравиртуализации в среде ОС Linux
наиболее подходящим для достижения параметров, определенных в
Техническом
задании
настоящего
проекта,
по
функциональным
возможностям и характеристикам производительности является Xen [20];
 в качестве возможных направлений исследований для решения основной
задачи проекта предполагается исследовать как подход, основанный на
создании
грид-сервиса
развертывания
виртуальных
машин
и
специальных репозитариев сред исполнения в ресурсных центрах гридсистем, так и подход, основанный на предоставлении пользователю
возможности самому готовить задание в подходящей среде;
 разработанная общая архитектура и алгоритмы работы (разд. 4.2, рис. 15
– 18) позволяют создать систему запуска заданий в грид-систему для
различных
сред
исполнения,
удовлетворяющую
требованиям
Технического задания НИР;
 при проведении работ по теме настоящего контракта должно быть
обеспечено тесное сочетание теоретических и экспериментальных
исследований.
Работа на первом этапе выполнения контракта основывалась на анализе
49
самой современной научно-технической литературы и Интернет-источников.
При этом основные принципы, заложенные в предложенной архитектуре и
алгоритмах работы модулей системы соответствуют передовым технологиям,
используемым для построения систем подобного рода, а конкретные
функциональные возможности и уровень интеграции в грид-систему не имеет
аналогов в мире.
Таким образом, задачи первого этапа осуществления проекта выполнены
полностью.
50
8 Список использованных источников
1. Foster и др. "Open Grid Services Architecture (OGSA) v1.0",
http://www.gridforum.org/documents/GFD.30.pdf
2. Проект Globus/Dynamic Accounts:
http://dev.globus.org/wiki/Incubator/Dynamic_Accounts/Documentation
3. Проект Globus/Virtual Workspaces: http://workspace.globus.org/
4. J. Denemark, M. Jankowski, P. Wolniewicz, L. Matyska, N. Meyer "Virtual
Environments - Framework for Virtualized Resource Access in the Grid",
CoreGRID Technical Report Number TR-0066, December 27, 2006
5. Keahey, K., K. Doering, and I. Foster. From Sandbox to Playground: Dynamic
Virtual Environments in the Grid. in 5th International Workshop in Grid
Computing. 2004.
6. Figueiredo, R., P. Dinda, and J. Fortes. A Case for Grid Computing on Virtual
Machines. in 23rd International Conference on Distributed Computing
Systems. 2003.
7. Krsul, I., A. Ganguly, J. Zhang, J. Fortes, and R. Figueiredo. VMPlants:
Providing and Managing Virtual Machine Execution Environments for Grid
Computing. in SC04. 2004. Pittsburgh, PA.
8. Adabala, S., V. Chadha, P. Chawla, R. Figueiredo, J. Fortes, I. Krsul, A.
Matsunaga, M. Tsugawa, J. Zhang, M. Zhao, L. Zhu, and X. Zhu, "From
Virtualized Resources to Virtual Computing Grids: The In-VIGO System. In
Future Generation Computer Systems, vol 21, no. 6, 2005
9. Sundararaj, A. and P. Dinda. Towards Virtual Networks for Virtual Machine
Grid Computing. in 3rd USENIX Conference on Virtual Machine Technology.
2004.
10.Jiang, X. and D. Xu, VIOLIN: Virtual Internetworking on OverLay
INfrastructure. Department of Computer Sciences Technical Report CSD TR
03-027, Purdue University, 2003.
51
11.Feldman, M., K. Lai, and L. Zhang, A Price-Anticipating Resource Allocation
mechanism for Distributed Shared Clusters. ACM Conference on Electronic
Commerce, 2005.
12.Anderson, P. and A. Scobie. Large Scale Linux Configuration with LCFG. in
4th Annual Linux Showcase and Conference. 2000.
13.Hacker, T. and B. Athey, A Methodology for Account Management in Grid
Computing Environments. Proceedings of the 2nd International Workshop on
Grid Computing, 2001.
14.Kapadia, N.H., R.J. Figueiredo, and J. Fortes. Enhancing the Scalability and
Usability of Computational Grids via Logical User Accounts and Virtual File
Systems. in 10th Heterogeneous Computing Workshop. 2001. San Francisco,
California.
15.McNab, A., Grid-Based Access Control for Unix Environments, Filesystems
and Web Sites. Proceeings of the CHEP 2003 conference, 2003.
16.Talwar, V., S. Basu, and R. Kumar. An Environment for Enabling Interactive
Grids. in The Twelfth IEEE International Symposium on High Performance
Distributed Computing (HPDC-12). 2003. Seattle, Washington.
17.Chase, J., L. Grit, D. Irwin, J. Moore, and S. Sprenkle, Dynamic Virtual
Clusters in a Grid Site Manager. accepted to the 12th International Symposium
on High Performance Distributed Computing (HPDC-12), 2003.
18.Проект Globus: http://www.globus.org
19.Спецификации WSRF: http://www.globus.org/wsrf
20.Проект Xen: http://xen.xensource.com
21.Проект Bochs: http://bochs.sourceforge.net
22.Проект PearPC: http://pearpc.sourceforge.net
23.Проект QEMU: http://fabrice.bellard.free.fr/qemu
24.Проект Hercules Emulator: http://www.hercules-390.org
25.Проект VMware: http://www.vmware.com
26.Проект Virtual Iron: http://www.virtualiron.com
27.Проект Virtual PC: http://www.microsoft.com/windowsxp/virtualpc
52
28.Проект VirtualBox: http://www.virtualbox.org
29.Проект Parallels Desktop: http://www.parallels.com
30.Проект User-mode Linux: http://user-mode-linux.sourceforge.net
31.Проект Denali: http://denali.cs.washington.edu
32.Проект Linux-VServer: http://linux-vserver.org
33.Проект Virtuozzo: http://www.swsoft.com/en/products/virtuozzo/
34.Проект OpenVZ: http://openvz.org/
35.Проект Solaris Containers: http://opensolaris.org/os/community/zones/
36.Проект FreeBSD Jails: http://www.freebsd.org/cgi/man.cgi?query=jail&format=html
37.А. Александров, "Спирали аппаратной виртуализации", Открытые
системы, №03, 2007 г.
38.http://download.intel.com/business/technologies/optimizing_virtualized_datace
nters.pdf
39.D. Bartholomew "QEMU: a Multihost, Multitarget Emulator", Linux Jornal,
2006, http://www.linuxjournal.com/article/8808
40.I. Foster и др. "Virtual Clusters for Grid Communities", доклад на
Международной конференции "CCGrid", Сингапур 2006.
41.M. Тим Джонс, "Виртуальный Linux",
http://www.ibm.com/developerworks/ru/library/l-linuxvirt
42.Проект Amazon EC2: http://www.amazon.com/gp/browse.html
43.Промежуточное программное обеспечение gLite:
http://glite.web.cern.ch/glite
44.Проект EGEE: http://www.eu-egee.org
45.Проект RDIG: http://egee-rdig.ru
46.Проект CoreGRID: http://www.coregrid.net
47.A.Kryukov and I.Gorbunov "First experience of submission to the
EGEE/RDIG Grid of jobs prepared for non standard OS's by means
virtualization", будет опубликовано в Трудах международной
конференции "XXI International Symposium on Nuclear Electronics &
Computing NEC'2007", Болгария, Варна, 10-17 сентября, 2007 г.
53
Приложение А
Характеристики виртуальных машин
Таблица А.1. Сравнение основных характеристик виртуальных машин.
Название
Процессор
хостмашины
Bochs
Intel x86,
AMD64,
SPARC,
PowerPC,
Alpha, MIPS
Colinux
Intel x86
DOSBox
Intel x86,
AMD64,
SPARC,
PowerPC,
Alpha, MIPS
DOSEMU
Intel x86
Гостевой
процессор
Поддер
Официально
ОС
жка
поддерживаемые
хост-машины
любой
гостевые ОС
ОС
Windows, Linux,
DOS, Windows,
Intel x86, AMD64 OS X, IRIX,
xBSD, Linux
AIX, BeOS
Windows NT
Такой же как и у (NT, 2000, XP,
родительской
Server 2003),
Linux
GNU/Linux,
Windows, Mac
OS Classic, Mac
OS X, BeOS,
Intel x86
FreeBSD,
OpenBSD,
Solaris, QNX,
IRIX
Intel x86
Linux
Linux
Принцип
действия
Есть
Эмулятор
LPGL
Очень низкая
Нет
Портирование
GPL
version 2
Без потерь
GPL
Крайне
низкая.
Скорость
работы никак
не связана с
тем, какое
приложение
исполняется
GPL
version 2
Без потерь
Внешне
эмулирует
оболочку DOS
Нет
Эмуляция с
помощью
динамической
трансляции или
интерпретации
DOS
Есть
Аппаратная
виртуализация
54
Скорость
работы
Лицензия гостевой ОС
в сравнении
с ОС хоста
FreeVPS
Intel x86,
AMD64
Совместимый
Linux
Различные
дистрибутивы
Linux
Нет
Виртуализация на GPL
уровне ОС
version 2
Без потерь
Jail
Intel x86,
Совместимый
FreeBSD
FreeBSD
Нет
Виртуализация на
FreeBSD
уровне ОС
Без потерь
Близка к
производител
ьности хостсистемы
KVM
LinuxVServer
Процессор
Intel с
поддержкой
технологии
VT
Intel x86,
AMD64, IA64, Alpha,
PowerPC/64,
PA-RISC/64,
SPARC/64,
ARM, S/390,
SH/66, MIPS
Процессор Intel с
поддержкой
Linux
технологии VT
Linux
Нет
Паравиртуализаци
я, Аппаратная
GPL2
виртуализация
Совместимый
Различные
дистрибутивы
Linux
Нет
Виртуализация на GPL
уровне ОС
version 2
Без потерь
Виртуализация
GPL
Без потерь
Виртуализация на
GPL
уровне ОС
Без потерь
Linux
Mac OS X,
Linux
Intel x86,
Различные
Intel x86, AMD64,
AMD64, IALinux
дистрибутивы
Нет
OpenVZ
IA-64
64
Linux
Windows, Linux,
Windows, Linux,
FreeBSD, OS/2,
Parallels Intel x86, Intel
Intel x86
Mac OS X (Intel
Есть
VT-x
eComStation, MSWorkstation
version)
DOS, Solaris
Mac on Linux PowerPC
PearPC
PowerPC
x86, AMD64,
PowerPC
PowerPC
Linux
Windows, Linux, OS X, Darwin,
OS X, NetBSD Linux
55
Есть
Виртуализация,
легковесный
гипервизор
Эмуляция с
помощью
динамической
трансляции
Близка к
Проприет производиарная
тельности
хост-системы
10%
производиGPL
тельности
хост-системы
QEMU
Intel x86,
AMD64, IAIntel x86, AMD64,
64, PowerPC,
Windows, Linux,
ARM, SPARC 32
Список постоянно
Alpha, SPARC
OS X, FreeBSD,
Есть
and 64, PowerPC,
меняется
32 and 64,
BeOS
MIPS
ARM, S/390,
M68k
Динамическая
рекомпиляция
GPL/
LGPL
QEMUс
модулем
kqemu
Intel x86,
AMD64
Такой же как и у Linux, FreeBSD, Список постоянно
Есть
хост-системы
Windows
меняется
Виртуализация
GPL
QEMU с
модулем
qvm86
x86
x86
Linux, NetBSD, Список постоянно
Есть
Windows
меняется
Виртуализация
GPL
View-OS
Intel x86,
PowerPC,
AMD64 (in
progress)
GPL
version 2
User Mode Intel x86,
PowerPC
Linux
VirtualBox
Intel x86
2004
Такая же как и у
хост-системы
Linux 2.6+
Исполняемые
файлы Linux
Нет
Частичная
виртуализация с
помощью
перехвата
системных
вызовов
Такая же как и у
хост-системы
Linux
Linux
Нет
Портирование
Intel x86
32-bit Windows, DOS, Windows,
Linux, MacOS X Linux, OpenBSD
Есть
Динамическая
рекомпиляция
(основана на
QEMU)
56
От 10 до 20%
скорости
хост-системы
Близка к
производительности
хост-системы
Близка к
производительности
хост-системы
Близка к
производительности
хост-системы
(лучше с
патчем ptrace
ядра)
GPL
Низкая
version 2
Свободна
яи
Практически
проприета
без потерь,
рная
если
версии
используются
(GPL,
расширения
PUEL)
Virtuozzo
Intel x86, IA- Intel x86, IA-64,
64, AMD64
AMD64
Linux &
Windows
Различные
дистрибутивы
Linux; Windows
Нет
Виртуализация на Проприет
Без потерь
уровне ОС
арная
Близка к
производител
ьности хостсистемы
Близка к
производител
ьности хостсистемы
При
использовани
и VMware
Tools
практически
без потерь
При
использовани
и VMware
Tools
практически
без потерь
При
использовани
и VMware
Tools
практически
без потерь
VMware ESX Intel x86,
Server 3.0 AMD64
Нет
Windows, RedHat,
Intel x86, AMD64 (инсталлируется SuSE, Netware,
Есть
на голое железо) Solaris
Виртуализация
x86
Проприет
арная
VMware ESX Intel x86,
Server 2.5.3 AMD64
Intel x86
Нет
Windows, RedHat,
(инсталлируется SuSE, FreeBSD,
Есть
на голое железо) Netware
Виртуализация
x86
Проприет
арная
Intel x86,
AMD64
DOS, Windows,
Linux, FreeBSD,
Intel x86, AMD64 Windows, Linux
Есть
Netware, Solaris,
Virtual Appliances
Виртуализация
x86
Проприет
арная
(Free)
VMware
Intel x86,
Workstation
AMD64
5.5
DOS, Windows,
Linux, FreeBSD,
Intel x86, AMD64 Windows, Linux
Есть
Netware, Solaris,
Virtual Appliances
Виртуализация
x86
Проприет
арная
Intel x86,
AMD64
DOS, Windows,
Linux, FreeBSD,
Intel x86, AMD64 Windows, Linux
Есть
Netware, Solaris,
Virtual Appliances
Виртуализация
x86
Проприет
арная
(Free)
Кеширование
кода,
виртуализация
Проприет
Почти в 10 раз
арная
медленней
(AMD)
VMware
Server
VMware
Player
SimNow
AMD64
AMD64
Linux (64bit),
Linux, Windows
Windows (64bit) (32bit и 64bit)
57
Есть
TRANGO
Xen
z/VM
none: bare metal
execution, Linux Linux, eCos,
Есть
or Windows as µC/OS-II
dev. hosts
Linux, NetBSD,
FreeBSD,
OpenBSD,
Intel x86,
Windows XP &
AMD64,
2003 Server
((ведётся
Такая же как у
(требует версию
NetBSD, Linux
Есть
портирование хост-системы
не ниже 3.0 и
на PowerPC и
процессор
IA-64))
поддерживающий
технологию
Vanderpool или
Pacifica), Plan 9
Никакая или
такая же.
Множество
уровней
вложенности,
Linux on zSeries,
например
z/OS, z/VSE,
VM/ESA
z/Architecture и
z/TPF, z/VM,
z/Architecture
работает внутри
Есть
предшественники
VM/CMS,
z/VM 4.4,
MUSIC/SP и
которая
предшественники
работает внутри
z/VM 5.2,
которая
работает внутри
z/VM 5.1.
ARM, XScale, Paravirtualized
MIPS,
ARM, MIPS,
PowerPC
PowerPC
58
Паравиртуализаци
я, портирование, Проприет
Без потерь
аппаратная
арная
виртуализация
Паравиртуализаци
я, портирование
GPL
или аппаратная
виртуализация
Уникальная
аппаратная
виртуализация
Без потерь
Наивысшая.
Обычно
работают
тысячи
виртуальных
Проприет
машин на
арная
одной
системе, одна
или более на
каждого
пользователя