Программное обеспечение как сервис.

Модель предоставления программного обеспечения как сервиса (Software

as a Service, SaaS) обеспечивает возможность аренды приложений с

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

распространенной на сегодняшний день моделью предоставления об-

лачных сервисов. Организации могут реализовывать подобную модель

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

вые каналы, дополнительно защищенные и не связанные с Интернетом.

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

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

Развитием логики SaaS является концепция WaaS (Workplace as a Service- рабочее место как услуга), когда клиент получает в свое распоряжение полностью оснащенное всем необходимым для работы программного обеспечения (ПО) виртуальное рабочее место.

 

Платформа как сервис.

Модель предоставления платформы как сервиса (Platform as a Service,

PaaS) предоставляет возможность аренды платформы, которая обычно

включает операционную систему и прикладные сервисы. Платформа как

сервис облегчает разработку, тестирование, развертывание и сопрово-

ждение приложений без необходимости инвестиций в инфраструктуру

и программную среду. Платформа как сервис также включает и инфра-

структуру как сервис. Примерами платформ как сервис могут служить широко распространенный в РФ продукт Windows Azure (Microsoft), Bluemix- передовая облачная платформа IBM для создания и исполнения приложений всех типов (web-приложений, мобильных приложений, приложений для работы с большими данными и др.), а также платформа с открытым кодом Cloud Foundry.

Инфраструктура как сервис.

Модель предоставления инфраструктуры (аппаратных ресурсов) как сер-

виса (Infrastructure as a Service, IaaS) предоставляет возможность аренды

таких инфраструктурных ресурсов, как серверы, устройства хранения

данных и сетевое оборудование. Управление всей инфраструктурой

осуществляется поставщиком сервисов, а потребитель управляет толь-

ко операционной системой и установленными приложениями. Такие

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

позволяют пользователю увеличивать или уменьшать объем исполь-

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

поставщиками сервисов.

Здесь потребителями являются владельцы приложений, ИТ-специалисты,

подготавливающие образы ОС для их запуска в сервисной инфраструк-

туре. Облачная платформа предоставляет сервисы для запуска виртуаль-

ных машин и сервисы хранения данных. Соглашение о предоставлении

сервисов обычно покрывает такие характеристики сервисов, как

доступность виртуального сервера, время развертывания образа ОС. В

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

приложения, установленные на стандартные образы ОС.

Как и в случае с PaaS, оплата инфраструктуры как сервиса обычно

производится исходя из объема использованных ресурсов.

Модели развертывания (Deployment Models):

• Частное облако (private cloud). Облачная инфраструктура функционирует целиком в целях обслуживания одной организации. Инфраструктура может управляться самой организацией или третьей стороной и может существовать как на стороне потребителя (on premise) так и у внешнего провайдера (off premise). Идеальный вариант частного облака — это облако, развернутое на территории организации, обслуживаемое и контролируемое ее сотрудниками. Примером такого подхода является центр обработки данных (ЦОД) ОАО «РЖД».

• Облако сообщества или общее облако (community cloud). Облачная инфраструктура используется совместно несколькими организациями и поддерживает ограниченное сообщество, разделяющими общие принципы (например, миссию, требования к безопасности, политики, требования к соответствию регламентам и руководящим документам). Такая облачная инфраструктура может управляться самими организациями или третьей стороной и может существовать как на стороне потребителя (on premise) так и у внешнего провайдера (off premise).

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

Такая инфраструктура находится во владении организации, продающей соответствующие облачные услуги (предоставляющей облачные сервисы).

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

Обе базовые модели (публичные и частные облака) обладают существенными достоинствами для бизнеса:

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

• высокая доступность – достоинство, связанное с распределёнными вычислениями: приложения могут пользоваться архитектурой высокой доступности, которая минимизирует или устраняет плановые и внеплановые простои, повышая уровень сервиса для пользователей и способствуя непрерывности ведения бизнеса;

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

Помимо описанной технологии облачных вычислений появились и развивается такие ее формы как fog и edge computing, а также MCC(mobile cloud computing, мобильные облачные вычисления).

