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

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

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

ВЫСШАЯ ШКОЛА ЭКОНОМИКИ

ФАКУЛЬТЕТ КОМПЬЮТЕРНЫХ НАУК

Курсовая работа

Разработка облачной системы под управлением XAPI/Xen

по направлению подготовки 09.04.04 Программная инженерия

образовательная программа « Системное программирование»

Студент

Борисов Павел Геннадьевич

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

д. ф.-м. н., профессор

А.К. Петренко

Москва 2019



Аннотация

Работа посвящена созданию системы управления вычислительными ресурсами - облачной системы - для системы виртуализации Citrix XenServer. Система имеет интерфейс прикладного программирования, написанный с использованием спецификации GraphQL и графический web-интерфейс.

Abstract

This paper is dedicated to developing a cloud computing system for managing computing resources available through Citrix XenServer. The system has a GraphQL API and web interface.

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



Введение

Наименование программы

Наименование программы - «Облачная система под управлением XAPI/Xen».

Краткое наименование программы - «VMEmperor».

Документы, на основании которых ведется разработка

Разработка ведется на основании приказа Национального исследовательского университета "Высшая школа экономики" № 6.18.1-02/0512-02 от 05.12.13.



1. Назначение и область применения

1.1. Назначение программы

1.1.1. Функциональное назначение

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

1.1.2. Эксплуатационное назначение

Управление виртуальной инфраструктурой является актуальной задачей, имеющей широкий круг приложений, например:

1) Создание облачной инфраструктуры в организации.

VMEmperor может быть интегрирован в любую систему авторизации пользователей, например LDAP. Это позволит использовать существующую инфраструктуру организации для предоставления доступа к ресурсам Xen.

2) Предоставление облачной инфраструктуры как сервиса

Так как VMEmperor не зависит от системы авторизации, облачные ресурсы могут быть предоставлены по (платной) подписке.

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

1.2. Краткая характеристика области применения

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

- Тестирование программного обеспечения в различных программных окружениях и в условиях ограниченных ресурсов

- Изоляция ПО с целью обеспечения безопасности

- Обучение работе с новым ПО без риска нанести урон «боевым» системам

- Предоставление части ресурсов компьютера/кластера пользователям по подписке

1) 

2. Технические характеристики

2.1. Постановка задачи на разработку программы

Разрабатываемая программа должна:

1) Реализовывать доступ к избранным возможностям API XenServer для авторизованных клиентов через протокол HTTP через собственный открытый API

- Создание/удаление виртуальной машины

- Установка размера оперативной памяти и характеристик виртуального процессора

- Создание/удаление новых виртуальных накопителей и подключение их к виртуальным машинам

- Подключение виртуальных сетей к виртуальным машинам

- Просмотр статистики использования ресурсов

2) Реализовывать возможность ограничения доступа к ресурсам и ограничения по объемам ресурсов для пользователей и групп со стороны администратора

3) Реализовывать web-интерфейс к данному API

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

2.2. Описание алгоритма и функционирования программы

Серверная часть приложения выполнена в виде Web-сервера на языке программирования Python 3 на основе сервера Tornado. Приложение работает по алгоритму стандартного web-сервера, параллельно принимая запросы от клиентов. Программа предусматривает абстракцию от источника аутентификации. В текущем дистрибутиве программы используется аутентификация по протоколу LDAP, но природа аутентификации не влияет на принцип функционирования программы.

Входными данными в серверной части являются HTTP GET, POST WebSocket-запросы. Все запросы, кроме запросов авторизации являются GraphQL-запросами, то есть выполняются по стандарту GraphQL[14]. Для запросов аутентификации данные передаются в формате JSON. В дальнейшем, под «параметрами запроса» имеем ввиду те данные, которые нужно передать с запросом в виде JSON-объекта, либо схему GraphQL-запроса. Перед выполнением любого запроса, кроме list_pools, следует авторизоваться (см. п. 3.2.1.1.1)

