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

Минобрнауки России

Федеральное государственное автономное образовательное учреждение высшего образования «Национальный исследовательский университет «Московский институт электронной техники»

Факультет микроприборов и технической кибернетики

Кафедра вычислительной техники

по направлению 09.03.01 «Информатика и вычислительная техника»

Библиотека классов .NET для управления ресурсами OpenStack облака



Аннотация

Библиотека классов .NET для управления ресурсами OpenStack облака.

Клочков Кирилл Сергеевич

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



Annotation

.NET class library for resource management of a OpenStack cloud.

Kirill Klochkov

In this work the problem of creation of the software means of the .NET platform intended for interaction with infrastructure of OpenStack of a cloud is considered. The work is devoted to the review of the OpenStack technology, analysis of possible solutions, and also development and implementation of class library, compatible to the .NET platform, realizing a functionality on resource management of OpenStack cloud.



Содержание

Введение

Постановка задачи

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

1.1 Область применения

1.2 Подсистемы платформы

1.3 OpenStack API

1.4 Описание проблемы

1.5 Вывод

2. Реализация библиотеки классов

2.1 OpenStack Python SDK

2.2 Выбор языка программирования

2.3 Архитектура библиотеки классов

2.4 Реализация базовых классов и интерфейсов архитектуры.

2.5 Реализация классов базовых команд

2.5.1 Пространство имён OpenstackManager.Identity

2.5.2 Пространство имён OpenstackManager.Compute

2.6 Реализация классов сценариев

2.6.1 Регистрация пользователя

2.6.2 Создание виртуального сервера

2.7 Вывод

3. Интеграция разработанной библиотеки классов

3.1 Архитектура проектного решения

3.2 Инфраструктура OpenStack

3.1 Тестирование результатов интеграции

3.2 Вывод

Заключение

ПРИЛОЖЕНИЕА



Введение

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

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

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

· Платформа как сервис (PaaS).В данном случае предоставляется доступ к окружению, в котором разработчики создают и разворачивают свои приложения. Пользователь абстрагирован от знания и понимания того, сколько памяти и процессоров использует его приложение. Примером PaaS является Google App Engine.

· Приложение как сервис (SaaS). Пользователь получает доступ к приложению через веб-порталы. Таким образом, потребитель работает с приложением, установленным на удаленной машине. Пример SaaS - WordPress.

Инфраструктура как сервис (IaaS) -- наиболее зрелая и востребованная в корпоративном сегменте модель облачных вычислений. Именно в IaaS инфраструктурах наиболее последовательно воплощаются классические преимущества облачных вычислений.

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

Управление облачнойIaaS-инфраструктурой осуществляется поставщиком сервисов, а потребитель, в свою очередь, управляет операционными системами, хранилищем, развернутыми приложениями и, возможно, имеет ограниченный контроль над отдельными компонентами сети.[2] Как правило, провайдер покупает один мощный сервер, на него устанавливается система виртуализации, а затем мощности этого сервера раздаются нескольким виртуальным машинам. Каждый из клиентов VDS видит у себя в консоли совершенно отдельный независимый сервер и имеет полный доступ к нему. Современные серверные процессоры от Intel и AMD имеют встроенную поддержку виртуализации, поэтому затраты на организацию нескольких VDS на одном сервере минимальны.

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

Постановка задачи

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

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

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

· Реализовывать функционал, позволяющий пользователю создавать новые виртуальные сервера и управлять существующими.

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



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

openstack библиотека сервер виртуальный

Проект по разработке облачной операционной системы OpenStack появился в июне 2010 года как проект, объединивший разработку Национального космического агентства США (NASA) для создания виртуальных серверов Nova и программную систему хранения данных Swift от американского хостинг-провайдера Rackspace. Важно понимать, что сам по себе OpenStack - это проект по разработке. Сайт проекта Openstack.org не предоставляет эталонного дистрибутива. Напротив, вендоры на основе кода проекта OpenStack создают свои дистрибутивы. [3]

1.1 Область применения

Главное отличие комплекса OpenStack от традиционных систем промышленной виртуализации заключается в ориентации на масштабируемые вертикально промышленные приложения.[4]

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

Облачные платформы, такие как OpenStack, предназначены для использования с другим классом приложений, таких как Apache Cassandra, MongoDB и Hadoop, которые спроектированные для горизонтального масштабирования, и являются устойчивыми к падению виртуальных машин. Ресурсы могут быть расширены за счет добавления новых экземпляров приложений на однотипных виртуальных серверах с последующей балансировкой нагрузки. Эти распределенные приложения самостоятельно обеспечивают собственную отказоустойчивость на уровне приложения, независимо от базовой инфраструктуры и передовых функций гипервизоров. Жизненный цикл подобных виртуальных машин - как правило, месяцы.

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

