Нир: “легковесная платформа управления виртуализацией”

1.2 Обзор существующих аналогов Существуют решения с открытым исходным кодом, но все они в той или иной степени обладают рядом недостатков: недостаточная гибкость сетевого стека, отсутствие поддержки распределенного хранилища данных, ограничения архитектуры, не позволяющие реализовать отказоустойчивость и т.д. Кроме того, все эти решения обладают большим набором функциональных объектов, которые при реализации предъявляют высокие требования к аппаратным ресурсам. Одна из самых известных платформ, Eucalyptus [5], на данный момент прекратила свое развитие. Последние обновления кода Eucalyptus были в марте 2011 года. Платформа поддерживает базовый функционал Amazon EC2, позволяя производить весьма ограниченный набор операций с виртуальными машинами. Следующая платформа OpenNebula [6] – проект, разрабатываемый в основном европейским сообществом. Платформа написана на языке С++ (основная часть кода) и Ruby и представляется достаточно успешным, так как имеет хороший набор функциональных возможностей. Однако, в разработке «ядра» платформы участвует менее 10 человек, что снижает его «уровень проработки» и он имеет большие сроки обновления. Проект развивается уже на протяжении трех лет. Проект OpenStack [7], код которого был открыт в середине 2010г., представляется одной из наиболее быстро развивающихся платформ на данный момент. Тем не менее, и он не лишен недостатков, таких как отсутствие гибкости в сетевых настройках, ограниченность параметров виртуальных машин, отсутствие интеграции с открытыми распределенными хранилищами данных (встроенное решение имеет проблемы с производительностью). Все перечисленные проекты имеют развитую архитектуру и для внедрения предъявляют высокие требования к вычислительным ресурсам, что затрудняет их использование в условиях ограниченности возможностей аппаратного обеспечения. 2 Выбор программного обеспечения и технологий для использования в работе над проектом Реализация проекта предполагает как исследование программного обеспечения систем управления, так и поиск подходящих технологий хранения данных. Были рассмотрены две технологии распределённого хранения и одна с репликацией данных. Каждое решение подвергалось тестированию на стабильность и производительность, использовалось программное обеспечение bonnie++. Испытательный стенд состоял из двух серверов. Применялась следующая методика: измерялась производительность подсистемы ввода/вывода хост-серверов с файловой системой поверх предоставляемого блочного устройства; производительность подсистемы ввода-вывода виртуальных машин, одновременно запущенных в количестве пяти штук, блочные устройства виртуальных машин созданы с помощью тестируемого решения. Критерием оценки являлся параметр “скорость блочной записи”, когда удовлетворительными значениями считались: не менее 80 Мбайт/сек для подсистемы ввода/вывода хост-сервера и не менее 5 Мбайт/сек для подсистемы ввода-вывода одновременно запущенных виртуальных машин. 2.1 Архитектура системы хранения данных Ceph/RDB – представляет собой распределённое сетевое хранилище с распределёнными метаданными. Она использует отказоустойчивое автономное распределенное хранилище данных RADOS (Reliable Autonomic Distributed Object Store) как хранилище объектов и блочное устройство RDB (Rados Block Device), которое реализует поддержку RADOS хранилища для ядра Linux. Клиентская сторона хранилища представлена RDB и библиотеками, которые позволяет работать непосредственно с RADOS. Таким образом, все файловые операции ввода-вывода (input/output, I/O) осуществляются напрямую с хранилищем, что положительно сказывается на быстродействии. Клиентская сторона так же взаимодействует с серверами метаданных для управления и корректировки I/O операций над хранилищем. Схематичную структуру можно представить рисунком 2.1.1. Решение имеет развитую архитектуру с многократным резервированием, однако представляется сложным для реализации. Тестирование показало, что в настоящий момент продукт является скорее экспериментальным и не готов к широкому применению. Рисунок 2.1.1 - Архитектура Ceph/RDB Sheepdog – представляет собой симметричную архитектуру, где отсутствует единая точка отказа. Архитектура этого проекта, однако, имеет и не решенные вопросы. Так лишние уровни абстракции снижают эффективность. Файловые операции I/O с клиентской стороны осуществляются посредством локального сервиса на каждом узле, который корректирует операции и реализует избыточность данных. Используется управление кластером хранилища, которое автоматически определяет неисправные узлы или новые добавленные узлы, автоматизирую операции над ними. Архитектура платформы Sheepdog представлена на рисунке 2.1.2. Тестирование платформы, проводимое в ходе исследования, показало нестабильность работы (возникновение различного рода ошибок). Рисунок 2.1.2 - Архитектура Sheepdog DRBD – является сетевым распределённым реплицируемым блочным устройством. Оно представляет собой сетевой аналог массива независимых жестких дисков (Redundant Array of Independent Disks, RAID1) зеркалирующих данные, обеспечивая повышенную надежность хранения данных. Простая архитектура определяет работоспособность и производительность (рисунок 2.1.3). Имеется ряд недостатков: в режиме primary-primary при потере сетевого соединения инициируется режим Split-brain, что теоретически может привести к потере данных. Несмотря на недостатки это решение наиболее стабильное и обеспечивает довольно высокую производительность. Таким образом, наиболее приемлемыми характеристиками стабильности и производительности обладает решение хранения данных на базе DRBD. Рисунок 2.1.3. - Архитектура DRBD 2.2 Разработка архитектуры Решение, используемое в проекте, должно предоставлять интерфейс прикладного программирования (Application Programming Interface, API), который позволит гибко управлять всеми необходимыми ресурсами кластера виртуализации. Это требование должно быть выполнено в виде программной библиотеки, которую можно использовать на клиентской стороне. Данный API должен быть предоставлен серверным программным обеспечением, которое будет выполняться на каждом узле и выполнять непосредственные операции локально. Кроме того должен существовать клиент, реализующий как высокоуровневые операции над виртуальной машине (ВМ), так и более низкоуровневые операции управления ВМ и хранилищем данных. Необходимо разработать протокол взаимодействия клиент-серверного программного обеспечения (ПО). В целом разрабатываемая платформа должна уметь создавать виртуальные машины из заранее подготовленных образов и шаблонов конфигурации. Архитектуру, удовлетворяющую выдвинутым требованиям, можно представить рисунком 2.2.1. Рисунок 2.2.1 - Архитектура разработанной системы Таким образом, архитектурное решение может быть представлено в виде аппаратно-программного комплекса, в котором можно выделить основные элементы: хранилище данных, серверное ПО (сервисы агентов), программная библиотека и клиентская часть. 3 Реализация задачи проекта 3.1 Легковесная платформа управления виртуализацией Легковесная платформа управления виртуализацией (virt-platform), представляет собой библиотеку (рисунок 3.1.1), которая реализует API для взаимодействия с агентами всей виртуальной инфраструктуры Рисунок 3.1.1 - Легковесная платформа управления виртуализацией Агент устанавливается на каждый физический узел системы и реализует операции над локальными виртуальными машинами. Учитывая, что стабильно работающего распределенного хранилища виртуальных машин на данный момент нет, было принято решение использовать менеджер логических томов (Logical Volume Manager, LVM) поверх DRBD, что обеспечивает простое отказоустойчивое решение. С точки зрения администратора платформа представляет собой единый интерфейс управления кластером виртуализации, позволяющий выполнять основные операции над виртуальными машинами при помощи разработанной клиентской программы (vpc). Для непосредственного управления блочными устройствами ВМ используется LVM. Для задач низкоуровнего управления виртуальными машинами используется библиотека libvirt [8], которая поддерживает все популярные гипервизоры с открытым исходным кодом. Автоматизированные операции над ВМ выполняет агент, установленный на каждом узле кластера виртуализации. Агент управляется посредством стандартизированного API. Таким образом, virt-platform включается в себя: серверное программное обеспечение(VirtPlatform Agent), библиотеку, реализующую API данной платформы (VirtPlatform API), и клиентское обеспечение для управление платформой (VirtPlatform Client). Всё программное обеспечение написано на высокоуровневом языке Python, с использованием сетевого фреймворка Twisted и других модулей. 3.2 Структура разработанного программного обеспечения Разработанное в проекте ПО представлено в виде программного модуля на языке Python. Дерево каталогов программы представлено на рисунке 3.2.1. Компоненты ПО взаимодействуют при помощи специально разработанного протокола взаимодействия компонентов платформы (Приложение А). В нем описан формат сообщений в виде запроса-ответа, а так же набор параметров сообщения и тип содержимого значений. Каждое сообщение имеет три параметра: method, code, data. Первый параметр - method, указывает на имя метода, который вызывается на стороне агента. Второй параметр - code, характерен только для “ответ”-сообщений. Третий параметр содержит тело сообщения. Рисунок 3.2.1 – Структура каталогов разработанного ПО. Основной модуль включает в себя базовую реализацию протокола взаимодействия (Приложение Б), а так же модули клиентской (Приложение В) и серверной (Приложение Г) части. Основной модуль называется virt_platform. Он содержит подмодули, которые реализуют клиентскую (vpc) и серверную (agentd) часть. Кроме того был разработан модуль unit-тестирования (Приложение Д), предназначенный для автоматического тестирования ПО после внесения изменений. Он включает в себя компоненты для тестирования клиентской части, агента и основного модуля программы. Проект содержит также вспомогательные программы для автоматической сборки rpm-пакетов (Приложение Е). Они выделены в отдельные файлы: скрипты для подготовки сборки и непосредственно спецификацию сборки пакетов для установки в операционные системы Fedora14, 15. После сборки программы получится четыре rpm-пакета: общая библиотека, агент, клиент и вспомогательные программы. 3.3 Типовые задачи виртуализации Можно выделить типовые задачи виртуализации, которые не всегда можно решить "вручную". Как правило, процесс создания виртуальных машин на основе специально подготовленного образа и с использованием библиотеки libvirt, включает в себя: выделение хранилища дла ВМ заданного размера, "применение" образа ВМ, изменение таблицы разделов и файловой системы под новые размеры, запуск виртуальной машины. Без использования библиотеки libvirt процесс значительно усложняется и его проблематично реализовать вручную, потому что приходится взаимодействовать с различными компонентами в отсутствии представления о уже занятых ресурсах. Для рассмотрения взаимодействия и функционирования того или иного компонента разрабатываемой платформы стоит рассмотреть ряд операций, которые дают возможность прокомментировать результат разработки. Рассмотрим операцию создания новой виртуальной машины по заранее заготовленному образу и шаблону настроек (рисунок 3.3.1). Для упрощения будем оценивать операции в пределах одного узла кластера виртуализации. Клиентская программа (vpc), через API вызов (1) сообщает агенту (Agent) о том, что нужно выделить новое хранилище заданного размера (8G), последний создает новый логический раздел в хранилище (2). После этого, на раздел ВМ копируется образ (3), который располагается в хранилище образов (Image Store), далее производятся операции с таблицей разделов и файловой системой. Используется шаблон конфигурации из хранилища шаблонов (Template Store) (4), на основании которого формируется конфигурация для создания виртуальной машины с помощью библиотеки libvirt (5). После этого виртуальная машина становится доступна к использованию. Рисунок 3.3.1 - Операция создания новой виртуальной машины по заранее заготовленному образу и шаблону настроек Рассмотрим теперь процесс миграции (реплицирования) виртуальной машины с одного узла на другой узел (рисунок 3.3.2). Реплицированное хранилище позволяет иметь на двух серверах (сайте) совершенно одинаковый набор блочных устройств виртуальных машин в режиме чтения/записи. Поэтому возможно осуществлять миграцию виртуальной машины в пределах этих серверов в "горячем" режиме, то есть без остановки виртуальных машин. Такая операция выполняется одной командой в терминале сервера и происходит вызов API, который сообщает агенту о том, что нужно активировать блочное устройство виртуальной машины на сервере назначения, а затем посредством библиотеки libvirt осуществить непосредственно операцию миграции. Рисунок 3.3.2 - Процесс миграции ВМ с одного узла на другой узел в пределах одного сайта Рассмотрим миграцию виртуальной машины за пределы одного сайта (рисунок 3.3.3). Операция отличается лишь тем, что на сервере назначения отсутствует реплицируемое доступное для чтения/записи блочное устройство виртуальной машины. Поэтому перед непосредственной операции миграции, блочное устройство импортируется на сервер назначения посредством скоростного протокола AoE (ATA over Ethernet). Рисунок 3.3.3 - Процесс миграции ВМ с одного узла на другой узел в пределах нескольких сайтов Заключение Сравнивая разработанный проект с операциями, которые необходимо было бы выполнить без него, можно прийти к выводу, что решение обладает рядом преимуществ: гибкое управление ресурсами кластера виртуализации, автоматизация операций над виртуальными машинами, наличие развитого интерфейса. В ходе проекта были проанализированы современные технологии управления виртуальными машинами и средой виртуализации в целом, проведено сравнительное тестирование распределенных хранилищ данных. На основе полученных результатов разработана архитектура легковесной платформой управления виртуализацией. С помощью выбранных технологий была создана платформа управления средой создания виртуальных структур. В настоящий момент проводится тестирование, исправление ошибок и доработка проекта. Легковесная платформа управления виртуализацией может найти своё применение в сфере обучения (курсы, требующие применения виртуальной среды, тестирование различных виртуальных систем, и т.д.), при создании исследовательских программно аппаратных комплексов, в IT-инфраструктуре предприятий для развертывания программного обеспечения в виртуальной среде.

