Учебнопрактическое пособие Владимир 2021
 Скачать 7.94 Mb.
|
|
1.5. Технологии одноранговых сетей Технология одноранговых сетей (или P2P-сетей от анг, peer-to- peer – равный-к-равному) обеспечивает формирование распределен- ных систем на базе принципа децентрализации, где разделение вы- числительных ресурсов и сервисов производится напрямую посред- ством прямого взаимодействия между участниками сети друг с дру- гом, без участия центрального сервера. Одноранговые вычислитель- ные сети, в какой-то степени, являются противоположностью клиент- серверным архитектурам. В отличие от традиционной клиент-серверной архитектуры в P2P-сетях каждый узел, входящий в вычислительную сеть, может яв- ляться как клиентом, так и сервером, предоставляя или используя ре- сурсы сети. На рис. 1.4 представлены связи в сетях с P2P и с центра- лизованной архитектурой. 37 Рис. 1.4. Сравнение вида связей P2P и централизованной (клиент-серверной) ар- хитектур Можно выделить следующие проблемы клиент-серверной архи- тектуры, связанные с наличием централизованного сервера, обеспе- чивающего обработку запросов от множества клиентов: Проблемы масштабируемости. При увеличении количе- ства клиентов растут требования к мощности сервера и пропускной способности канала. Единственным вариантом решения данной зада- чи является наращивание пропускной способности канала до сервера и использование более высокопроизводительных решений для аппа- ратной платформы сервера; Зависимость. Стабильная работа всех клиентов зависит от загруженности и функционирования одного сервера. При выходе из строя или отключении сервера, клиенты не смогут выполнять функ- циональные обязанности. Этим проблемам можно противопоставить следующие преиму- щества P2P: Отсутствие зависимости от централизованных сервисов и ресурсов; Система может пережить серьезное изменение в структуре сети; Высокая масштабируемость модели одноранговых вычис- лений. Можно выделить следующие основные задачи, которые с легко- стью решают P2P сети: 38 1. Уменьшение/распределение затрат. Серверы централизован- ных систем, которые обслуживают большое количество клиентов, обычно несут на себе основной объем затрат ресурсов (денежных, вычислительных и др.) на поддержание вычислительной системы. P2P архитектура может помочь распределить эти затраты между уз- лами сети. Так как узлы, как правило, автономны, важно, чтобы за- траты были распределены справедливо. 2. Объединение ресурсов. Каждый узел в P2P-системе обладает определенными ресурсами (вычислительные мощности, объем памя- ти). Приложения, которым необходимо большое количество ресурсов, например ресурсозатратные задачи моделирования или распределен- ные файловые системы, используют возможность объединения ре- сурсов всей сети для решения своей задачи. При этом важны как объ- ем дискового пространства для хранения данных, так и пропускная способность сети. 3. Повышенная масштабируемость. Поскольку в сетях Р2Р от- сутствует сильный центральный механизм, важной задачей является повышение масштабируемости и надежности системы. Масштабиру- емость определяет количество систем, которые могут быть достигну- ты из одного узла, сколько систем могут функционировать одновре- менно, сколько пользователей может пользоваться сетью, сколько памяти может быть использовано. Надежность сети определяется та- кими параметрами как количество сбоев в работе сети, отношение времени простоя к общему времени работы, доступностью ресурсов и т.д. Таким образом, основной проблемой становится разработка но- вых алгоритмов обнаружения ресурсов, на которых базируются но- вые P2P платформы. 4. Анонимность. Бывает, пользователь не желает, чтобы другие пользователи или поставщики услуг знали о его нахождении в сети. При использовании центрального сервера трудно обеспечить ано- нимность, так как серверу, как правило, необходимо идентифициро- вать клиента, по крайней мере через интернет адрес. При использова- ния P2P-сети пользователи могут избежать предоставления любой информацию о себе. 39 Основные элементы P2P сетей Пир(Peer)– это фундаментальный составляющий блок любой одноранговой сети: Каждый пир имеет уникальный идентификатор; Каждый пир принадлежит одной или нескольким группам; Каждый пир может взаимодействовать с другими пирами, как в своей так и в других группах. Можно выделить следующие виды пиров: Простой пир: обеспечивает работу конечного пользовате- ля, предоставляя ему сервисы других пиров и обеспечивая предостав- ление ресурсов пользовательского компьютера другим участникам сети; Роутер: обеспечивает механизм взаимодействия между пи- рами, отделенными от сети брандмауэрами или NAT-системами. Группа пиров– это набор пиров, сформированный для решения общей задачи или достижения общей цели. Группы пиров могут предоставлять членам своей группы такие наборы сервисов, которые недоступны пирам, входящим в другие группы. Сервисы – это функциональные возможности, которые может привлекать отдельный пир для полноценной работы с удаленными пирами. В качестве примера сервисов, которые может предоставлять отдельный пир можно указать сервисы передачи файлов, предостав- ления информации о статусе, проведения вычислений и др. Сервисы пира– это такие сервисы, которые может предоставить конкретный узел P2P. Каждый узел в сети P2P предоставляет определенные функциональные возможности, которыми могут воспользоваться дру- гие узлы. Эти возможности зависят от конкретного узла и доступны только тогда, когда узел подключен к сети. Как только узел отключа- ется, его сервисы становятся недоступны. Сервисы группы– это функциональные возможности, предоставляемые группой входящим в нее узлам. Возможности могут предоставляться несколькими узла- ми в группе, для обеспечения избыточного доступа к этим возможно- 40 стям. Как только к группе подключается узел, обеспечивающий необ- ходимый сервис, он становиться доступной для всей группы. P2P — это не только сети, но еще и сетевой протокол, обеспе- чивающий возможность создания и функционирования сети равно- правных узлов, их взаимодействия. Множество узлов, объединенных в единую систему и взаимодействующих в соответствии с протоко- лом P2P, образуют пиринговую сеть. P2P относятся к прикладному уровню сетевых протоколов и являются наложенной сетью, исполь- зующей существующие транспортные протоколы стека TCP/IP. Про- токолы сети P2P обеспечивают: поиск узлов в сети; получение списка служб отдельного узла; получение информации о статусе узла; использование службы на отдельном узле; создание, объединение и выход из групп; создание соединений с узлами; маршрутизацию сообщений другим узлам. Можно выделить следующие основные преимущества одноран- говых сетей: высокая масштабируемость, связанная с равномерным распределением вычислительной нагрузки на всех участников сети; стабильность работы сети, обусловленная отсутствием «узкого места» – выделенного сервера, обрабатывающего все сетевые запросы; возможность объединения ресурсов отдельных участников сети, и их предоставление другим участникам; распределение совокупных затрат на предоставление ре- сурсов между участниками сети. С другой стороны, отдельно стоит упомянуть о следующих не- достатках и особенностях функционированияP2P-сетей: в одноранговых сетях не может быть обеспечено гаранти- рованное качество обслуживания: любой узел, предоставляющий те или иные сервисы, может быть отключен от сети в любой момент; 41 индивидуальные технические характеристики узла могут не позволить полностью использовать ресурсы P2P сети (каждый из узлов обладает индивидуальными техническими характеристиками что, возможно, будет ограничивать его роль в P2P-сети и не позволят полностью использовать ее ресурсы: низкий рейтинг в torrent-сетях, LowID в eDonkey могут значительно ограничить ресурсы сети, до- ступные пользователю); при работе того или иного узла через брандмауэр может быть значительно снижена пропускная способность передачи данных в связи с необходимостью использования специальных механизмов обхода участниками одноранговых сетей в основном являются индивидуальные пользователи, а не организации, в связи с чем возни- кают вопросы безопасности предоставления ресурсов: владельцы уз- лов P2P-сети, скорее всего, не знакомы друг с другом лично, предо- ставление ресурсов происходит без предварительной договоренности; при увеличении числа участников P2P сети может возник- нуть ситуация значительного возрастания нагрузки на сеть (как с цен- трализованной, так и с децентрализованной структурой); в случае применения сети типа P2P приходится направлять значительные усилия на поддержку стабильного уровня ее произво- дительности, резервное копирование данных, антивирусную защиту, защиту от информационного шума и других злонамеренных действий пользователей. 1.6. Архитектура грид. Термин «грид» был введен в обращение Яном Фостером в нача- ле 1998 года публикацией книги «Грид. Новая инфраструктура вы- числений»: Грид – это система, которая координирует распределенные ре- сурсы посредством стандартных, открытых, универсальных протоко- лов и интерфейсов для обеспечения нетривиального качества обслу- живания. 42 Основной идеей, заложенной в концепции грид-вычислений, яв- ляется централизованное удаленное предоставление ресурсов, необ- ходимых для решения различного рода вычислительных задач. В идеологии грид: мы можем запустить любую задачу с любого компь- ютера или мобильного устройств на вычисление, ресурсы же для это- го вычисления должны быть автоматически предоставлены на уда- ленных высокопроизводительных серверах, независимо от типа нашей задачи. С более практической точки зрения, основная задача, лежащая в основе концепции грид, это согласованное распределение ресурсов и решение задач в условиях динамических, многопрофильных вирту- альных организаций. Распределение ресурсов, в котором заинтересо- ваны разработчики грид, это не обмен файлами, а прямой доступ к компьютерам, программному обеспечению, данным и другим ресур- сам, которые требуются для совместного решения задач и стратегий управления ресурсами, возникающих в промышленности, науке и технике. Технологии грид включают в себя: решения по безопасности, поддерживающие управление сертификацией и политиками безопасности, когда вычисления произ- водятся несколькими организациями; протоколы управления ресурсами и сервисами, поддержи- вающие безопасный удаленный доступ к вычислительным ресурсам и ресурсам данных, а также перераспределение различных ресурсов; протоколы запроса информации и сервисы, обеспечиваю- щие настройку и мониторинг состояния ресурсов, организаций и сер- висов; сервисы обработки данных, обеспечивающие поиск и пе- редачу наборов данных между системами хранения данных и прило- жениями. Выделяют следующие уровни архитектуры грид: 1. Базовый уровень (Fabric) – содержит различные ресурсы, та- кие как компьютеры, устройства хранения, сети, сенсоры и др. 43 2. Связывающий уровень(Connectivity)– определяет коммуни- кационные протоколы и протоколы аутентификации. 3. Ресурсный уровень(Resource)– реализует протоколы взаимо- действия с ресурсами РВС и их управления. 4. Коллективный уровень(Collective)– управление каталогами ресурсов, диагностика, мониторинг; 5. Прикладной уровень (Applications)– инструментарий для ра- боты с грид и пользовательские приложения. На базовом уровне определяются службы, обеспечивающие непосредственный доступ к ресурсам, использование которых рас- пределено посредством протоколов грид. Вычислительные ресурсы предоставляют пользователю грид-системы (точнее говоря, задаче пользователя) процессорные мощности. Вычислительными ресурсами могут быть как кластеры, так и отдельные рабочие станции. При всем разнообразии архитектур любая вычислительная система может рассматриваться как потенци- альный вычислительный ресурс грид-системы. Ресурсы памяти представляют собой пространство для хранения данных. Для доступа к ресурсам памяти также используется программное обеспечение промежуточного уровня, реализующее унифицированный интерфейс Управления и передачи данных. Информационные ресурсы и каталоги являются особым видом ресурсов памяти. Они служат для хранения и предоставления метаданных и информации о других ресурсах грид-системы. Сетевой ресурс является связующим звеном между рас- пределенными ресурсами грид-системы. Основной характеристикой сетевого ресурса является скорость передачи данных. Связывающий уровень определяет коммуникационные прото- колы и протоколы аутентификации, обеспечивая передачу данных между ресурсами базового уровня. Связывающий уровень грид осно- ван на стеке протоколов TCP/IP: 1. Интернет (IP, ICMP); 2. Транспортные протоколы (TCP, UDP); 44 3. Прикладные протоколы (DNS, OSRF…). Ресурсный уровень реализует протоколы, обеспечивающие вы- полнение следующих функций: Согласование политик безопасности использования ресур- са; Процедура инициации ресурса; Мониторинг состояния ресурса; Контроль над ресурсом; Учет использования ресурса. Отдельно выделяются 2 типа протоколов ресурсного уровня: 1. Информационные протоколы – используются для получения информации о структуре и состоянии ресурса. 2. Протоколы управления – используются для согласования до- ступа к разделяемым ресурсам, определяя требований и допустимых действий по отношению к ресурсу (например, поддержка резервиро- вания, возможность создания процессов, доступ к данным). Коллективный уровень отвечает за глобальную интеграцию раз- личных наборов ресурсов и может включать в себя службы каталогов; службы совместного выделения, планирования и распределения ре- сурсов; службы мониторинга и диагностики ресурсов; службы репли- кации данных. На прикладном уровне располагаются пользователь- ские приложения, исполняемые в среде ВО. Они могут использовать ресурсы, находящиеся на любых нижних слоях архитектуры грид. Стандарты Грид Ключевым моментом в разработке грид приложений является стандартизация, позволяющая организовать поиск, использование, размещение и мониторинг различных компонентов, составляющих единую виртуальную систему, даже если они предоставляются раз- личными поставщиками услуг или управляются различными органи- зациями. В 2001 году в качестве базы для создания стандарта архитекту- ры грид приложений была выбрана технология веб-сервисов. Данный 45 выбор был обусловлен двумя основными достоинствами данной тех- нологии. Во-первых, язык описания интерфейсов веб-сервисов WSDL (Web Service Definition Language) поддерживает стандартные меха- низмы для определения интерфейсов отдельно от их реализации, что в совокупности со специальными механизмами связывания (транс- портным протоколом и форматом кодирования данных) обеспечивает возможность динамического поиска и компоновки сервисов в гетеро- генных средах. Во-вторых, широко распространенная адаптация ме- ханизмов веб-сервисов означает, что инфраструктура, построенная на базе веб-сервисов, может использовать различные утилиты и другие существующие сервисы, такие как различные процессоры WSDL, си- стемы планирования потоков задач и среды для размещения веб- сервисов. Разработанный стандарт архитектуры грид получил название OGSA (Open Grid Services Architecture – Открытая архитектура грид- сервисов). Он основывается на понятии грид-сервиса. Грид-сервисом называется сервис, поддерживающий предоставление полной инфор- мации о текущем состоянии (потенциально временного) экземпляра сервиса, а также поддерживающий возможность надежного и без- опасного исполнения, управления временем жизни, рассылки уведом- лений об изменении состояния экземпляра сервиса, управления поли- тикой доступа к ресурсам, управления сертификатами доступа и вир- туализации. Грид-сервис поддерживает следующие стандартные ин- терфейсы. 1. Поиск. Грид - приложениям необходимы механизмы для по- иска доступных сервисов и определения их характеристик. 2. Динамическое создание сервисов. Возможность динамиче- ского создания и управления сервисами – это один из базовых прин- ципов OGSA, требующий наличия сервисов создания новых сервисов. 3. Управление временем жизни. Распределенная система долж- на обеспечивать возможность уничтожения экземпляра грид-сервиса. 4. Уведомление. Для обеспечения работы грид приложения наборы грид сервисов должны иметь возможность асинхронно уве- домлять друг друга о изменениях в их состоянии. 46 1.7. Облачные вычисления Облачные вычисления привлекают много внимания в последнее время. В средствах массовой информации, в интернете, даже на теле- видении можно встретить восторженные материалы, описывающие все прекрасные возможности, которые может предоставить данная технология. Термин «Облачные вычисления» появился на свет совсем не- давно. Согласно результатам анализа поисковой системы Google, термин «Облачные вычисления» («Cloud Computing») начал набирать вес в конце 2007 – начале 2008 года. На сегодняшний день уже можно говорить о том, что облачные вычисления прочно вошли в повсе- дневную жизнь каждого пользователя Интернета (хотя многие об этом и не подозревают). По некоторым экспертным оценкам, техно- логия облачных вычислений может в три-пять раз сократить стои- мость бизнес-приложений и более чем в пять раз стоимость приложе- ний для конечных потребителей. Определение облачных вычислений С одной стороны, у термина «Облачные вычисления» нет усто- явшегося стандартного определения. С другой стороны множество различных корпораций, ученых и аналитиков дают собственные определения этому термину. Например, в лаборатории Беркли дают следующее определение облачных вычислений: «Облачные вычисления– это не только приложения, поставляе- мые в качестве услуг через Интернет, но и аппаратные средства и программные системы в центрах обработки данных, которые обеспе- чивают предоставление этих услуг. Услуги сами по себе уже давно называют «предоставление программного обеспечения как услуги» (Software-as-a-Service или SaaS). Облаком называется аппаратное и программное обеспечение центра обработки данных. Общественное 47 облако предоставляет ресурсы облака широкому кругу пользователей по принципу «оплата по мере использования» (pay-as-you-go – прин- цип предоставления услуг, при котором пользователь оплачивает только те ресурсы, которые были по факту затрачены на решение по- ставленной задачи). Частное облако – это внутренние центры обра- ботки данных, в коммерческой или иной организации, которые не до- ступны широкому кругу пользователей. Таким образом, облачные вычисления являются суммой SaaS и «коммунальных вычислений» (Utility Computing– модель вычислительных систем, в которой предо- ставление данных и процессорных мощностей организовано по прин- ципам коммунальных услуг). Люди могут быть пользователями или провайдерами SaaS, либо пользователями или поставщиками комму- нальных вычислений». Ян Фостер определяет облачные вычисления как «парадигму крупному-штабных распределенных вычислений, основанную на эф- фекте масштаба, в рамках которой пул абстрактных, виртуализиван- ных, динамически масштабируемых вычислительных ресурсов, ре- сурсов хранения, платформ и сервисов предоставляется по запросу внешним пользователям через Интернет». Еще одно распространенное определение облачных вычислений состоит в следующем. «Облако – это большой пул легко используемых и легкодоступ- ных виртуализиванных ресурсов (таких как аппаратные комплексы, сервисы и др.). Эти ресурсы могут быть динамически перераспреде- лены (масштабированы) для подстройки под динамически изменяю- щуюся нагрузку, обеспечивая оптимальное использование ресурсов. Этот пул ресурсов обычно предоставляется по принципу «оплата по мере использования». При этом владелец облака гарантирует каче- ство обслуживания на основе определенных соглашений с пользова- телем». Все определения иллюстрируют одну простую мысль: феномен облачных вычислений объединяет несколько различных концепций информационных технологий и представляет собой новую парадигму предоставления информационных ресурсов (аппаратных и программ- 48 ных комплексов). Со стороны владельца вычислительных ресурсов облачные вычисления ориентированы на предоставление информаци- онных ресурсов внешним пользователям. Со стороны пользователя, облачные вычисления – это получение информационных ресурсов в виде услуги у внешнего поставщика, оплата за которую производится в зависимости от объема потребленных ресурсов согласно установ- ленному тарифу. Ключевыми характеристиками облачных вычисле- ний являются масштабируемость и виртуализация. Масштабируемость представляет собой возможность динамиче- ской настройки информационных ресурсов к изменяющейся нагрузке, например к увеличению или уменьшению количества пользователей, изменению необходимой емкости хранилищ данных или вычисли- тельной мощности. Виртуализация, которая также рассматривается как важнейшая технология всех облачных систем, в основном ис- пользуется для обеспечения абстракции и инкапсуляции. Абстракция позволяет унифицировать «сырые» вычислитель- ные, коммуникационные ресурсы и хранилища информации в виде пула ресурсов и выстроить унифицированный слой ресурсов, кото- рый содержит те же ресурсы, но в абстрагированном виде. Они пред- ставляются пользователям и верхним слоям облачных систем как виртуализиванных серверы, кластеры серверов, файловые системы и СУБД. Инкапсуляция приложений повышает безопасность, управля- емость и изолированность. Еще одной важной особенностью облач- ных платформ является интеграция аппаратных ресурсов и системно- го ПО с приложениями, которые предоставляются конечному пользо- вателю в виде сервисов. В соответствии со всем вышесказанным, можно выделить сле- дующие основные черты облачных вычислений: Облачные вычисления представляют собой новую пара- дигму предоставления вычислительных ресурсов; Базовые инфраструктурные ресурсы (аппаратные ресурсы, системы хранения данных, системное ПО) и приложения предостав- ляются в виде сервисов. Данные сервисы могут предоставляться неза- 49 висимым поставщиком для внешних пользователей по принципу «оплата по мере использования»; Основными особенностями облачных вычислений являют- ся виртуализация и динамическая масштабируемость; Облачные сервисы могут предоставляться конечному пользователю через веб-браузер или посредством определенного про- граммного интерфейса. Многослойная архитектура облачных приложений Все возможные методы классификации облаков можно свести к трехслойной архитектуре облачных систем, состоящей из следующих уровней: Инфраструктура как сервис (Infrastructure as a Service: IaaS); Платформа как сервис (Platform as a Service: PaaS); Программное обеспечение как сервис (Software as a Service: SaaS). Рассмотрим более подробно, что собой представляет каждый из указанных уровней, и каким образом они взаимодействуют друг с другом. Рис. 1.5. Три слоя облачных вычислений 50 Инфраструктура как сервис (IaaS) IaaS предлагает информационные ресурсы, такие как вычисли- тельные циклы или ресурсы хранения информации, в виде сервиса. Вместо предоставления доступа к «сырым» вычислительным устрой- ствам и системам хранения, поставщики IaaS обычно предоставляют виртуализованную инфраструктуру в виде сервиса. Обычно «сырые» ресурсы (процессорные циклы, сетевое оборудование, системы хра- нения) располагают на базовом уровне, над которым посредством виртуализации надстраивают слои сервисов, которые и предоставля- ются конечным пользователям в виде IaaS. Надо сказать, что еще задолго до появления облачных вычисле- ний инфраструктура была доступна как сервис. Такой подход назы- вался «коммунальные вычисления», и это словосочетание часто при- меняется некоторыми авторами при описании инфраструктурного уровня облачных систем. В сравнении с ранними попытками организации коммунальных вычислений, подход IaaS предоставляет разработчикам понятный ин- терфейс, к которому легко получить доступ и использовать в соб- ственных приложениях. Данный интерфейс должен легко интегриро- ваться с инфраструктурой потенциальных пользователей и разработ- чиков решений SaaS. Давно замечено, что ресурсы поставщиков ком- мунальных вычислений могут быть эффективно использованы только в том случае, если они используются большим числом потребителей, а этого можно добиться путем организации хорошего программного интерфейса к своим ресурсам. Платформа как сервис(PaaS) Платформа – это слой абстракции между программными при- ложениями (SaaS) и виртуализованной инфраструктурой (IaaS). Ос- новной целевой аудиторией PaaS являются разработчики приложе- ний. Разработчики могут писать собственные приложения на основе спецификаций определенной платформы, не заботясь о том, каким 51 образом организовать взаимодействие с нижележащей инфраструкту- рой (IaaS). Разработчики загружают свой программный код на плат- форму, которая обеспечивает автоматическое масштабирование при- ложения в зависимости от нагрузки. Слой PaaS основывается на стан- дартизованном интерфейсе, предоставляемом слоем IaaS, который виртуализует базовые вычислительные ресурсы и предоставляет стандартный интерфейс для разработки приложений, функциониру- ющих на слое SaaS. Программное обеспечение как сервис(SaaS) SaaS – это программное обеспечение, которое предоставляется по принципу «оплата по мере использования» и управляется удаленно одним или несколькими поставщиками. SaaS – это наиболее замет- ный слой облачных вычислений, так как именно он представляет ре- альную ценность для конечного пользователя и обеспечивает реше- ние его задач. С точки зрения пользователя, основным достоинством SaaS яв- ляется цеж-новое преимущество перед «классическим» ПО. Оплата SaaS осуществляется по модели «оплата по мере использования», что означает отсутствие необходимости инвестиций в собственную аппа- ратную и программную инфраструктуру. Типичный пользователь SaaS не может контролировать базовую инфраструктуру, будь это программная платформа, на которой SaaS основано (PaaS) или же непосредственно аппаратная инфраструкту- ра(IaaS). Однако поставщик SaaS обязан проработать взаимодействие данных слоев, потому что они необходимы для работы системы. Например, SaaS-приложение может быть разработано на базе суще- ствующей платформы и исполняться на инфраструктуре, предостав- ленной сторонней компанией. Работа с платформами и/или инфра- структурой как с сервисом является очень привлекательной с точки зрения поставщиков SaaS, так как это может уменьшить в разы от- числения на используемые лицензии или затраты на инфраструктуру. Это также позволяет им сосредоточиться на тех областях, в которых 52 они по-настоящему компетентны. Как можно заметить, это очень по- хоже на те преимущества, которые мотивируют конечных пользова- телей ПО переходить к использованию решений SaaS. Компоненты облачных приложений На сегодняшний день не существует единой компонентной ар- хитектуры облачных приложений. Это вызвано высокой закрытостью различных аспектов реализации наиболее распространенных облач- ных систем. Но, не смотря на это, можно выделить основные наибо- лее важные компоненты, присущие практически всем существующим облачным платформам. Рис. 1.6. Компонентная модель облачного решения Облако можно разбить на основные компоненты, отражающие следующие ключевые особенности облачных решений. 1. Платформа: среда и набор утилит, обеспечивающих разра- ботку, интеграцию и предоставление облачных сервисов. Платформа является центральным компонентом модели облака. Платформа с од- ной стороны, предоставляет набор базовых сервисов, доступных раз- работчику облачного приложения, а с другой накладывает опреде- 53 ленные ограничения на методы разработки и предоставления прило- жения. 2. Представление: интерфейс, через который пользователь производит взаимодействие с облаком. Этот компонент обеспечивает получение входных данных и предоставление информации конечно- му пользователю. Наиболее типичным методом реализации представ- ления является веб-приложение, обеспечивающее взаимодействие с пользователем посредством веб-браузера. В последнее время все ча- ще используются все возможности предоставления пользователю удобного интерфейса работы независимо от устройства, с которого он выходит в Интернет. Это влечет за собой разработку отдельных поль- зовательских интерфейсов для мобильных устройств (смартфонов, планшетов) которые могут представлять собой как отдельные интер- нет-страницы, так и полноценные мобильные приложения, взаимо- действующие с облаком посредством API. 3. Информация: источники данных, обеспечивающие рас- пределенное хранение структурированных или неструктурированных, статических или динамически-изменяющихся данных. Пользователь- ская информация в облачных системах может достигать огромных объемов. Классические SQL базы данных уже не дают удовлетвори- тельных результатов по скорости обработки. Более того, облачным платформам часто приходится обрабатывать связанные структуры данных (графы, деревья) что становится очень тяжело при использо- вании SQL-подхода и реляционных баз данных. В связи с этим, в по- следние несколько лет стали активно развиваться альтернативные «NoSQL» системы управления базами данных (колоночные СУБД, такие как Hadoop; документно-ориентированные СУБД, такие как CouchDB и MongoDB) и альтернативные подходы к обработке сверх- больших объемов информации. Наиболее известной реализацией та- кого подхода является фреймворк MapReduce, представленный ком- панией Google. Он используется для параллельных вычислений над очень большими (несколько петабайт) наборами данных в компью- терных кластерах. 54 4. Идентификация: информация об основных потребителях облачных ресурсов, используется для оптимизации и подстройки об- лака под их задачи. Большинству приложений требуется уметь отличать пользова- телей друг от друга для предоставления релевантной информации. Такая информация имеет первостепенную значимость для облачной платформы, так как на нее завязаны большие объемы пользователь- ских данных, и при этом необходимо обеспечить ее максимальную доступность в рамках системы, т.к. процедура авторизации должна проходить максимально быстро. Также, необходимо обеспечить про- зрачную авторизацию пользователя во всех сервисах одной облачной платформы, чтобы не требовалось каждый раз вводить имя пользова- теля и пароль заново. В связи с распределенной природой облачных сервисов необходимо обеспечить высочайший уровень безопасности при работе с пользовательской информацией. 5. Интеграция: инфраструктура, упрощающая обмен инфор- мацией и исполнение задач в распределенной вычислительной среде. Высокая степень декомпозиции сервисов позволяет достичь макси- мальной эффективности и гибкости выполнения облачных приложе- ний, так как появляется возможность загрузки сразу нескольких вы- числительных машин при исполнении одной пользовательской зада- чи. В связи с этим появляется необходимость организации обмена информацией и исполнения задач в распределенных вычислительных средах. В рамках этого компонента необходимо обеспечить макси- мальную производительность и безопасность процесса обмена дан- ными между сервисами. Далее, необходимо обеспечить совмести- мость форматов данных и разработать механизмы синхронного и асинхронного взаимодействия с унаследованным ПО. На более высо- ком уровне необходимо обеспечить слабосвязанность программных компонентов и убедиться в отсутствии узких мест в программной ар- хитектуре системы. 6. Масштабируемость: гибкость методов предоставления ре- сурсов, обеспечивающая поддержку выделения дополнительных ин- формационных ресурсов при возрастании нагрузки на приложение. 55 При этом необходимо учитывать не только возможность кратковре- менного увеличения нагрузки на приложение но и планировать дол- госрочное увеличение производительности системы в результате по- стоянного прироста аудитории. В обоих случаях, необходимо обеспе- чить декомпозицию облачного приложения на отдельные модульные компоненты, которые могут быть распределены на несколько вычис- лительных устройств. 7. Монетизация: учет и биллинг ресурсов, затраченных на исполнение пользовательских задач. Это ключевой компонент мно- жества коммерческих приложений. Для организации качественного биллинга облачных платформ необходимо организовать сбор и предоставление полноценной информации о всевозможных ресурсах, затрачиваемых на решение пользовательских задач. Также, необхо- димо обеспечить пользователю возможность удобной и быстрой оплаты затраченных ресурсов. 8. Внедрение: процесс разработки нового облачного прило- жения, который включает в себя разработку, тестирования и внедре- ние в эксплуатацию. На этапе разработки облачного приложения требуется совсем небольшой объем вычислительных ресурсов, кото- рый значительно увеличивается при переходе к этапу нагрузочного тестирования и внедрения в эксплуатацию. При этом очевидно, что применение готовой облачной инфра- структуры позволяет значительно сократить издержки на разработку и внедрение высоко масштабируемого приложения, так как оплата использованных информационных ресурсов производится на основе модели коммунальных вычислений и не требует значительных инве- стиций в собственную инфраструктуру. Это позволяет минимизиро- вать начальные затраты и сконцентрировать финансирование на все- стороннем тестировании приложения. Но, не смотря на все перечисленные достоинства, необходимо оценить все возможные недостатки модели облачных вычислений, как то сложности организации репликации данных между сервисами, сложность отката на предыдущие версии при появлении неожидан- ных ошибок в процессе внедрения, необходимость аккуратного и все- 56 стороннего тестирования разработанных сервисов на совместимость данных и слаженность работы приложения. 9. Функционирование: мониторинг и поддержка приложе- ний, находящихся в стадии эксплуатации. Приложение, которое за- пущено в эксплуатацию, необходимо администрировать, что может оказаться чрезвычайно сложной задачей, если учесть большое число отдельных сервисов, составляющих облачное приложение. В связи с этим необходимо обеспечить интеграцию процессов администриро- вания и управления сервисами в виде единого «центра управления сервисами». Параллельно, в него можно включить мониторинг нагрузки приложения, панель управления пользовательскими задача- ми и т.п. Все вышеперечисленные компоненты облачного приложения должны быть запланированы с самого начала разработки для обеспе- чения высокого уровня масштабируемости и автоматизации. Достоинства и недостатки облачных вычислений Как ранее было описано, облачные вычисления ориентированы на предоставление информационных ресурсов на трех уровнях: уровне инфраструктур (IaaS), уровне платформ (PaaS) и уровне про- граммного обеспечения (SaaS). Предоставляя интерфейсы ко всем трем различным уровням, облака взаимодействуют с тремя различными типами потребителей. 1. Конечные пользователи, которые используют SaaS-решения через веб-браузер, или же какие-либо базовые ресурсы инфраструк- турного слоя которые предоставляются посредством слоя. 2. Корпоративные потребители, которые могут использовать все три слоя: IaaS – для того, чтобы расширить собственную про- граммно-аппаратную инфраструктуру или получить дополнительные вычислительные ресурсы по требованию; PaaS – для того, чтобы иметь возможность запуска собственных приложений в облаке; SaaS – для получения возможностей тех приложений, которые уже доступ- ны в облаке. 57 3. Разработчики и независимые поставщики программного обеспечения, разрабатывающие приложения, которые предоставля- ются в виде облачных SaaS-решений. Обычно, эта категория пользо- вателей напрямую взаимодействует со слоем PaaS, и уже через него, опосредованно, со слоем IaaS. С точки зрения пользователя, основное достоинство облачных вычислений – это модель оплаты ресурсов по мере их использования. Отсутствует необходимость предварительных инвестиций в инфра- структуру: нет необходимости инвестиций в лицензионное ПО, от- сутствует необходимость инвестиции в аппаратную инфраструктуру и связанные с этим затраты на обслуживание и персонал. Таким обра- зом, капитальные затраты превращаются в текущие расходы. Покупатели облачных сервисов используют только тот объем информационных ресурсов, который им на самом деле необходим, и оплачивают только тот объем информационных ресурсов, которыми они реально воспользовались. В то же время, они пользуются такими достоинствами облачных вычислений как масштабируемость и гиб- кость. Облачные вычисления позволяет легко и быстро предоставить необходимые вычислительные ресурсы по требованию. Тем не менее, существуют некоторые недостатки модели облач- ных вычислений, которые вытекают из одной очевидной особенности – облака обслуживают сразу множество различных клиентов. Пользо- ватель облачной платформы не знает, задачи каких пользователей бу- дут исполняться на том или ином сервере, входящем в облачную ин- фраструктуру. Типичное облако является внешним по отношению к внутренней инфраструктуре любой компании, то есть находится вне зоны ответственности администраторов и служб безопасности компа- нии-потребителя. В то время как для отдельного потребителя это может быть несущественным, крупные компании уделяют этому во- просу очень большое значение Пользователю приходится полагаться на обещания поставщика облачных решений в вопросах надежности, производительности и качества обслуживания инфраструктуры обла- ка. Использование облаков также сопряжено с высокими рисками 58 безопасности и защиты конфиденциальной информации. Это связано с двумя факторами: 1) необходимость загрузки и получения данных из облака; 2) хранение данных производится на базе удаленных хранилищ, в связи с чем владельцу информации приходится полагаться на гаран- тии поставщика облачных решений, что несанкционированного до- ступа к данным не произойдет. Более того, использование облаков требует определенных инвестиций в интеграцию собственной инфра- структуры и приложений в облако. В настоящее время нет стандартов для интерфейсов IaaS, PaaS и SaaS. В связи с этим выбор поставщика облачных решений становится довольно рискованным занятием. В связи с этим, необходимо всегда учитывать риски, связанные с использованием облаков. В каждом отдельном случае необходимо внимательно взвесить все потенциальные выгоды и угрозы при пере- ходе на облачную платформу. Также, необходимо решить какие дан- ные и какая обработка может производиться на базе «облачного аут- сорсинга», а какие данные лучше никогда не выводить за рамки ло- кальной сети организации. |