Таким образом, благоприятными условиями для использования платформы OpenStack являются:

· хостинг серверов и приложений с коротким сроком жизни (часы, дни, недели);

· хостинг некритичных виртуальных серверов и приложений;

· частое развертывание однотипных серверов.

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

Таблица 1, Примеры использования технологии OpenStack

Пример	Описание
Тестовые и лабораторные стенды, среды обучения	Любые компании стремятся к сокращению рисков, связанных с IT, в production окружениях. Часто это решается путём моделирования и тестирования процессов обновления и внедрения нового ПО в лабораторных средах. Требования к таким средам невелики, а срок существования виртуальных серверов для тестов и обучения, как правило не превышает 1 недели. OpenStack позволяет существенно ускорить развёртывание тестового окружения, и, тем самым сокращает трудозатраты на развертывание и моделирование различных ситуаций.
Среды разработки	Подготовка среды для разработки вызывает у разработчиков некоторые сложности и отнимает драгоценное время. Автоматизированные системы и использование шаблонов в Openstack сокращают трудозатраты на создание такое среды, освобождая разработчиков от необходимости выполнения рутинных операций.
Среды автоматизированного тестирования	Большая часть современных бизнес-приложений является распределенной. Качественная разработка требует выполнения тестирования. Если приложение состоит из веб-серверов, базы данных и серверов приложений, распределенных между несколькими серверами, то подготовка процесса тестирования будет отнимать значительное время.OpenStackобладает возможностями орекстрации и широкой автоматизации всех облачных процессов, что позволяет, написав один раз сценарий тестирования, многократно повторять его по запросу или в полностью автоматизированном режиме.
Платформа облачной виртуализации для Cloud-ready приложений	Вендоры ПО постоянно обновляют свои приложения, подготавливая их для работы в облаке. КомпанияMicrosoft активно адаптирует свои продукты. На сегодняшний день в облаке Openstack могут прекрасно работать следующие приложенияMicrosoft: · Microsoft Exchange · Microsoft Lync · Microsoft MS SQL Server AlwaysOn СУБД: · Apache Cassandra · MongoDB

1.2 Подсистемы платформы

Проект OpenStack, который также называют облачной операционной системой, состоит из ряда отдельных проектов, разрабатывающих отдельные подсистемы. Конкретная установка OpenStack может включать в себя лишь часть из них. Некоторые подсистемы могут использоваться вообще автономно или как часть других OpenSource-проектов. Каждый из проектов имеет свой документированный набор REST API, утилит командной строки и «родные» интерфейсы Python, предоставляющие набор функций, аналогичных утилитам командной строки.

Одним из базовых сервисов является OpenStack Compute (Nova). Этот сервис устанавливается на всех вычислительных узлах кластера. Он предоставляет уровень абстракции виртуального оборудования (процессоры, память, блочные устройства, сетевые адаптеры). Nova обеспечивает управление экземплярами виртуальных машин, обращаясь к гипервизору и отдавая такие команды, как, например, их запуск и остановку.

Следующий сервис под названием OpenStack Networking (Neutron) отвечает за сетевую связанность. Пользователи могут самостоятельно создавать виртуальные сети, маршрутизаторы, назначать IP-адреса. Один из механизмов, обеспечиваемых Neutron, называется «плавающие адреса». Благодаря этому механизму виртуальные машины могут получать внешние фиксированные IP-адреса. Через механизм подключаемых модулей можно реализовать такой функционал, как балансировщик сетевой нагрузки как сервис, брандмауэр как сервис и VPN как сервис.

Служба идентификации OpenStack Keystone представляет собой централизованный каталог пользователей и сервисов, к которым они имеют доступ. Keystone выступает в виде единой системы аутентификации облачной операционной системы. Keystone проверяет действительность учетных записей пользователей, проверяет сопоставление пользователей проектам OpenStack и ролям и в случае успеха выдает токен на доступ к другим сервисам. Также Keystone ведет каталог служб. [3]

OpenStack Image Service (Glance) ведет каталог образов виртуальных машин, которые пользователи могут использовать как шаблоны для запуска экземпляров виртуальных машин в облаке. Также данный сервис предоставляет функционал резервного копирования и создания моментальных снимков.