2.2.1. Взаимодействие с XenServer

Взаимодействие с XenServer осуществляется через запросы событий со стороны VMEmperor к XenServer в резидентном режиме в отдельном потоке. Событие - любое изменение характеристик любого объекта инфраструктуры Xen. Эти события затем фильтруются, и информация о состоянии объектов записывается в виде JSON-документов в кеширующую базу данных документов RethinkDB. Обоснованием к использованию базы данных является соображение о минимизации количества запросов к XenServer. Благодаря этому, прямые запросы к XenServer API осуществляются только тогда, когда пользователь хочет создать или изменить инфраструктурный объект. Получение информации о состоянии объектов не приводит к запросу в XenAPI, что позволяет рассматривать возможности масштабирования настоящего приложения в будущем.

2.2.2. Взаимодействие с объектами XenServer с помощью классов Python API XenServer, которое использует формат XML-RPC для транспорта данных, состоит из классов, полей и сообщений. Данные понятия раскрываются на веб- странице XenAPI[13].

Для каждого класса XenAPI (кроме классов метрик и некоторых других) существует эквивалентный класс Python, методами которого являются методы соответствующего класса XenAPI, как в синхронной, так и в асинхронной реализации. Кроме того, существуют методы - обращения к полям класса, как показано в источнике[13].

2.2.3. Создание виртуальной машины

В процессе создания виртуальной машины выполняются следующие шаги:

1. Регистрация задачи создания ВМ внутри vmemperor, и возврат идентификатора задачи пользователю. Создание «клона» выбранного шаблона установки (аргумент template процедуры создания виртуальной машины)

2. В зависимости от типа шаблона:

1) Получение IP-адреса (агрумент ip, в случае отсутствия - настройка сети по DHCP), шлюза (аргумент gateway), маски подсети (аргумент netmask), серверов DNS(аргументы dns0, dns1), имени создаваемого пользователя (аргумент username), пользовательского пароля (аргумент password), полного имени пользователя (аргумент fullname), метода разбивки диска (аргумент partition). В данном случае применяется автоматическая установка

2) Получение уникального идентификатора образа ISO для установки. В данном случае применяется установка

3. Создание нового виртуального накопителя на выбранном хранилище носителей (аргумент storage) с размером, указанным в аргументе vdi_size в байтах

4. Установка оперативной памяти в размер, указанный в аргументе ram_size

5. Установка названия виртуальной машины в аргумент name_label

6. Подключение виртуальной машины к выбранной сети (аргумент network)

7. Запуск установки. В случае автоустановки - применение параметров из п. 3 и автоматическая установка драйверов для интеграции с Xen через сценарии автоматической установки

8. Запись SSH-ключа для доступа с помощью Ansible в ~/.ssh/authorized_keys виртуальной машины в случае автоматической установки

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

2.3. Описание и обоснование выбора метода организации входных и выходных данных

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

Входные данные представляют собой HTTP-запросы[12] и GraphQL-запросы[14]

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

JavaScript-объект, полями которого являются элементы словаря JSON.

GraphQL[14] - декларативный синтаксис формирования запросов, произвольно (в рамках некоторой схемы, подобно базе данных) регулирующий формат ответа на запрос - то есть запрос включает в себя множество полей, которые клиент ожидает получить в ответ. Кроме того, у запроса могут быть аргументы, ожидаемые от пользователя.

Запрос GraphQL состоит из названия запроса, множества аргументов - входных данных, каждый из которых характеризуется либо «скалярным» типом (строка, число, дата), либо объектным типом - типом, состоящим из множества полей скалярного или объектного типа; а также выходного типа данных.

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

Существует три типа запросов GraphQL:

- Запрос (Query) - возвращает данные (аналог GET)

- Мутация (Mutation) - возвращает данные и выполняет некоторое изменение данных на сервере (аналог POST)

- Подписка (Subscription) - возвращает данные по мере поступления по протоколу WebSocket

