Файл: Облачные сервисы: описание.pdf

Некоторые из этих параметров стандартные и уже широко применяются вне контекста облака:

• время выполнения эталонных тестов на производительность для измерения эффективности работы виртуальной машины;
• задержка и пропускная способность при работе сервисов хранения;
• задержка и пропускная способность сети.

Кроме того, для оценки уникальных облаков могут быть выбраны нетрадиционные параметры. 

2.2. Создание облачного сервиса на примере Яндекс.Диск

Получение приглашения и регистрация на Яндекс.Диск

Сам сервис находится по такому адресу: http://disk.yandex.ru/. Чтобы получить регистрацию в данном облачном сервисе, необходимо получить приглашение, представленное в соответствии с рисунком 3.

Рисунок 3 – Регистрация

В доступные поля вводим свой адрес электронной почты email и нажимаем кнопку «Оставить заявку». В результате пользователю на экран будет выведено сообщение, представленное в соответствии с рисунком 4.

Рисунок 4 – Заявка

Через некоторое время на электронную почту будет доставлено электронное письмо от «Капитана» Яндекс.Диска. Через некоторое время придёт еще одно письмо, где нужно будет нажать кнопку «Запустить диск».

Всё, после этого аккаунт облачного сервиса будет доступен по адресу http://mail.yandex.ru/?disk.

Выводы по главе

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

ГЛАВА 3. Тестирование и развертывание облачного сервиса

3.1. Обоснование технологии тестирования. Выбор методов тестирования, программной поддержки тестирования

На сегодняшний день существуют различные методы тестирования облачных сервисов. Рассмотрим их.

Модульное тестирование

Модульное тестирование позволяет проверить на корректность отдельные части приложения, изолируя их от всей программы. С точки зрения тестирования облачных сервисов основное внимание при модульном тестировании следует сосредоточить на поведении конкретного объекта класса, а не на взаимодействии этого объекта с другими компонентами приложения. Например, для Windows Azure любой тест, зависящий от хранилища Windows Azure, требует сложной настройки и дополнительно логики для обеспечения доступности корректных данных при выполнении тестирования. Вследствие этого разработчики специально для тестирования часто создают специальный модуль доступа к данным. В частности, это средство позволяет выполнять тестирование классов хранения данных независимо от облачного хранилища Windows Azure. Например, можно создать специальный модуль (wrapper) для компонентов хранилища Windows Azure, заменяющий хранилище Windows Azure фиктивными (mock) объектами.

Для выполнения модульных тестов в Visual Studio предлагается инструмент MSTest автоматического запуска и выполнения тестов. В Visual Studio 2012 предусмотрено средство непрерывного выполнения модульных тестов в фоновом режиме, в то время как разработчики продолжают работу над кодом, одновременно наблюдая результаты тестирования. Visual Studio поддерживает также сторонние инструменты модульного тестирования: TypeMock, Moq и RhinoMock, NUnit, xUnit.

Интеграционное тестирование

Интеграционное тестирование предназначено для проверки взаимодействия и интерфейсов между компонентами, подсистемами и т. п. После того как разработаны основные компоненты облачного приложения, необходимо создать интеграционные тесты. Если у приложения нет Web-интерфейса, то интеграционные тесты могут быть и функциональными. Для разработки интеграционных тестов может быть использован инструмент MSTest, но в отличие от модульного тестирования подход mock-объекты не применяется – тестирование полагается на реальную, а не фиктивную реализацию компонентов. Надо отметить, что для проведения интегрального тестирования в Windows Azure необходимо, чтобы все модули приложения уже были развернуты в локальной или облачной среде. Поэтому для проведения таких тестов важна автоматизация сборки и публикация решения, это может быть выполнено с помощью Team Foundation Server.

Функциональное тестирование

В ходе функционального тестирования определяется, решает ли приложение задачи, для которых оно было разработано, соответствует ли требованиям и ожиданиям пользователей. Обычно функциональное тестирование включает также тестирование пользовательского интерфейса. Для планирования и выполнения функционального тестирования облачных сервисов может быть использован инструмент Microsoft Test Manager Visual Studio 2012, причем в самом начале жизненного цикла приложения, начиная с публикации в среде эмуляции. В конце этапа испытаний необходимо создать тестовую публикацию приложения на реальную облачную среду Azure и провести финальное функциональное тестирование. Кроме выполнения ручного тестирования, можно использовать модуль Coded UI Test, позволяющий автоматизировать процесс тестирования интерфейса приложения.

С помощью Visual Studio Ultimate или Visual Studio Premium можно создавать автоматические тесты для отладки пользовательского интерфейса, называемые закодированными тестами. Эти тесты позволяют проверить, что после внесения изменений в код пользовательский интерфейс функционирует правильно. Они выполняются быстрее, чем ручные тесты, поэтому их можно выполнять чаще.

Нагрузочное тестирование

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

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

3.2. Разработка плана тестирования облачного сервиса

Для проведения тестирования будем использовать функциональное тестирование для облачного сервиса Яндекс.Диск.

Необходимо протестировать следующие характеристики облачного хранилища:

1. Скорость создания облачного хранилища.
2. Соотношение свободного места на жестком диске и размер облачного хранилища.
3. Скорость загрузки файла в хранилище.
4. Возможность доступа к хранилищу через браузер.
5. Уровни доступа (частный и общий).

3.3. Проведение тестирования и составление отчета о тестировании облачного сервиса

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

В результате проведения тестирования были получены следующие результаты.

1. При создании своего Яндекс.Диска, представленного в соответствии с рисунком 10, т.е. выделенного пространства в сети Интернет, пользователь получает объем 10 ГБ облачного пространства, в котором может хранить любого типа информацию.

Рисунок 3 – Яндекс.Диск

Для увеличения объема выделенного облачно пространства пользователю предлагается оплатить определенный тариф, получив при этом определенные бонусы, представленные в соответствии с рисунком 11.

Рисунок 4 – Тарифы

1. При загрузке файлов на Яндек.Диск предоставляется два типа доступа к загруженной информации:
2. конфиденциальная – доступно только пользователю, загрузившему данный файл;
3. общедоступная – доступно тем пользователям, которые получили ссылку на скачивание данного файла или ссылка на файл была опубликована в сети Интернет на определенных поисковых системах.
4. Для передачи файлов нет необходимости ждать окончания просмотра рекламы в сети Интернет. Используя ссылку на файл, пользователь легко может скачать его с сервиса.
5. Редактирование общедоступного файла дает возможность другим пользователям получать актуальную информацию с изменениями, т.к. файл хранится в облачном сервисе.

При проведении тестирования ошибки не были обнаружены.

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

1. Создание хранилища заняло около 2-ух минут.
2. Соотношение свободного места на жестком диске и размер облачного хранилища – совпал.
3. Скорость загрузки файлов очень высокая (в основном зависит от скорости передачи данных по локальной сети).
4. С помощью браузера можно совершать аналогичные действия, как и в других облачных хранилищах (добавить, удалить, сортировать и т.п.).
5. Уровни доступа к файлам распределяются по вкладкам (Publick и File).

3.4. Разработка технологии развертывания облачного сервиса

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

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

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