Сервис OpenStack Block Storage (Cinder) управляет блочным хранилищем, которое могут использовать запущенные экземпляры виртуальных машин. Это постоянное хранилище информации для виртуальных машин. Можно использовать моментальные снимки для сохранения и восстановления информации или для целей клонирования.

Сервис OpenStack Object Storage (Swift), помимо Nova, является одним из двух первых проектов, появившихся в OpenStack. Сервис представляет собой объектное хранилище, позволяющее пользователям хранить файлы. Swift имеет распределенную архитектуру, обеспечивая горизонтальное масштабирование, а также избыточность и репликацию для целей отказоустойчивости. Swift ориентирован преимущественно на статические данные, такие как образы виртуальных машин, резервные копии и архивы.

OpenStack Orchestration (Heat) - сервис, задача которого - обеспечение жизненного цикла приложения в облачной инфраструктуре. При помощи шаблона формата AWS CloudFormation сервис управляет остальными сервисами OpenStack, позволяя создать большинство типов ресурсов (виртуальные машины, тома, плавающие IP, пользователи, группы безопасности и т. д.). Heat при помощи данных Ceilometer также может осуществлять автоматическое масштабирование приложения. Шаблоны описывают отношения между ресурсами, и это позволяет сервису Heat осуществлять вызовы API OpenStack в правильном порядке, например, сначала создать сервер, а потом подключить к нему том. [5]

И наконец, самый близкий к пользователю облака сервис OpenStack Dashboard (Horizon), позволяющий управлять ресурсами облака через веб-консоль.

1.3 OpenStack API

OpenStackAPI является RESTFull интерфейсом. Это означает, что для запуска команды, выполняющей некоторую функцию управления ресурсами OpenStack облака, необходимо отправить запрос на соответствующий URL-адресс. Формат URL определяет, какая команда будет выполнена. Запрос к URL-адрессу осуществляется по протоколу HTTP, как и в web-браузере. Это значит, что на некоторые запросы можно выполнить прямо из браузера, но это работает только в том случае, если в запрос не включается какая-то дополнительная информация. Как правило, вместо этого запросы отправляются напрямую из кода программы или с помощью утилиты командной строки, например cUrl. cUrl это один из самых простых способов отправить запрос серверу.

Как правило, каждая API-функция определяется следующими элементами

1) URL-путь, который включает себя базовый адрес, имя команды и дополнительный параметры, разделенные прямой косой чертой.

2) Метод отправления запроса (в основном, GET или POST, но существуют и другие варианты, которые не так часто используются).

3) Дополнительные данные, которые можно передать в заголовках сообщения в случае Get-запроса или в теле сообщения, в случае POST запроса.

Базовую часть URL-адреса называют конечной точкой. Разные сервисы имеют различные конечные точки, которые можно найти в документации к OpenStack.

APIOpenStack можно использовать, чтобы запускать виртуальные сервера, создавать образы, или,например, прикреплять метаданные к серверам и образам.[6] На рисунке 1 изображена архитектура взаимодействия пользователя с сервисами OpenStack через вызовы методов API

Рисунок 1.OpenStackAPI

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

curl -shttps://identity.api.rackspacecloud.com/v2.0/tokens -X 'POST' \

-d '{"auth":{"passwordCredentials":{"username":"MyRackspaceAcct", "password":"MyRackspacePwd"}}}' \

-H "Content-Type: application/json"

В ответ на отправленное http-сообщение возвращается следующий JSON-объект:

1.4 Описание проблемы

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

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

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

Таким образом, на этапе планирования программного проекта, в контексте задач, на решение которых он будет направлен, лучшем выбором базовой платформы, языка программирования и средств разработки может оказаться стек технологий .NET компании Microsoft. Платформа .NET состоит из общеязыковой среды выполнения (среды CLR) и библиотеки классов .NET Framework. Среду выполнения можно считать агентом, который управляет памятью, выполнением потоков, выполнением кода, проверкой безопасности кода, компиляцией и другими системными службами. При этом накладываются условия строгой типизации и другие виды проверки точности кода, обеспечивающие безопасность и надежность.[7] Библиотека классов является комплексной объектно-ориентированной коллекцией допускающих повторное использование типов, которые применяются для разработки приложений -- начиная с обычных приложений, запускаемых из командной строки, и приложений с графическим интерфейсом пользователя (GUI), и заканчивая приложениями, использующими последние технологические возможности ASP.NET, такие как Web Forms и веб-службы XML.[8] Платформа .NET обеспечивает согласованную объектно-ориентированную среду программирования для локального сохранения и выполнения объектного кода, для локального выполнения кода, распределенного в Интернете, либо для удаленного выполнения, минимизирует конфликты при развертывании программного обеспечения и управлении версиями, гарантирует безопасное выполнение кода, включая код, созданный неизвестным или не полностью доверенным сторонним изготовителем, обеспечивает единые принципы работы разработчиков для разных типов приложений, таких как приложения Windows и веб-приложения. Также, платформа предоставляет возможность интегрировать код платформы .NET Framework с любым другим кодом, совместимым с этой платформой, т.е. программисты могут писать приложения на привычном языке разработки, при этом используя все преимущества среды выполнения, библиотеку классов и компоненты, написанные другими разработчиками на других языках.

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