Fog computing (туманные вычисления) — архитектура системного уровня для расширения облачных функций хранения, вычисления и сетевого взаимодействия. Концепция предполагает обработку данных на конечных устройствах сети (компьютерах, мобильных устройствах, датчиках, смартфонах и т.п.), а не в облаке.

Термин предложен компанией Cisco, под туманом подразумевается приближение облака к земле, в данном случае туман — это разновидность облачных сервисов, расположенных не где-то в недоступных высотах, а в окружающей нас среде. Иначе говоря, Fog Computing не альтернатива, а дополнение к Cloud Computing, и могут возникнуть ситуации их совместного действия (например, выполнение аналитического приложения), и в таком случае Cloud окажет услугу Fog.

Fog Computing можно определить как в максимальной степени виртуализированную платформу, поддерживающую три основных типа сервисов, образующих M2M: вычисления, хранение и сеть (М2М- группа технологий межмашинного взаимодействия Machine to Machine,являющаяся основой реализации концепции Интернета вещей IoT) постепенно перемещают Интернет вещей в практическую. Задача Fog Computing заключается в обеспечении взаимодействия множества устройств между собой и с облачными ЦОД. Туман можно представить в виде трехуровневой модели. Верхний уровень занимают тысячи облачных ЦОД, предоставляющих ресурсы, необходимые для выполнения трудоемких, например аналитических, приложений. Уровнем ниже располагаются десятки тысяч распределенных управляющих ЦОД, в которых содержится «интеллект» Fog Computing, а на нижнем уровне находятся миллионы отдельных пользовательских устройств.

Преимуществом fog computing является снижение объема данных, передаваемых в облако, что уменьшает требования к пропускной способности сети, увеличивает скорость обработки данных и снижает задержки в принятии решений. Технология Fog computing решают ряд наиболее распространенных проблем, среди которых:

● высокая задержка в сети;

● трудности, связанные с подвижностью оконечных точек;

● потеря связи;

● высокая стоимость полосы пропускания;

● большая географическая распределенность систем и клиентов.

 

Edge computing (периферийные вычисления) предоставляет средства для сбора и обработки данных в локальных вычислительных устройствах, а не в облаке или удаленном центре обработки данных.

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

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

Мобильное облако это, по сути, облако с дополнительным функционалом, позволяющим работать с мобильными устройствами. Многие компании позволяют сотрудникам получать доступ к электронной почте и календарям, используя смартфоны и планшетные ПК, а также работать с критически-важными для компании приложениями и данными с таких устройств. В Европе по данному направлению консорциумом из ведущих вендоров и университетов (SAP, FRANCE TELECOM, TELECOM ITALIA, BRITISH TELECOM, PORTUGAL TELECOM, NEC EUROPE, INTEL, ITALTEL, CLOUDSIGMA, NEXTWORKS, SOFTTELECOM DESARROLLOS, ONE SOURCE CONSULTORIA INFORMATICA, TECHNISCHE UNIVERSITÄT BERLIN, INOV, INESC INOVACAO, INSTITUTO DE NOVAS TECNOLOGIAS, UNIVERSITÄT BERN, ZÜRCHER HOCHSCHULE FUR ANGEWANDTE WISSENSCHAFTEN, FRAUNHOFER) реализован широкомасштабный проект EU FP7(2012-2015 г.г.) по разработке полностью облачно-ориентированной платформы мобильных коммуникаций и приложений, основанной на использовании в качестве телекоммуникационной среды систем класса LTE и выше, которые обеспечивают канальную производительность сравнимую с фиксированными сетями.

Облачные сервисы.

Под ИТ- сервисом в корпоративной среде понимается ИТ-услуга, которую ИТ- подразделение (департамент, отдел, служба) или внешний провайдер предоставляет подразделениям предприятия для поддержки их бизнес-процессов.

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

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

• поддержка ИТ-инфраструктуры;
• поддержка бизнес-приложений;
• поддержка пользователей.

В общем случае ИТ-сервис характеризуется рядом параметров:

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

Функциональность определяет решаемую задачу (информатизацию бизнес-операции, бизнес-функции, бизнес-процесса) и предметную область её использования.