Похожие:

	«Название темы» Обязательные структурные элементы отчета о нир выделены полужирным шрифтом. В отчет о нир объемом не более 10 страниц содержание...		Реферат Тема нир Тема нир: Исследование возможности принудительного радиоактивного распада ядер вольфрама
	Реферат Тема нир Тема нир: Исследование возможности принудительного радиоактивного распада ядер вольфрама		Реферат Тема нир Тема нир: Анализ экономического механизма и разработка критериев эффективности системы консалтинга для издательско-полиграфического...
	Реферат Тема нир ...		Реферат Тема нир ...
	Реферат Тема нир Тема нир: Анализ экономического механизма и разработка критериев эффективности системы консалтинга для издательско-полиграфического...		Реферат Тема нир Тема нир: Математическое моделирование и исследование квазипериодических структур
	Реферат Тема нир Тема нир: Математическое моделирование и исследование квазипериодических структур		Реферат Тема нир Тема нир: Разработка способов снижения износа и повышения химической стойкости резинотехнических изделий для полиграфии и других...
	Реферат Тема нир Тема нир: Методология определения цветового и структурного соответствия при сравнении изображений, воспроизведенных на носителях...		Рекомендации по предотвращению типовых недостатков в оформлении итоговых... Нир, выполненных по Программе фи, необходимо соблюдать требования гост 32-2001. По результатам внутренней экспертизы итоговых отчетов...
	Рекомендации по предотвращению типовых недостатков в оформлении итоговых... Нир, выполненных по Программе фи, необходимо соблюдать требования гост 32-2001. По результатам внутренней экспертизы итоговых отчетов...		План нир управления инновационного развития Совершенствование моделей краткосрочного прогнозирования социально-экономического развития Российской Федерации
	Отчет о нир (заключительный) Рекомендации по оформлению отчетной документации по государственным контрактам на выполнение нир в рамках федеральной целевой программы...		Реферат с элементами нир, представляемый на Конкурс может содержать следующие разделы К положению об организации и проведении конкурса на лучший реферат с элементами нир для студентов младших курсов в рамках ниу