1.5 Вывод

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



2. Реализация библиотеки классов

На этапе реализации была разработана совместимая с платформой .NET библиотека классов, которая предоставляет набор средств, необходимых для управления ресурсами облака.

2.1 OpenStackPythonSDK

Для нахождения оптимального варианта решения стоит принять во внимание существующее возможное решения описанной ранее проблемы. Платформа OpenStack предоставляет проект OpenStack Python SDK, который является попыткой предоставить потребителям конечную точку входа для работы с OpenStack, упрощая создание различного клиентского программного обеспечения. Данный комплекс включает в себя пакет библиотек, подробную документацию и примеры использования. OpenStack Python SDK обеспечивает понятный и последовательный интерфейс для написания приложений, работающих с сервисами, обеспечиваемыми конкретной облачной инфраструктурой. SDK имплементирует связь Python с Openstack API, которая позволяет выполнять автоматические задачи вызовами методов python-объекта, а не с помощью непосредственных вызовов методов Opensatck API.

Следующий пример кода показывает, как можно использовать возможности OpenStack Python SDK, чтобы выполнить простое подключение облаку и получить список контейнеров в объектном хранилище Swift.

from openstack import connection

conn = connection.Connection(auth_url="http://openstack:5000/v3",

project_name="big_project",

username="SDK_user",

password="Super5ecretPassw0rd")

for container in conn.object_store.containers():

print(container.name)

OpenStackPythonSDK реализует весь необходимый функционал для взаимодействия с ресурсами облака, но, несмотря на существующую возможность интеграции кода Python с любым другим кодом платформы .NET, подход, основанный на вызовах методов данного SDK, имеет несколько существенных недостатков. Во-первых, язык Pythonне имеет единого стандарта реализации, что может привести к различным проблемам с контролем и синхронизацией версий.Во-вторых, язык Python- динамически типизируемый. Данный факт подразумевает, что разработчики не смогут полностью воспользоваться преимуществами строгой типизации языков платформы .NET, а также, будут вынужденысамостоятельно реализовывать обработку определенного класса ошибок и т.д., что подразумевает не менее трудоемкий процесс, чем непосредственный вызов методов APIOpenStack.

2.2 Выбор языка программирования

Для разработки библиотеки классов, совместимой с платформой .NET, был выбран язык программирования C#.

Прежде всего, данное решение связанно с тем, что C# является чисто объектно-ориентированным языком и отражает возможности и особенности .NET. В нем доступна вся обширная библиотека классов .NET Framework. Кроме того, C# - язык компонентного программирования, основной мотивировкой и целью которого является разработка программных компонент многократного использования. В роли таких компонент выступают классы и интерфейсы. Они структурированы с помощью пространств имен, которые обеспечивают удобство обращения к группе тех или иных возможностей, сосредоточенных в одном пространстве имен, с одной стороны, и отсутствие конфликтов имен с прочими пространствами имен, с другой стороны. Данный язык программирования является строго типизированным, что ускоряет и упрощает поиск ошибок на этапе компиляции, играет значительную роль в самодокументировании программы, а также, в случае использования среды разработки VisualStudio, ускоряет процесс разработки за счёт отсеивания вариантов, заведомо не подходящих по типу. Таким образом, язык C# - удобный, лишенный "пережитков прошлого" (вроде заголовочных файлов), использующий полезные универсальные концепции и механизмы, заимствованные из других языков, эффективно реализованный, современный объектно-ориентированный язык.

2.3 Архитектура библиотеки классов

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

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

Фундаментом конечной архитектуры библиотеки классов стал паттерн объектно-ориентированного проектирования Command. Здесь под паттерном проектирования понимается описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте.

Основным элементом паттерна и, соответственно, дизайна библиотеки является интерфейс ICommand. Интерфейс в C# представляет собой именованный набор абстрактных методов, которые моделируют некоторый набор поведения.[9]Выбор интерфейса, как базовой логической абстракции, связан с расчетом на то, что в том коде, где будет объявлена ссылка на ICommand, могут быть использованы объекты любого из классов, его реализующих, что позволяет в полной мере воспользоваться одним из принципов объектно-ориентированного программирования - полиморфизмом.