Время обслуживания определяет период времени, в течение которого ИТ-подразделение поддерживает данный сервис, т.е. несет ответственность за его непрерывное функционирование. Время обслуживания измеряется долей суток и долей календарной недели, в течение которых ИТ-подразделение поддерживает ИТ-сервис. Например, время обслуживания 24×7 означает, что ИТ-сервис поддерживается 24 часа в сутки 7 дней в неделю, 5×8 - 5 дней в неделю по рабочим дням по 8 часов в день, т.е. в течение рабочего дня.

Доступность определяет долю согласованного времени обслуживания, которая измеряется в процентах, и характеризует в течение какого времени ИТ-сервис доступен;. Например, доступность 95% при согласованном времени обслуживания 8×5 означает, что сервис простаивает 2 часа в неделю (5% от 40 часов).

Надежностьопределяется средним временем наработки на отказ ИТ-сервиса, т.е. средним периодом времени между двумя сбоями в предоставлении ИТ-сервиса. Например, если в условиях предыдущего примера (время обслуживания 8×5, доступность 95%) в неделю в среднем происходит два сбоя ИТ-сервиса, среднее время наработки на отказ составляет 19 часов.

Производительность характеризует способность информационной системы соответствовать требованиям оперативности. Для различных ИТ-сервисов показателями производительности могут быть время реакции (время выполнения бизнес-транзакции) или пропускная способность системы. Например, при задании времени реакции системы пользователь может потребовать чтобы время проводки по счету клиента было не более 5 сек., а при задании производительности – количество транзакций по счету клиента было не менее 20 в течении 1 часа т.е. 20 транзакции/ч. Для задания производительности ИТ-сервиса следует использовать бизнес-операции (бизнес-функции), существенные для конечного пользователя, - ввод документов, подготовку отчетов и т.д.

Конфиденциальность определяет вероятность несанкционированного доступа к данным и/или их несанкционированного изменения. Количественные измерения данного показателя обычно не проводятся. Вместо этого ИС, обеспечивающие ИТ-сервис, классифицируются по степени конфиденциальности. Принадлежность ИС к тому или иному классу подтверждается независимой сертификацией. Конфиденциальность ИТ-сервиса в целом определяется классом безопасности наиболее слабой из обеспечивающих сервис ИС, а также корректируется с учетом качества инструкций для конечных пользователей и их обучения.

Масштаб характеризует объем и сложность работ по поддержке ИТ-сервиса. Единого измерителя масштаба не существует, к его показателям относятся число рабочих мест, количество удаленных сайтов, сложность используемых приложений и т.п.

Затраты- стоимость всей совокупности ресурсов, вовлеченных в сопровождение ИТ-сервиса, а также потерь от простоев ИТ-сервиса. В ресурсы включаются стоимость оборудования, программного обеспечения (ПО), используемых ресурсов структурированной кабельной системы (СКС) и каналов связи, внешних услуг, заработная плата сотрудников организации (включая связанные с ней расходы) и т.д.

По мнению ведущих ИT-компаний и аналитиков (наиболее известными из них являются IBM, Microsoft, Sun Microsystems, BEA, SAP, Oracle, Gartner Group,, Stencil Group, IDC- International Data Corp.), важными и перспективными направлениями в развитии информационных систем и ПО являются архитектуры, ориентированные на сервисы (Service Oriented Architecture, SOA). При этом основной акцент делается на SOA, которая ориентирована на Internet и Intranet, т.е. на архитектуру веб-сервисов (Web Services Architecture, WSA).

Архитектура, ориентированная на сервисы (SOA), имеет следующие характерные особенности:

1. Архитектура является распределенной. Функциональные модули приложения (системы) могут быть распределены по множеству вычислительных систем и способны к взаимодействию с использованием локальных или глобальных сетей.

2. Интерфейс функциональных модулей таков, что использование модулей не зависит от технологии или платформы, в рамках которой они реализованы.

3. Возможен динамический поиск и подключение нужных функциональных модулей.

4. Архитектура базируется на общепринятых отраслевых или международных стандартах.

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

• поставщика сервиса;
• потребителя сервиса;
• реестра сервисов.

Взаимоотношение участников включает следующие основные аспекты:

• публикация сервиса;
• поиск сервиса;
• подключение и использование.

Для реализации SOA необходимы три типа соглашений:

1. Транспортное соглашение: о форматах и протоколах взаимодействия.

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

3. Соглашение о способе обнаружения сервиса.

Архитектура веб-сервисов является одной из реализаций SOA. Понятие архитектуры, ориентированной на сервисы, сложилось в ходе развития концепции веб-сервисов. Однако, существуют и другие походы к реализации SOA: Java RMI (от Sun Microsystems), CORBA (от консорциума OMG), DCOM (от Microsoft), DCE (предложен ассоциацией Open Group).

Концепция веб-сервисов возникла в конце 90-х годов XX века. Однако, к настоящему моменту она является устоявшейся и архитектура, которую предлагает, стала отраслевым стандартом в сфере ИТ.

Стандартизацией архитектуры веб-сервисов занимаются рабочие группы комитета W3C. Они предлагают следующее определение понятия веб-сервис - это реализуемая программными средствами система для поддержки межмашинного взаимодействия через сеть. Интерфейс сервиса описывается на языке, читаемом машиной, например, WSDL. Другие системы взаимодействуют с веб-сервисом способом, указанным в его описании, используя сообщения в стандарте SOAP, передаваемые с использованием HTTP и XML и в сочетании с другими стандартами, относящимися к Web.

Физически Web-сервис представляет собой фрагмент программного обеспечения, называемый агентом. Агент способен передавать и принимать сообщения, именно он реализует функциональность сервиса. Существует различие между агентомисервисом - один и тот же сервис может быть обеспечен разными агентами.

Механизм обмена сообщениями определяется в описании сервисов (Web Services Description), которое представляет собой спецификацию интерфейса сервиса и охватывает форматы сообщений, типы данных, транспортные протоколы, способы сериализации, используемые при обмене между агентами заказчика и поставщика услуг. Кроме того, описание сервиса содержит указание на одну или несколько точек в сети (endpoint), откуда доступен поставщик.

Технология Universal Description Discovery and Integration(UDDI) предполагает ведение реестра веб-сервисов. Подключившись к этому реестру, потребитель сможет найти веб-сервисы, которые удовлетворяют его потребностям. Технология UDDI дает возможность поиска и публикации нужного сервиса, как человеком, так и программой-клиентом.

Характеристики эффективности работы пользователей с облачными сервисами в решающей мере определяются возможностями протоколов телекоммуникационного (удаленного) доступа [3]. Наиболее распространенными из них являются следующие.

● SOAP (Simple Object Access Protocol) – простой протокол доступа к объектам

● REST (Representational State Transfer) - передача состояния представления

● XML-RPC (XML Remote Procedure Call) – XML-вызов удалённых процедур

● WebDAV (Web-based Distributed Authoring and Versioning) - Веб распределенная авторизация и определение версий

Протокол REST по сравнению с SOAP является более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.

REST (Representational State Transfer – передача репрезентативного состояния) – это не стандарт и не спецификация, а архитектурный стиль, построенный на существующих стандартах, таких как HTTP, URI и XML. В REST-сервисах акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов. В общем случае REST является очень простым интерфейсом управления информацией без использования каких-либо дополнительных внутренних прослоек. XML-RPC (Extensible Markup Language Remote Procedure Call, XML-вызов удалённых процедур) – протокол вызова удаленных процедур, который, как и любой другой интерфейс RPC, определяет набор стандартных типов данных и команд, используемых для доступа к функциональности удаленной программы.

Протокол использует язык XML для кодирования сообщений и HTTP в качестве транспортного механизма. Является прародителем SOAP, отличается исключительной простотой в применении, как и любой другой интерфейс Remote Procedure Call (RPC), определяет набор стандартных типов данных и команд, которые программист может использовать для доступа к функциональности другой программы, находящейся на другом компьютере в сети.

WebDAV (Web-based Distributed Authoring and Versioning) - расширение протокола HTTP, позволяющее не только загружать веб-страницы в браузер, но и при помощи расширенного набора команд работать с файлами на удаленном сервере. Протокол позволяет выполнять и расширенные типы операций - блокировку, поддержку версий, работу с метаданными объектов. А также возможна работа не только с файлами, но и другими объектами, - например, записями адресной книги.

