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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ

Федеральное государственное бюджетное образовательное
учреждение высшего образования

«ПЕНЗЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

Факультет вычислительной техники

Кафедра «Высшая и прикладная математика»

 

 

Реферат

по дисциплине: «Облачные вычисления»

на тему: «Какие аспекты стоит принимать во внимание при проектировании облачных сервисов / ПО»

 

 

Выполнил: студент гр. 18ВГм2
Салимов Г. Ю.
Проверила:к. ф.-м. н., доцент

Захарова Ю.Ф.

 

Пенза, 2020

СОДЕРЖАНИЕ

Введение. 3

Лицензирование программного обеспечения. 4

Доступность. 6

Надежность. 8

Производительность. 9

Безопасность. 10

Заключение. 12

Список использованной литературы.. 13

 

 

Введение

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

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

При проектировании облачных сервисов необходимо учитывать моменты, которые влияют на стоимостные и прикладные характеристики. Рассмотрим основные аспекты проектирования.

Лицензирование программного обеспечения

 

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

С точки зрения модели лицензирования, идеальным для использования в облачной среде является ПО на основе открытого кода (Open Source). Фактически именно гибкость модели лицензирования Open Source и сделала возможной реализацию облака Amazon. Если вы сможете полностью ликвидировать вопросы лицензирования при развертывании ваших приложений в облачной инфраструктуре, можно сконцентрироваться на других вопросах перехода на использование облачной обработки данных. Хотя большинство решений на основе открытого кода (например, Apache и большинство дистрибутивов Linux) предоставляют вам полную свободу действий, с вопросами лицензирования вам все же придется столкнуться если вы приобретаете поддерживаемые версии программного обеспечения Open Source, например Red Hat Enterprise Linux или MySQL Enterprise. К счастью, схемы лицензирования такого ПО вполне дружественны по отношению к использованию в облачной инфраструктуре.

Если не брать в расчет модель лицензирования Open Source, которая наилучшим образом подходит для облачных вычислений, то второй будет модель, в соответствии с которой плата взимается за CPU в час. По мере того как облачная модель входит в обиход, все большее и большее количество поставщиков предлагают услуги с почасовой оплатой. Например, Microsoft, Valtira, Red Hat, Vertica, Sun, а также многие другие компании уже приняли условия почасовой оплаты за CPU и довольно неплохо поддерживают облачную обработку данных. Oracle тоже рекламирует свою доступность в облачных вычислениях, но вот, к сожалению, они все равно придерживаются своей устаревшей модели лицензирования, которая направлена на поддержание традиционных условий.

ПО, схема лицензирования которого основывается на количестве пользователей, тоже может адекватно работать в облачной среде. Основная сложность с таким ПО часто заключается в том, как оно производит проверку условий лицензирования. Вы можете подвергаться риску нарушения лицензионного соглашения, лицензия может быть "привязана" к конкретным MAC- или IP-адресам или система управления лицензиями может оказаться недостаточно интеллектуальной для того, чтобы поддерживать облачную среду, или необоснованно лишать вас возможности масштабирования вашей системы в облаке.

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

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

 

Доступность

Доступность — это показатель, который указывает, насколько часто может использоваться сервис в течение предопределенного периода времени.

Большинство людей считают, что система обладает высокой доступностью, если объявленное ожидаемое значение показателя доступности составляет от 99,99 до 99,999 %. При доступности 99,999 % система может оказаться недоступной только 5 минут 15 секунд за год.

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

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

периода;

ожидаемое время простоя в случае возникновения сбоев и неполадок.

Ожидаемая доступность компонента выражается следующей математической формулой:

a — ожидаемая доступность;

c — вероятность (в %) отказа сервера в течение заданного периода;

d — ожидаемое время простоя вследствие отказа сервера;

p — оцениваемый период.

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

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

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

Следует ли вам включить в анализ периоды планового простоя? Включение планового простоя в чем-то противоречиво, но оно может вам потребоваться для некоторых видов управления доступностью. Например, возможна такая ситуация, когда архитектура системы позволяет вам обеспечить доступность 99,999 %, но, тем не менее, предпочитениие запланировать для системы 1 час простоя в неделю для проведения плановых профилактических работ (вследствие повышенных требований к безопасности или любого другого критерия, который не имеет отношения к теоретической оценке доступности системы как таковой). Если производить оценку для внутренних целей, можно считать, что оценка 99,999 % объективна. Но если пытаться рекламировать систему для конечных пользователей и сообщаете им, какого уровня доступности им следует ожидать, то оценка 99,999 % введет их в заблуждение.