Интерфейс ICommandсостоит из единственной операции-Execute [10], что подразумевает, что конкретные классы, реализующие ICommand, определяют пару «получатель-действие», где получателем является облако, готовое к обработке запросов на выполнение задач, а действием - формирование и отправление HTTP-запроса, соответствующего конкретной задачи по взаимодействию с ресурсами облачной инфраструктуры.

Применение паттернаCommand, позволило отделить объект, инициирующий операцию, от объекта, который «знает», как ее выполнить. [11]Это решение помогло получить некоторые преимущества при проектировании кода на следующих этапах работы, например, возможность ассоциировать несколько команд с одной и той же функцией, динамически подменять команды в контекстно-зависимых модулях и реализовать сложные сценарии, компонуя простые команды в более сложные.

Помимо ICommand, архитектура спроектированной библиотеки классов содержит интерфейс IQuery<T>, который является немного более сложной версией паттерна Command. Подразумевается, что класс, реализующий метод Executeданного интерфейса, получает в ответ на сообщение получателю набор структурированных данных, которые он должен вернуть клиентскому коду.

В силу того, что конкретный запрос подразумевает специфичные для него возвращаемые данные, для реализации этого требования интерфейс IQuery определен, как обобщенный. Обобщенные классы инкапсулируют операции, не относящиеся к какому-либо определенному типу данных, сочетая при этом возможность многократного использования, строгую типизацию и эффективность. В определении универсального типа или метода параметры типа представляют собой заполнитель для определенного типа, задаваемого клиентом при создании переменной универсального типа. Аргумент-тип для этого конкретного класса может быть любым типом, распознаваемым компилятором.[9] Таким образом, можно создать любое количество наследников IQuery<T>, и каждый из них может использовать разные аргументы типа.

На рисунке 2 представлена UML-диаграмма, которая полностью описывает основные фрагменты описанной выше архитектуры.

Рисунок 2. Архитектура классов

Реализация интерфейсов ICommandи IQuery<T>представлена в листинге 1 приложения А.

2.4 Реализация базовых классов и интерфейсов архитектуры

На этапе реализации базовых классов библиотеки был выполнен анализ набора функций, доступных через Openstack API и формализован общий алгоритм взаимодействия с облаком по протоколу HTTP. На основе результатов проведенного анализа было определенно пространство имён OpenstackManager.Core. Данный модуль содержит определения абстрактных классов BaseCommand и BaseQuery, инкапсулирующих общие алгоритмы взаимодействия кода библиотеки с API-интерфейсом облака и класс данных HtttpRequestParams, в котором определенны поля, специфицирующие параметры Http-запроса.

Для вызова определенной API-функции, необходимо выбрать в документации нужный метод, сформировать запрос согласно документации метода, и выполнить сформированный запрос. В большинстве случаев, для вызова требуемого метода OpenstackAPI необходимо специфицировать следующие атрибуты HTTP-запроса: method, content-type, message-body и X-Auth-Token (если запрос требует предварительной аутентификации). В ответ на запросприходит ответ, который также описан в документации каждой функции.[6] Алгоритм, формализующий описанный характер взаимодействия, изображён на рисунке 3.

Реализация класса HttpRequestParams, который содержит члены, инкапсулирующие перечисленные ранее атрибуты HTTP-запроса, представлена в листинге 2 приложения А.

Классы BaseCommandиBaseQuery, определенные в пространстве имён OpenstackManager.Core являются абстрактными. Это значит, что нет возможности инстанциировать данные классы.[9] Таким образом, они просто хранят в себе общий для всех команд наследников алгоритм отправления HTTP-запроса и обработку его результата. Также, в каждом из классов определен абстрактный метод GetHttpParams.



Рисунок 3. Алгоритм взаимодействия с API Openstack

Данный метод необходим для получения специфичных для конкретной команды параметров HTTP-запроса, т.е. определяет интерфейс для создания объекта, но оставляет подклассам решение о том, как именно инстанцировать класс HttpRequestParams. Данное архитектурное решение является примером использования шаблона объектно-ориентированного проектирования Фабричный метод.[10] Поскольку решение о том, как инстанцировать класс HttpRequestParams, зависит от конкретной команды, то BaseCommand(BaseQuery) не может «предсказать», что именно понадобится. Этому классу известно лишь, когда нужно инстанцировать новый экземпляр HttpRequestParams, а не как именно. В методе GetHttpParamsинкапсулируется информация о том, как создать объект класса HttpRequestPatams, и это знание выводится за пределы класса BaseCommand(BaseQuery). Подклассы класса BaseCommand(BaseQuery) переопределяют абстрактную операцию GetHttpParams таким образом, чтобы она возвращала подходящий объект класса HttpRequestParams.