Все запросы принадлежат к одному из трех типов и специфицируются в специальной схеме. Полная схема GraphQL-запросов программы приводится в Приложении 1.

Каждый объект инфраструктуры (виртуальная машина, накопитель и т.д.) характеризуется в запросе уникальным идентификатором (ref). VMEmperor предоставляет возможность получить списки всех объектов, доступных данному пользователю. В разделе 3.3.3 приведены спецификации запросов и их аргументы, в разделе 3.3.1 - входные (объектные) типы данных, 3.3.2 - выходные типы данных.

Приведем пример спецификации GraphQL-запроса типа Query:

type Query {

findUser(query: String!): [User]!

}

Здесь: findUser - название запроса, “query” - аргумент типа String(строка), [User]! - выходной тип данных, скобки [] показывают, что это массив, а восклицательный знак (!) показывает, что результатом запроса не может быть null. “uuid” не является обязательным аргументом, поскольку восклицательного знака после типа аргумента нет.

Если выходной тип данных User определен как

type User {

id: ID!

name: String!

username: String!

}

То пользователь может выбрать любые поля из множества id, name, username и получит соответствующим образом сформированное тело ответа. Например, на запрос:

query {

findUser(“user1”) {

id

name

}

}

Корректный ответ может быть таким (JSON):

{

"data": {

"findUser": [

{

"id": "1",

"name": "User name 1"

}

]

}

}

Обратите внимание, что поле username в ответе не участвует.

Как входные, так и выходные типы данных могут быть расширением базовых типов - интерфейсов.



2.3.1.1. Запросы авторизации (POST)

Запрос авторизации следует выполнить до всех запросов, кроме list_pools. Параметры передаются в теле запроса в формате JSON.

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

2.3.1.1.1. login

Аутентификация обычного пользователя. Используется внешний источник аутентификации

Параметры:

Название	Описание	Является обязательным
username	Имя пользователя	да
Password	Пароль пользователя	да

2.3.1.1.2. adminauth

Аутентификация администратора. Администратор имеет доступ ко всем объектам инфраструктуры. Параметры идентичны login

2.3.1.2. Запросы GraphQL

Документация по запросам GraphQL доступна через Web-интерфейс с помощью утилиты GraphQL Voyager, встроенной в программный комплекс. Для того, чтобы получить документацию по GraphQL-запросам, перейдите по ссылке http://IPADDRESS:3000/voyager, где IPADDRESS - IP-адрес компьютера, на который установлен VMEmperor.

2.4. Описание и обоснование выбора состава технических и программных средств

2.4.1. Состав технических и программных средств

Для работы программы необходим следующий состав программных средств:

- Серверная часть:

o Python 3.7

o RethinkDB

o Пакеты Python, указанные в requirements.txt.

- Клиентская часть:

o Node.JS 8

o NPM (Node Package Manager)

o Пакеты NPM, указанные в frontend/package.json

2.4.2. Обоснование выбора технических и программных средств

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

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

2.5. Сравнение программы VMEmperor и ее аналогов

Главным аналогом программы VMEmperor является программа XenOrcherstra[15]. Иных напрямую аналогичных продуктов, а именно, работающих с XenServer, найдено не было, кроме XenCenter Management GUI, который, в отличие от настоящей программы, является графическим приложением для Windows. Основные возможности программы XenOrchestra приведены в источнике[16].

В отличие от [15], VMEmperor предоставляет возможность делегирования прав на исполнение отдельных действий над виртуальными машинами, а не групп действий. В XenOrchestra пользователь может обладать одной из трех ролей: Admin, Operator, Viewer [17]. В VMEmperor роль “Owner” эквивалентна вышеозначенной роли Admin, и кроме того, любые пользователи могут получить любое подмножество действий.

Кроме того, VMEmperor предоставляет возможность автоматической установки дистрибутивов Linux: CentOS 7, Debian и Ubuntu, а XenOrchestra такой возможности (по состоянию на конец мая 2019) не предоставляет.