Протоколы для удаленного рабочего стола:

● SPICE (Simple Protocol for Independent Computing Environments) – Простой протокол для независимой вычислительной среды;

● VNC (Virtual Network Computing) - система удалённого доступа к рабочему столу компьютера;

● RDP (Remote Desktop Protocol – протокол доступа к удалённому рабочему столу)

● PCoIP (Personal Computer over Internet Protocol – Персональный компьютер по протоколу IP)

SPICE — протокол удаленного доступа к рабочему столу, ориентированный на использование в виртуальной среде. При разработке протокола особо учитывались требования, необходимые для работы с мультимедиа-контентом. SPICE использует специальные кодеки для сжатия аудио и видео, что позволяет обеспечить двунаправленную передачу звука, а также возможность просмотра видео на удаленной машине. На сегодняшний день существует реализация протокола для подключения к виртуальным машинам на базе KVM. Одно из самых значительных отличий от существующих протоколов удаленного доступа заключается в том, что SPICE осуществляет подключение непосредственно к системе виртуализации, а не к операционной системе. Таким образом при помощи SPICE теоретически возможно осуществить подключение к любой ОС, запущенной в виртуальной среде. Для использования всех возможностей SPICE необходимо наличие соответствующего видеодрайвера на гостевой системе, хотя работать протокол может и без него. В настоящий момент такие драйверы есть как для Linux, так и для Windows. Протокол является полностью открытым.

VNC — система удалённого доступа к рабочему столу компьютера, использующая протокол RFB (Remote FrameBuffer, удалённый кадровый буфер). Управление осуществляется путём передачи нажатий клавиш на клавиатуре и движений мыши с одного компьютера на другой и ретрансляции содержимого экрана через компьютерную сеть. Система VNC платформо независима: VNC-клиент, называемый VNC viewer, запущенный на одной операционной системе, может подключаться к VNC-серверу, работающему на любой другой ОС. Существуют реализации клиентской и серверной части практически для всех операционных систем, в том числе и для Java (включая мобильную платформу J2ME). К одному VNC-серверу одновременно могут подключаться множественные клиенты. Наиболее популярные способы использования VNC — удалённая техническая поддержка и доступ к рабочему компьютеру из дома.

RDP – проприетарный протокол прикладного уровня, использующийся для обеспечения удалённой работы пользователя с сервером, на котором запущен сервис терминальных подключений. Клиенты существуют практически для всех версий Windows (включая Windows CE, Phone и Mobile), Linux, FreeBSD, Mac OS X, iOS, Android, Symbian. По умолчанию используется порт TCP 3389. Официальное название Microsoft для клиентского ПО — Remote Desktop Connection или Terminal Services Client, в частности, клиент в Windows 2k/XP/2003/Vista/2008/7/8/10 называется mstsc.exe.

PCoIP – технология PCoIP позволяет осуществлять удаленный доступ к рабочим столам, развернутым на компьютерах в центрах обработки данных с широкого спектра потребительских устройств: от персональных компьютеров, ноутбуков, тонких клиентов, планшетов, мобильных телефонов, на которые устанавливается специализированное клиентское программное обеспечение или мониторов, так называемых нулевых клиентов — устройств со встроенным аппаратным процессором PCoIP. На стороне рабочих станций поддерживается как аппаратная, так и программная реализация захвата рабочего стола. Используется в программном обеспечении по организации виртуальной инфраструктуры рабочих столов, в частности, поддерживается в VMware View, обеспечивая удаленный рабочий стол к виртуальным машинам. Протокол PCoIP предусматривает сжатие, шифрование и кодирование информации об экранном буфере, обеспечивает передачу PCoIP-устройствам только данных об изменившихся пикселях. Требования к пропускной способности сети при использовании PCoIP варьируются от 200 Кбит/с для простых работ, 1 Мбит/с при интенсивной работе с офисными документами и веб-серфинге и до 54 Мбит/с при работе с трехмерной графикой в высоком разрешении.