Для взаимодействия с OpenstackAPI по протоколу HTTP используется класс WebClient из пространства имен System.Net базовой библиотеки классов. Данный класс предоставляет общие методы обмена (приема и передачи) данными с любыми локальными ресурсами, ресурсами в сети Интернет и ресурсами в интрасети, указанными с помощью URI.

В качестве средства десериализации, т.е. сборки .NET, обеспечивающей преобразование JSON ответов от OpensatckAPIв объекты определенных в данной работе классов-данных, используется библиотека NewtonJson.NET.

Реализация классовCommandBase и QueryBase<T>изображена в листинге 3 приложения А.

2.5 Реализация классов базовых команд

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

2.5.1 ПространствоимёнOpenstackManager.Identity

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

Класс CreateUserQuery

Базовым объектом системы управления идентификацией OpenStackявляется т. н. "пользователь" -- в данном случае это цифровое представление человека или системы, использующей какие-либо сервисы OpenStack.[12]

Метод API-интерфейса OpenStack, выполняющий операцию создания пользователя вызывается посредством HTTPPOSTзапроса по URL-адресу, содержащему полностью прописанное доменное имя хоста в системе DNS или IP-адрес хоста и URL-пути ~/v3/users, уточняющего информацию о месте нахождения ресурса.

В таблице 2 перечислены необходимые параметры, которые должны быть переданы конструктору класса CreateUserQuery.

Таблица 2.Парметры конструктора класса CreateUserQuery

Параметр	Тип	Описание
Url	String	Доменное имя или IP-адрес хоста.
Name	String	Имя пользователя. Необходима уникальность в пределах одного домена.
Password	String	Пароль пользователя
DomainUUID	String	Идентификатор домена

В листинге 3приложения А приведена реализация класса CreateUserQuery.

Метод GetHttpRequestParams класса CreateUserQuery переопределяет абстрактный метод базового класса и реализует алгоритм обработки данных приватных полей класса, инициализированных во время инстанцирования класса, и создания сущности класса HttpRequestParams, необходимой для выполнения корректного вызова метода APIOpenstack, отвечающего за создание нового пользователя.

Поля, определенные в классе данных CreateUserResponse, возвращаемом методом Execute, инициализируется средствами библиотеки Json.NET при десериализации ответа от OpenStackAPI. Описание всех полей класса перечислено в таблице 3.

Таблица 3.Поля класса CreateUserResponse

Параметр	Тип	Описание
Id	String	Идентификатор пользователя
Name	String	Имя пользователя.
Enabled	Boolean	Состояние блокировки пользователя
Domain_id	String	Идентификатор домена

После выполнения метода Execute данной команды, можно воспользоваться классами GetUsersListQuery, GetUserDetailsQuery, UpdateUserCommand или DeleteUserCommand, также определенными в пространстве имён OpenstackManager.Identity. Данные классы выполняют задачи по получению списка существующих пользователей, получению детальной информации о пользователе, обновлению данных о пользователе и удалению пользователя из облака соответственно.

Реализация классовCreateUserQuery и CreateUserResponseизображена в листинге 4 приложения А.

AuthorizeQuery

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

После того, как компонент OpenStack Identity подтвердил идентичность пользователя, он предоставляют этому пользователю токен (token), который подтверждает эту идентичность и может использоваться при последующем обращении к ресурсам. Каждый токен имеет определенную область действия, в которой перечислены ресурсы, к которым применяется этот токен. Токен имеет конечный срок действия и может быть аннулирован при необходимости прекращения доступа соответствующего пользователя.[12]

Метод API-интерфейса OpenStack, выполняющий аутентификацию пользователя в облаке и возвращающий токен доступа к остальным сервисам OpenStack вызывается посредством HTTPPOST запроса по URL-адресу, содержащему полностью прописанное доменное имя хоста в системе DNS или IP-адрес хоста и URL-пути ~/v3/auth/token, уточняющего информацию о месте нахождения ресурса.

В таблице 4 перечислены необходимые параметры, которые должны быть переданы конструктору класса AuthorizeQuery.

Поля, определенные в классе данных AthorizeResponse, возвращаемом методом Execute,инициализируется средствами библиотеки Json.NET при десериализации ответа от OpenStackAPI. Описание всех полей класса перечислено в таблице 5.

