Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Облачные сервисы: описание

Содержание:

Введение

Люди живут во время стремительного роста информационных технологий, идет колоссальное развитие программного обеспечения. Раньше разработанные программистами приложения распространялись на физических носителях, после чего их необходимо было устанавливать на компьютер. Для корректной работы программ персональный компьютер должен был отвечать минимальным системным требованиям, выставленными разработчиками программного обеспечения. Развивался Интернет, модернизировалось и серверное оборудование. И в какой-то момент оказалось, что можно объединить вычислительные мощности для поддержки программных сервисов – например, текстовые и табличные процессоры. Это и стало отправной точкой в развитии «облачных» вычислений.

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

Аспектом рассмотрения новизны, преимущества облачных вычислений для конечного потребителя является экономия на:

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

Объект исследования – процесс создания облачного хранилища.

Предмет исследования – облачные технологии.

Учитывая изложенное, целью настоящей работы является изучение структуры облачных технологий, анализ категорий «облака», а так же создание облачного сервиса.

Исходя из поставленной цели, определен следующий круг задач:

  1. Изучить характеристику облачных технологий, определить понятия и структуры облака.
  2. Выбрать программное обеспечение для создания облачного хранилища.
  3. Протестировать созданное облако.

ГЛАВА 1. ОПИСАНИЕ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ, ТЕХНИЧЕСКОЙ И ОРГАНИЗАЦИОННОЙ СТРУКТУР СИСТЕМЫ

1.1. Описание облачных вычислений

Облачные вычисления (cloud computing) –  это модель обеспечения сетевого доступа, который повсеместно и удобно по требованию к общему пулу конфигурируемых вычислительных ресурсов (например, сетям передачи данных, серверам, устройствам хранения данных, приложениям и сервисам – как вместе, так и по отдельности). Облачные вычисления, могут быть оперативно представлены и освобождены с минимальными эксплуатационными затратами или обращениями к провайдеру.[1]

Если объяснить доступным языком, то – это, в некотором смысле рабочая площадка в интернете, а точнее на удаленном сервере. Например, если пользователь работает с почтой на каком-то сайте-сервисе (например, gmail.com), который эту почту позволяет использовать, то это и есть не что иное, как облачный сервис или, к примеру, обработка изображений. Если пользователь уменьшает размер, переворачивает свою фотографию в Photoshop или другой специальной программе, то к облачным технологиям это не имеет никакого отношения, – всё происходит и обрабатывается локально на компьютере пользователя.

Характеристики облачных вычислений:

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

Модели развертывания:

  • частное облако (private cloud) – инфраструктура, предназначенная для использования одной организацией, включающей несколько потребителей. частное облако может находиться в собственности, управлении и эксплуатации, как самой организации, так и третьей стороны (или какой-либо их комбинации), и оно может физически существовать как внутри, так и вне юрисдикции владельца;
  • публичное облако (public cloud)  – инфраструктура, предназначенная для свободного использования широкой публикой. Публичное облако может находиться в собственности, управлении и эксплуатации коммерческих, научных и правительственных организаций (или какой-либо их комбинации). Публичное облако физически существует в юрисдикции владельца – поставщика услуг;
  • общественное облако (community cloud) – вид инфраструктуры, предназначенный для использования конкретным сообществом потребителей из организаций, имеющих общие задачи (например, миссии, требований безопасности, политики, и соответствия различным требованиям). Общественное облако может находиться в кооперативной (совместной) собственности, управлении и эксплуатации одной или более из организаций сообщества или третьей стороны (или какой-либо их комбинации), и оно может физически существовать как внутри, так и вне юрисдикции владельца;
  • гибридное облако (hybrid cloud) – это комбинация из двух или более различных облачных инфраструктур (частных, публичных или общественных), остающихся уникальными объектами, но связанных между собой стандартизованными или частными технологиями передачи данных и приложений (например, кратковременное использование ресурсов публичных облаков для балансировки нагрузки между облаками).[1]

1.2. Описание технической структуры

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

hybrid_1.gif

Рисунок 1 – Облачный сервис

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