Каждый из вышеперечисленных протоколов имеет свои плюсы и минусы. Например, протоколы SPICE и VNC имеют открытое программное обеспечение (open-source software) что позволяет пользователю принять участие в доработке самой открытой программы, использовать код для создания новых программ и исправления в них ошибок.

В табл.1 приведено сравнение протоколов SPICE и RDP для различных сценариев работы, при этом под комфортной работой клиента подразумевается достигаемый уровень производительность протокола удаленного доступа по параметрам:

● Минимальная скорость при которой возможно соединение.

● Скорость при которой становится возможной офисная работа (вероятно недостаточно комфортная).

● Минимальная скорость соединения, при которой можно выполнять типичные офисные задачи (набор текста, работа в интернете, подготовка презентаций).

● Комфортный веб-серфинг.

● Скорость, достаточная для прослушивания аудио.

● Скорость, при которой становится возможным просмотр видео.

 

Таблица 1: Сравнение «скоростей комфортной работы» для SPICE и RDP

Сценарий	SPICE	RDP
Офисная работа	1024 кбит/с	512 кбит/с
Локальная музыка	512 кбит/с	1024 кбит/с
Интернет-видео	2048 кбит/с	не работает
Локальное видео	4096 кбит/с	не работает

 

Основываясь на результатах экспериментальных исследований [4], можно сделать вывод о том, что протокол SPICE показывает лучшую производительность чем RDP, но при работе офисными приложениями, протокол SPICE уступает RDP. В связи с этим при ограничении 512—1024 Кбит/с на канальный трафик предпочтительнее использовать RDP протокол.

Управление SLA.

Service Level Agreement (SLA) – это соглашение между заказчиком и исполнителем, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги. Соглашение SLA четко прописывает временные рамки для устранения проблем, определяет штрафные санкции, накладываемые на компанию в том случае, если качество услуг оказалось ниже прописанного в договоре уровня. Это позволит минимизировать убытки. Таким образом, заказчик получает удобный способ контролировать услуги, быть уверенным в их полноте и качестве [5]. Более того соглашение об уровне обслуживая предусматривает финансовые гарантии - возврат денег при нарушении SLA.

Типовая модель SLA включает следующие разделы:

1. Определение предоставляемого сервиса, стороны, вовлеченные в соглашение, и сроки действия соглашения.

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

3. Количество и размещение пользователей и/или оборудования, использующих данный сервис.

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

5. Описание процедуры запросов на изменение. Может включаться ожидаемое время выполнения этой процедуры.

6. Спецификации целевых уровней качества сервиса, включая:

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

b. Минимальная доступность для каждого пользователя

c. Среднее время отклика сервиса

d. Максимальное время отклика для каждого пользователя

e. Средняя пропускная способность

f. Описания расчёта приведённых выше метрик и частоты отчётов

7. Описание платежей, связанных с сервисом. Возможно, как установление единой цены за весь сервис, так и с разбивкой по уровням сервиса.

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

9. Процедура разрешения рассогласований, связанных с предоставлением сервиса.

10. Процесс улучшения SLA.

Параметры качества услуги, указанные в SLA, должны быть измеримыми, то есть представляемыми в виде числовых метрик. Например, для услуги доступа в Интернет это может быть максимальное время недоступности, максимальное суммарное время недоступности за период (например, за месяц). Скорость доступа при этом не является учитываемым параметром, поскольку зависит не только от оператора, но и от других операторов, от загруженности сервера сайта и т. п., на что, как правило, поставщик повлиять не может. Часто в SLA определяется период, за который поставщик услуги предоставляет заказчику отчёт об измеренных параметрах качества.

Жизненный цикл сервиса.

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

в настоящее время базируется на использовании

 

Рис.1. Жизненный цикл сервиса.

ITIL (IT Infrastructure Library — библиотека инфраструктуры информационных технологий) [6] — библиотеки, описывающей лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

В настоящее время на основе ITIL разработан британский стандарт BSI 15 000, который практически без изменений перешёл в категорию международного стандарта под именем ISO 2000. На базе рекомендаций ITIL реализован ряд программных средств автоматизации работы служб технической поддержки ИТ. В 2011г. завершена последняя (третья) редакция ITILv3. Русскоязычный глоссарий терминов и определений,используемых в библиотеке, можно найти на сайте [7].