После выполнения метода Execute данной команды, можно воспользоваться классами GetTokenInfoQuery, CheckTokenQueryили DeleteTokenCommand, также определенными в пространстве имён OpenstackManager.Identity. Данные классы выполняют задачи по получению информации о токене, проверки валидности токена и принудительному удалению токена соответственно.

Таблица 4. Парметры конструктора класса AuthorizeQuery

Параметр	Тип	Описание
Url	String	Доменное имя или IP-адрес хоста.
Name	String	Имя пользователя.
Password	String	Пароль пользователя.

Таблица 5.Поля класса AthorizeResponse

Параметр	Тип	Описание
Domain_Id	String	Идентификатор домена, к которому принадлежит пользователь
User_Id	String	Идентификатор пользователя
XSubjectToken	String	Токен доступа
Issued_at	String	Дата и время окончания действия текущего токена

2.5.2 ПространствоимёнOpenstackManager.Compute

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

CreateServerQuery

Метод API-интерфейса OpenStack, выполняющий задачу создания нового экземпляра виртуального сервера вызывается посредством HTTPPOSTзапроса по URL-адресу, содержащему базовый адрес сервиса Nova, который может быть получен после авторизации пользователя в облаке и URL-пути ~/v3/ servers.

В таблице 6 перечислены необходимые параметры, которые должны быть переданы конструктору класса CreateServerQueryдля формирования корректного HTTP-запроса на инициализацию операции создания виртуального сервера.

Таблица 6, Параметры конструктора класса CreateServerQuery

Параметр	Тип	Описание
BasrUrl	String	Адресс сервиса Nova
XAuthToken	String	Токен досутпа
FlavorRef	String	UUID или полный URL шаблона виртуального оборудования
ImageRef	String	UUID или полный URL образа
Name	String	Имя виртуального сервера
AdminPass	String	Пароль администратора виртуального сервера

Поля, определенные в классе данных CreateServerResponse, возвращаемом методом Execute, инициализируется средствами библиотеки Json.NET при десериализации ответа от OpenStackAPI. Описание всех полей класса перечислено в таблице 6.

После выполнения метода Execute данной команды, можно воспользоваться классами StartServerCommand,StopServerCommand или RebuildCommand, также определенными в пространстве имён OpenstackManager.Compute. Данные классы выполняют задачи по запуску, остановке и переустановке виртуального сервера соответственно. Также, с помощью команды CreateSnapshotCommand можно создать моментальный снимок экземпляра виртуального сервера.

Таблица 7. Поля класса CreateServerResponse

Параметр	Тип	Описание
Сreated	DateTime	Дата создания виртуального сервера
Id	String	UUIDвиртуального сервера
Name	String	Имя виртуального сервера
AccessIPv4	String	Адрес виртуального сервера, который может быть использован для доступа к виртуальному серверу
AccessIPv6	String	Адрес виртуального сервера, который может быть использован для доступа к виртуальному серверу
Vm_state	String	Состояние виртуального сервера
User_id	String	Идентификатор пользователя -владельца виртуального сервера

Реализация классов CreateServerQuery и CreateServerResponse изображена в листинге 5 приложения А.

2.6 Реализация классов сценариев

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

2.6.1 Регистрация пользователя

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

1) Создать нового пользователя на основе предоставленных учётных данных

2) Прикрепить пользователя к одному из доменов инфраструктуры. Если существует необходимость, создать новый домен.

3) Установить пользовательские роли.

Алгоритм регистрации пользователя изображён на рисунке 4.

Класс RegistrationQuery, инкапсулирующий описанный алгоритм, в соответствии с принятыми отношениями между базовыми элементами архитектуры и классами макрокоманд, реализует интерфейс IQuery<T>. Для выполнения задачи регистрации пользователя необходимо создать экземпляр данного класса, передав в конструктор адрес сервера, на котором развёрнуто облако, токен доступа администратора, учётные данные нового пользователя, имя домена, который ограничивает область уникальности создаваемого пользователя, и набор выбранных ролей. На рисунке 5 изображена диаграмма последовательностей, отражающая взаимодействия между классами в контексте выполняемой задачи.

Вызов метода Executeсущности класса RegistrationQuery инициирует процесс выполнения алгоритма регистрации. Данный метод, в соответствии с этапами алгоритма, инстанциирует созданные на втором этапе разработки библиотеки, классы простых запросов GetDomainQuery, CreateDomainQuery, CreateUserQuery, GetRoleQueryи простой команды SetRoleToUserCommand, инкапсулирующих непосредственные вызовы функций OpenstackAPIи обеспечивающие полное выполнение сценария регистрации пользователя в облаке.