Модели сервисов:

  1. Программное обеспечение как услуга (SaaS, англ. Software-as-a-Service) – модель, в которой потребителю предоставляется возможность использования прикладного программного обеспечения провайдера, работающего в облачной инфраструктуре и доступного из различных клиентских устройств или посредством тонкого клиента, например, из браузера (например, веб-почта) или посредством интерфейса программы. Контроль и управление основной физической и виртуальной инфраструктурой облака, в том числе сети, серверов, операционных систем, хранения, или даже индивидуальных возможностей приложения (за исключением ограниченного набора пользовательских настроек конфигурации приложения) осуществляется облачным провайдером.
  2. Платформа как услуга (PaaS, англ. Platform-as-a-Service) – модель, когда потребителю предоставляется возможность использования облачной инфраструктуры для размещения базового программного обеспечения для последующего размещения на нём новых или существующих приложений (собственных, разработанных на заказ или приобретённых тиражируемых приложений). В состав таких платформ входят инструментальные средства создания, тестирования и выполнения прикладного программного обеспечения – системы управления базами данных, связующее программное обеспечение, среды исполнения языков программирования – предоставляемые облачным провайдером. Контроль и управление основной физической и виртуальной инфраструктурой облака, в том числе сети, серверов, операционных систем, хранения осуществляется облачным провайдером, за исключением разработанных или установленных приложений, а также, по возможности, параметров конфигурации среды (платформы).
  3. Инфраструктура как услуга (IaaS, англ. IaaS or Infrastructure-as-a-Service) предоставляется как возможность использования облачной инфраструктуры для самостоятельного управления ресурсами обработки, хранения, сетями и другими фундаментальными вычислительными ресурсами, например, потребитель может устанавливать и запускать произвольное программное обеспечение, которое может включать в себя операционные системы, платформенное и прикладное программное обеспечение. Потребитель может контролировать операционные системы, виртуальные системы хранения данных и установленные приложения, а также ограниченный контроль набора доступных сервисов (например, межсетевой экран, DNS). Контроль и управление основной физической и виртуальной инфраструктурой облака, в том числе сети, серверов, типов используемых операционных систем, систем хранения осуществляется облачным провайдером.
  4. База данных как сервис (DaaS, Database-as-a-Service). Данный сервис предназначен для администраторов, так как предоставляет возможность работать с базами данных, как если бы СУБД была установлена на локальном сервере. Причем, в этом случае гораздо легче “делиться” проектами между разными исполнителями.
  5. Приложение как сервис (AaaS, Application-as-a-Service). Позиционируется как «программное обеспечение по требованию», которое развернуто на удаленных серверах и каждый пользователь может получать к нему доступ посредством Интернета. Причем все вопросы обновления и лицензий регулируются поставщиком данной услуги. Оплата в данном случае производиться за фактическое использование. В качестве примера можно привести Google Docs, Google Calendar и т.п.
  6. Безопасность как сервис (SeaaS, Security-as-a-Service). Данный вид услуги предоставляет возможность пользователям быстро развертывать продукты, позволяющие обеспечить безопасное использование веб-технологий, электронной переписки, локальной сети, что позволяет пользователям данного сервиса экономить на развертывании и поддержании своей собственной системы безопасности.
  7. Администрирование и управление как сервис (MaaS, Management/Governace-as-a-Service). Дает возможность управлять и задавать параметры работы одного или многих “облачных” сервисов. Это в основном такие параметры, как топология, использование ресурсов, виртуализация.

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

1.3. Описание организационной структуры

Для эффективной облачной инфраструктуры требуется эффективная структура и организация. Определение и использование стандартов на каждом этапе работы – при размещении в стойках от отдельных компьютеров до отдельных кабелей и от рядовых операций до безопасности – позволяет сэкономить значительное время и правильно организовать процессы. Традиционно большой масштаб облачной инфраструктуры неизбежно требует автоматизации. Даже в маломасштабной облачной инфраструктуре автоматизация критически важна. Например, если нужно выполнять такие ИТ-операции, как подготовка и удаление машин за минимальные деньги в максимально короткий срок. Агрегирование компонентов в виде заданных структур не ограничивается оборудованием, таким как компьютеры, подсистемы хранения и сети. Стоит также позаботиться о правильном структурировании компонентов поддержки, таких как электропитание и сетевые кабеля. Систематизация этих более мелких компонентов тоже полезна, например, стандартные соглашение о нумерации и маркировке. Это обеспечивает выполнение процессов управления конфигурацией и изменениями. Определение и использование этих стандартов имеет собственную ценность при их оптимизации для получения даже небольших преимуществ на этапе построения облачной среды. В дальнейшем преимущества постоянно проявляются на каждом уровне, от подготовки виртуальных машин до управления и сопровождения облачной инфраструктуры. Такие цели, как автоматическое управления, удаленная работа и ограничение сбоев, позволяют совершенствовать стандарты и процессы. Пример услуг представлен в соответствии с рисунком 2.

Otkrytye_sistemy_12_(7353)_500.png

Рисунок 2 – Услуги, предоставляемые облачным сервисом

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

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