Жизненный цикл сервиса согласно ITIL рассматривается как управление сервисами ИТ (Рис.1). Сервисная стратегия описывает общие основы и цели, формируя ось, вокруг которой вращается весь жизненный цикл. Проектирование сервисов, их внедрение и функционирование — три взаимосвязанных фазы цикла. Эти три сервиса охватывают проектирование, внедрение и текущую эксплуатацию сервисов ИТ, реализуя, таким образом, сервисную стратегию.

Стратегия – это комплекс (набор) видов деятельности в области планирования, посредством выполнения которых организация ищет пути перехода из одного состояния в другое в ответ на внешние и внутренние воздействия. Стратегия сервиса определяет, в частности, как поставщик сервиса будет использовать сервисы для достижения заказчиками их бизнес-результатов.
Целью стратегии сервиса является определение перспектив (perspective), текущих позиций (positions), планов (plans) действий и моделей (pattern) осуществления деятельности, необходимых поставщику услуг для формирования требуемых бизнес-результатов.
Проектирование сервиса.
Согласно ITIL стадия проектирования сервиса(service design) является одной из стадий жизненного цикла сервиса (стратегия, проектирование, преобразование, эксплуатация и постоянное совершенствование).
Проектирование - деятельность или процесс, который идентифицирует требования и далее определяет решение, способное удовлетворить этим требованиям.
Деятельность по проектированию сервиса начинается с набора новых или измененных бизнес-требований и заканчивается спроектированным сервисным решением, соответствующим документированным требованиям бизнеса. Для всех аспектов и частей проектирования услуги должен применяться целостный подход с тем, чтобы гарантировать целостность и интегрированность услуги с существующей системой управления и технологиями.
Функционирование сервиса.
Согласно библиотеке ITIL стадия функционирование услуг (service operation) является одной из стадий жизненного цикла услуг (стратегия, проектирование, преобразование, эксплуатация и постоянное совершенствование).
Функционирование (operation) – постоянное управление услугой, системой или другими компонентами.
Функционирования услуг является одной из важнейших стадий жизненного цикла услуг, поскольку, деятельность всех процессов на других стадиях жизненного цикла опирается на каждодневную систематическую работу по сбору данных и контролю показателей, осуществляемых в ходе функционирование услуги.
Постоянное улучшение сервиса.

Согласно ITIL постоянное совершенствование услуг (CSI, continual service improvement) является одной из стадий жизненного цикла сервиса (стратегия, проектирование, преобразование, эксплуатация и постоянное совершенствование). Меры по совершенствованию услуг реализуются на всех стадиях жизненного цикла услуг. Важным фактором для совершенствования услуг является измерение текущей деятельности поставщика услуг. Результаты работы поставщика сервис постоянно измеряются, разрабатываются меры по совершенствованию процессов, сервиса и ИТ- инфраструктуры с целью увеличения их эффективности, результативности и рациональности.

4.Содержание и примеры выполнения лабораторных работ.

В настоящее время основными поставщиками облачных инфраструктур являются Amazon, Google, Microsoft,IBM,Cisco. У каждой из компаний имеется целая линейка предоставляемых услуг. Кроме линейки продуктов вышеперечисленных компаний существует сотни разных облачных сервисов [8].

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

Хранение данных.

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

К наиболее известным хранилищам относятся Dropbox, Microsoft OneDrive, Google Drive, iCloud, Яндекс.Диск. В таблице 2 приведено их сравнение по различным пользовательским аспектам.

 

 

 

 

 

Таблица 2. Основные характеристики популярных облачных сервисов.

Наименование, адрес в Интернете	Объем хранимой информации (Гб)	Поддерживаемые операционные системы	Русифицированный интерфейс	Достоинства	Недостатки
Бес-платно	Плат-но
Dropbox www.dropbox.com			Linux, Windows, Mac OS, iOS, Android, Blackberry, Bada	Нет	Простота, поддержка всех типов файлов и возможност