VMEmperor обладает API с использованием GraphQL, а XenOrchestra - JSON-RPC. Сравнение данных спецификаций API выходит за рамки данной работы, но API XenOrchestra не документировано, в отличие от настоящего API.

Некоторые возможности, реализованные в XenOrchestra[16],



3. Ожидаемые технико-экономические показатели

3.1. Предполагаемая потребность

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

3.2. Экономические преимущества разработки по сравнению с отечественными и зарубежными образцами или аналогами

Аналогами данного приложения являются XenCenter Management GUI и XenOrchestra. Однако, XenCenter не предоставляет возможности скрывать объекты инфраструктуры и делегировать владение ими. Кроме того, это - приложение для Windows, что накладывает ограничения на программное обеспечение на компьютере клиента. XenOrchestra является web-приложением, но делегирование прав пользователям и группам доступно только с версии Enterprise, которая стоит $220 в месяц по состоянию на 2018 г.

VMEmperor является бесплатным приложением с открытым исходным кодом.



4. Стадии и этапы разработки

Стадии и этапы разработки были выявлены с учетом ГОСТ 19.102-77:

Стадии разработки	Этапы работ	Содержание работ
1. Техническое задание	Обоснование необходимости разработки программы	Постановка задачи
		Сбор исходных материалов
	Научно-исследовательские работы	Определение структуры входных и выходных данных.
		Определение требований к техническим средствам.
		Обоснование принципиальной возможности решения поставленной задачи
	Разработка и утверждение технического задания	Определение требований к программе.
		Определение стадий, этапов и сроков разработки программы и документации на неё.
		Согласование и утверждение технического задания.
2. Технический проект	Разработка технического проекта	Разработка алгоритма решения задачи.
		Окончательное определение конфигурации технических средств.
	Утверждение технического проекта	Разработка плана мероприятий по разработке программы.
		Разработка пояснительной записки.
3. Рабочий проект	Разработка программы	Программирование и отладка программы.
	Разработка программной документации	Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77 [1].
	Испытания программы	Разработка, согласование и утверждение порядка и методики испытаний.
4. Внедрение	Подготовка и защита программного продукта.	Подготовка программы и программной документации для презентации и защиты.
1.		Утверждение дня защиты программы.
1.		Презентация программного продукта.
1.		Передача программы и программной документации в архив НИУ ВШЭ.

5. Порядок контроля и приемки

Виды испытаний

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

Функциональное тестирование осуществляется в соответствии с документом. «Программа и методика испытаний» (ГОСТ 19.301-79), в котором указывают [18]:

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

2) перечень необходимой документации и требования к ней (со ссылкой на пункт 5 настоящего технического задания);

3) методы испытаний и обработки информации;

4) технические средства и порядок проведения испытаний;

Сроки проведения испытаний обсуждаются дополнительно.

Общие требования к приемке работы

Прием программного продукта происходит при полной работоспособности программы при различных входных данных, при выполнении указанных в пункте 4.1.1 настоящего документа функций, при выполнении требований указанных в пункте 4.2. настоящего документа и при наличии полной документации к программе, указанной в пункте 5.1, выполненной в соответствии со специальными требования указанными в пункте 5.2 настоящего технического задания.



Терминология

Виртуальная машина - эмулируемый программными средствами аппаратный комплекс (компьютер)

Виртуальный накопитель - эмулируемый программными средствами накопитель, подключаемый по виртуальной шине IDE или SCSI

PV - Paravirtualization - техника виртуализации, при которой гостевые операционные системы подготавливаются для исполнения в виртуализированной среде, для чего их ядро незначительно модифицируется.

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



Список используемой литературы

1) ГОСТ 19.101-77 Виды программ и программных документов. //Единая система программной документации. - М.: ИПК Издательство стандартов, 2001.