Обеспечение доступности означает предоставление своевременного и надежного доступа к персональным данным. Одна из серьезных угроз доступности в облаке - случайная потеря подключения к сети между клиентом и поставщиком или производительным сервером, вызванная вредоносными действиями такими, как (распределенный) отказ в обслуживании – DoS-атаки. Другие риски включают в себя наличие случайного аппаратного сбоя, как в сети, так и в обработке данных в облаке и системе хранения данных. Так же риски связаны со сбоями питания и другими проблемами инфраструктуры. Контроллеры данных должны убедиться, что провайдер облака принял разумные меры, чтобы справиться с риском нарушения. Такими мерами могут быть: избыточное хранение и эффективное резервное копирование данных. Целостность может быть определена как свойство, которое удостоверяет подлинность данных, и отвечает за то, что - бы с ними не происходило злонамеренных или случайных изменений во время обработки, хранения или передачи. Понятие целостности может быть распространено и на ИТ-систему, и требует, чтобы обработка персональных данных в этих системах оставалась неизменной. Определение изменений в персональных данных может быть достигнуто путем криптографических механизмов аутентификации, таких как коды аутентификации сообщений или подписей. Вмешательство в целостность ИТ-систем в облаке может быть предотвращено или обнаружено с помощью системы предотвращения вторжений (IPS / IDS). Это особенно важно в открытых типах сетей, в которых облака обычно работают.

ГЛАВА 2. ВЫБОР ПРОГРАММНОГО И ТЕХНИЧЕСКОГО ОБЕСПЕЧЕНИЯ ДЛЯ СОЗДАНИЯ ОБЛАЧНОГО СЕРВИСА

2.1. Обоснование выбора программного обеспечения облачного сервиса

В последние годы онлайновые файловые хранилища завоевали огромную популярность, и сегодня на компьютерах большинства пользователей установлен клиент Dropbox, Google Drive, SkyDrive или SugarSync. Практически во всех случаях бесплатных возможностей этих служб вполне хватает для удовлетворения всех обычных потребностей.

Для выбора определенного программного обеспечения облачного сервиса необходимо оценить определенные параметры. Рассмотрим их.

Во-первых, параметры оценки должны быть напрямую связаны с производительностью приложений, должны быть понятны и напрямую отражать различные аспекты производительности. Например, параметры хранения должны отражать эффективность ввода/вывода для приложений, интенсивно использующих системы хранения. Во-вторых, параметры должны быть применимы к самым разным провайдерам, вне зависимости от того, как они реализуют сервисы. Например, одни провайдеры используют виртуальные машины Xen, а другие предпочитают Hyper-V или иные внутренние технологии виртуализации. Эти параметры должны быть абстрагированы от деталей реализации и отражать влияние на производительность сервисов от начала до конца.

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

Таблица 1 – Параметры облачного сервиса

Сервис

Параметр

Гибкий вычислительный кластер

Время выполнения задач эталонных тестов на производительность

Стоимость в расчете на эталонный тест

Задержка при масштабировании

Постоянное хранение

Задержка при операциях

Пропускная способность при операциях

Стоимость в расчете на операцию

Время возвращения в согласованное состояние

Сеть внутри облака

Задержка канала

Пропускная способность канала

Глобальная сеть

Задержка глобальной сети

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

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

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

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. Построение частного облака. Данный этап актуален для крупных компаний. Началом данного этапа можно считать момент, когда большая часть сотрудников активно пользуется «облачными» сервисами в своей работе. При наличии экономической целесообразности, можно начать формирование своего корпоративного вычислительного облака, на базе имеющегося центра обработки данных.

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

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

Заключение

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

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

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

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

СПИСОК ЛИТЕРАТУРЫ

  1. В.А. Устинов, И.П. Клементьев. Введение в облачные вычисления. – Электронная книга, 2011. http://www.ildarmukhutdinov.ru/2017/02/23/web-os/
  2. Gillam, Lee. Cloud Computing: Principles, Systems and Applications / Nick Antonopoulos, Lee Gillam. — L.: Springer, 2015. — 379 p. — (Computer Communications and Networks). — ISBN 9781849962407
  3. SoCC '10: Proceedings of the 1st ACM symposium on Cloud computing / Hellerstein, Joseph M. — N. Y.: ACM, 2010. — ISBN 978-1-4503-0036-0
  4. http://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D0%BB%D0%B0%D1%87%D0%BD%D1%8B%D0%B5_%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F
  5. http://technet.microsoft.com/ru-ru/magazine/jj851176.aspx
  6. Баранов А.П «Можно ли защитить в «облаке» конфиденциальную информацию?» \\ Системы высокой доступности, 2017. Т. 8. № 2. C. 12—15
  7. Бабаш А.В., Гольев Ю.И., Ларин Д.А., Шанкин Г.П. О развитии криптографии в XIX веке // Защита информации. Конфидент. №5, 2013, с.90-96.
  8. http://123-box.ru/5980