В течение какого процента времени среда должна быть доступна? Например, для Web-сайта можно задать требование, в соответствии с которым доступность его домашней и всех дочерних страниц из-за пределов корпоративной сети должна составлять 99,999 % ежедневно от 07:00 до 21:00.

 

Надежность

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

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

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

теряются любые данные, которые хранятся в этом экземпляре и никогда не резервировались;

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

не хранить постоянные данные EC2 в эфемерных хранилищах экземпляра (не обязательно применимо к другим облакам, отличным от Amazon);

регулярно создавать резервные копии.

 

Производительность

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

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

± Если вы не создаете кластеры серверов баз данных, сегментируйте доступ к базе данных таким образом, чтобы операции чтения могли выполняться на подчиненных серверах (slaves), а операции записи — на главном (master).

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

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

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

± Использовать балансировщик нагрузки для маршрутизации трафика на узлы, собранные в кластер серверов приложений. Путем организации кластеров узлы серверов приложений могут взаимодействовать друг с другом и совместно использовать информацию о статусе. Организация кластеров дает то преимущество, что вы можете организовать обмен информацией о статусе на уровне сервера приложений; наряду с этим, недостатком этого подхода является то, что он сложнее и ограничивает долгосрочную масштабируемость. Еще одна проблема с настоящей кластеризацией состоит в том, что многие кластерные архитекту ры основываются на многоадресной рассылке (multicasting) — а в Amazon EC2 она недоступна (но доступна в GoGrid и Rackspace).

 

Безопасность

Безопасность в облачной среде — это один из основных аспектов, на которые особенно "напирают" критики облачной инфраструктуры. Для многих людей перенос их данных в облачную среду на компьютеры, где они никак не могут их контролировать, кажется эмоционально дискомфортным. Кроме того, этот подход действительно требует рассмотрения вопросов соответствия стандартам и учета различных нормативно-правовых аспектов. Впрочем, в действительности облачная среда может быть защищена ничуть не хуже, а может быть, даже и лучше, чем традиционный центр обработки данных. Однако в случае работы с облачной средой ваш подход к информационной безопасности тоже будет радикально отличаться от того, к чему вы привыкли в традиционной среде.

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

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

± в облаке Amazon нет такого понятия, как "периметр". Следовательно, политика безопасности, разработанная таким образом, чтобы держать в центре внимания защиту периметра, в облаке Amazon работать не будет. Вам не следует ориентироваться на такую политику даже в тех облачных инфраструктурах, которые поддерживают традиционную модель защиты периметра;

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

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

Заключение

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

В данной работе рассмотрены аспекты, которые стоит принимать во внимание при проектировании облачных сервисов и ПО, которые в конечном счете влияют на стоимостно - прикладные характеристики.

Таким образом, выделяют:

- производительность;

- лицензирование ПО;

- надежность;

- безопасность.

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

1. Облачные сервисы. Взгляд из России / Под ред. Е. Гребнева. — м.: Cnews, 2011;

2. Институт ЮНЕСКО по информационным технологиям в образовании «Облачные вычисления в образовании» - М.: 2010;

3. Миронович В. Обзор: Облачные вычисления http://www.ht.ua/pub/104309.html;

4. Риз Д. Облачные вычисления. – СПб.: БХВ-Петербург, 2011;

5. УК «АЛЬЯНС. ВЕНЧУРНЫЙ БИЗНЕС», статья Облачные вычисления как настоящее и будущее ИТ, http://venture-biz.ru/informatsionnye-tekhnologii/205-oblachnye-vychisleniya

6. Tadviser, статья Облачные вычисления (Cloud computing), http://www.tadviser.ru/index.php7. Oracle, статья Облачные вычисления Oracle, http://www.oracle.com/ru/technologies/cloud/cloud-computing-wp-ru-513234-ru.pdf

8. Фокин Н.Б., статья Обоснование эффективности использования Облачных технологий, http://journal.itmane.ru/node/649

9. Беленький А. «Облачные» технологии начинают и выигрывают. — КомпьютерПресс, N7. — 2011;

10. Горелов А. Куда идут «облака». — КомпьютерПресс, N12. — 2011;

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