2) ГОСТ 19.102-77 Стадии разработки. //Единая система программной документации. - М.: ИПК Издательство стандартов, 2001.

3) ГОСТ 19.103-77 Обозначения программ и программных документов. Единая система программной документации. - М.: ИПК Издательство стандартов, 2001.

4) ГОСТ 19.104-78 Основные надписи. //Единая система программной документации. - М.: ИПК Издательство стандартов, 2001.

5) ГОСТ 19.105-78 Общие требования к программным документам. Единая система программной документации. - М.: ИПК Издательство стандартов, 2001.

6) ГОСТ 19.106-78 Требования к программным документам, выполненным печатным способом. //Единая система программной документации. - М.: ИПК Издательство стандартов, 2001.

7) ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению. //Единая система программной документации. - М.: ИПК Издательство стандартов, 2001.

8) ГОСТ 19.603-78 Общие правила внесения изменений. //Единая система программной документации. - М.: ИПК Издательство стандартов, 2001.

9) ГОСТ 19.604-78 Правила внесения изменений в программные документы, выполненные печатным способом. //Единая система программной документации. - М.: ИПК Издательство стандартов, 2001.

10) ГОСТ 15150-69 Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды. - М.: Изд-во стандартов, 1997.

11) Устинов В.. Надежность оптических дисков: как их правильно хранить и использовать. //Журнал «625» №7. М.: Издательство «625», 2005.

12) ГОСТ Р 7.02-2006 Консервация документов на компакт-дисках. Общие требования. - М.: ИПК Издательство стандартов, 2006.

13) ГОСТ 18300-87 Спирт этиловый ректификованный технический. Технические условия. - М.: ИПК Издательство стандартов, 1997.

14) ГОСТ 9805-84. Спирт изопропиловый. Технические условия. - М.: ИПК Издательство стандартов, 1984.

15) ГОСТ 19.602-78 Правила дублирования, учета и хранения программных документов, выполненных печатным способом. //Единая система программной документации. - М.: ИПК Издательство стандартов, 2001.

16) ГОСТ 19.301-79 Программа и методика испытаний. Требования к содержанию и оформлению. //Единая система программной документации. - М.: ИПК Издательство стандартов, 2001.



Приложение

Формат файла описания сценариев Ansible для VMEmperor

Файл должен находиться в корневой директории сценария (playbook) ansible и иметь название vmemperor.conf

Файл имеет формат YAML[10] со следующими ключами:

name (string)

Название сценария

description (string)

Описание сценария

playbook (string)

Путь к файлу запуска (запускаемому с ansible-playbook) относительно текущей директории

inventory (string; optional)

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

variables (dictionary, optional)

Описание переменных, доступных для редактирования пользователем

Ключи словаря

Названия переменных из файлов host_vars/all и group_vars/all

Структура значений в словаре

Каждое значение - словарь со следующими ключами:

· description - описание переменной

· type - тип переменной (см. ниже)

Типы переменной

· str - string (строка)

· int - number (число)

· bool - check box (флажок)

· option - list of choices (список с выбором варианта, см. ниже)

Тип option

Для типа option подразумевается еще один ключ: options. Его значение - словарь, в котором ключами выступают все возможные варианты выбора.

Значения в options

Каждое значение options - словарь с ключом description и значением - описанием данного варианта выбора

Пример (на английском языке)

---

name: WordPress

description: WordPress CentOS Setup

playbook: site.yml

inventory: hosts

variables:

wp_version:

description: WordPress version

type: str

wp_sha256sum:

description: WordPress release SHA256

type: str

mysql_port:

description: MySQL port

type: int

server_hostname:

description: WordPress server hostname

type: str

auto_up_disable:

description: Disable automatic updates

type: bool

core_update_level:

description: Core Update Level

type: option

options:

true:

description: Development, minor, and major updates are all enabled

false:

description: Development, minor, and major updates are all disabled

minor:

description: Minor updates are enabled, development, and major updates are disabled

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

...