Рисунок 4. Алгоритм регистрации пользователя

2.6.2 Создание виртуального сервера

Для создания нового виртуального сервера ресурсами кластера облачной инфраструктуры необходимо выполнить следующие действия

1) Выбрать шаблон конфигурации из списка доступных пользователю

2) Выбрать образ из списка доступных пользователю

3) Создать виртуальный сервер

Алгоритм создания виртуального сервера изображён на рисунке 6.

Рисунок 5. Диаграмма последовательностей алгоритма регистрации пользователя

Класс CreateServerQuery, инкапсулирующий описанный алгоритм, в соответствии с принятыми отношениями между базовыми элементами архитектуры и классами макрокоманд, реализует интерфейс IQuery<T>. Определение данного класса в пространстве имён OpenStackManager.Complex (в котором определены все классы сложных сценариев взаимодействия) позволило избежать конфликта имён с одноименным классом пространства имён OpenStackManager.Compute, описанным ранее. Для выполнения задачи создания виртуального сервера необходимо создать экземпляр данного класса, передав конструктору базовый адрес сервиса Nova, который может быть получен после авторизации пользователя в облаке, токен доступа пользователя, имя виртуального сервера, имя шаблона конфигурации и образа, которые определяют количество выделенных виртуальному серверу аппаратных ресурсов и тип операционной системы. На рисунке 7 изображена диаграмма последовательностей, отражающая взаимодействия между классами в контексте выполняемой задачи.

Рисунок 6. Алгоритм создания виртуального сервера

Вызов метода Executeсущности класса CreateServerQueryинициирует процесс выполнения алгоритма создания виртуального сервера. Данный метод, в соответствии с этапами алгоритма, инстанциирует созданные на втором этапе разработки библиотеки, классы простых запросов Ge Flavors Query, Get Images Query и Create Server Query инкапсулирующих непосредственные вызовы функций Openstack API интерфейса и обеспечивающие полное выполнение сценария создания виртуального сервера в облаке.

Реализация класса Create Server Query представлена в листинге 6 приложения А.

Также в пространстве имён OpenStackManager.Complex реализованы классы StartServerCommand, StopServerCommand, DeleteServerCommandит.д., которые также реализуют сложные сценарии взаимодействия с облаком.

Рисунок 7. Диаграмма последовательностей алгоритма создания виртуального сервера

2.7 Вывод

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

Платформа .NET, как фундамент данной библиотеки, гарантирует полное и безопасное исполнение кода на нескольких операционных системах. Типы, реализованные при помощи языка C#, ориентированного на общеязыковую исполняющую среду (CLR), можно использовать в любом другом языке программирования, совместимым с платформой .NET. Дизайн архитектуры классов итоговой библиотеки спроектирован с учётом необходимости соответствовать таким критериям качества программного обеспечения, как удобство сопровождения, гибкость, возможность повторного использования,ясность и тестируемость, что гарантирует некоторую устойчивость библиотеки к будущим изменениям. В дополнение к этому, библиотека не скрывает от клиентского кода базовые абстракции системы, а отношения между классами сборки в достаточной мере соответствуют основным принципам объектно-ориентированного проектирования, что, при правильном подходе, позволит пользователям разработанной библиотеки построить гибкие, масштабируемые приложения, решающие задачи, для которых была развёрнута облачная инфраструктура.



3. Интеграция разработанной библиотеки классов

Разработанная библиотека классов была успешно интегрирована в проект vsd.ultrazoom.ru компании Ultrazoom. Данный проект является Web-сервисом, выполняющим функции портала самообслуживания.

3.1 Архитектура проектного решения

Архитектура данного проектного решения включает в себя следующие функциональные узлы

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

· Серверное приложение, созданное с помощью стандартной библиотеки .NETASP.NETMVC и запущенное внутри веб-сервера IIS

· Клиентское приложение, исполняемое в браузере, созданное на основе средств HTML, CSS иJQuery

· Реляционная база данных MicrosoftSQLServer

2) Программно-аппаратный комплекс, включающий в себя несколько серверов, объединенных в вычислительный кластер средствами OpenStack.

На рисунке8 изображена схема описанной выше системы.

Типичный цикл работы программы можно представить следующим образом:

a) Пользователь с помощью web-интерфейса клиентского приложения инициирует выполнение одной из возможных задач по управлению ресурсами облачной инфраструктуры