МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ федеральное государственное бюджетное образовательное учреждение
высшего образования «УЛЬЯНОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»
РАСПРЕДЕЛЕННЫЕ
ВЫЧИСЛЕНИЯ И ПРИЛОЖЕНИЯ
Учебное пособие
Составитель А.А. Романов
Ульяновск УлГТУ
2018
УДК 004.3(075.8) ББК 32.973-04я73
Р 24
Рецензенты: заместитель директора ООО «СимбирСофт» О. Ф. Власенко, заместитель директора по технологиям ООО СимбирСофт» В. В. Сычев.
Утверждено редакционно-издательским советом университета в качестве учебного пособия
Р 24 Распределенные вычисления и приложения: учебное пособие / составитель А.А. Романов. – Ульяновск : УлГТУ, 2018. – 151 с.
ISBN 978-5-9795-1802-2
Представлены разнообразные технологии кластерных и грид-
вычислений, по созданию многопоточных приложений, а также
содержится базовый материал по представлению моделей распределенных
вычислений. Пособие предназначено для студентов направлений 09.03.03
«Прикладная информатика», 09.03.04 «Программная инженерия»,
изучающих дисциплину «Распределенные вычисления и приложения».
УДК 004.3(075.8)
ББК 32.973-04я73
© Романов А. А., составление. 2018 ISBN 978-5-9795-1802-2 © Оформление. УлГТУ, 2018
3
Оглавление Введение ..................................................................................................... 4 1. Введение в распределенные вычисления ............................................ 5 1.1. Понятия распределенных вычислений и распределенной системы ....................................................................... 6 1.2. Признаки распределенных систем .................................................... 9 1.3. Требования к распределенным системам ....................................... 13 2. Взаимодействие в распределенных системах ................................... 26 2.1. Физическое время ............................................................................. 26 2.2. Синхронные и асинхронные распределенные системы ................ 29 2.3. Упорядочивание событий ................................................................ 33 2.4. Примитивы взаимодействия ............................................................ 35 2.5. Синхронный и асинхронный обмен сообщениями ....................... 46 3. Модель распределенного вычисления ............................................... 49 3.1. Модель распределенной системы ................................................... 49 4. Взаимное исключение в распределенных системах ......................... 59 4.1. Общие концепции ............................................................................. 60 4.2. Синхронизация в распределенных системах ................................. 64 5. Многопоточное программирование ................................................... 75 6. Кластерные вычисления ..................................................................... 81 6.1. Основные понятия MPI .................................................................... 84 7. Грид .................................................................................................... 111 8. Основы облачных технологий .......................................................... 123 8.1. Инфраструктура как сервис (IaaS) ................................................ 124 8.2. Платформа как сервис (PaaS) ........................................................ 126 8.3. Программное обеспечение как сервис (SaaS) .............................. 129 Сокращения ............................................................................................ 148 Список контрольных вопросов ............................................................ 148 Заключение ............................................................................................ 149 Библиографический список .................................................................. 150
4
Введение
В пособии представлены разнообразные технологии кластерных
и грид-вычислений, создания многопоточных приложений, а также
содержится базовый материал по представлению моделей
распределенных вычислений.
Материал содержит характеристику распределенных систем и
вычислений, даются основные понятия. Описываются базовые
модели взаимодействия в распределенных вычислениях. Приводятся
практические примеры по созданию распределенных вычислений.
Отдельно выделяются разделы для кластерных, грид и облачных
вычислений.
Пособие предназначено для студентов направления 09.03.04
«Программная инженерия», и направления 09.03.03 «Прикладная
информатика», изучающих дисциплину «Распределенные вычисления
и приложения».
5
1. Введение в распределенные вычисления
Сегодняшние реалии таковы, что разработка практически
любого программного обеспечения требует хороших знаний
параллельного и распределенного программирования. Обе эти
области объединяет то, что и параллельное, и распределенное
программное обеспечение состоит из нескольких процессов, которые
вместе решают одну общую задачу [2].
Однако отметим, что понятия параллельной и распределенной
обработки данных не являются эквивалентными. Действительно,
параллелизм подразумевает одновременное существование и
выполнение задач. Распределение же обозначает территориальную
удаленность процессов друг от друга. При этом задачи, связанные с
распределенной обработкой данных, могут выполняться несколькими
последовательными этапами в различные периоды времени. Конечно, в
некоторых случаях параллельная обработка данных может быть
эффективно реализована с помощью распределенного программного
обеспечения, особенно при проведении большого объема вычислений,
слабо связанных между собой [2].
Поэтому в общем случае распределенная обработка данных не
подразумевает параллелизма, но возможность «параллельного
использования» распределенных вычислительных систем существует.
Обратим внимание, что для совместной работы процессов им
необходим некоторый механизм взаимодействия. В мире параллельных
систем обычно считается, что взаимодействие процессов обеспечивается
с помощью разделяемых переменных. В этом случае один процесс
осуществляет запись в одну из таких переменных, а другой – считывает
записанное значение. В свою очередь в распределенных системах
процессы взаимодействуют путем пересылки сообщений. Поэтому для
обмена данными или координации совместных действий процессы
должны использовать механизмы отправки и приема сообщений.
6
1.1. Понятия распределенных вычислений и распределенной
системы
Область распределенных вычислений представляет собой раздел
теории вычислительных систем, изучающий теоретические вопросы
организации распределенных систем. Распределенные вычисления
иногда определяют в более узком смысле, как применение
распределенных систем для решения трудоемких вычислительных
задач. В таком контексте распределенные вычисления являются
частным случаем параллельных вычислений, т. е. одновременного
решения различных частей одной вычислительной задачи несколькими
вычислительными устройствами. Отметим, что при изучении
параллельных вычислений основной акцент обычно делается на
методах разделения решаемой задачи на подзадачи, которые могут
рассчитываться одновременно для максимального ускорения
вычислений. Основная же особенность в организации параллельных
вычислений с использованием распределенных систем будет
заключаться в необходимости учитывать различие характеристик
доступных вычислительных устройств и наличие существенной
временной задержки при обмене данными между ними [2].
В дальнейшем будем рассматривать распределенные
вычисления в широком смысле, как теоретическую основу для
построения распределенных систем обработки данных. Существует
множество определений распределенной системы, причем ни одно из
них не является строгим или общепринятым.
Весьма оригинальное определение принадлежит американскому
ученому в области теории вычислительных систем Лесли Лэмпорту
(Leslie Lamport). Согласно его утверждению, вы понимаете, что
пользуетесь распределенной системой, когда поломка компьютера, о
существовании которого вы даже не подозревали, приводит к
останову всей системы, а для вас – к невозможности выполнить свою
работу. Значительная часть распределенных систем, к сожалению,
7
удовлетворяет такому определению, однако, строго говоря, оно
относится только к системам с единой точкой отказа.
В свою очередь хорошо известный российской аудитории
профессор вычислительной техники Эндрю С. Таненбаум определяет
распределенную систему как набор независимых компьютеров,
представляющийся их пользователям единой объединенной системой.
Здесь необходимо обратить внимание на то, что сами по себе
независимые компьютеры не могут представляться пользователю
единой системой. Обеспечить это можно только с помощью
дополнительного специального программного обеспечения,
называемого программным обеспечением промежуточного уровня
(англ. middleware). Именно с его помощью пользователи полагают,
что имеют дело с единой системой, а все различия между
компьютерами и способы связи между ними остаются скрытыми для
пользователей.
Распределенная система – это такая система, в которой
взаимодействие и синхронизация программных компонентов,
выполняемых на независимых сетевых компьютерах, осуществляется
посредством передачи сообщений.
Распределенная система – набор независимых компьютеров, не
имеющих общей совместно используемой памяти и общего единого
времени (таймера) и взаимодействующих через коммуникационную
сеть посредством передачи сообщений, где каждый компьютер
использует свою собственную оперативную память и на котором
выполняется отдельный экземпляр своей операционной системы.
Однако эти операционные системы функционируют совместно,
предоставляя свои службы друг другу для решения общей задачи.
Термин «распределенная система» описывает широкий спектр
систем от слабо связанных многомашинных комплексов,
представляемых, например, набором персональных компьютеров,
объединенных в сеть, до сильно связанных многопроцессорных систем.
8
Мы будем рассматривать распределенную систему с аппаратной
точки зрения в виде совокупности взаимосвязанных автономных
компьютеров или процессоров, с программной точки зрения – в виде
совокупности независимых процессов (исполняемых программных
компонентов распределенной системы), взаимодействующих
посредством передачи сообщений для обмена данными и
координации своих действий.
Компьютеры, процессоры или процессы будем называть узлами
распределенной системы. Чтобы процессоры могли считаться
автономными, они должны, по меньшей мере, обладать собственным
независимым управлением. По этой причине параллельный
компьютер, архитектура которого устроена по схеме «одна команда
для многих данных» (англ. Single Instruction - Multiple Data, SIMD), не
может считаться распределенной системой.
Под независимостью процессов подразумевается тот факт, что
каждый процесс имеет свое собственное состояние, представляемое
набором данных, включающим текущие значения счетчика команд,
регистров и переменных, к которым процесс может обращаться и
которые может изменять. Состояние каждого процесса является
полностью закрытым для других процессов: другие процессы не
имеют к нему прямого доступа и не могут изменять его.
Скорости выполнения операций разных процессов в
распределенной системе различны и заранее неизвестны, а доставка
отправленных сообщений может занимать непредсказуемое время.
Поскольку в качестве узлов системы могут выступать процессы, под
приведенное нами определение подпадают также и программные
системы, представляющие собой совокупность взаимодействующих
процессов, выполняемых на одном и том же вычислительном
устройстве. В этой ситуации каналы взаимодействия,
осуществляющие передачу сообщений между процессами,
реализуются с помощью разделяемой памяти вместо сети связи.
9
Однако в большинстве случаев в распределенной системе все же
содержится несколько процессоров, взаимосвязанных друг с другом
при помощи средств коммуникации.
Типичная распределенная система представлена на рис. 1.
Рис.1. Распределенная система. ЦП – центральный процессор,
ОП – оперативная (основная) память
1.2. Признаки распределенных систем
Отсутствие единого времени для компонентов распределенной
системы. Это важное предположение для решения задач проектирования
и построения распределенных систем. Оно характеризует
территориальное распределение компонентов системы, а именно
процессоров, входящих в ее состав, но что более важно, из него следует
отсутствие синхронности в их работе [2].
Отсутствие общей памяти. Это ключевая характеристика, из
которой следует необходимость обмена сообщениями между
программными компонентами распределенной системы для их
взаимодействия и синхронизации. Кроме того, эта характеристика
10
подразумевает отсутствие единого для всех процессоров физического
времени. Здесь следует отметить, что некоторые распределенные
системы могут предоставлять своим пользователям абстракцию
единого адресного пространства для всех процессоров с помощью
механизмов распределенной разделяемой памяти (англ. Distributed
Shared Memory, DSM). В этом случае, если не рассматривать
сложности конкурентного доступа нескольких процессоров к одному
сегменту памяти, для каждого процессора распределенную
разделяемую память можно представлять как вполне нормальную
организацию виртуальной памяти, где в качестве временного
хранилища информации используется не собственный диск, а
оперативная память удаленного компьютера. В этой связи в
распределенных системах обычно рассматриваются различные
аспекты организации общей памяти в многопроцессорных системах.
Географическое распределение. Вполне естественно, что чем
более удалены процессоры друг от друга территориально, тем
очевиднее, что система будет рассматриваться как распределенная.
Однако совсем не обязательно, чтобы компьютеры были объединены в
глобальную вычислительную сеть (ГВС). В последнее время кластер из
обыкновенных рабочих станций (англ. Cluster Of Workstation, COW),
соединенных с помощью локальной вычислительной сети (ЛВС),
также все чаще рассматривается как небольшая распределенная
система. При этом все оборудование такой распределенной системы
может находиться в одном или нескольких соседних зданиях.
Подобные кластеры COW становятся все популярнее из-за
относительно низкой стоимости входящих в нее компонентов, с одной
стороны, и неплохой производительности – с другой.
Независимость и гетерогенность. Компьютеры, входящие в
состав распределенной системы, слабо связаны в том смысле, что они
могут иметь различный состав и различную производительность и,
следовательно, обеспечивать различное время выполнения
11
идентичных задач. Обычно они не являются частями одной
специализированной системы, но функционируют совместно,
предоставляя свои службы друг другу для выполнения общей задачи.
Более того, в общем случае на компьютерах, составляющих
распределенную систему, могут выполняться различные
операционные системы.
За последние несколько лет распределенные системы
становились все более популярными и их роль только возрастала.
Перечислим цели построения распределенных систем.
Географически распределенная вычислительная среда.
Сегодня в большинстве случаев сама вычислительная среда по своей
природе представляет собой территориально распределенную
систему. В качестве примера можно привести банковскую сеть.
Каждый банк обслуживает счета своих клиентов и обрабатывает
операции с ними. В случае же перевода денег из одного банка в
другой требуется осуществление межбанковской транзакции и
взаимодействие систем банков друг с другом. Другим примером
географически распределенной вычислительной среды является всем
хорошо знакомая сеть Интернет.
Требование увеличения производительности вычислений.
Быстродействие традиционных однопроцессорных систем
стремительно приближается к своему пределу. Различные
архитектуры (такие как суперскалярная архитектура, матричные и
векторные процессоры, однокристальные многопроцессорные
системы) призваны увеличивать производительность вычислительных
систем за счет различных механизмов параллельного исполнения
команд. Однако все эти приемы способны повысить
производительность максимум в десятки раз по сравнения с
классическими последовательными решениями. Кроме того,
масштабируемость подобных подходов оставляет желать лучшего.
Чтобы повысить производительность в сотни или тысячи раз и при
12
этом обеспечивать хорошую масштабируемость решения, необходимо
свести воедино многочисленные процессоры и обеспечить их
эффективное взаимодействие. Этот принцип реализуется в виде
больших многопроцессорных систем и многомашинных комплексов.
Совместное использование ресурсов. Важной целью создания
и использования распределенных систем является предоставление
пользователям (и приложениям) доступа к удаленным ресурсам и
обеспечение их совместного использования. В данной формулировке
термин «ресурс» относится как к компонентам аппаратного
обеспечения вычислительной системы, так и к программным
абстракциям, с которыми работает распределенная система.
Например, пользователь компьютера 1 может использовать дисковое
пространство компьютера 2 для хранения своих файлов. Или
приложение А может использовать свободную вычислительную
мощность нескольких компьютеров для ускорения собственных
расчетов. Распределенные базы данных и распределенные системы
объектов могут быть отличным примером совместного использования
программных компонентов, когда соответствующие программные
абстракции распределены по нескольким компьютерам и
согласованно обслуживаются несколькими процессами,
образующими распределенную систему.
Отказоустойчивость. В традиционных «нераспределенных»
вычислительных системах, построенных на базе единичного
компьютера (возможно высокопроизводительного), выход из строя
одного из его компонентов обычно приводит к неработоспособности
всей системы. Такой сбой в одном или нескольких компонентах
системы называют частичным отказом, если он не затрагивает
другие компоненты. Характерной чертой распределенных систем,
которая отличает их от единичных компьютеров, является
устойчивость к частичным отказам, т. е. система продолжает
функционировать после частичных отказов, правда, незначительно
13
снижая при этом общую производительность. Подобная возможность
достигается за счет избыточности, когда в систему добавляется
дополнительное оборудование (аппаратная избыточность) или
процессы (программная избыточность), которые делают возможной
правильное функционирование системы при неработоспособности
или некорректной работе некоторых из ее компонентов. В этом
случае распределенная система пытается скрывать факты отказов или
ошибок в одних процессах от других процессов.
1.3. Требования к распределенным системам
Эффективная распределенная система должна обладать
следующими свойствами: прозрачность (англ. transparency), открытость
(англ. openness), безопасность (англ. security), масштабирование (англ.
scalability). Однако стоит отметить, что, несмотря на кажущуюся
простоту и очевидность перечисленных свойств, их реализация на
практике часто представляет собой непростую задачу [2].
Прозрачность (Transparency)
Под прозрачностью распределенной системы понимают ее
способность скрывать свою распределенную природу, а именно,
распределение процессов и ресурсов по множеству компьютеров, и
представляться для пользователей и разработчиков приложений в
виде единой централизованной компьютерной системы. Стандарты
эталонной модели для распределенной обработки в открытых
системах Reference Model for Open Distributed Processing (RM-ODP)
определяют несколько типов прозрачности:
- прозрачность доступа (англ. access transparency). Вне зависимости
от способов доступа к ресурсам и их внутреннего представления,
обращения к локальным и удаленным ресурсам осуществляется
одинаковым образом. На базовом уровне скрывается разница
архитектур вычислительных платформ, но, что более важно,
достигается соглашение о том, как ресурсы разнородных машин
14
будут представляться пользователям распределенной системы
единым образом. В качестве примера можно привести прикладной
программный интерфейс (англ. application programming interface, API)
для работы с файлами, хранящимися на множестве компьютеров
различных архитектур, который предоставляет одинаковые вызовы
операций как с локальными, так и с удаленными файлами;
- прозрачность местоположения (англ. location transparency).
Позволяет обращаться к ресурсам без знания их физического
местоположения. В этом случае имя запрашиваемого ресурса не
должно давать никакого представления о том, где ресурс расположен.
Поэтому важную роль для обеспечения прозрачности
местоположения играет именование ресурсов. Например, чтобы
отправить электронное сообщение на адрес [email protected], не
требуется знать физического местоположения получателя, его
почтового ящика или почтового сервера. В свою очередь обращение к
файлу \\server\foo подразумевает знание имени сервера, на котором он
расположен, а значит, не является полностью прозрачным с точки
зрения местоположения;
- прозрачность перемещения (англ. migration transparency).
Перемещение ресурса или процесса в другое физическое
местоположение остается незаметным для пользователя
распределенной системы. Здесь стоит отметить, что выполнение
требования прозрачности местоположения не гарантирует
прозрачности перемещения. Другими словами, если распределенная
система скрывает местоположение ресурса, это не означает, что его
можно сменить незаметно для пользователя. Например,
распределенные файловые системы позволяют монтировать файловые
системы удаленных компьютеров в локальное пространство имен
клиента, предоставляя единое дерево каталогов и тем самым
обеспечивая прозрачность местоположения. Однако если файлы на
удаленных компьютерах будут перемещены в другое место, в
15
большей части распределенных файловых систем они станут
недоступны для пользователя;
- прозрачность смены местоположения (англ. relocation
transparency). Более строгое по отношению к предыдущему
требование скрыть факт перемещения ресурса во время его
использования. Примером могут служить мобильные пользователи,
использующие сотовые телефоны. В этом случае, если рассматривать
вызывающего абонента в качестве пользователя распределенной
системы, а вызываемого – в качестве ее ресурса, то система будет
прозрачной с точки зрения смены местоположения. Действительно,
перемещение «ресурса» из соты в соту в процессе разговора остается
незаметным для звонящего;
- прозрачность репликации (англ. replication transparency).
Если для повышения доступности или увеличения производительности
используется несколько копий ресурса (реплик), этот факт остается
скрытым от пользователя, и он полагает, что в системе присутствует
только один экземпляр ресурса. Для обеспечения прозрачности
репликации необходимо, чтобы все реплики имели одно и то же имя,
очевидно, не зависящее от местоположения копии ресурса. Таким
образом, системы, которые обеспечивают прозрачность репликации,
также должны поддерживать и прозрачность местоположения;
- прозрачность одновременного доступа (англ. concurrency
transparency). Позволяет нескольким пользователям (конкурирующим
процессам) одновременно выполнять операции над общим, совместно
используемым ресурсом без взаимного влияния друг на друга. Иначе
говоря, скрывается факт использования ресурса другими
пользователями (процессами). Стоит отметить, что сам ресурс должен
оставаться в непротиворечивом состоянии, что может достигаться,
например, с помощью механизма блокировок, когда пользователи
(процессы) по очереди получают исключительные права на
запрашиваемый ресурс;
16
- прозрачность отказов (англ. failure transparency).
Подразумевается, что система должна пытаться скрывать частичные
отказы, позволяя пользователям и приложениям выполнить свою работу
вне зависимости от сбоев в аппаратных или программных компонентах
распределенной системы, а также скрывать факт их последующего
восстановления. В связи с тем, что любой процесс, компьютер или
сетевое соединение могут отказывать независимо от других в
произвольные моменты времени, каждый компонент распределенной
системы должен быть готов к сбоям в других компонентах и
обрабатывать подобные ситуации соответствующим образом.
Важно отметить, что степень, до которой каждое из
перечисленных выше свойств должно быть выполнено, может сильно
варьироваться в зависимости от задач построения распределенной
системы. Действительно, полностью скрыть распределение процессов
и ресурсов вряд ли удастся. Из-за ограничения в скорости передачи
сигнала, задержка на обращение к ресурсам, территориально
удаленным от клиента, всегда будет больше, чем к ресурсам,
расположенным поблизости. Поэтому не каждая система в состоянии
скрывать все свои особенности от пользователя. Обычно это
утверждение выражается в поиске компромисса между
прозрачностью распределенной системы и ее производительностью.
Например, если для повышения отказоустойчивости в системе
присутствуют географически распределенные копии ресурса, то
поддержка их идентичного состояния для обеспечения прозрачности
репликации потребует гораздо большего времени выполнения каждой
операции обновления. Другими словами, каждая операция
обновления должна будет распространиться на все реплики до того,
как будет разрешена следующая операция с данным ресурсом.
Открытость (Openness).
Согласно определению, принятому комитетом IEEE POSIX
1003.0, открытая система – это система, реализующая открытые
17
спецификации (стандарты) на интерфейсы, службы и
поддерживаемые форматы данных, достаточные для того, чтобы
обеспечить:
- возможность переноса разработанного прикладного
программного обеспечения на широкий диапазон систем с
минимальными изменениями (мобильность приложений,
переносимость);
- совместную работу (взаимодействие) с другими прикладными
приложениями на локальных и удаленных платформах
(интероперабельность, способность к взаимодействию);
- взаимодействие с пользователями в стиле, облегчающим
последним переход от системы к системе (мобильность
пользователя).
Ключевой момент в этом определении – использование понятия
«открытая спецификация», которое, в свою очередь, определяется как
общедоступная спецификация, которая поддерживается открытым,
гласным согласительным процессом, направленным на постоянную
адаптацию к новым технологиям, и соответствует стандартам.
Согласно этому определению открытая спецификация не зависит от
конкретной технологии, т. е. не зависит от конкретных технических и
программных средств или продуктов отдельных производителей.
Открытая спецификация одинаково доступна любой
заинтересованной стороне. Более того, открытая спецификация
находится под контролем общественного мнения, поэтому
заинтересованные стороны могут принимать участие в ее развитии.
В контексте распределенных систем приведенное выше
определение означает, что свойство открытости не может быть
достигнуто, если спецификация и описание ключевых интерфейсов
программных компонентов системы не доступны для разработчиков.
Одним словом, ключевые интерфейсы должны быть описаны и
опубликованы. Важно отметить, что здесь в первую очередь
18
подразумеваются интерфейсы внутренних компонентов системы, а не
только интерфейсы верхнего уровня, с которыми работают
пользователи и приложения. При этом синтаксис интерфейсов, т. е.
имена доступных функций, типы передаваемых параметров,
возвращаемых значений и т. п., обычно описывается посредством
языка определения интерфейсов (англ. Interface Definition Language,
IDL). В свою очередь семантика интерфейсов, т. е. то, что на самом
деле делают службы, предоставляющие эти интерфейсы, обычно
задается неформально, с помощью естественного языка.
Подобное описание позволяет произвольному процессу,
нуждающемуся в определенной службе, обратиться к другому
процессу, реализующему эту службу, через соответствующий
интерфейс. Кроме того, такой подход позволяет создавать несколько
различных реализаций одной и той же службы, которые с точки
зрения внешних процессов будут работать абсолютно одинаково.
Как следствие, несколько реализаций программных компонентов
(возможно, от различных производителей) могут взаимодействовать и
работать совместно, образуя единую распределенную систему. Таким
образом, достигается свойство интероперабельности или, другими
словами, способности к взаимодействию. Более того, в этом случае
прикладное приложение, разработанное для распределенной системы
A, может без изменений выполняться в распределенной системе B,
реализующей те же интерфейсы, что и А. То есть достигается
свойство переносимости.
Еще одно важное преимущество заключается в том, что
открытая распределенная система потенциально может быть
образована из разнородного аппаратного и программного
обеспечения (опять-таки, возможно, от разных производителей).
При этом добавление новых компонентов или замена существующих
может осуществляться относительно легко, не затрагивая других
компонентов. На аппаратном уровне это выражается в способности
19
простого подключения к системе дополнительных компьютеров или
замены существующих на более мощные. На программном – в
возможности простого внедрения новых служб или новых реализаций
уже существующих. Другими словами, важным свойством открытой
распределенной системы является расширяемость.
Масштабируемость
В общем случае масштабируемость определяют как способность
вычислительной системы эффективно справляться с увеличением
числа пользователей или поддерживаемых ресурсов без потери
производительности и без увеличения административной нагрузки на
ее управление. При этом систему называют масштабируемой, если
она способна увеличивать свою производительность при добавлении
новых аппаратных средств, т. е. под масштабируемостью понимают
способность системы расти вместе с ростом нагрузки на нее.
Масштабируемость является важным свойством вычислительных
систем, если им может потребоваться работать под большой
нагрузкой, поскольку это означает, что вам не придется начинать с
нуля и создавать абсолютно новую информационную систему.
Для распределенных систем обычно выделяют несколько
параметров, характеризующих их масштаб: количество пользователей
и количество компонентов, составляющих систему, степень
территориальной отдаленности сетевых компьютеров системы друг
от друга и количество административных организаций,
обслуживающих части распределенной системы.
Поэтому масштабируемость распределенных систем также
определяют по соответствующим направлениям:
- нагрузочная масштабируемость. Способность системы
увеличивать свою производительность при увеличении нагрузки
путем замены существующих аппаратных компонентов на более
мощные или путем добавления новых аппаратных средств. При этом
первый случай увеличения производительности каждого компонента
20
системы с целью повышения общей производительности называют
вертикальным масштабированием, а второй, выражающийся в
увеличении количества сетевых компьютеров (серверов)
распределенной системы – горизонтальным масштабированием;
- географическая масштабируемость. Способность системы
сохранять свои основные характеристики, такие как
производительность, простота и удобство использования, при
территориальном разнесении ее компонентов от более локального
взаимного расположения до более распределенного;
- административная масштабируемость. Характеризует простоту
управления системой при увеличении количества административно
независимых организаций, обслуживающих части одной
распределенной системы.
Сложности масштабирования
Построение масштабируемых систем подразумевает решение
широкого круга задач и часто сталкивается с ограничениями
реализованных в вычислительных системах централизованных служб,
данных и алгоритмов. А именно, многие службы централизованы в
том смысле, что они реализованы в виде единственного процесса и
могут выполняться только на одном компьютере (сервере). Проблема
такого подхода заключается в том, что при увеличении числа
пользователей или приложений, использующих эту службу, сервер,
на котором она выполняется, станет узким местом и будет
ограничивать общую производительность. Если даже предположить
возможность неограниченного увеличения мощности такого сервера
(вертикальное масштабирование), то тогда ограничивающим
фактором станет пропускная способность линий связи, соединяющих
его с остальными компонентами распределенной системы.
Аналогично, централизация данных требует централизованной
обработки, приводя к тем же самым ограничениям.
21
В качестве примера преимуществ децентрализованного подхода
можно привести службу доменных имен (англ. Domain Name Service,
DNS), которая на сегодняшний день является одной из самых больших
распределенных систем именования. Служба DNS используется в
первую очередь для поиска IP-адресов по доменному имени и
обрабатывает миллионы запросов с компьютеров по всему миру. При
этом распределенная база данных DNS поддерживается с помощью
иерархии DNS-серверов, взаимодействующих по определенному
протоколу. Если бы все данные DNS централизовано хранились бы на
единственном сервере, и каждый запрос на интерпретацию доменного
имени передавался бы на этот сервер, воспользоваться такой системой
в масштабах всего мира было бы невозможно.
Отдельно стоит отметить ограничения, создаваемые
применением централизованных алгоритмов. Дело в том, что
централизованные алгоритмы для своей работы требуют получения
всех входных данных и только после этого производят
соответствующие операции над ними, а уже затем распространяют
результаты всем заинтересованным сторонам. С этой точки зрения
проблемы использования централизованных алгоритмов
эквивалентны рассмотренным выше проблемам централизации служб
и данных. Поэтому для достижения хорошей масштабируемости
следует применять распределенные алгоритмы, предусматривающие
параллельное выполнение частей одного и того же алгоритма
независимыми процессами.
В отличие от централизованных алгоритмов, распределенные
алгоритмы обладают следующими свойствами, которые на самом
деле значительно усложняют их проектирование и реализацию:
- отсутствие знания глобального состояния. Как уже было
сказано, централизованные алгоритмы обладают полной
информацией о состоянии всей системы и определяют следующие
действия, исходя из ее текущего состояния. В свою очередь, каждый
22
процесс, реализующий часть распределенного алгоритма, имеет
непосредственный доступ только к своему состоянию, но не к
глобальному состоянию всей системы. Соответственно, процессы
принимают решения только на основе своей локальной информации.
Следует отметить, что информацию о состоянии других процессов в
распределенной системе каждый процесс может получить только из
пришедших сообщений, и эта информация может оказаться
устаревшей на момент получения. Аналогичная ситуация имеет место
в астрономии: знания об изучаемом объекте (звезде/галактике)
формируются на основании светового и прочего электромагнитного
излучения, и это излучение дает представление о состоянии объекта в
прошлом. Например, знания об объекте, находящемся на расстоянии
пяти тысяч световых лет, являются устаревшими на пять тысяч лет;
- отсутствие общего единого времени. События,
составляющие ход выполнения централизованного алгоритма
полностью упорядочены: для любой пары событий можно с
уверенностью утверждать, что одно из них произошло раньше
другого. При выполнении распределенного алгоритма вследствие
отсутствия единого для всех процессов времени, события нельзя
считать полностью упорядоченными: для некоторых пар событий
мы можем утверждать, какое из них произошло раньше другого,
для других – нет;
- отсутствие детерминизма. Централизованный алгоритм чаще
всего определяется как строго детерминированная последовательность
действий, описывающая процесс преобразования объекта из начального
состояния в конечное. Если запускать централизованный алгоритм на
выполнение с одним и тем же набором входных данных, будем
получать один и тот же результат и одинаковую последовательность
переходов из состояния в состояние. В свою очередь выполнение
распределенного алгоритма носит недетерминированный характер из-за
независимого исполнения процессов с различной и неизвестной
23
скоростью, а также из-за случайных задержек передачи сообщений
между ними. Поэтому, несмотря на то, что для распределенных систем
может быть определено понятие глобального состояния, выполнение
распределенного алгоритма может лишь ограниченно рассматриваться
как переход из одного глобального состояния в другое;
- устойчивость к отказам. Сбой в любом из процессов или
каналов связи не должен вызывать нарушения работы
распределенного алгоритма;
- для обеспечения географической масштабируемости
требуются свои подходы. Одна из основных причин плохой
географической масштабируемости многих распределенных систем,
разработанных для локальных сетей, заключается в том, что в их
основе лежит принцип синхронной связи (англ. synchronous
communication). В этом виде связи клиент, вызывающий какую-либо
службу сервера, блокируется до получения ответа. Это неплохо
работает, когда взаимодействие между процессами происходит
быстро и незаметно для пользователя. Однако при увеличении
задержки на обращение к удаленной службе в глобальной системе
подобный подход становится все менее привлекательным и, очень
часто, абсолютно неприемлемым. Другая сложность обеспечения
географической масштабируемости состоит в том, что связь в
глобальных сетях по своей природе ненадежна и взаимодействие
процессов практически всегда является двухточечным (англ.
point-to-point). В свою очередь, связь в локальных сетях является
высоконадежной и подразумевает использование
широковещательных сообщений, что значительно упрощает
разработку распределенных приложений. Например, если процессу
требуется обнаружить адрес другого процесса, предоставляющего
определенную службу, в локальных сетях ему достаточно разослать
широковещательное сообщение с просьбой для искомого процесса
откликнуться на него. Все процессы получают и обрабатывают это
24
сообщение. Но только процесс, предоставляющий требуемую службу,
отвечает на полученную просьбу, указывая свой адрес в ответном
сообщении. Очевидно, подобное взаимодействие перегружает сеть, и
использовать его в глобальных сетях нереально.
Технологии масштабирования
В большинстве случаев сложности масштабирования проявляются
в проблемах с эффективностью функционирования распределенных
систем, вызванных ограниченной производительностью ее отдельных
компонентов: серверов и сетевых соединений. Существуют несколько
основных технологий, позволяющих уменьшить нагрузку на каждый
компонент распределенной системы. К таким технологиям обычно
относят распространение (англ. distribution), репликацию (англ.
replication) и кэширование (англ. caching).
Распространение предполагает разбиение множества
поддерживаемых ресурсов на части с последующим разнесением этих
частей по компонентам системы. Простым примером
распространения может служить распределенная файловая система
при условии, что каждый файловый сервер обслуживает свой набор
файлов из общего адресного пространства. Другим примером может
являться уже упоминавшаяся служба доменных имен DNS, в которой
все пространство DNS-имен разбивается на зоны, и имена каждой
зоны обслуживаются отдельным DNS-сервером.
Важную роль в обеспечении масштабируемости играют
репликация и кэширование. Репликация не только повышает
доступность ресурсов в случае возникновения частичного отказа, но и
помогает балансировать нагрузку между компонентами системы, тем
самым увеличивая производительность. Кэширование представляет
собой особую форму репликации, когда копия ресурса создается в
непосредственной близости от пользователя, использующего этот
ресурс. Разница заключается лишь в том, что репликация
инициируется владельцем ресурса, а кэширование – пользователем
25
при обращении к этому ресурсу. Однако стоит отметить, что наличие
нескольких копий ресурса приводит к другим сложностям, а именно к
необходимости обеспечивать их непротиворечивость (англ.
consistency), что, в свою очередь, может отрицательно сказаться на
масштабируемости системы.
Таким образом, распространение и репликация позволяют
распределить поступающие в систему запросы по нескольким ее
компонентам, в то время как кэширование уменьшает количество
повторных обращений к одному и тому же ресурсу.
Кэширование призвано не только снижать нагрузку на
компоненты распределенной системы, но и позволяет скрывать от
пользователя задержки коммуникации при обращении к удаленным
ресурсам. Подобные технологии, скрывающие задержки коммуникации,
важны для достижения географической масштабируемости системы.
К ним, в частности, еще можно отнести механизмы асинхронной связи
(англ. asynchronous communication), в которых клиент не блокируется
при обращении к удаленной службе, а получает возможность
продолжить свою работу сразу после обращения. Позже, когда будет
получен ответ, клиентский процесс сможет прерваться и вызвать
специальный обработчик для завершения операции.
Однако асинхронная связь применима не всегда. Например, в
интерактивных приложениях пользователь вынужден ожидать
реакции системы. В таких случаях можно воспользоваться
технологиями переноса кода, когда часть кода приложения
загружается на сторону клиента и исполняется локально для
обеспечения быстрого отклика на действия пользователя.
Преимущество подобных решений заключается в том, что они
позволяют сократить количество сетевых взаимодействий и снизить
зависимость работы приложения от случайных задержек обмена
сообщениями через сеть. В настоящее время перенос кода широко
используется в Интернете в форме апплетов Java и Javascript.
26
2. Взаимодействие в распределенных системах
2.1. Физическое время
В распределенных системах вычисления осуществляются
совокупностью независимых процессов, взаимодействующих
посредством передачи сообщений для обмена данными и
координации своих действий. Время, затрачиваемое каждым
процессом на выполнение отдельных действий, различно для разных
процессов и заранее неизвестно, а доставка отправленных сообщений
занимает непредсказуемое время. Поэтому точность, с которой
независимые процессы могут координировать свои действия,
ограничена такими временными задержками и сложностью
представления единого времени среди всех компьютеров в
распределенной системе [2].
Каждый из компьютеров в распределенной системе имеет свои
собственные часы, точнее говоря, системный таймер, который
используется его локальными процессами для получения текущего
времени. Поэтому два процесса, выполняющиеся на различных
компьютерах, могут ассоциировать соответствующую отметку
времени с каждым событием. Однако даже если эти процессы будут
считывать показания своих часов в одно и то же время, возвращаемые
значения, скорее всего, будут отличаться. Дело в том, что ни одни
часы не являются идеальными: кварцевые генераторы, составляющие
основу часов для современных компьютеров, не могут иметь
абсолютно одинаковую частоту, что ведет к постепенной потере
синхронизации и возвращении таймерами различных значений при
обращении к ним. Эта разница в показаниях часов называется
рассинхронизацией часов (англ. clock skew), а скорость отклонения
часов от точных показаний универсального скоординированного
времени UTC (Coordinated Universal Time) с течением времени –
скоростью дрейфа (англ. clock drift rate) (см. рис. 2).
27
Рис. 2. Соотношение времени по часам компьютеров и времени UTC;
δ – рассинхронизация часов, Δ – скорость дрейфа
Таким образом, даже если в какой-то момент на часах всех
компьютеров, входящих в распределенную систему, установлено одно
и то же значение, с течением времени их показания станут
существенно отличаться, если не предпринимать никаких
дополнительных мер. В результате приложения, которые ожидают,
что временная отметка, ассоциируемая с тем или иным событием,
корректна и не зависит от компьютера, на которой она
регистрировалась (т. е. часы которого использовались), могут
работать неправильно. Чтобы пояснить это приведем следующий
пример [2].
Банковская система. Рассмотрим задачу подсчета полной
суммы денег, находящихся на счетах в разных филиалах банка.
Предположим, что банковская система не позволяет вносить
дополнительные денежные средства на счет филиала и снимать их
наличными, а лишь осуществляет перевод различных сумм из одного
филиала банка в другой с помощью сообщений.
Для иллюстрации работы такой банковской системы
воспользуемся графиками процессов и событий, представленными на
28
рис. 3. Горизонтальными линиями на этих графиках изображены
временные оси. Точка на оси соответствует событию (например,
внутреннему событию процесса, событию отправки или приема
сообщения). Квадрат, обведенный вокруг точки, обозначает
состояние локального процесса (определяемого состоянием счета
данного филиала) в фиксированный момент времени,
соответствующий этой точке. Стрелкой обозначается передача
сообщения от одного процесса другому.
(а)
(б)
(в)
Рис. 3. Пример определения суммы денег на счетах банка.
Чтобы определить полную сумму, банк должен иметь сведения
о количестве денег в каждом из филиалов. Предположим, что
требуется подсчитать денежные средства в 9:00 – время, известное
всем процессам. В случае, показанном на рис. 3а, сумма окажется
равной $10. Однако возможна также ситуация, представленная на рис. 3б,
в которой на момент определения полной суммы денежные средства
29
филиала А находятся в состоянии передачи в филиал В, т. е. деньги
уже отправлены филиалом А, но еще не получены филиалом В.
В этом случае будет получен неправильный результат, равный $0.
Эту проблему можно решить, изучая все сообщения, находящиеся в
состоянии передачи в момент подсчета денег. Например, можно
потребовать от филиала А хранить записи обо всех отправленных
переводах и их получателях, а от филиала В хранить записи о всех
полученных переводах и их отправителях. Тогда в «состояние»
филиала нужно включить не только информацию о количестве денег
на его счете, но и указанные записи обо всех отправленных и
полученных денежных переводах. Проверяя такие «состояния»
процессов, система обнаружит перевод, покинувший филиал А, но
еще не полученный филиалом В, и соответствующие средства можно
будет добавить в общую сумму. Важно отметить, что денежные
средства, уже полученные филиалом В, отдельно учитывать не
нужно, т. к. они будут отражены в счете этого филиала.
К сожалению, подход, представленный выше, не гарантирует
вычисление верного результата. В примере, приведенном на рис. 3в,
часы в разных филиалах идут с некоторым относительным сдвигом,
т. е. имеет место небольшая рассинхронизация часов. Проверка
состояния счета филиала А в момент времени 9:00 дает результат,
равный $10. Впоследствии, в 9:01 по часам филиала А, эти деньги
переводятся в филиал В, часы которого на момент их получения
показывают 8:59. Поэтому при подсчете общей суммы по состоянию
на 9:00 эти денежные средства будут учитываться дважды.
2.2. Синхронные и асинхронные распределенные системы
В распределенных системах практически невозможно
предсказать время выполнения отдельных действий различных
процессов, скорость отклонения их локальных часов от точных
показаний или задержку доставки сообщения от одного процесса к
30
другому. В этой связи выделяют две диаметрально противоположные
модели вычислительных систем: первая накладывает строгие
временные ограничения на соответствующие характеристики, во
второй не делается никаких предположений относительно времени [2].
Синхронные распределенные системы. Синхронные
распределенные системы это системы, в которых определены
следующие временные ограничения.
Время выполнения каждого отдельного действия любого
процесса ограничено снизу и сверху известными значениями.
Задержка доставки каждого сообщения от одного процесса к
другому не превышает известный предел.
Каждый процесс имеет свои локальные часы со скоростью
отклонения от точных показаний, не превышающей известное
значение.
Важно отметить, что для большинства случаев, скорее всего,
можно дать некоторые оценки перечисленным временным
характеристикам. Однако если на практике все же невозможно
гарантировать их выполнение, например, обеспечить доставку всех
сообщений в пределах заданного времени, то любые системы или
алгоритмы, построенные на основе предполагаемых значений
представленных выше ограничений, не будут работать в случае их
нарушения.
Благодаря скоординированной работе всех процессов в
синхронных системах разрабатывать и отлаживать алгоритмы
взаимодействия для этой модели вычислительных систем гораздо
проще. Например, в синхронных системах возможно использование
таймаутов для определения отказа одного из процессов.
Асинхронные распределенные системы. Многие из
распределенных систем, например, построенные на базе сети
Интернет, по своей природе не являются синхронными. Поэтому
очень часто используется другая модель асинхронные
31
распределенные системы, в которых не накладывается никаких
ограничений на рассматриваемые характеристики, перечисленные
ниже.
Скорость выполнения операций: время выполнения каждого
отдельного действия любого процесса конечно, но не имеет известной
верхней границы;
Задержка доставки сообщений: сообщение может быть
доставлено через произвольное, но конечное время после его
отправки. Например, сообщение от процесса A к процессу B может
быть доставлено за несколько миллисекунд, а сообщение от процесса
B к процессу C - за несколько минут;
Скорость отклонения часов также может быть произвольной.
Основная причина асинхронности большинства распределенных
систем кроется в совместном использовании несколькими процессами
одного процессора и несколькими логическими каналами связи
одного физического соединения. Соответственно в случае, когда
слишком много процессов неизвестной природы и поведения
работают на одном и том же процессоре, результирующая
производительность любого из них не может быть гарантирована. Это
в точности описывает работу приложений в сети Интернет, где, по
сути, нагрузка на сервера и сетевые соединения никак не ограничена.
Поэтому, к примеру, нельзя предсказать, сколько времени займет
передача файла по протоколу FTP с сервера на компьютер
пользователя. Необходимо отметить, что наибольший вклад в
задержку доставки сообщения оказывает не собственно время
распространения сигнала, а время, затрачиваемое различными
уровнями стека протоколов на обработку операций отправки и
получения, а также задержка, вносимая промежуточными узлами на
пути передачи сообщения.
Преимущество асинхронной модели заключается в том, что
построенные на ее основе распределенные системы и алгоритмы
32
являются более устойчивыми к изменению условий их
функционирования и, как следствие, оказываются более
универсальными. Однако существует множество архитектурных и
алгоритмических проблем, которые не могут быть разрешены в
предположении асинхронной модели, в то время как они имеют
решение для синхронных систем. Рассмотрим следующий пример
задачи двух генералов, призванный проиллюстрировать сложности
достижения соглашения в асинхронных системах.
Соглашение в задаче двух генералов. Две армии, каждая
руководимая своим генералом, готовятся к штурму города. Лагери
обеих армий располагаются на двух холмах, разделенных долиной.
Единственным способом связи между генералами является отправка
посыльных с сообщениями через долину. Коммуникацию будем
считать надежной, т. е. посыльные не могут быть перехвачены и
уничтожены противником. Для успешного штурма генералы должны
атаковать город вместе. При этом им необходимо согласовать, кто из
них будет возглавлять штурм, и в какое время необходимо его
начинать.
Легко увидеть, что даже в асинхронной системе, генералы могут
прийти к соглашению, кто из них будет возглавлять штурм.
Например, каждый из генералов отправляет другому посыльного с
информацией о количестве солдат, входящих в его армию. Тот
генерал, у которого солдат в армии больше, и будет возглавлять
штурм (в случае, если в армиях одинаковое количество солдат, есть
договоренность, что возглавлять штурм будет генерал из первой
армии). Но открытым остается вопрос, когда начинать штурм? К
сожалению, в асинхронных системах посыльные могут добираться до
другой армии сколь угодно долго. Предположим, первый генерал
отправляет второму сообщение «Атакуем!» Второй может так и не
получить это сообщение, скажем, в течение 3 часов, или, все же,
посыльный добрался до него за 10 минут? В синхронных системах
33
проблема по-прежнему остается, но генералы уже обладают
некоторой дополнительной информацией: посыльный доберется до
другой армии за время, не меньшее, чем min минут, и не
превышающее max минут. Поэтому, в этом случае первый генерал
может отправить сообщение «Атакуем!», подождать min минут и
выступать в атаку. Вторая армия после получения сообщения может
подождать 1 минуту и тоже выступать в атаку. При этом
гарантируется, что вторая армия выступит после первой руководящей
армии, но придет вслед за ней не более чем через (max – min + 1)
минут.
2.3. Упорядочивание событий
Очень часто имеет значение не точное время наступления того
или иного события (например, события отправки или получения
сообщения), а порядок, в котором эти события происходили,
т. е. требуется определить, произошло ли данное событие в данном
процессе до или после другого события в другом процессе. В этих
случаях выполнение процессов можно описывать в терминах
последовательности событий в условиях отсутствия знания точного
времени их происхождения.
Рассмотрим следующий пример групповой рассылки сообщений
электронной почты между пользователями A, B, C и Х. Пользователь
А отправляет всей группе письмо с темой «Общее собрание».
Пользователи В и С отвечают на него всей группе своими
сообщениями с темой «Re: Общее собрание».
В действительности события происходят в такой
последовательности:
1. Первым отправляется сообщение от пользователя А.
2. Пользователь В получает его, читает и отправляет ответ.
3. Пользователь С получает оба сообщения от А и В и затем
отправляет свой ответ, опирающийся на оба сообщения от А и В.
34
Однако в связи с произвольными и независимыми задержками
доставки сообщений, некоторые пользователи могут видеть другую
последовательность наступления событий. Например, согласно
сценарию, приведенному на рис. 4, в почтовом ящике пользователя Х
сообщения будут располагаться в следующем порядке:
1. Сообщение от пользователя С с темой «Re: Общее
собрание».
2. Сообщение от пользователя А с темой «Общее собрание».
3. Сообщение от пользователя В с темой «Re: Общее
собрание»
Рис. 4. Порядок сообщений, наблюдаемый различными пользователями
В случае, если часы компьютеров пользователей А, В и С можно
было бы точно синхронизировать, каждое отправляемое сообщение
могло бы содержать отметку времени отправки согласно локальным
часам компьютера-отправителя. Для нашего примера, сообщения m1, m2 и
m3 содержали бы в себе отметки времени t1, t2 и t3, где t1<t2<t3. Тогда в
почтовом ящике пользователя Х полученные сообщения можно было
бы отображать согласно порядку, задаваемому их временными
отметками.
Однако, как уже обсуждалось, в распределенных системах часы
не могут быть синхронизированы с абсолютной точностью.
35
Если рассинхронизация часов невелика, то описанный выше подход с
использованием отметок реального времени в большинстве случаев
будет давать верный результат. Но не всегда. Для преодоления
проблем, связанных с использованием реального времени, Л. Лэмпорт
предложил модель логических часов (англ. logical clock),
отсчитывающих логическое время (англ. logical time), которая может
быть применена для упорядочивания событий, происходящих в
различных процессах распределенной системы. Логическое время
позволяет определить порядок событий (или порядок сообщений для
рассматриваемого примера рассылки электронной почты) без
обращения к часам компьютеров. Вопросы, связанные с моделью
логического времени, мы рассмотрим далее в соответствующем
разделе.
2.4. Примитивы взаимодействия
Базовыми примитивами взаимодействия в распределенных
системах являются примитивы send() и receive(), позволяющие
соответственно отправлять и принимать сообщения. В простейшем
случае примитив send() имеет по меньшей мере три параметра:
идентификатор процесса-получателя сообщения, указатель на буфер с
передаваемыми данными в адресном пространстве процесса-
отправителя и количество передаваемых элементов данных
конкретного типа. Например, функция отправки данных может иметь
следующий вид: send(void *sendbuf, int count, int dest),
где sendbuf – указывает на буфер, содержащий передаваемые
данные; count – содержит количество передаваемых элементов
данных; dest – идентифицирует процесс-получатель.
В свою очередь вызов receive() также должен содержать как
минимум три аргумента: идентификатор процесса-отправителя, от
которого разрешается принимать сообщения (возможно
36
использование значения, позволяющего принимать сообщения от
любого процесса), указатель на буфер в адресном пространстве
процесса-получателя, куда следует помещать принимаемые данные, и
количество принимаемых элементов данных: receive(void *recvbuf, int count, int source),
где recvbuf – указывает на буфер, сохраняющий принимаемые
данные; count – содержит количество принимаемых элементов
данных; source – идентифицирует процесс-отправитель.
Для анализа работы команд send() и receive() рассмотрим
следующий пример кода, в котором процесс P1 отправляет сообщение
процессу P2, а процесс P2 выводит полученное сообщение в
стандартный выходной поток.
P1 P2
a = 100;
send(&a, 1, 2);
a = 0;
receive(&a, 1, 1);
printf("%d\n", a);
Стоит обратить внимание, что процесс P1 изменяет значение
переменной «a» сразу после команды send(). Очевидно, что семантика
операции send() должна обеспечивать получение процессом P2 значения
100, а не нуля. Другими словами, процесс P2 должен получить значение
переменной «a» на момент вызова команды send(). В то же время
большинство современных компьютерных архитектур доверяют
функции приема-передачи данных сетевым интерфейсам и не
подразумевают участия центрального процессора (ЦП) в пересылке
данных. В результате, если команда send() попросту дает задание
коммуникационной подсистеме на отправку данных и сразу же
возвращает управление вызвавшему ее процессу, не исключены
ситуации, когда процесс P2 получит значение ноль вместо ожидаемого
100.
37
Простым решением указанной проблемы является возврат
управления в отправляющий процесс P1 только тогда, когда он не
окажет влияния на семантику передачи данных. Важно отметить, что
под этим не обязательно подразумевается возвращение в вызвавший
процесс только после того, как принимающий процесс получит все
передаваемые данные. Это всего лишь означает, что отправитель
блокируется до момента, когда выполнение семантики операции
send() сможет быть гарантировано вне зависимости от дальнейшего
хода выполнения приложения. Существуют два механизма
обеспечения этого требования.
Блокирующие операции отправки/получения без буферизации.
В этом случае возврат из команды send() не осуществляется до тех
пор, пока не будет вызвана соответствующая команда receive() в
принимающем процессе и пока все данные не будут переданы
процессу-получателю.
Подобный механизм взаимодействия обычно подразумевает
дополнительный обмен сигналами для установления связи (англ.
handshake) между отправляющим и принимающим процессами.
Когда процесс-отправитель достигает состояния готовности к обмену
данными, он отправляет запрос на передачу данных процессу-
получателю и переходит в состояние ожидания до тех пор, пока не
получит от него соответствующего ответа. Процесс-получатель
отвечает на данный запрос только после того, как он сам достигнет
состояния готовности к приему данных и вызовет команду receive().
Собственно передачу данных процесс-отправитель начинает только
после получения ответа от принимающего процесса, что
свидетельствует о готовности последнего к приему данных.
Описанная схема взаимодействия представлена на рис. 5, где А –
передающий процесс, а В – принимающий процесс, и носит название
блокирующей отправки/получения без буферизации, т. к. в этом случае
38
не используется никаких дополнительных буферов, как на стороне
отправителя, так и на стороне получателя.
(в) Рис. 5. Механизм блокирующей отправки/ получения без буферизации;
(а) первым осуществляется вызов send(),
(б) вызовы send() и receive() происходят практически одновременно,
(в) первым осуществляется вызов receive()
Из рис. 5 видно, что блокирующая отправка/ получение без
буферизации неплохо работает, когда команды send() и receive()
вызываются приблизительно в одно и то же время. Однако в
асинхронных системах достичь подобной синхронности в действиях
нескольких процессов практически невозможно. Поэтому накладные
расходы, связанные с ожиданием и соответствующим простоем процессов,
становятся основным недостатком данного механизма
взаимодействия.
Кроме того, при использовании блокирующей
отправки/получения без буферизации возможны ситуации,
39
приводящие к взаимной блокировке процессов, или тупиковой
ситуации (англ. deadlock). Рассмотрим следующий простой пример
обмена сообщениями, демонстрирующий возникновение тупиковой
ситуации:
P1 P2
send(&a, 1, 2);
receive(&b, 1, 2);
send(&a, 1, 1);
receive(&b, 1, 1);
Приведенный выше фрагмент кода призван обеспечить
передачу значений переменных «а» между процессами P1 и P2. Однако
в случае, если команды send() и receive() реализованы согласно
механизму блокирующей отправки/ получения без буферизации, то
примитив send() в процессе P1 будет ожидать вызова соответствующей
команды receive() в процессе P2, а примитив send() в процессе P2 будет
ожидать вызова receive() в P1. В результате оба процесса будут
находиться в состоянии ожидания и оказываются заблокированными
навсегда.
Блокирующие операции буферизованной отправки/получения.
Простым решением проблем, связанных с возникновением взаимных
блокировок, указанных выше, и простоем процессов, ожидающих
готовности к приему-передаче данных от других процессов, является
использование дополнительных буферов на отправляющей и
принимающей стороне. В этом случае передаваемые данные просто
копируются из буфера процесса-отправителя в дополнительный
буфер отправки (обычно размещаемый в адресном пространстве
операционной системы). При этом команда send() возвращает
управление вызвавшему ее процессу сразу после того как завершится
операция копирования, и процесс-отправитель сможет продолжать
свою работу, т. к. любые изменения данных с его стороны уже не
будут влиять на семантику передачи сообщения.
40
Стоить отметить, что принимаемые данные не могут быть
сохранены непосредственно в адресном пространстве процесса-
получателя, пока он не будет готов к приему и не вызовет команду
receive(). Иначе его нормальное исполнение может быть нарушено.
Поэтому наличие дополнительного буфера приема на стороне
получателя, куда следует помещать принимаемые данные, также
является обязательным. Когда же процесс-получатель достигнет
состояния готовности к приему данных, он вызовет команду receive(),
которая проверит буфер приема, и если в нем находится новое
сообщение, скопирует его содержимое в целевой буфер в адресном
пространстве принимающего процесса.
Описанная выше схема взаимодействия опирается на наличие
двух дополнительных буферов отправки и приема, соответственно, на
стороне отправителя и на стороне получателя. Кроме того,
подразумевается, что сам обмен данными осуществляется
специальной коммуникационной подсистемой, работающей
независимо от исполняемых процессов. Если подобные средства
недоступны, то проблемы блокирующей отправки/получения без
буферизации могут быть решены путем введения только одного
буфера, располагающегося на одной стороне, например, на стороне
получателя. В этом случае операция send() должна будет прервать
работу принимающего процесса, оба процесса должны будут
самостоятельно осуществить передачу и сохранение данных в
дополнительный буфер приема на стороне получателя, после чего
процесс-получатель продолжит работу. В дальнейшем, когда
принимающий процесс вызовет команду receive(), данные будут
скопированы из буфера приема в целевой буфер в адресном
пространстве получателя.
Механизм блокирующего буферизованного взаимодействия для
случая двух дополнительных буферов отправки и приема
иллюстрируется рис. 6.
41
(а) (б) Рис. 6. Механизм блокирующей буферизованной отправки/ получения;
(а) первым осуществляется вызов send(),
(б) первым осуществляется вызов receive()
При использовании механизма буферизованной отправки и
получения вместо издержек, вызванных простоем процессов,
ожидающих приема или передачи данных, появляются накладные
расходы, связанные с выделением дополнительной памяти,
копированием данных в буфер/из буфера, управлением
дополнительными буферами. В случае, когда распределенная система
является синхронной (т. е. когда команды send() и receive()
вызываются приблизительно в одно и то же время), отправка и
получение данных без буферизации может быть даже более
эффективной и производительной, чем буферизованная передача.
Для более общего случая асинхронных систем буферизованное
взаимодействие будет являться предпочтительным до тех пор, пока
емкость буфера не станет ограничивающим фактором. Для понимания
влияния буферов конечного размера на передачу сообщений
рассмотрим следующий пример:
42
P1 P2
for (i = 0; i < 1000; i++){
produce_data(&a);
send(&a, 1, 2);
}
for (i = 0; i < 1000; i++){
receive(&a, 1, 1);
consume_data(&a);
}
В этом фрагменте кода процесс P1 производит 1000
элементов данных, а процесс P2 потребляет их. Предположим, что
процесс P2 исполняется существенно медленнее, чем процесс P1.
Если в дополнительных буферах отправки и приема достаточно
места для размещения всех производимых элементов данных, то
оба процесса могут выполняться без проблем. Если свободного
пространства в буфере недостаточно, возникает ситуация
переполнения буфера. В зависимости от реализации команды send(),
она может либо вернуть ошибку вызвавшему процессу, либо
заблокировать отправителя до тех пор, пока не будет вызвана
соответствующая команда receive(), освобождающая место в буфере.
В первом случае ответственность за обработку таких ошибочных
ситуаций ложится на разработчика ПО, и в приложении должны быть
реализованы дополнительные механизмы синхронизации между
отправляющим и принимающим процессами. Во втором случае
возможная блокировка отправляющего процесса может приводить к
непредсказуемому снижению производительности системы. Поэтому
хорошим правилом является написание программ с ограниченными
требованиями к размеру буферов.
В то время как буферизация помогает избежать многих
тупиковых ситуаций при исполнении процессов, написание кода,
приводящего к взаимным блокировкам, все равно остается
возможным. Дело в том, что как и в случае взаимодействия без
буферизации, вызовы команды receive() по-прежнему являются
блокирующими для сохранения семантики передачи сообщений.
Поэтому фрагмент кода, представленный ниже, приведет к взаимной
43
блокировке, т. к. оба процесса будут ожидать поступления данных, но ни
один из них не будет их передавать:
P1 P2
receive(&a, 1, 2);
send(&b, 1, 2);
receive(&a, 1, 1);
send(&b, 1, 1);
Стоит еще раз отметить, что в данном примере взаимная
блокировка вызвана ожиданием завершения команд receive().
Тупиковые ситуации также могут возникать при использовании
команды send(), блокирующей отправителя до вызова
соответствующей команды receive(), в случае если свободного
пространства в буфере оказывается недостаточно. Еще раз
рассмотрим пример обмена сообщениями между двумя процессами:
P1 P2
send(&a, 1, 2);
receive(&b, 1, 2);
send(&a, 1, 1);
receive(&b, 1, 1);
Команда send() вернет управление вызывающему процессу,
когда передаваемые данные будут скопированы из памяти процесса-
отправителя в дополнительный буфер отправки. Если хотя бы одно
сообщение сможет быть скопировано в дополнительный буфер
отправки, то представленный выше код выполнится успешно.
Если же свободного пространства в обоих буферах окажется
недостаточно, возникнет взаимная блокировка процессов. Как и в
предыдущем случае блокирующей отправки/получения без
буферизации, подобные ситуации циклического ожидания должны
быть распознаны и разрешены.
Стоит отметить, что возникновение взаимных блокировок при
использовании блокирующих примитивов взаимодействия – явление
нередкое, и предотвращение подобного циклического ожидания
требует аккуратности и внимательности от разработчиков ПО.
44
Неблокирующие операции отправки/получения. При использовании
блокирующих примитивов взаимодействия семантика операции
передачи данных обеспечивается либо за счет простоя процессов при
обмене данными, либо за счет использования дополнительных
буферов. Инициируемый такими операциями переход процесса в
следующее состояние после отправки или получения сообщения
завершается до того, как процессу возвращается управление. Поэтому
блокирующие операции send() и receive() можно считать атомарными.
В некоторых случаях ответственность за обеспечение семантики
передачи данных можно переложить на разработчика ПО и, тем
самым, обеспечить быстрое выполнение операций send() и receive()
без дополнительных издержек. Для таких неблокирующих
примитивов отправки/ получения возврат управления в исполняемый
процесс осуществляется сразу после вызова соответствующей
команды и, следовательно, до того, как выполнение семантики
передачи данных может быть гарантировано, и до того, как процесс
перейдет в состояние после отправки или получения сообщения.
Другими словами, вызов команды send() и receive() лишь начинает
соответствующую операцию. Поэтому разработчик должен
внимательно следить за тем, чтобы его код не изменял отправляемые
данные и не использовал принимаемые данные, до завершения
команд send() и receive().
Неблокирующие операции отправки/получения дополняются
командами, позволяющими проверить признак их завершения. Сразу
после вызова неблокирующей операции send() или receive()
исполнение процесса будет безопасным, если оно не зависит от
передаваемых или получаемых данных. Позже процесс сможет
проверить, завершено ли выполнение неблокирующей операции
отправки или приема, и при необходимости дождаться ее завершения.
Таким образом, при правильном использовании неблокирующие
45
примитивы позволяют скрыть издержки обмена данными за счет
других вычислений.
Как показано на рис. 7, существуют механизмы неблокирующей
отправки/получения как без буферизации, так и с использованием
дополнительных буферов на стороне отправителя и/или на стороне
получателя.
(а) (б)
Рис. 7. Механизмы неблокирующей отправки/получения;
(а) без буферизации, (б) с использованием буферов
В случае взаимодействия без буферизации, процесс-отправитель
направляет получателю запрос на передачу данных и продолжает
свою работу. Этот запрос будет ожидать от процесса-получателя
готовности к приему данных и соответствующего вызова команды
receive(), после чего начнется собственно передача данных.
Взаимодействующие процессы смогут узнать об окончании сетевого
обмена и, следовательно, о возможности работать с передаваемыми и
принимаемыми данными без риска их повреждения с помощью
команд, проверяющих признак завершения операций send() или
receive(). Эта ситуация иллюстрируется рис. 7а.
46
В случае буферизованного взаимодействия, отправитель
инициирует копирование передаваемых данных из своего буфера в
дополнительный буфер отправки и сразу продолжает работать. При этом
дальнейшая обработка передаваемых данных процессом-
отправителем становится безопасной в момент завершения операции
копирования. На стороне получателя команда receive() инициирует
перемещение данных из дополнительного буфера приема в адресное
пространство получателя и возвращает управление в вызвавший
процесс. Стоит отметить, что возращение управления произойдет
даже в том случае, если данные еще не поступили от отправителя в
дополнительный буфер приема. При этом запрос от команды receive()
будет ожидать поступления данных. Как видно из рис. 7,
использование механизма неблокирующей буферизованной отправки/
получения позволяет уменьшить время, в течение которого работа с
передаваемыми и принимаемыми данными является небезопасной.
Таким образом, блокирующие примитивы взаимодействия
обеспечивают простоту программирования и гарантируют
выполнение семантики передачи данных, в то время как
неблокирующие операции применимы для увеличения
производительности компьютерных систем за счет маскирования
издержек обмена данными. Однако в последнем случае
разработчикам ПО приходится следить за тем, чтобы приложение не
обращалось к передаваемым и принимаемым данным до завершения
операций отправки или приема. Поэтому большинство современных
библиотек, реализующих операции обмена сообщениями, обычно
предоставляют как блокирующие, так и неблокирующие примитивы.
2.5. Синхронный и асинхронный обмен сообщениями
Основной смысл определения блокирующих и неблокирующих
операций отправки и приема данных заключается в описании
локального поведения вызывающего процесса без учета хода
47
выполнения других процессов. А именно, блокирующие примитивы
возвращают управление вызывающему процессу при завершении
копирования данных из адресного пространства процесса-
отправителя или в адресное пространство процесса-получателя,
неблокирующие – лишь начинают соответствующую операцию.
Имеет смысл рассматривать взаимодействие также с глобальной
точки зрения. В этом контексте различают синхронный и
асинхронный механизм обмена сообщениями [2].
Синхронный обмен сообщениями. При синхронном обмене
сообщениями отправитель и получатель дожидаются друг друга для
передачи каждого сообщения, и операция отправки считается
завершенной только после того, как получатель закончит прием
сообщения.
Завершение синхронной операции send() свидетельствует не
только о том, что семантика передачи данных оказывается
обеспеченной, но и о том, что получатель достиг определенной точки
в ходе своего выполнения, а именно, вызова соответствующей
операции receive(). Поэтому процессы не только обмениваются
данными, но и синхронизируют свое выполнение во времени.
Другое преимущество синхронного обмена сообщениями
заключается в том, что для передачи сообщения не требуется
использования дополнительных буферов, т. к. синхронная операция
send() все равно не сможет завершиться, пока не будет вызвана
соответствующая операция receive(). Хотя, конечно, возможна
реализации этих примитивов и с использованием буферизации.
Важно отметить, что синхронная операция receive() после получения
сообщения должна отослать соответствующее подтверждение (англ.
acknowledgement) отправителю для завершения операции send().
В случае использования блокирующих примитивов
взаимодействия передача сообщения с помощью пары вызовов send()
и receive() может рассматриваться как одна атомарная операция.
48
Асинхронный обмен сообщениями. При асинхронном обмене
сообщениями не происходит никакой координации между
отправителем и получателем сообщения. Для завершения операции
send() отправителю не требуется дожидаться приема сообщения
процессом-получателем. При отправке нового сообщения
отправителю неизвестно, получено ли его предыдущее сообщение,
направленное этому же или, возможно, другому получателю.
Поэтому, если канал связи между отправителем и получателем не
сохраняет порядок передаваемых по нему сообщений, т. е. не
обеспечивает свойство FIFO (англ. First In First Out), получатель
может принимать сообщения в другом порядке, нежели они были
переданы отправителем. Асинхронной операции receive() нет
необходимости отсылать отправителю подтверждение (англ.
acknowledgement) о приеме сообщения.
Преимуществом асинхронного обмена сообщениями является
возможность перекрывать вычисления отправителя и получателя во
времени, т. к. процессы не будут ожидать друг друга для передачи
каждого сообщения.
В связи с тем, что отправка и прием сообщения не
синхронизированы во времени, передача сообщения с помощью
блокирующих примитивов требует наличия дополнительных
буферов для размещения отправленных, но еще не полученных
сообщений. Как уже обсуждалось, в этом случае необходимо
определить поведение операции send() в ситуациях переполнения
буфера. Если блокировать отправителя до освобождения
требуемого пространства, то непредсказуемо может возникнуть
ситуация взаимной блокировки процессов. Если сообщение
отбрасывать, то коммуникацию нельзя считать надежной.
49
3. Модель распределенного вычисления
Для изучения различных аспектов функционирования
распределенных систем часто используют несколько моделей
распределенной обработки данных. При этом та или иная модель
выбирается в зависимости от исследуемой задачи из области
распределенных вычислений.
Распределенное вычисление удобно рассматривать в виде
совокупности дискретных событий, каждое из которых вызывает
небольшое изменение состояния всей системы. Система становится
«распределенной» благодаря тому обстоятельству, что каждое
событие приводит к изменению только части глобального состояния
всей системы. А именно, при наступлении события изменяется лишь
локальное состояние одного процесса и, возможно, состояние одного
или нескольких каналов связи (или локальные состояния некоторого
подмножества процессов, взаимодействующих при помощи
синхронного механизма обмена сообщениями) [2].
В данном разделе мы представим модель распределенной
обработки данных и несколько основных понятий и концепций,
которые будут использованы в дальнейшем. Будем рассматривать
асинхронные распределенные системы, в которых процессы
взаимодействуют с помощью асинхронного механизма обмена
сообщениями. Описание модели и доказательство утверждений
проводится до определенной степени неформально, но на уровне,
достаточном для понимания существенных особенностей
функционирования распределенных систем, выделяющих их среди
систем других классов.
3.1. Модель распределенной системы
Распределенная система состоит из конечного множества N
независимых процессов {P1, P2, … PN}. Если процесс Pi может
50
напрямую отправлять сообщения процессу Pj, то мы будем говорить,
что между процессом Pi и процессом Pj имеется канал Cij.
Для удобства все каналы будем считать однонаправленными.
Чтобы два процесса имели возможность обмениваться сообщениями,
между ними необходимо установить два разнонаправленных канала,
каждый из которых служит для передачи сообщений в одном
направлении. Структуру распределенной системы можно представить
в виде ориентированного графа, в котором вершины графа
соответствуют процессам, а ребра – каналам связи между процессами.
Указанный граф также называется топологией сети распределенной
системы. Далее, если не оговорено противное, мы будем подразумевать,
что топология является полносвязной, т. е. любые две вершины
соединены ребром, и каждый процесс может непосредственно
взаимодействовать со всеми другими процессами.
Состояние канала С определяется совокупностью сообщений
отправленных по этому каналу, но еще не полученных принимающим
процессом. (Внутреннее) состояние процесса Р по-своему
формализуется в контексте каждой решаемой задачи. Неформально
можно сказать, что в своем состоянии процесс фиксирует свое
«концентрированное прошлое», т. е. все существенные для
рассматриваемой задачи аспекты своего предыдущего выполнения.
Кроме того, состояние процесса – это характеристика, однозначно
определяющая его дальнейшее поведение, все последующие реакции
на внешние события. В общем случае состояние процесса
определяется текущими значениями его счетчика команд, регистров и
переменных.
Теоретическую модель процесса определим в виде множества
его возможных состояний (англ. states), некоторого подмножества
этого множества, элементы которого называются начальными
состояниями (англ. initial states), и множества дискретных событий
(англ. events). Событие е, происходящее в процессе Р, представляет
51
собой атомарное действие, которое может изменить состояние самого
процесса Р и состояние канала С, инцидентного этому процессу:
состояние С будет изменено при отправке сообщения по этому каналу
(если ребро, соответствующее С, направлено от вершины с процессом
Р) или при получении сообщения из этого канала (если ребро,
соответствующее С, направлено к вершине с процессом Р). Поэтому
все события могут быть классифицированы как внутренние события
(англ. internal events), события отправки (англ. send events) и события
получения сообщения (англ. receive events). Следует отметить, что в
качестве одного атомарного события также часто рассматривают
отправку сразу нескольких сообщений по нескольким каналам связи,
инцидентным Р, например, при широковещательной или групповой
рассылке. При этом для удобства будем полагать, что получение
сообщения не может совпадать с отправкой или получением других
сообщений в виде одного события.
Событие е определяется:
(1) процессом Р, в котором оно произошло;
(2) состоянием s процесса Р непосредственно перед событием е;
(3) состоянием s' процесса Р непосредственно после события е;
(4) каналом С, состояние которого изменяется при
наступлении события е;
(5) сообщением m, отправленным по каналу С (если ребро,
соответствующее С, направлено от вершины с процессом Р), или
полученным из канала С (если ребро, соответствующее С, направлено
к вершине с процессом Р). Поэтому событие е мы будем определять
как пятерку (Р, s, s', m, С), где m и С принимают специальное
значение null, в случае, когда событие е не изменяет состояние ни
одного из каналов связи. Множество событий процесса P линейно
упорядочено согласно порядку их наступления. Через eix обозначим x-е
по порядку событие в процессе Pi, 1 ≤ i ≤ N. Будем опускать верхний
или нижний индекс, когда его значение очевидно из контекста, или
52
когда его употребление не имеет смысла. Запись eix(s) будет
обозначать состояние s', в которое переходит процесс Pi из состояния
s при наступлении события eix.
Выполнением (англ. run, execution) процесса Pi называется
последовательность событий ei0, ei
1, … eix, ei
x+1, … в которой si0 –
начальное состояние процесса Pi и для каждого x ≥ 0 выполняется
соотношение six+1 = ei
x(six). Выполнение процесса Pi будем обозначать
через Ri:
Ri = (Ei, →i),
где Ei – множество событий процесса Pi, а бинарное отношение
→i задает линейный порядок на этом множестве согласно порядку
наступления событий в Pi. Запись ei →i ei' обозначает, что событие ei
предшествует ei' в выполнении процесса Pi.
Нас, однако, будет интересовать не выполнение отдельного
процесса, а выполнение всей распределенной системы в целом.
Глобальное состояние S (англ. global state) распределенной
системы определяется состояниями всех процессов и всех каналов,
входящих в ее состав. Начальными глобальными состояниями (англ.
initial global state) считаются все те состояния, в которых все
процессы пребывают в своих начальных состояниях, а каналы связи –
пусты. Функционирование распределенной системы порождает
множество распределенных событий, происходящих в процессах, и
оказывающих влияние только на часть глобального состояния
системы.
Обозначим через E =Ei множество всех событий,
происходящих при выполнении распределенной системы. Событие,
такое что е = (Р, s, s', m, С), считается допустимым в глобальном
состоянии S тогда и только тогда, когда (1) в глобальном состоянии S
процесс Р находится в состоянии s ,и (2), если ребро,
соответствующее каналу С, направлено к вершине с процессом Р, и
сообщение m находится в канале С и может быть принято из него.
53
Обозначим через e(S) глобальное состояние распределенной системы
непосредственно после наступления события e в глобальном
состоянии S. Состояние e(S) определено только в случае, если
событие е допустимо в глобальном состоянии S. Тогда e(S) будет
отличаться от состояния S только состоянием процесса Р и,
возможно, состоянием канала С.
1. В глобальном состоянии e(S) процесс Р будет находиться в
состоянии s'.
2. Если ребро, соответствующее каналу С, направлено к вершине
с процессом Р, то в глобальном состоянии e(S) состояние канала С будет
совпадать с его состоянием в S за исключением сообщения m,
удаленного из этого канала.
3. Если ребро, соответствующее каналу С, направлено от
вершины с процессом Р, то в глобальном состоянии e(S) состояние
канала С будет совпадать с его состоянием в S за исключением
сообщения m, добавленного в этот канал.
Последовательность событий e0, e1, … ex, ex+1, … будем называть
выполнением распределенной системы тогда и только тогда, когда
событие ex допустимо в глобальном состоянии Sx, S0 – начальное
глобальное состояние распределенной системы, и для каждого x ≥ 0
выполняется соотношение Sx+1 = ex(Sx). Выполнение всей
распределенной системы будем обозначать через R. Глобальное
состояние S называется достижимым в выполнении R, если для этой
последовательности событий существует такое k ≥ 0, что ek(Sk) = S.
Для иллюстрации выполнения распределенной системы
рассмотрим следующий пример передачи маркера (англ. token). Пусть
распределенная система состоит из двух процессов Р1 и Р2 и двух
каналов С12 и С21, рис. 8.
Рис. 8. Пример распределенной системы из двух процессов
54
Маркер – это уникальный объект, который процессы передают
друг другу с помощью сообщения. Каждый процесс может
находиться в одном из двух состояний s или s', где s – состояние, в
котором процесс не владеет маркером, а s' – состояние, в котором
процесс обладает маркером. Пусть начальное состояние процесса Р1 –
s', а начальное состояние процесса Р2 – s, т. е. маркер находится в
процессе Р1. В каждом процессе могут происходить только два
события: (1) событие отправки маркера по каналу с переходом
процесса из состояния s' в состояние s, и (2) событие получения
маркера из канала с переходом процесса из состояния s в s'.
Диаграмма переходов процесса из одного состояния в другое
показана на рис. 9.
Рис. 9. Диаграмма состояний процесса.
Глобальные состояния распределенной системы и переходы
между ними представлены на рис. 10. На этой диаграмме
выполнению распределенной системы соответствует путь из
начального глобального состояния S0 в одно из других глобальных
состояний S. Примерами выполнения распределенной системы могут
служить такие последовательности событий: (1) пустая
последовательность или (2) последовательность «Р1 отправляет маркер,
Р2 получает маркер, Р2 отправляет маркер». Последовательность «Р1
отправляет маркер, Р2 отправляет маркер» не может являться
выполнением распределенной системы, т. к. событие «Р2 отправляет
55
маркер» недопустимо в глобальном состоянии, в котором Р2
находится в состоянии s.
Рис. 10. Глобальные состояния и переходы между ними
В представленном выше примере передачи маркера в каждом
глобальном состоянии распределенной системы допустимо ровно
одно событие. Для иллюстрации недетерминированного выполнения
распределенных систем рассмотрим систему с такой же топологией
(см.рис. 8), но в которой состояния процессов Р1 и Р2 и переходы между
ними определяются согласно рис. 11. Начальное состояние процесса
Р1 – s1, начальное состояние процесса Р2 – s2.
Получение сообщения т' Получение сообщения т
(а) (б) Рис. 11. Диаграмма состояний (а) процесса Р 1 и (б) процесса Р2
56
Пример выполнения такой системы показан на рис. 12. Можно
увидеть, что в некоторых глобальных состояниях допустимо более
одного события и, соответственно, более одного перехода из этого
глобального состояния.
Рис. 12. Глобальные состояния и переходы между ними
Например, в начальном глобальном состоянии S0 могут
произойти оба события «Р1 отправляет m» и «Р2 отправляет m'».
Важно отметить, что глобальные состояния, в которые система
может перейти из состояния S0 при наступлении одного из этих
событий, различны. А именно, при наступлении события «Р1
отправляет m» система перейдет из состояния S0 в состояние S1, в
котором Р1 находится в состоянии s1', Р2 – в состоянии s2, канал С12
содержит сообщение m, а канал С21 пуст. В свою очередь при
наступлении события «Р2 отправляет m'» система перейдет из
состояния S0 в другое глобальное состояние S1', в котором Р1
находится в состоянии s1, Р2 – в состоянии s2', канал С12 пуст, а канал С21
содержит сообщение m'. Поэтому выполнение такой распределенной
системы может представлять собой другую по сравнению с рис. 12
57
последовательность событий и, как следствие, последовательность
других глобальных состояний.
Справедливость (англ. fairness). При исследовании поведения
распределенных систем часто возникает необходимость ограничиться
рассмотрением только так называемых справедливых выполнений
(англ. fair executions). Условия слабой справедливости позволяют
исключить из рассмотрения такие выполнения, в которых некоторые
события оказываются постоянно допустимыми для бесконечного
числа идущих подряд глобальных состояний, но при этом ни разу не
происходят в виде переходов из этих состояний из-за того, что
выполнение продолжается всякий раз за счет других допустимых
событий. Условия сильной справедливости позволяют исключить из
рассмотрения такие выполнения, в которых некоторые события
оказываются бесконечно часто допустимыми для глобальных
состояний в выполнении, но при этом ни разу не происходят в виде
переходов из этих состояний из-за того, что выполнение
продолжается всякий раз за счет других допустимых событий.
Другими словами, выполнение считается слабо справедливым, если
ни одно событие не может оставаться постоянно допустимым без
того, чтобы, в конце концов, не произойти в виде перехода.
Выполнение считается сильно справедливым, если ни одно событие не
может оказываться допустимым бесконечно часто без того, чтобы, в
конце концов, не произойти в виде перехода.
Безопасность (англ. safety) и живучесть (англ. liveness). При разработке
распределенного алгоритма, решающего ту или иную задачу,
необходимо показать, что полученный алгоритм действительно
представляет собой корректное решение поставленной задачи.
Существуют два фундаментальных типа свойств, проверяемых для
подтверждения корректности распределенного алгоритма:
безопасность и живучесть.
58
Неформально можно сказать, что алгоритм удовлетворяет
свойству безопасности, если «что-то плохое никогда не случается».
Другими словами, условие безопасности требует, чтобы определенное
утверждение оставалось истинным в каждом достижимом
глобальном состоянии в любом выполнении. Для иллюстрации этого
требования можно привести пример системы управления сигналами
светофоров; тогда требование безопасности будет выражаться в том, что
при любом распределении сигналов светофоров одновременное
движение по пересекающимся направлениям на перекрестке должно
быть запрещено.
Однако из того, что в системе не может произойти ничего
плохого, совсем не следует, что в ней может случиться что-то
хорошее. Так, программные системы, которые ничего не делают,
всегда удовлетворяют требованиям безопасности: в них ничего не
происходит, и, как следствие, ничего плохого тоже не случается.
Или, например, для системы управления сигналами светофоров
требование безопасности можно выполнить путем разрешения
проезда только в одном направлении и полного запрещения
движения в другом.
Таким образом, требования безопасности должны
сопровождаться требованиями прогресса вычислительной системы в
нужном направлении. Такие требования называются живучестью.
Неформально можно сказать, что алгоритм удовлетворяет свойству
живучести, если «что-то хорошее рано или поздно случится».
Другими словами, условие живучести требует, чтобы определенное
утверждение становилось истинным хотя бы в одном достижимом
глобальном состоянии в любом выполнении. Для нашего примера
системы управления сигналами светофоров это свойство должно
выражаться в обеспечении возможности проехать по любому
направлению на перекрестке.
59
4. Взаимное исключение в распределенных системах
Процессам распределенной системы часто приходиться
координировать свои действия. Например, они могут соревноваться за
возможность работы с разделяемыми ресурсами, требующими
эксклюзивного доступа. Для организации такой работы, во-первых,
нужно в коде каждого процесса выделять некоторую его часть,
называемую критической секцией (англ. critical section), в которой
есть обращения к таким ресурсам [2].
Во-вторых, необходимо реализовать тот или иной механизм
взаимного исключения (англ. mutual exclusion), выражающийся в
удовлетворении следующего основного требования: во время
выполнения критической секции одного процесса с обращениями к
разделяемым ресурсам ни один другой процесс не должен
выполняться в своей критической секции, работающей с любым из
этих ресурсов. В некоторых случаях совместно используемые ресурсы
управляются специализированными процессами (серверами),
которые, в том числе, обеспечивают взаимное исключение при
доступе к управляемым ресурсам со стороны других процессов
(клиентов). Однако бывают ситуации, когда равноправные процессы
должны координировать обращения к общему ресурсу
самостоятельно между собой. В таких случаях требуются отдельные
механизмы взаимного исключения, независимые от конкретной схемы
управления ресурсами. Отсутствие общей памяти в распределенных
системах не позволяет использовать разделяемые переменные (такие
как семафоры) для решения рассматриваемой задачи: распределенные
алгоритмы взаимного исключения должны опираться исключительно
на обмен сообщениями между процессами.
Разработка таких алгоритмов осложняется тем, что приходится
иметь дело с произвольными задержками передачи сообщений и
отсутствием полной информации о состоянии всей системы. Также не
60
делается никаких предположений об относительной скорости
выполнения процессов и об их количестве.
4.1. Общие концепции
При рассмотрении распределенных алгоритмов взаимного
исключения будем оставаться в рамках следующих допущений:
процессы выполняются и взаимодействуют асинхронно, ни один
из процессов не выходит из строя,
все каналы связи являются надежными и коммуникационная
сеть не разбивается на несвязанные друг с другом части.
Не будем делать никаких предположений о том, являются ли
каналы между процессами очередями (FIFO) или нет (non-FIFO).
Требование к свойству очередности каналов будет определяться
отдельно для каждого обсуждаемого алгоритма. Также будем
полагать, что обращения к разделяемым ресурсам происходят из
одной единственной критической секции. Распространение
представленных ниже алгоритмов на случаи работы с более чем одной
критической секцией не вызывает затруднений. С позиции
организации работы с разделяемыми ресурсами в коде каждого процесса
можно выделить следующие части: (1) критическая секция, в которой
есть обращения к разделяемым ресурсам, и (2) предшествующая и
последующая части кода, где такие обращения отсутствуют. Общая
структура кода процессов распределенной системы, рассматриваемая
далее для изучения механизмов взаимного исключения, приведена в
Листинге 1. В коде каждого процесса используются две функции:
request_CS() для получения разрешения на вход в критическую
секцию и блокировки процесса в случае необходимости и release_CS()
для выхода из критической секции и предоставления возможности
остальным процессам войти в нее. Каждая из этих функций
принимает в качестве аргумента общий для всех процессов
идентификатор критической секции R. Суть разработки
61
распределенных алгоритмов взаимного исключения как раз и состоит
в построении механизмов, обеспечивающих работу этих двух
функций.
Рис. 13. Структура кода с критической секцией
Исходя из организации работы с критической секцией (КС),
множество возможных состояний процесса будет определяться тремя
состояниями: (1) запрос на вход в КС, (2) выполнение внутри КС и (3)
выполнение вне КС. При этом возможны только переходы из
состояния выполнения вне КС в состояние запроса на вход в КС
(вызов функции request CS), из состояния запроса на вход в КС в
состояние выполнения внутри КС (возврат из функции requestCS) и из
состояния выполнения внутри КС вновь в состояние выполнения вне
КС (вызов функции releaseCS и возврат из нее). Важно отметить, что в
состоянии выполнения внутри КС процесс может находиться лишь
ограниченное время, в то время как в состоянии выполнения вне КС
процесс может находиться сколь угодно долго. В состоянии запроса
на вход в КС процесс блокируется до получения разрешения на вход в
КС и не должен формировать новых запросов для доступа к КС.
62
Основные требования к алгоритмам взаимного исключения
формулируются следующим образом.
• Безопасность. В каждый момент времени в КС может
выполняться не более одного процесса.
• Живучесть. Каждый запрос на вход в КС рано или поздно
должен быть удовлетворен. Условие живучести алгоритма взаимного
исключения говорит о том, что нельзя допускать ситуации взаимной
блокировки, т. е. бесконечного ожидания прихода сообщения, которое
никогда не придет, и ситуации голодания, т. е. бесконечного ожидания
разрешения на вход в КС одним процессом, в то время как другие
процессы неоднократно получают доступ к КС.
Отсутствие голодания также является условием справедливости.
Другой контекст определения справедливости обслуживания запросов
на вход в КС связан с установлением порядка вхождения процессов в
КС и ограничением на число позволяемых входов-выходов в КС для
одного процесса, пока другой процесс ожидает входа в КС. А именно,
логично потребовать, что в случае, если один запрос на вход в КС
произошел раньше другого, то и доступ к КС должен быть
предоставлен в таком же порядке. Если механизм взаимного
исключения удовлетворяет этому требованию, и все запросы на вход в
КС связаны отношением причинно-следственного порядка, то ни один
процесс не сможет войти в КС более одного раза, пока другой процесс
ожидает получения разрешения на вход в КС. Все многообразие
алгоритмов взаимного исключения в распределенных системах на
самом деле базируется на реализации одного из двух основных
принципов.
1. Алгоритмы на основе получения разрешений (англ.
permission-based algorithms). В этом случае для входа в КС процессу
требуется собрать «достаточное» число разрешений от других
процессов распределенной системы. Свойство безопасности будет
выполнено, если такое число разрешений сможет получить лишь один
63
процесс из всех процессов, желающих войти в КС. Свойство
живучести обычно обеспечивается за счет упорядочивания запросов
по их отметкам логического времени или с помощью ациклического
графа предшествования, в котором вершины соответствуют
процессам распределенной системы, а направленные ребра
описывают приоритет процессов друг над другом для определения
порядка предоставления доступа к КС.
2. Алгоритмы на основе передачи маркера (англ. token-based
algorithms). Для таких алгоритмов право войти в КС материализуется
в виде уникального объекта – маркера, который в каждый момент
времени может содержаться только у одного процесса или же
находиться в канале в состоянии пересылки от одного процесса к
другому. Свойство безопасности в этом случае будет гарантировано
ввиду уникальности маркера. Поэтому основные усилия при
разработке алгоритмов данного класса направлены на обеспечение
свойства живучести, а именно, на управление перемещением маркера
таким образом, чтобы он рано или поздно оказался в каждом
процессе, желающем войти в КС. Существуют два подхода к решению
этой задачи: непрерывное перемещение маркера среди всех процессов
распределенной системы или перемещение маркера лишь в ответ на
получение запроса от заинтересованного в нем процесса. Отметим,
что при формировании запросов на владение маркером необходимо
создать такие условия их распространения, при которых каждый
запрос рано или поздно достигнет процесса, в котором находится
маркер, вне зависимости от перемещений самого маркера. Обратим
внимание, что два перечисленных принципа построения алгоритмов
взаимного исключения объединяются в централизованном алгоритме,
когда доступ к КС управляется специально выделенным процессом,
называемым координатором. В этом случае для входа в КС процессу
достаточно получить одно единственное разрешение от координатора,
который становится ответственным за поддержку информации о
64
состояниях всех процессов и за выдачу разрешений на вход в КС
таким образом, чтобы гарантировать выполнение свойств
безопасности и живучести. С другой стороны, такое уникальное
разрешение, выдаваемое координатором, можно рассматривать как
маркер, передаваемый координатором процессу, желающему войти в
КС, и возвращаемый обратно координатору после его использования.
Более подробно работу централизованного алгоритма взаимного
исключения рассмотрим в следующем подразделе.
4.2. Синхронизация в распределенных системах
К вопросам связи процессов, реализуемой путем передачи
сообщений или вызовов RPC, тесно примыкают и вопросы
синхронизации процессов. Синхронизация необходима процессам для
организации совместного использования ресурсов, таких как файлы
или устройства, а также для обмена данными.
В однопроцессорных системах решение задач взаимного
исключения, критических областей и других проблем синхронизации
осуществлялось с использованием общих методов, таких как
семафоры и мониторы. Однако эти методы не совсем подходят для
распределенных систем, так как все они базируются на использовании
разделяемой оперативной памяти. Например, два процесса, которые
взаимодействуют, используя семафор, должны иметь доступ к нему.
Если оба процесса выполняются на одной и той же машине, они могут
иметь совместный доступ к семафору, хранящемуся, например, в ядре,
делая системные вызовы. Однако если процессы выполняются на
разных машинах, то этот метод не применим, для распределенных
систем нужны новые подходы.
Алгоритм синхронизации логических часов
В централизованной однопроцессорной системе, как правило,
важно только относительное время и не важна точность часов.
65
В распределенной системе, где каждый процессор имеет собственные
часы со своей точностью хода, ситуация резко меняется: программы,
использующие время (например, программы, подобные команде make
в UNIX, которые используют время создания файлов, или программы,
для которых важно время прибытия сообщений и т. п.) становятся
зависимыми от того, часами какого компьютера они пользуются.
В распределенных системах синхронизация физических часов
(показывающих реальное время) является сложной проблемой, но, с
другой стороны, очень часто в этом нет никакой необходимости, то
есть процессам не нужно, чтобы во всех машинах было правильное
время, для них важно, чтобы оно было везде одинаковое, более того,
для некоторых процессов важен только правильный порядок событий.
В этом случае мы имеем дело с логическими часами.
Введем для двух произвольных событий отношение «случилось
до». Выражение a ® b читается «a случилось до b» и означает, что все
процессы в системе считают, что сначала произошло событие a, а
потом событие b. Отношение «случилось до» обладает свойством
транзитивности: если выражения a ® b и b ® c истинны, то
справедливо и выражение a ® c. Для двух событий одного и того же
процесса всегда можно установить отношение «случилось до»,
аналогично может быть установлено это отношение и для событий
передачи сообщения одним процессом и приемом его другим, так как
прием не может произойти раньше отправки. Однако если два
произвольных события случились в разных процессах на разных
машинах, и эти процессы не имеют между собой никакой связи (даже
косвенной через третьи процессы), то нельзя сказать с полной
определенностью, какое из событий произошло раньше, а какое
позже.
Ставится задача создания такого механизма ведения времени,
который бы для каждого события а мог указать значение времени Т(а),
с которым бы были согласны все процессы в системе. При этом
66
должно выполняться условие: если а ® b , то Т(а) < Т(b). Кроме того,
время может только увеличиваться и, следовательно, любые
корректировки времени могут выполняться только путем добавления
положительных значений, и никогда путем вычитания.
Рассмотрим алгоритм решения этой задачи, который
предложил Lamport. Для отметок времени в нем используются
события. На рисунке 14 показаны три процесса, выполняющихся на
разных машинах, каждая из которых имеет свои часы, идущие со
своей скоростью. Как видно из рисунка, когда часы процесса 0
показали время 6, в процессе 1 часы показывали 8, а в процессе 2 10.
Предполагается, что все эти часы идут с постоянной для себя
скоростью.
В момент времени 6 процесс 0 посылает сообщение А процессу 1.
Это сообщение приходит к процессу 1 в момент времени 16 по его
часам. В логическом смысле это вполне возможно, так как 6<16.
Аналогично, сообщение В, посланное процессом 1 процессу 2, пришло
к последнему в момент времени 40, то есть его передача заняла 16
единиц времени, что также является правдоподобным.
Рис. 14. Синхронизация логических часов:
(а) три процесса, каждый со своими собственными часами;
(б) алгоритм синхронизации логических часов
Сообщение С от процесса 2 к процессу 1 было отправлено в
момент времени 60, а поступило в место назначения в момент времени
67
54. Очевидно, что это невозможно. Такие ситуации необходимо
предотвращать. Решение Lamport'а вытекает непосредственно из
отношений «случилось до». Так как С было отправлено в момент 60, то
оно должно дойти в момент 61 или позже. Следовательно, каждое
сообщение должно нести с собой время своего отправления по часам
машины-отправителя. Если в машине, получившей сообщение, часы
показывают время, которое меньше времени отправления, то эти часы
переводятся вперед, так, чтобы они показали время, большее времени
отправления сообщения. На рисунке 14,б видно, что С поступило в
момент 61, а сообщение D в 70.
Этот алгоритм удовлетворяет сформулированным выше
требованиям.
Алгоритмы взаимного исключения
Системы, состоящие из нескольких процессов, часто легче
программировать, используя так называемые критические секции.
Когда процессу нужно читать или модифицировать некоторые
разделяемые структуры данных, он прежде всего входит в
критическую секцию для того, чтобы обеспечить себе исключительное
право использования этих данных, при этом он уверен, что никакой
процесс не будет иметь доступа к этому ресурсу одновременно с ним.
Это называется взаимным исключением. В однопроцессорных системах
критические секции защищаются семафорами, мониторами и другими
аналогичными конструкциями. Рассмотрим, какие алгоритмы могут
быть использованы в распределенных системах.
Централизованный алгоритм
Наиболее очевидный и простой путь реализации взаимного
исключения в распределенных системах это применение тех же
методов, которые используются в однопроцессорных системах. Один
из процессов выбирается в качестве координатора (например,
процесс, выполняющийся на машине, имеющей наибольшее значение
сетевого адреса). Когда какой-либо процесс хочет войти в
68
критическую секцию, он посылает сообщение с запросом к
координатору, оповещая его о том, в какую критическую секцию он
хочет войти, и ждет от координатора разрешение. Если в этот момент
ни один из процессов не находится в критической секции, то
координатор посылает ответ с разрешением. Если же некоторый
процесс уже выполняет критическую секцию, связанную с данным
ресурсом, то никакой ответ не посылается; запрашивавший процесс
ставится в очередь, и после освобождения критической секции ему
отправляется ответ-разрешение. Этот алгоритм гарантирует взаимное
исключение, но вследствие своей централизованной природы
обладает низкой отказоустойчивостью.
Распределенный алгоритм
Когда процесс хочет войти в критическую секцию, он
формирует сообщение, содержащее имя нужной ему критической
секции, номер процесса и текущее значение времени. Затем он
посылает это сообщение всем другим процессам. Предполагается, что
передача сообщения надежна, то есть получение каждого сообщения
сопровождается подтверждением. Когда процесс получает сообщение
такого рода, его действия зависят от того, в каком состоянии по
отношению к указанной в сообщении критической секции он
находится. Имеют место три ситуации:
1. Если получатель не находится и не собирается входить в
критическую секцию в данный момент, то он отсылает назад
процессу-отправителю сообщение с разрешением.
2. Если получатель уже находится в критической секции, то
он не отправляет никакого ответа, а ставит запрос в очередь.
3. Если получатель хочет войти в критическую секцию, но
еще не сделал этого, то он сравнивает временную отметку
поступившего сообщения со значением времени, которое содержится
в его собственном сообщении, разосланном всем другим процессам.
Если время в поступившем к нему сообщении меньше, то есть его
69
собственный запрос возник позже, то он посылает сообщение-
разрешение, в обратном случае он не посылает ничего и ставит
поступившее сообщение-запрос в очередь.
Процесс может войти в критическую секцию только в том
случае, если он получил ответные сообщения-разрешения от всех
остальных процессов. Когда процесс покидает критическую секцию,
он посылает разрешение всем процессам из своей очереди и
исключает их из очереди.
Алгоритм Token Ring
Совершенно другой подход к достижению взаимного исключения
в распределенных системах иллюстрируется рисунком 15.
Все процессы системы образуют логическое кольцо, т. е. каждый
процесс знает номер своей позиции в кольце, а также номер
ближайшего к нему следующего процесса. Когда кольцо
инициализируется, процессу 0 передается токен. Токен циркулирует по
кольцу. Он переходит от процесса n к процессу n+1 путем передачи
сообщения по типу «точка-точка». Когда процесс получает токен от
своего соседа, он анализирует, не требуется ли ему самому войти в
критическую секцию. Если да, то процесс входит в критическую
секцию. После того как процесс выйдет из критической секции, он
передает токен дальше по кольцу. Если же процесс, принявший токен
от своего соседа, не заинтересован во вхождении в критическую
секцию, то он сразу отправляет токен в кольцо. Следовательно, если ни
один из процессов не желает входить в критическую секцию, то в этом
случае токен просто циркулирует по кольцу с высокой скоростью.
Сравним эти три алгоритма взаимного исключения.
Централизованный алгоритм является наиболее простым и наиболее
эффективным. При его использовании требуется только три
сообщения для того, чтобы процесс вошел и покинул критическую
секцию: запрос и сообщение-разрешение для входа и сообщение об
освобождении ресурса при выходе. При использовании
70
распределенного алгоритма для одного использования критической
секции требуется послать (n1) сообщений-запросов (где n число
процессов) по одному на каждый процесс и получить (n1)
сообщений-разрешений, то есть всего необходимо 2(n1) сообщений.
В алгоритме Token Ring число сообщений переменно: от 1 в случае,
если каждый процесс входил в критическую секцию, до бесконечно
большого числа, при циркуляции токена по кольцу, в котором ни один
процесс не входил в критическую секцию.
К сожалению, все эти три алгоритма плохо защищены от
отказов. В первом случае к краху приводит отказ координатора, во
втором отказ любого процесса (парадоксально, но распределенный
алгоритм оказывается менее отказоустойчивым, чем
централизованный), а в третьем потеря токена или отказ процесса.
Рис. 15. Средства взаимного исключения в распределенных системах:
(а) - неупорядоченная группа процессов в сети;
(б) - логическое кольцо, образованное программным обеспечением
Неделимые транзакции
Все средства синхронизации, которые были рассмотрены ранее,
относятся к нижнему уровню, например, семафоры. Они требуют от
71
программиста детального знания алгоритмов взаимного исключения,
управления критическими секциями, умения предотвращать клинчи
(взаимные блокировки), а также владения средствами восстановления
после краха. Однако существуют средства синхронизации более
высокого уровня, которые освобождают программиста от
необходимости вникать во все эти подробности и позволяют ему
сконцентрировать свое внимание на логике алгоритмов и организации
параллельных вычислений. Таким средством является неделимая
транзакция.
Модель неделимой транзакции пришла из бизнеса. Представьте
себе переговорный процесс двух фирм о продаже-покупке некоторого
товара. В процессе переговоров условия договора могут многократно
меняться, уточняться. Пока договор еще не подписан обеими
сторонами, каждая из них может от него отказаться. Но после
подписания контракта сделка (transaction) должна быть выполнена.
Компьютерная транзакция полностью аналогична. Один процесс
объявляет, что он хочет начать транзакцию с одним или более
процессами. Они могут некоторое время создавать и уничтожать
разные объекты, выполнять какие-либо операции. Затем инициатор
объявляет, что он хочет завершить транзакцию. Если все с ним
соглашаются, то результат фиксируется. Если один или более
процессов отказываются (или они потерпели крах еще до выработки
согласия), тогда измененные объекты возвращается точно к тому
состоянию, в котором они находились до начала выполнения
транзакции. Такое свойство «все-или-ничего» облегчает работу
программиста.
Для программирования с использованием транзакций требуется
некоторый набор примитивов, которые должны быть предоставлены
программисту либо операционной системой, либо языком
программирования. Примеры примитивов такого рода:
72
Таблица 1. Примитивы транзакций
BEGIN_TRANSACTION команды, которые следуют за этим примитивом,
формируют транзакцию
END_TRANSACTION завершает транзакцию и пытается зафиксировать ее
ABORT_TRANSACTION прерывает транзакцию, восстанавливает предыдущие
значения
READ читает данные из файла (или другого объекта)
WRITE пишет данные в файл (или другой объект)
Первые два примитива используются для определения границ
транзакции. Операции между ними представляют собой тело
транзакции. Либо все они должны быть выполнены, либо ни одна из
них. Это может быть системный вызов, библиотечная процедура или
группа операторов языка программирования, заключенная в скобки.
Транзакции обладают следующими свойствами:
упорядочиваемостью, неделимостью, постоянством.
Упорядочиваемость гарантирует, что если две или более
транзакции выполняются в одно и то же время, то конечный результат
выглядит так, как если бы все транзакции выполнялись
последовательно в некотором (в зависимости от системы) порядке.
Неделимость означает, что когда транзакция находится в
процессе выполнения, то никакой другой процесс не видит ее
промежуточные результаты.
Постоянство означает, что после фиксации транзакции никакой
сбой не может отменить результатов ее выполнения.
Если программное обеспечение гарантирует
вышеперечисленные свойства, то это означает, что в системе
поддерживается механизм транзакций.
Рассмотрим некоторые подходы к реализации механизма
транзакций.
В соответствии с первым подходом, когда процесс начинает
транзакцию, то он работает в индивидуальном рабочем пространстве,
73
содержащем все файлы и другие объекты, к которым он имеет доступ.
Пока транзакция не зафиксируется или не прервется, все изменения
данных происходят в этом рабочем пространстве, а не в «реальном», под
которым мы понимаем обычную файловую систему. Главная проблема
этого подхода состоит в больших накладных расходах по копированию
большого объема данных в индивидуальное рабочее пространство, хотя
и имеются несколько приемов уменьшения этих расходов.
Второй общий подход к реализации механизма транзакций
называется списком намерений. Этот метод заключается в том, что
модифицируются сами файлы, а не их копии, но перед изменением
любого блока производится запись в специальный файл журнал
регистрации, где отмечается, какая транзакция делает изменения, какой
файл и блок изменяется и каковы старое и новое значения изменяемого
блока. Только после успешной записи в журнал регистрации делаются
изменения в исходном файле. Если транзакция фиксируется, то и об
этом делается запись в журнал регистрации, но старые значения
измененных данных сохраняются. Если транзакция прерывается, то
информация журнала регистрации используется для приведения файла в
исходное состояние, и это действие называется откатом.
В распределенных системах фиксация транзакций может
потребовать взаимодействия нескольких процессов на разных
машинах, каждая из которых хранит некоторые переменные, файлы,
базы данных. Для достижения свойства неделимости транзакций в
распределенных системах используется специальный протокол,
называемый протоколом двухфазной фиксации транзакций. Хотя он и
не является единственным протоколом такого рода, но он наиболее
широко используется.
Суть этого протокола состоит в следующем. Один из процессов
выполняет функции координатора (рисунок 16). Координатор
начинает транзакцию, делая запись об этом в своем журнале
регистрации, затем он посылает всем подчиненным процессам, также
74
выполняющим эту транзакцию, сообщение «подготовиться к
фиксации». Когда подчиненные процессы получают это сообщение, то
они проверяют, готовы ли они к фиксации, делают запись в своем
журнале и посылают координатору сообщение-ответ «готов к
фиксации». После этого подчиненные процессы остаются в состоянии
готовности и ждут от координатора команду фиксации. Если хотя бы
один из подчиненных процессов не откликнулся, то координатор
откатывает подчиненные транзакции, включая и те, которые
подготовились к фиксации.
Рис. 16. Двухфазный протокол фиксации транзакции
Выполнение второй фазы заключается в том, что координатор
посылает команду «фиксировать» (commit) всем подчиненным
процессам. Выполняя эту команду, последние фиксируют изменения и
завершают подчиненные транзакции. В результате гарантируется
одновременное синхронное завершение (удачное или неудачное)
распределенной транзакции.
75
5. Многопоточное программирование Рассмотрим создание многопоточного приложение на примере
языка Java. Каждый процесс имеет хотя бы один выполняющийся
поток. Тот поток, с которого начинается выполнение программы,
называется главным. В языке Java, после создания процесса,
выполнение главного потока начинается с метода main(). Затем, по мере
необходимости, в заданных программистом местах, и при выполнении
заданных им же условий, запускаются другие, побочные потоки.
В языке Java поток представляется в виде объекта-потомка
класса Thread. Этот класс инкапсулирует стандартные механизмы
работы с потоком.
Запустить новый поток можно двумя способами:
Способ 1
Создать объект класса Thread, передав ему в конструкторе
нечто, реализующее интерфейс Runnable. Этот интерфейс содержит
метод run(), который будет выполняться в новом потоке. Поток
закончит выполнение, когда завершится его метод run(). class SomeThing //Нечто, реализующее интерфейс Runnable implements Runnable { //(содержащее метод run()) public void run() { //Этот метод будет выполняться
в побочном потоке System.out.println("Привет из побочного потока!"); } } public class Program { //Класс с методом main() public static void main(String[] args) { SomeThing mThing = new SomeThing(); // объект класса, реализующего интерфейс Runnable //Создание потока "myThready" Thread myThready = new Thread(mThing); myThready.start();//Запуск потока System.out.println("Главный поток завершен..."); } }
76
Для укорочения кода можно передать в конструктор класса
Thread объект безымянного внутреннего класса, реализующего
интерфейс Runnable: public class Program { //Класс с методом main(). public static void main(String[] args) { //Создание потока Thread myThready = new Thread(new Runnable() { public void run() { //Этот метод будет выполняться в побочном потоке System.out.println("Привет из побочного потока!"); } }); myThready.start(); //Запуск потока System.out.println("Главный поток завершен..."); } }
Способ 2
Создать потомка класса Thread и переопределить его метод run(): class AffableThread extends Thread { @Override public void run() { //Этот метод будет выполнен в побочном потоке System.out.println("Привет из побочного потока!"); } } public class Program { AffableThread mSecondThread; public static void main(String[] args) { mSecondThread = new AffableThread(); //Создание потока mSecondThread.start(); //Запуск потока System.out.println("Главный поток завершен..."); } }
77
В приведенном выше примере в методе main() создается и
запускается еще один поток. Важно отметить, что после вызова
метода mSecondThread.start() главный поток продолжает свое
выполнение, не дожидаясь, пока порожденный им поток завершится.
И те инструкции, которые идут после вызова метода start(), будут
выполнены параллельно с инструкциями потока mSecondThread.
Синхронизация потоков
Для управления параллельным выполнением потоков, в
частности для обеспечения доступа к совместно используемым
ресурсам, используется синхронизация. Механизм синхронизации
основывается на концепции монитора.
Монитор это объект специального назначения, в котором
применен принцип взаимного исключения (mutual exclusion) для групп
процедур. Во время выполнения программы монитор допускает лишь
поочередное выполнение процедуры, находящейся под его контролем.
У каждого объекта в Java имеется свой собственный неявный
монитор. Когда метод типа synchronized вызывается для объекта,
происходит обращение к монитору объекта, чтобы определить,
выполняет ли в данный момент какой-либо другой поток метод типа
synchronized для данного объекта. Если нет, то текущий поток получает
разрешение войти в монитор. Вход в монитор называется также
блокировкой(locking) монитора. Если при этом другой поток уже вошел
в монитор, то текущий поток должен ожидать до тех пор, пока другой
поток не покинет монитор. Таким образом, монитор Java вводит
поочередность в параллельную обработку. Этот способ называется
также преобразованием в последовательную форму (serialization).
Объявление метода synchronized не подразумевает, что только
один поток может одновременно выполнять этот метод, как в случае
критического участка (critical sections). Имеется в виду, что в любой
момент времени только один поток может вызвать этот метод (или
любой другой метод типа synchronized) для конкретного объекта. Таким
78
образом, мониторы Java связаны с объектами, но не с блоками кода. Два
потока могут параллельно выполнять один и тот же метод типа
synchronized при условии, что этот метод вызван для разных объектов.
Мониторы не являются объектами языка Java,у них нет
атрибутов или методов. Доступ к мониторам возможен на уровне
собственного кода JVM.
В Java есть два способа синхронизации потоков.
1. Создание синхронизирующего метода внутри класса.
Используется при наличии метода или группы методов,
обрабатывающих внутреннее состояние объекта в многопоточной
ситуации. Для организации последовательного доступа потоков к
методу объявление метода предваряется ключевым словом
synchronized. class Callme{ synchronized void call(String msg){ . . . . . . . . . . . . . . . . . . } 2. Создание синхронизирующего блока.
Используется для организации доступа к объектам класса, не
разработанного для многопоточного доступа (например к массивам)
или созданного другим программистом (нет доступа к исходному
коду). Необходимо поместить вызовы методов в синхронизирующий
блок путем использования оператора synchronized, имеющего
следующий синтаксис: synchronized (object){
// операторы, которые необходимо
синхронизировать
}
Оператор synchronized полезен при непосредственном
изменении общих переменных объекта. Пример: void call(SomeClassobj){
synchronized(obj){ obj.variable=5; } }
79
Следует учесть, что синхронизированные методы выполняются
медленнее их несинхронизированных аналогов.
Согласование потоков
Синхронизация позволяет осуществлять блокировку потоков,
предотвращая асинхронный доступ к определенным методам. Однако
часто возникает необходимость согласования потоков, когда выполнение
одного потока может зависеть от завершения в другом потоке запроса на
обслуживание или выполнения определенной операции. При этом важно,
чтобы ожидающий поток или потоки ожидали, не используя время ЦП
на опрос для постоянной проверки некоторых условий. Чтобы избежать
потери времени, связанные с опросом, Java использует механизм
взаимодействия между потоками через методы wait(), notify(), notifyall().
Все три метода объявлены в классе Object. final void wait()
final void notify()
final void notifyall()
wait() предписывает вызвавшему потоку отдать монитор и
перейти в состояние ожидания, пока какой-нибудь другой поток не
войдет в тот же монитор и не вызовет метод notify();
notify() активизирует один из ожидающих потоков, вызвавших
метод wait() того же объекта. Запускается поток с наибольшим
приоритетом;
notifyall() активизирует все ожидающие потоки, вызвавшие
метод wait() того же объекта.
Метод wait() имеет дополнительную форму, позволяющую
задать период ожидания. Все три метода служат интерфейсом для
взаимодействия с монитором объекта и их можно вызвать только в
том случае, когда текущий поток владеет правами на монитор
объекта, т. е. внутри метода или блока типа sysnchronized.
Мониторы используются как для введения поочередности в
параллельную обработку, так и для согласования потоков. Вызов
80
метода wait() для данного объекта приостанавливает текущий поток и
вводит его в очередь ожидания по условию (condition variable wait
queue) в мониторе объекта. Очередь содержит список всех потоков,
заблокированных внутри метода wait() для данного объекта. Вызов
метода notify() переводит единственный поток в активный режим,
уведомляя о том,что условие изменилось.
Обычно wait() помещается в блок try{} обработки
исключительных ситуаций. synchronized int get() { while( условие ) {
try { wait();
} catch() {} } . . . . . . . . . . . . . . . . notify(); . . . . . . . . . . . . . . . .
}
Вызов wait() и notify() для массивов осуществляется внутри
синхронизирующего блока. Obj[]array = getArray(); synchronized(array){
array.wait(); } . . . . . . . . . . . . . synchronized(array){ array.notify(); }
81
6. Кластерные вычисления
Практическое использование параллельных вычислительных
систем не является столь широким, как это могло бы быть
потенциально возможным. К основным сдерживающим факторам
широкого распространения параллельных вычислений следует
отнести большую стоимость и разнообразие архитектурного
построения ПВС, существенно более высокую (по сравнению с
последовательным программированием) трудоемкость разработки
эффективных параллельных алгоритмов и программ [16].
Преодоление первого сдерживающего фактора по широкому
использованию параллельных вычислений (высокая стоимость ПВС)
может быть получено на пути построения кластерных
вычислительных систем (clusters). Под кластером обычно понимается
множество отдельных компьютеров, объединенных в сеть, для
которых при помощи специальных аппаратно-программных средств
обеспечивается возможность унифицированного управления (single
system image), надежного функционирования (availability) и
эффективного использования (performance). Кластеры могут быть
образованы на базе уже существующих у потребителей отдельных
компьютеров либо же сконструированы из типовых компьютерных
элементов, что обычно не требует значительных финансовых затрат.
Применение кластеров может также в некоторой степени снизить
проблемы, связанные с разработкой параллельных алгоритмов и
программ, поскольку повышение вычислительной мощности
отдельных процессоров позволяет строить кластеры из сравнительно
небольшого количества (несколько десятков) отдельных компьютеров
(lowly parallel processing). Это приводит к тому, что для
параллельного выполнения в алгоритмах решения вычислительных
задач достаточно выделять только крупные независимые части
расчетов (coarse granularity), что, в свою очередь, снижает сложность
82
построения параллельных методов вычислений и уменьшает потоки
передаваемых данных между компьютерами кластера. Вместе с этим
следует отметить, что организация взаимодействия вычислительных
узлов кластера при помощи передачи сообщений обычно приводит к
значительным временным задержкам, что накладывает
дополнительные ограничения на тип разрабатываемых параллельных
алгоритмов и программ.
Решение проблемы разнообразия архитектур параллельных
вычислительных систем и обеспечение возможности создания
мобильных (переносимых между различными компьютерными
платформами) программ лежит на пути разработки
стандартизованного базового системного программного обеспечения
для организации параллельных вычислений. Основным стандартом,
широко используемым в настоящее время в практических
приложениях, является интерфейс передачи сообщений (message
passing interface MPI). Наличие такого стандарта позволило
разработать стандартные библиотеки программ (MPI-библиотеки), в
которых оказалось возможным скрыть большинство архитектурных
особенностей ПВС и, как результат, существенно упростить проблему
создания параллельных программ. Более того, стандартизация
базового системного уровня позволила в значительной степени
обеспечить мобильность параллельных программ, поскольку в
настоящее время реализации MPI-стандарта имеются для
большинства компьютерных платформ.
Использование передачи сообщений для организации
параллельных вычислений ориентировано прежде всего на
многопроцессорные компьютерные системы с распределенной
памятью. Уменьшение времени расчетов (ускорение) при таком
подходе может быть достигнуто только для тех научно-технических
проблем, в которых объем вычислений превалирует над уровнем
необходимых межпроцессорных взаимодействий (т. е. для
83
вычислительно-трудоемких задач с низкой коммуникационной
сложностью).
Параллельные вычислительные модели
Параллельные вычислительные модели образуют сложную
структуру. Они могут быть дифференцированы по нескольким
направлениям: является ли память физически общей или
распределенной; насколько обмен данными реализован в аппаратном
и насколько в программном обеспечении; что в точности является
единицей исполнения и т. д. Общая картина осложняется тем, что
программное обеспечение позволяет реализовать любую
вычислительную модель на любом оборудовании.
Для систем с распределенной памятью организация
параллельных вычислений является возможной при использовании
тех или иных способов передачи данных между
взаимодействующими процессорами. Модель с передачей сообщений
подразумевает множество процессов, имеющих только локальную
память, но способных связываться с другими процессами, посылая и
принимая сообщения. Определяющим свойством модели для
передачи сообщений является тот факт, что передача данных из
локальной памяти одного процесса в локальную память другого
процесса требует выполнения операций обоими процессами.
Преимущества модели с передачей данных
Универсальность. Модель с передачей сообщений хорошо
подходит к системам с отдельными процессорами, соединенными с
помощью (быстрой или медленной) сети. Тем самым она
соответствует как большинству сегодняшних параллельных
суперкомпьютеров, так и сетям рабочих станций.
Выразительность. Модель с передачей сообщений является
полезной и полной для выражения параллельных алгоритмов. Она
приводит к ограничению управляющей роли моделей, основанных на
компиляторах и параллельности данных. Она хорошо приспособлена
84
для реализации адаптивных алгоритмов, подстраивающихся к
несбалансированности скоростей процессов.
Легкость отладки. Отладка параллельных программ обычно
представляет собой непростую задачу. Модель с передачей
сообщений управляет обращением к памяти более явно, чем любая
другая модель (только один процесс имеет прямой доступ к любым
переменным в памяти), и, тем самым, облегчает локализацию
ошибочного чтения или записи в память.
Производительность. Важнейшей причиной того, что передача
сообщений остается постоянной частью параллельных вычислений,
является производительность. По мере того, как CPU становятся все
более быстрыми, управление их кэшем и иерархией памяти вообще
становится ключом к достижению максимальной производительности.
Передача сообщений дает программисту возможность явно связывать
специфические данные с процессом, что позволяет компилятору и
схемам управления кэшем работать в полную силу.
Все вышеперечисленное объясняет, почему передача сообщений
становится одной из наиболее широко используемых технологий для
выражения параллельных алгоритмов. Несмотря на некоторые
недостатки, передача сообщений, более чем любая другая модель,
приближается к тому, чтобы быть стандартным подходом для
реализации параллельных приложений.
6.1. Основные понятия MPI
Функции передачи сообщений [16].
Многие понятия MPI, которые, на первый взгляд, могут
показаться новыми, на самом деле являются необходимыми
уточнениями хорошо знакомых понятий. Рассмотрим самую
элементарную операцию в библиотеке передачи сообщений
основную операцию send. Во многих современных системах передачи
сообщений она выглядит следующим образом:
85
send(address, length, destination, tag),
где address адрес в памяти начала буфера, содержащего
посылаемые данные;
- length длина сообщения в байтах;
- destination идентификатор процесса, которому посылается
сообщение (обычно, как целое);
- tag произвольное неотрицательное целое число, метка
сообщения (иногда называемое также типом). Позволяет
принимающей стороне «различать» сообщения и организовывать
прием сообщений только нужного типа.
Эта конкретная совокупность параметров часто выбирается
благодаря тому, что она представляет собой хороший компромисс
между тем, что нужно программисту, и тем, что эффективно
реализуется аппаратурой (передача непрерывной области памяти от
одного процессора другому). В частности, можно ожидать, что
операционная система обеспечивает обслуживание очередей так,
чтобы операция приема recv(address, maxlen, source, tag, datlen)
успешно завершалась только в случае получения сообщения с
нужной меткой (tag). Другие сообщения помещаются в очередь до
тех пор, пока не будет выполнена соответствующая операция
приема. В большинстве систем source это выходной аргумент,
указывающий, откуда пришло сообщение, хотя в некоторых
системах он также может быть использован для ужесточения отбора
сообщений и помещения их в очередь. При приеме address и maxlen
вместе описывают буфер, в который нужно поместить принимаемые
данные, datlen представляет число принятых байтов.
Системы передачи сообщений с такого рода синтаксисом и
семантикой показали себя чрезвычайно полезными, хотя и наложили
ограничения, нежелательные для большого числа пользователей. MPI
старался снять эти ограничения, предлагая более гибкие версии
86
каждого из этих параметров, сохраняя при этом привычный смысл
основных операций send и receive.
Понятие коммуникаторов
Разделение семейств сообщений. Почти все системы передачи
сообщений предусматривают аргумент tag для операций send и
receive. Этот аргумент позволяет программисту обрабатывать
приходящие сообщения упорядоченным образом, даже если
сообщения поступают в порядке, отличном от желаемого. Системы
передачи сообщений помещают сообщения, пришедшие «с неверной
меткой», в очередь до тех пор, пока программа не будет готова
принять их. Обычно имеется возможность специфицировать
«универсальную» метку, которая сопоставляется с любой меткой.
Этот механизм оказался необходимым, но не достаточным,
поскольку произвольность выбора метки означает, что по всей
программе метки должны использоваться единым заранее
определенным образом. Особые трудности возникают в случае
библиотек, написанных далеко от прикладного программиста во
времени и пространстве, так как сообщения этой библиотеки не
должны быть случайно приняты прикладной программой.
Решение MPI состоит в расширении понятия метки до нового
понятия контекста. Контексты размещаются во время исполнения
программы системой в ответ на запрос пользователя (или библиотеки)
и используются для сопоставления сообщений. От метки контексты
отличаются тем, что вырабатываются системой, а не пользователем, и
никакое «универсальное» сопоставление не допускается.
MPI сохраняет и обычное определение метки сообщения,
включающего качество универсального сопоставления.
Наименование процессов. Процессы принадлежат группам. Если
группа содержит n процессов, то процессы внутри группы
идентифицируются рангами целыми числами от 0 до n1. В рамках
стандарта MPI предполагается, что существует начальная группа
87
которой принадлежат все процессы выполняемой параллельной
программы. Внутри этой группы процессы нумеруются подобно тому,
как они нумеруются во многих существующих системах передачи
сообщений - от нуля до общего числа процессов минус один.
Коммуникаторы. Понятия контекста и группы комбинируются в
единый объект, называемый коммуникатором, который становится
аргументом к большинству двухточечных и коллективных операций.
Таким образом, destination или source, специфицированные в
операции посылки или приема, всегда указывают на ранг процесса в
группе, идентифицированный с данным коммуникатором.
Иными словами, в MPI основная (синхронная) операция send
выглядит следующим образом: MPI_Send(buf, count, datatype, dest, tag, comm),
Где (buf, count, datatype) описывают count элементов вида
datatype, начинающихся с buf;
- dest ранг получателя в группе, связанной с коммуникатором
comm;
- tag имеет обычное значение;
- comm идентифицирует группу процессов и контекст связи.
Операция receive превращается в MPI_Recv(buf, count, datatype, source, tag, comm,
status).
Источник, метку и размер реально принятого сообщения можно
извлечь из status.
Некоторые другие системы передачи сообщений возвращают
параметры «статуса» отдельными вызовами, которые косвенно
ссылаются на последнее принятое сообщение. Метод MPI один из
аспектов усилий, направленных на то, чтобы надежно работать в
ситуации, когда несколько потоков принимают сообщение от имени
одного процесса.
88
Методы разработки параллельных программ
с использованием интерфейса передачи сообщений MPI
При программировании с использованием модели передачи
сообщений считают, что компьютер представляет собой набор
независимых процессоров, каждый из которых обладает
собственной локальной памятью. Работающая программа – это
набор процессов (подзадач), каждая из которых выполняется на
своем процессоре. В процессе работы подзадачи обмениваются
данными между собой.
При разработке параллельной программы с использованием MPI
исходная задача разбивается на подзадачи (декомпозиция). Обычная
техника состоит в следующем: каждая из подзадач оформляется в
виде отдельной структурной единицы (функции, модуля), на всех
процессорах запускается одна и та же программа «загрузчик»,
которая, в зависимости от «номера» процессора загружает ту или
иную подзадачу. Такой подход (запуск одной и той же программы на
всех выделенных для решения задачи процессоров) получил в
литературе наименование SPMD (single program multiple data).
Рассмотрим эту технологию подробнее на примере широко
используемой демонстрационной программы типа «Hello world»
Первая программа #include <stdio.h>
#include "mpi.h"
int main(int argc, char* argv[])
{
int rank, numprocs, i, message;
// инициализация библиотеки MPI
MPI_Init(&argc, &argv);
// получение количества процессов в программе
MPI_Comm_size(MPI_COMM_WORLD, &numprocs);
// получение ранга процесса
89
MPI_Comm_rank(MPI_COMM_WORLD, &rank);
printf ("\n Hello from process %3d", rank);
// завершение библиотеки MPI
MPI_Finalize();
return 0;
}
Первым в каждой MPI программе должен быть вызов MPI_Init,
который должен присутствовать в каждой программе MPI и
предшествует всем другим вызовам MPI1. Он устанавливает «среду»
(environment) MPI. Только одно обращение к MPI_Init допускается в
исполнении программы. Его аргументами являются количество
аргументов командной строки процесса и собственно командная строка
процесса. Почти каждая функция MPI возвращает код ошибки, который
выражен либо как MPI_SUCCESS, либо как зависимый от реализации
код ошибки. В этом примере (и многих других примерах) для
сокращения количества кода не будем особенно тщательны в проверке
кода возврата, предполагая, что он всегда равен MPI_SUCCESS.
Весь обмен данных в MPI связан с коммуникатором. В этой
программе будем использовать только предопределенный
коммуникатор MPI_COMM_WORLD, определяющий единый
контекст и весь набор процессов параллельной программы.
Определение MPI_COMM_WORLD приводится в mpi.h.
Функция MPI_Comm_size возвращает (в numprocs) число
запущенных для данной программы процессов. Каким способом
пользователь запускает эти процессы зависит от реализации, но
любая программа может определить число запущенных процессов с
помощью данного вызова. Значение numprocs это, по сути, размер
группы, связанной с коммуникатором MPI_COMM_WORLD.
Процессы каждой группы пронумерованы целыми числами, начиная с
0, которые называются рангами (rank). Каждый процесс определяет
свой номер в группе, связанной с данным коммуникатором, с
90
помощью MPI_Comm_rank. Таким образом, каждый процесс получает
одно и то же число в numprocs, но разные числа в rank. Каждый
процесс печатает свой ранг и общее количество запущенных
процессов, затем все процессы выполняют MPI_Finalize. Эта функция
должна быть выполнена каждым процессом MPI и приводит к
ликвидации «среды» MPI. Никакие вызовы MPI не могут быть
осуществлены процессом после вызова MPI_Finalize (повторный
MPI_Init также невозможен).
Нужно заметить, что каждый процесс таким образом
написанной и запущенной MPI-программы напечатает одно
сообщение. Если все процессы были запущены на разных машинах,
на каждой машине будет напечатано соответствующее сообщение.
Допустим, необходимо, чтобы все сообщения напечатал какой-то
один процесс, например, процесс с рангом 0. Кроме того, хотим,
чтобы ранги процессов, которые он должен напечатать, передали бы
ему сами процессы. Таким образом, мы хотим реализовать систему с
выделенным нулевым процессом, который должен принять
сообщения от всех остальных процессов.
Передача сообщений между двумя процессами #include <stdio.h>
#include "mpi.h"
int main(int argc, char* argv[]){
int rank, n, i, message;
MPI_Status status;
MPI_Init(&argc, &argv);
MPI_Comm_size(MPI_COMM_WORLD, &n);
MPI_Comm_rank(MPI_COMM_WORLD, &rank);
if (rank == 0){
printf ("\n Hello from process %3d",rank);
for (i=1; i<n; i++){
MPI_Recv(&message, 1, MPI_INT, MPI_ANY_SOURCE,
MPI_ANY_TAG, MPI_COMM_WORLD, &status);
91
printf("\n Hello from process %3d", message);
}
} else
MPI_Send(&rank,1,MPI_INT,0,0,MPI_COMM_WORLD);
MPI_Finalize();
return 0;}
Каждый процесс, стартуя, опрашивает два параметра: общее
количество процессов в группе (n) и свой ранг (rank). Делается это при
помощи уже известных нам функций MPI_Comm_size и MPI_Comm_rank.
То, что происходит далее, иллюстрирует широко применяемую при
написании MPI программ технику: процессы начинают вести себя
по-разному в зависимости от своего ранга3. В тексте программы буквой А
помечен код, выполняемый всеми процессами. Буквой B помечен код,
выполняемый процессом с рангом, равным нулю. И, наконец, буквой С
помечен код, выполняемый всеми другими процессами, с рангами,
отличными от нуля. Для того чтобы понять логику выполнения
программы, нужно рассмотреть еще две функции MPI функцию
передачи сообщений (MPI_Send) и функцию приема сообщений
(MPI_Recv). int MPI_Send(void *buf, int count, MPI_Datatype
datatype, int dest, int tag, MPI_Comm comm)
Первые три аргумента buffer, count, datatype описывают
сообщение в обычном для MPI стиле: адрес данных, их количество и
тип. Следующий аргумент, dest, это адрес получателя, целое число,
означающее номер процесса получателя в группе, определяемой
коммуникатором, который задан параметром comm. Следующий
аргумент целое число, задающее тип сообщения или его тег, по
терминологии MPI. Тег используется для передачи дополнительной
информации вместе с передаваемыми данными. MPI гарантирует, что
допустимыми значениями тега могут быть целые числа от 0 до 32767.
Сообщения от подчиненных процессов принимаются с
помощью функции
92
int MPI_Recv(void *buf, int count, MPI_Datatype
datatype, int source, int tag, MPI_Comm comm,
MPI_Status *status)
Следует отметить, что получение сообщения происходит с
блокировкой, т. е. управление не возвращается программе до тех пор,
пока сообщение не будет принято. Первые три аргумента указывают,
куда и в каком виде будет помещено сообщение. Процесс также
может указать, что он будет ждать сообщения от какого-либо
определенного процесса в таком случае нужно указать ранг этого
процесса в качестве параметра source. Если этого не нужно, можно
использовать определенное в MPI значение MPI_ANY_SOURCE,
чтобы указать, что процесс будет принимать сообщение от любого
процесса из группы коммуникатора comm. Использование
определенного в MPI значения MPI_ANY_TAG в качестве параметра
tag указывает, что приемлемыми будут сообщения с любым тегом.
Если необходимо принимать сообщения только с определенным
тегом в качестве параметра tag, нужно использовать его.
Выходной параметр stat содержит информацию о принятом
сообщении. Это структура типа MPI_Stat. Он должен быть определен
в программе пользователя. Проанализировав значение полей stat,
можно узнать ранг процесса, отправившего данные
stat.MPI_SOURCE, и тег stat.MPI_TAG. Другие элементы stat служат
для определения числа единиц реально полученных данных с
использованием функции MPI_Get_count.
Итак, после определения своего ранга процесс в зависимости от
него выполняет следующие действия. Все процессы с рангами,
отличными от нуля, передают на нулевой процесс свой ранг. Нулевой
процесс в цикле принимает сообщения от любого процесса с любым
тегом. Количество итераций цикла на 1 меньше количества процессов
в группе (печать ранга нулевого процесса осуществляется до цикла).
93
Следует отметить также, что, несмотря на наличие в программе
множества процессов, в каждый текущий момент времени в
элементарном цикле обмена участвуют два процесса отправитель и
получатель (операция передачи «процесс-процесс»). В разные
моменты времени в качестве отправителей выступают разные
процессы.
Откомпилировав и запустив этот пример, мы можем получить,
например, следующий вывод (было запущено четыре процесса):
Hello from process 0
Hello from process 2
Hello from process 1
Hello from process 3
Несложно заметить, что сообщения от процессов выводятся «не
по порядку». Порядок вывода сообщений может изменяться от
запуска к запуску. Причина происходящего кроется в том, как в
приведенном примере описан цикл приема сообщений. В самом деле,
нулевой процесс при приеме не указывает явно, с какого процесса он
принимает сообщения. Передавая в качестве ожидаемого источника
константу MPI_ANY_SOURCE, нулевой процесс принимает
сообщение от любого другого процесса. Поскольку, будучи
запущенными на разных машинах, процессы стартуют и выполняются
с разными скоростями, порядок, в котором процессы будут входить в
функцию передачи сообщений MPI_Send, предсказать сложно.
Основные типы операций передачи данных
Рассмотренные нами операции MPI_Send и MPI_Recv являются
основными для обменов типа «процесс – процесс». Однако их
использование в «настоящих» (не учебных) программах сопряжено с
известными трудностями и (в большинстве случаев) приводит к
невысокой производительности полученных параллельных
программ.
94
Все дело в том, каким образом происходит обмен сообщениями
при использовании стандартных процедур передачи данных. Вообще
в MPI поддерживаются следующие разновидности операций обмена:
- стандартная передача. Считается завершенной, как только
сообщение отправлено, независимо от того, получено оно или нет.
Передача сообщения может начинаться, даже если не начался его
прием;
- синхронная передача. Не завершается до тех пор, пока не будет
завершена приемка сообщения;
- буферизированная передача. Завершается сразу же. При
выполнении буферизированной передачи управление сразу же
возвращается в вызывающую процедуру сообщение при этом
копируется в системный буфер и ожидает пересылки;
- передача по готовности. Начинается только в том случае, если
начата приемка сообщения и сразу завершается, не дожидаясь
окончания приема.
В MPI принято определенное соглашение об именах процедур,
позволяющее определять тип используемой операции. Имя
процедуры строится по следующему правилу: MPI_[I][R|S|B]Send,
где I (Immediate) обозначает неблокирующую операцию;
- R передача по готовности;
- S – синхронный;
- B – буферизированный.
Отсутствие префикса означает, что используется стандартный
режим. Следует отметить, что функция приема любого типа
(MPI_XXRecv) способна принять сообщение, отосланное с помощью
любой функции (MPI_XXSend).
Функция MPI_Send выполняет стандартную блокирующую
передачу. Она блокирует процесс до завершения операции передачи
сообщения (это не гарантирует завершения приема!), что крайне
95
неэффективно при пересылке большого массива данных, так как
процессор, вместо того, чтобы выполнять вычисления, простаивает.
То же самое относится и к функции MPI_Recv.
Итак, чтобы избежать замедления исполнения, нужно
использовать другой способ организации работы позволять
пользователям начинать посылку (и получение) нескольких
сообщений и продолжать выполнение других операций. MPI
поддерживает этот подход, предоставляя неблокирующие посылки и
прием.
Неблокирующий обмен
Неблокирующим аналогом MPI_Send является функция
MPI_Isend. Функция MPI_Isend начинает неблокиpующую операцию
передачи. Аргументы этой процедуры такие же, как у MPI_Send, с
добавлением handle вслед за последним аргументом. Обе функции
(MPI_Send и MPI_Isend) ведут себя одинаково, за исключением того,
что в случае MPI_Isend буфер с посылаемым сообщением не должен
модифицироваться до тех пор, пока сообщение не будет доставлено
(более точно, до завершения операции, что можно выяснить с
помощью процедур MPI_Wait или MPI_Test). Причины такого
ограничения вполне понятны: в течение операции передачи данные не
должны изменяться. Параметр handle имеет тип MPI_Request и
используется для того, чтобы определить, было ли сообщение
доставлено. Необходимая проверка осуществляется с помощью
функции MPI_Test.
Процедура MPI_Irecv начинает неблокирующую операцию
приема. Она имеет один дополнительный аргумент, handle, точно так
же, как MPI_Isend. В то же время она имеет на один аргумент меньше:
status-аргумент, который используется для возврата информации по
окончанию приема, исключен из списка аргументов. Точно так же,
как для MPI_Isend, для проверки завершения приема, начатого
MPI_Irecv, можно использовать MPI_Test, а для ожидания завершения
96
такого приема − MPI_Wait. Аргументы status этих двух процедур
возвращают информацию о завершенном приеме в том же виде, что и
MPI_Recv для блокирующего приема.
Во многих случаях необходимо проверить или ждать
завершения многих неблокирующих операций. Хотя можно просто
циклически исполнять несколько таких операций, такой подход
неэффективен, так как он приводит к бесцельной трате
процессорного времени. MPI обеспечивает ожидание всех или какой-
либо из набора неблокирующих операций (с помощью MPI_Waitall и
MPI_Waitany) и проверки всех или какой-либо из набора
неблокирующих операций (с помощью MPI_Testall и MPI_Testany).
Синхронный блокирующий обмен
MPI предоставляет способ передачи сообщения, при котором
возврат из процедуры передачи не происходит до тех пор, пока
адресат не начнет принимать сообщение. Это процедура MPI_Ssend.
Аргументы этой процедуры идентичны MPI_Send. Отметим, что MPI
разрешает реализацию MPI_Send в виде MPI_Ssend; таким образом,
максимальная переносимость гарантируется тем, что любое
использование MPI_Send может быть замещено MPI_Ssend.
Если процесс выполняет блокирующую синхронную передачу, то он
будет приостановлен до приема адресатом сообщения. Синхронный
обмен сообщениями происходит медленнее, чем стандартный, но он
является более надежным и предпочтительным в плане обеспечения
предсказуемости выполнения программ.
Буферизованный обмен
Буферизованная передача выполняется с использованием
функции: int MPI_Bsend(void* buffer,int count,MPI_Datatype
datatype,int dest,int tag,MPI_Comm comm).
Параметры идентичны MPI_Send. Управление процессу
передается сразу же после копирования сообщения в буфер. Буфер
97
для копирования данных выделяется системой или создается
программистом при помощи функции: int MPI_Buffer_attach(void* buffer,int size).
После завершения работы буфер уничтожается: int MPI_Buffer_detach(void* buffer,int size).
Память для копирования сообщений должена быть достаточного
размера; при переполнении буфера возникает ошибка.
Обмен по готовности
Обмен по готовности должен начинаться только в том случае,
если начата соответствующая процедура приема, в противном случае
результат функции не определен. Завершается процедура сразу.
Передача по готовности осуществляется с помощью процедуры int MPI_Rsend(void* buffer, int count, MPI_Datatype
datatype, int dest, int tag, MPI_Comm comm).
Параметры идентичны MPI_Send.
Выполнение операций приема и передачи одной функцией
В MPI есть группа интересных процедур, совмещающих
функции приема и передачи. Они достаточно часто применяются при
программировании «каскадных» или «линейных» схем, когда
необходимо осуществлять обмен однотипными данными между
процессорами. Примером является функция: int MPI_Sendrecv (void* sendbuffer, int
sendcount, MPI_Datatype senddatatype, int dest, int
sendtag, void* recvbuffer, int recvcount,
MPI_Datatype recvdatatype, int src, int recvtag
MPI_Comm comm, MPI_Status* status),
где sendbuffer − адрес массива передаваемых данных
- sendcount − количество элементов в массиве;
- senddatatype− тип передаваемых элементов;
- dest − ранг адресата;
- sendtag − тег передаваемого сообщения;
- recvbuffer − адрес буфера для приема;
98
- recvcount − количество элементов в буфере приема;
- recvdatatype − тип элементов в буфере приема;
- src − ранг источника;
- recvtag − тег принимаемого сообщения;
- comm – коммуникатор;
- status − структура с дополнительной информацией.
Функция копирует данные из массива sendbuffer процесса с
рангом src в буфер recvbuffer процесса с рангом dest.
Типы данных
При рассмотрении функций передачи сообщений MPI в качестве
одного из аргументов этих функций передавался тип данных для
посылаемых и получаемых сообщений. В рассмотренных до этого
примерах использовались только элементарные типы данных,
которые соответствуют базовым типам данных в используемом языке
программирования − целым числам, числам с плавающей точкой
и т. п., а также их массивам. В этом разделе обсудим весь набор
базовых типов и, кроме того, рассмотрим способы конструирования
производных типов MPI.
Базовые типы данных в MPI
MPI предоставляет широкий набор элементарных типов данных.
Этот набор включает все базовые типы «Си», а также два типа данных,
специфичных для MPI: MPI_BYTE и MPI_PACKED. MPI_BYTE
описывает байт, который определяется как 8 двоичных цифр. Этот тип
не тождественен MPI_CHAR и MPI_CHARACTER. Во-первых,
MPI_BYTE гарантированно представляет числа в диапазоне [0..255], в
то время как char, в зависимости от реализации, может быть и
16-битным. Вторая причина в том, что в гетерогенной (неоднородной)
среде машины литеры могут иметь различные кодировки.
Коллективные операции
До сих пор рассматривались взаимодействия, в которых
участвуют два процесса: один передает сообщение, другой
99
принимает. MPI поддерживает более сложные типы взаимодействий,
которые предполагают участие нескольких (возможно, более двух)
процессов. Такие операции называют коллективными. Коллективные
операции широко используются при написании программ MPI.
Это связано не только с естественностью таких операций (часто
используемые алгоритмы предполагают рассылку данных всем
вычислительным процессам, или наоборот, сборку рассчитанных
данных на корневом процессе), но и высокой эффективностью таких
операций. Однако прежде чем перейти к рассмотрению этих операций
MPI, необходимо более глубоко ознакомиться с понятием
коммуникатора.
Коммуникаторы
Как уже говорилось ранее, весь обмен данных в MPI
осуществляется в рамках коммуникаторов, которые определяют
контекст обмена и группу процессов, с ними связанных. До сих пор
использовали только предопределенный коммуникатор
MPI_COMM_WORLD, определяющий единый контекст и
совокупность всех выполняющихся процессов MPI. В MPI имеются
средства создания и изменения коммуникаторов, предоставляющие
возможность программисту создавать собственные группы процессов,
что делает возможным использование в программах достаточно
сложных типов взаимодействия. Типичной проблемой, которую
может решить использование коммуникаторов, является проблема
недопущения «пересечения» обменов по тегам. В самом деле, если
программист использует какую-то библиотеку параллельных методов,
то он часто не знает, какие теги использует библиотека при передаче
сообщений. В таком случае существует опасность, что тег,
выбранный программистом, совпадет с одним из тегов, используемых
библиотекой. Чтобы этого не произошло, программист может создать
собственный коммуникатор и выполнять операции обмена в его
рамках. Несмотря на то, что этот коммуникатор будет содержать те
100
же процессы, что и коммуникатор библиотеки, обмены в рамках этих
двух разных коммуникаторов «не пересекутся».
Управление группами
С понятием коммуникатора тесно связано понятие группы
процессов. Под группой понимают упорядоченное множество
процессов. Каждому процессу в группе соответствует уникальный
номер − ранг. Группа − отдельное понятие MPI, и операции с
группами могут выполняться отдельно от операций с
коммуникаторами, но операции обмена для указания области
действия всегда используют коммуникаторы, а не группы. Таким
образом, один процесс или группа процессов могут входить в
несколько различных коммуникаторов. С группами процессов в MPI
допустимы следующие действия:
- объединение групп;
- пересечение групп;
- разность групп.
Новая группа может быть создана только из уже существующих
групп. В качестве исходной группы при создании новой может быть
использована группа, связанная с предопределенным
коммуникатором MPI_COMM_WORLD. При ручном
конструировании групп может оказаться полезной специальная
пустая группа MPI_COMM_EMPTY.
Для доступа к группе, связанной с коммуникатором comm.,.
используется функция int MPI_Comm_group (MPI_Comm comm,MPI_Group *group).
Возвращаемый параметр group − группа, связанная с
коммуникатором. Далее, для конструирования новых групп могут
быть применены следующие действия:
− создание новой группы newgroup из группы oldgroup, которая
будет включать в себя n процессов, ранги которых задаются массивом
ranks
101
int MPI_Group_incl(MPI_Group oldgroup, int n, int
*ranks, MPI_Group *newgroup);
− создание новой группы newgroup из группы oldgroup, которая
будет включать в себя n процессов, ранги которых не совпадают с
рангами, перечисленными в массиве ranks int MPI_Group_excll(MPI_Group oldgroup, int n,
int *ranks, MPI_Group *newgroup);
− создание новой группы newgroup как разность групп group1 и
group2 int MPI_Group_difference(MPI_Group group1,
MPI_Group group2, MPI_Group *newgroup);
− создание новой группы newgroup как пересечение групп
group1 и group2 int MPI_Group_intersection(MPI_Group group1,
MPI_Group group2, MPI_Group *newgroup);
− создание новой группы newgroup как объединение групп
group1 и group2 int MPI_Group_union(MPI_Group group1, MPI_Group
group2, MPI_Group *newgroup);
− удаление группы group int MPI_Group_free(MPI_Group *group).
Получить информацию об уже созданной группе можно,
используя следующие функции:
− получение количества процессов в группе int MPI_Group_size(MPI_Group group, int *size);
− получение ранга текущего процесса в группе int MPI_Group_rank(MPI_Group group, int *rank).
Управление коммуникаторами
В MPI различают два вида коммуникаторов –
интракоммуникаторы, используемые для операций внутри одной
группы процессов, и интеркоммуникаторы − для обмена между
102
группами процессов. В большинстве случаев используются
интракоммуникаторы, поэтому далее говорить будем только о них.
Создание коммуникатора − операция коллективная (и должна
вызываться всеми процессами коммуникатора). Вызов
MPI_Comm_dup копирует уже существующий коммуникатор oldcom int MPI_Comm_dup (MPI_Comm oldcom,MPI_comm
*newcomm),
в результате будет создан новый коммуникатор newcomm,
включающий в себя те же процессы.
Для создания нового коммуникатора служит функция
MPI_Comm_create. int MPI_comm_create (MPI_Comm oldcom, MPI_Group
group, MPI_Comm *newcomm)
Вызов создает новый коммуникатор newcomm, который будет
включать в себя процессы группы group коммуникатора oldcomm.
Рассмотрим пример простой программы. #include "mpi.h"
#include <stdio.h>
int main(int argc,char* argv[]){
MPI_Group systemgroup;
MPI_Group mygroup;
MPI_Comm newcomm;
int size,rank;
int[2] ranks;
MPI_Init(&argc,&argv);
MPI_Comm_size(MPI_COMM_WORLD,&size);
MPI_Comm_rank(MPI_COMM_WORLD,&rank);
MPI_Comm_group(MPI_COMM_WORLD,systemgroup);
// получили группу процессов, связанную с
// коммуникатором MPI_COMM_WORLD
// в эту группу входят все процессы
ranks[0] = 1;
ranks[1] = 3;
103
MPI_Group_incl(systemgroup,2,ranks,&mygroup);
//новая группа содержит 2 процесса - 1 и 3
MPI_Comm_create(MPI_COMM_WORLD,mygroup,&newcomm);
//коммуникатор newcomm полностью готов к работе
MPI_Comm_free(&newcomm);
MPI_Group_free(&mygroup);
MPI_Finalize();
}
В программе создается новый коммуникатор, включающий в
себя процессы с рангами 1 и 3 из «старого» коммуникатора −
MPI_COMM_WORLD. Заметим, что теперь у 3-го процесса два ранга
− один глобальный (в рамках коммуникатора MPI_COMM_WORLD),
а другой − в рамках только что созданного коммуникатора newcomm.
Зачем нужны созданные пользователем коммуникаторы? Одна
причина, побуждающая их использовать, уже называлась − без них не
обойтись разработчикам библиотек. Вторая причина, по которой
приходится создавать собственные коммуникаторы, состоит в том,
что только с их помощью можно управлять более сложными, чем
«точка – точка», типами обменов.
Передача данных от одного процесса всем.
Широковещательная рассылка
При программировании параллельных задач часто возникает
необходимость разослать какую-то порцию данных всем процессам
сразу. Очевидно, что для решения этой задачи можно воспользоваться
рассмотренными ранее операциями двупроцессного обмена. MPI_Comm_size(MPI_COMM_WORLD,&size);
for (i=1; i<size; i++)
MPI_Send(&buf,buflen,MPI_INT,i,0,MPI_COMM_WORLD);
Однако такое решение неэффективно вследствие значительных
затрат на синхронизацию процессов. Поэтому в MPI появилась
специальная операция − операция широковещательной рассылки
104
int MPI_Bcast(void *buffer, int count,
MPI_Datatype datatype, int root, MPI_Comm comm).
Операция предполагает рассылку данных из буфера buffer,
содержащего count элементов типа datatype с процесса, имеющего номер
root, всем процессам, входящим в коммуникатор comm. Для пояснения
сказанного рассмотрим простую задачу. Пусть нам требуется вычислить
скалярное произведение двух векторов, причем векторы вводятся на
нулевом процессе (например, считываются из файла). Ниже представлен
текст соответствующей программы: #include "mpi.h"
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
double x[100], y[100];
double res, p_res = 0.0;
MPI_Status status;
int n, myid, numprocs, i, N;
N = 100;
/* инициализация MPI */
/* выяснение числа процессов и рангов */
MPI_Init(&argc,&argv);
MPI_Comm_size(MPI_COMM_WORLD,&numprocs);
MPI_Comm_rank(MPI_COMM_WORLD,&myid);
/* ввод векторов */
if (0 == myid) read_vectors(x,y)
/*рассылка векторов на все процессы*/
MPI_Bcast(x, N, MPI_DOUBLE, 0, MPI_COMM_WORLD);
MPI_Bcast(y, N, MPI_DOUBLE, 0, MPI_COMM_WORLD);
/*вычисление частичной суммы на каждом из
процессов*/
for (i = myid * N/numprocs; i < (myid + 1)*N/
numprocs; i++)
105
p_res = p_res + x[i] * y[i];
/* сборка на 0-м процессе результата*/
if (0 == myid){
for (i=1; i< numprocs; i++)
MPI_Recv(&res, 1, MPI_DOUBLE, i, MPI_ANY_TAG,
MPI_COMM_WORLD, &status);
p_res = p_res+res;
}else /*все процессы отсылают частичные суммы на
0-й*/
MPI_Send(&p_res,1,MPI_DOUBLE,0,0,MPI_COMM_WORLD);
/*на 0-м печатаем результат*/
if (0 == myid) printf("\nInner product =
%10.2f",p_res);
MPI_Finalize();
}
В рассмотренной программе сначала производится
инициализация MPI. Затем выясняются ранг процесса и общее
количество процессов. Затем на 0-м процессе происходит чтение
данных и заполнение векторов. Нужно обратить внимание, что только
на 0-м процессе массивы x и y содержат данные; на всех остальных
процессах в этих массивах находятся не инициализированные
данные! 0-й процесс рассылает данные на все остальные процессы.
Это обеспечивается двумя вызовами функции MPI_Bcast: первый
вызов рассылает вектор x, второй вызов − вектор у. Следует обратить
внимание на следующие обстоятельства:
− вызов функции MPI_Bcast присутствует во всех процессах.
Таким образом, на 0-м процессе этот вызов обеспечивает отправку
данных, а на остальных − их приемку. Ранг процесса, с которого
осуществляется рассылка данных, задается параметром root;
− данные отправляются из области памяти buffer (в нашем
случае − из массива x) и принимаются в ту же область памяти, только
на другом процессе;
106
− данные рассылаются всем процессам в рамках коммуникатора.
Таким образом, если необходимо, например, на одну часть
процессов разослать одно, а на другую − другое, необходимо будет
создать два коммуникатора и выполнять соответствующую операцию
широковещательной рассылки в каждом из них.
Передача данных от всех процессов одному. Операции
редукции
В рассмотренной в предыдущем разделе задаче возникает еще
одна проблема − собрать рассчитанные на каждом из процессов
частичные суммы на 0-м процессе. Приведенный выше код решает
эту проблему неэффективно − с помощью уже знакомого цикла
приема сообщений от всех процессов. MPI предоставляет
возможность решить эту задачу по-другому, используя обратную по
отношению к широковещательной рассылке операцию − операцию
сбора данных или редукцию. Операция редукции позволяет, собрав на
одном из узлов данные, посланные остальными узлами, выполнить
над ними какую-либо из групповых операций: сложения, поиска
максимума, минимума, среднего значения и т. д. int MPI_Reduce(void *sendbuf, void *recvbuf, int
count, MPI_Datatype datatype, MPI_Op op, int root,
MPI_Comm comm),
где sendbuf − данные, которые посылаются на каждом из
процессов;
− recvbuf −адрес буфера, в который будет помещен результат;
− count − количество элементов в буфере sendbuf;
− datatype − тип элементов в буфере sendbuf;
− op − коллективная операция, которая должна быть выполнена
над данными;
− root − ранг процесса, на котором должен быть собран
результат;
107
− comm − коммуникатор, в рамках которого производится
коллективная операция.
В качестве коллективных операций можно использовать
предопределенные в MPI операции, такие как MPI_SUM, MPI_MIN,
MPI_MAX и другие (всего их 12). Кроме того, имеется возможность
определить свою операцию 5. С учетом всего предыдущую
программу можно переписать следующим образом: #include "mpi.h"
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
double x[100], y[100];
double res, p_res = 0.0;
MPI_Status status;
int n, myid, numprocs, i, N;
N = 100;
/* инициализация MPI */
/* выяснение числа процессов и рангов */
MPI_Init(&argc,&argv);
MPI_Comm_size(MPI_COMM_WORLD,&numprocs);
MPI_Comm_rank(MPI_COMM_WORLD,&myid);
/* ввод векторов */
if (0 == myid) read_vectors(x,y)
/*рассылка векторов на все процессы*/
MPI_Bcast(x, N, MPI_DOUBLE, 0, MPI_COMM_WORLD);
MPI_Bcast(y, N, MPI_DOUBLE, 0, MPI_COMM_WORLD);
/*вычисление частичной суммы на каждом из
процессов*/
for (i = myid *N/numprocs; i < (myid +
1)*N/numprocs; i++)
p_res = p_res + x[i] * y[i];
/* сборка на 0-м процессе результата*/
108
MPI_Reduce(p_res,res,N/numprocs,MPI_DOUBLE,MPI_SUM,0,
MPI_COMM_WORLD)
if (0 == myid) printf("\nInner product =
%10.2f",res);
MPI_Finalize();
}
Так же, как и в случае с MPI_Bcast, функция MPI_Reduce
должна вызываться во всех процессах, участвующих в сборке данных.
Sendbuf на всех процессах содержит адрес области данных, которые
будут участвовать в редукции. Значение recvbuf вычисляется только
на процессе с рангом root6. В случае, если значение recvbuf
необходимо получить на всех процессах, вместо процедуры
MPI_Reduce следует использовать процедуру MPI_Allreduce со
сходным синтаксисом.
Распределение и сбор данных
При программировании часто возникает задача распределения
массива данных по процессам некоторыми регулярными «кусками».
Например, распределение матрицы, нарезанной вертикальными
лентами. Возникает и обратная задача − сбор на некотором
выделенном процессе некоторого набора данных, распределенного по
всем процессам.
Распределение и сбор данных осуществляется с помощью
вызовов процедур MPI_Scatter и MPI_Gather. int MPI_Scatter(void* sendbuf, int sentcount,
MPI_Datatype senddatatype, void* recbuf, int
reccount, MPI_Datatype recdatatype,int root,MPI_Comm
comm),
где: − sendbuf − адрес буфера для передачи данных;
− sentcount − количество элементов, передаваемых на каждый
процесс (общее количество элементов в буфере равно произведению
sentcount на количество процессов в коммуникаторе);
− senddatatype − тип передаваемых данных;
109
− recbuf − буфер для приема данных;
− reccount − размер буфера recbuf;
− recdatatype − тип данных для приемки;
− root − ранг процесса, с которого рассылаются данные;
− comm – коммуникатор.
При вызове этой процедуры произойдет следующее. Процесс с
рангом root произведет передачу данных всем другим процессам в
коммуникаторе. Каждому процессу будет отправлено sendcount
элементов. Процесс с рангом 0 получит порцию из sendbuf, начиная с
0-го и заканчивая sendcount-1 элементом. Процесс с рангом 1 получит
порцию, начиная с sendcount, заканчивая 2* sendcount-1 и т. д.
Подпрограмма MPI_Gather собирает данные от остальных
процессов. int MPI_Gather(void* sendbuf, int sentcount,
MPI_Datatype senddatatype, void* recbuf, int
reccount, MPI_Datatype recdatatype,int root,MPI_Comm
comm),
где sendbuf – адрес буфера для передачи данных;
− sentcount – количество элементов, передаваемое на главный
процесс;
− senddatatype – тип передаваемых данных;
− recbuf – буфер для приема данных;
− reccount - размер буфера recbuf;
− recdatatype – тип данных для приемки;
− root – ранг процесса, на котором собираются данные;
− comm – коммуникатор.
Посредством MPI_Gather каждый процесс в коммуникаторе
передает данные из буфера sendbuf на процесс с рангом root.
Этот «ведущий» процесс осуществляет склейку поступающих данных
в буфере recbuf. Склейка данных осуществляется линейно, положение
пришедшего фрагмента данных определяется рангом процесса, его
110
приславшего. В целом процедура MPI_Gather обратна по своему
действию процедуре MPI_Scatter.
Следует заметить, что при использовании MPI_Gather сборка
осуществляется только на одном процессе. Во всех остальных
процессах заполнение буфера recbuf не определено. Для некоторых
задач необходимо, чтобы данные, рассчитанные на каждом из
процессов, были собраны в единый объект опять же на каждом
процессе. В таком случае вместо функции MPI_Gather следует
использовать функцию MPI_Allgather. При использовании функции
MPI_Allgather на всех процессах в буфере recbuf будут собраны
одинаковые данные – «большой» объект, полученный как
объединение фрагментов, переданных с каждого из процессов.
111
7. Грид
В прогнозе аналитики Gartner включили вычисления в памяти
(In-Memory Computing, IMC) в десятку наиболее «горячих»
технологий, аргументируя свой выбор тем, что распространение
IMC позволит заметно усовершенствовать работу с Большими
Данными в реальном времени и даст возможность обрабатывать
множество одновременно происходящих событий. Эти аргументы
в пользу преимуществ работы в памяти не новость, но тем не
менее до сих пор широкое распространение решений IMC
сдерживала дороговизна памяти DRAM. Однако ситуация
меняется, память становится доступнее, что делает IMC
привлекательнее, а получающие все более широкое
распространение флэш-накопители пока не могут составить
конкуренцию DRAM по быстродействию [17].
Во всей полноте разнообразие подходов к IMC можно,
например, представить в виде стека (рис. 17), но здесь
ограничимся одной, возможно наиболее перспективной и наиболее
новой из областей IMC – гридами данных в памяти (In-Memory
Data Grid, IMDG) и вычислительными гридами в памяти
(In-Memory Compute Grid, IMCG), а также их связью между собой
и с СУБД в памяти (In-Memory Database, IMDB). Следует
отметить, что во многих случаях сложно провести грань между
различными ипостасями гридов в памяти, то есть определить,
является ли данный грид вычислительным или гридом данных.
Более того, часто говорят вообще о полной интеграции этих двух
типов гридов.
112
Рис. 17. In-Memory Computing – от приложений до оборудования; гриды данных
Основным стимулом к появлению IMDG является практика
работы с MapReduce в форме Hadoop, показавшая, что технология
Hadoop независимо от ее конкретной реализации хорошо подходит
для обработки больших массивов, но у нее есть серьезные
врожденные ограничения – данные должны быть накопленными и
историческими, а обрабатываться исключительно в пакетном режиме.
Как следствие, технология Hadoop оказывается слишком медленной,
громоздкой при работе с оперативными данными и непригодной к
использованию в реальном времени. Кроме того, непрогнозируемые
размеры данных и их многообразие предъявляют повышенные
требования к надежности платформы. Под влиянием этих факторов
складываются условия, побуждающие возвратиться к идее гридов.
Гриды появились в восьмидесятые годы, когда казалось, что они
смогут решить насущную на тот момент проблему использования
113
ресурсов временно простаивающих компьютеров, но постепенно
актуальность этой задачи сошла на нет, а само ее решение оказалось
намного сложнее, чем предполагалось. В итоге кластеры потеснили
гриды. Нынешняя реинкарнация гридов объясняется органической
способностью их архитектуры удовлетворить требованию «трех V»
для средств работы с Большими Данными: velocity – высокая
скорость работы в памяти, variability – способность хранить в гридах
самые разнообразные данные, volumes — объемы хранения данных в
гридах теоретически бесконечны. IMDG оказались подходящим
средством для хранения Больших Данных, причем удешевление памяти
можно назвать необходимым условием появления IMDG, а к числу
достаточных можно отнести массовое распространение 64-разрядной
адресации и многоядерной процессорной архитектуры. Движение в
сторону IMDG началось с появления кэшей данных в памяти, которые
постепенно эволюционировали в полноценные гриды памяти.
Способность непрерывно анализировать большие объемы данных,
выделяя скрытые образы и тенденции, позволяет создавать системы,
приближенные к живым организмам, и серьезная роль здесь
принадлежит IMDG, способным работать с данными на скорости,
измеряемой терабайтами в секунду.
In Memory Data Grid – это не реляционная СУБД и даже не СУБД,
резидентная в памяти (IMDB), но и не СУБД типа NoSQL. Это готовый к
использованию продукт, обладающий следующими качествами:
- модель данных построена по принципу «ничего общего»
(shared nothing) и предполагает распределение данных между
множеством физически разнесенных серверов;
- модель данных может быть объектной или с хранением по
ключам (key-value);
- все серверы равнозначны, а все данные хранятся в их
оперативной памяти;
114
- для изменения размеров оперативной памяти серверы могут
подключаться или отключаться без нарушения работы
инфраструктуры грида;
- поддерживаются приложения на .NET или Java;
- конструкция грида является отказоустойчивой с возможностью
автоматического обнаружения вышедших из строя серверов.
По сравнению с реляционными СУБД у IMDG есть заметные
преимущества: по производительности – память намного быстрее
дисков, а прямой доступ избавляет от попыток предсказания при
чтении; по гибкости – структура данных с доступом по ключам
представляет большую свободу разработчикам приложений,
которые могут изменять связь между моделью данных и
приложением. Нет необходимости думать о контенте или форматах,
то, что нужно, помещается под ключом, оно же и получается
обратно.
С программной точки зрения IMDG можно рассматривать как
распределенное хранилище объектов с интерфейсом, похожим на
интерфейс с согласованной неблокирующей структурой данных
(Concurrent HashMap) в Java. В хранилище содержатся объекты с
ключами, причем объекты могут быть любыми, а не только
массивами байтов или строками, что дает гибкость – можно хранить
точно те объекты, которые требует бизнес-логика. Способность
работы с объектами отличает IMDG от IMDB, от СУБД NoSQL и
NewSQL, а IMDG вообще отличает возможность распределения по
множеству серверов. По существу, IMDG можно рассматривать как
карты хэша, при котором каждый ключ кэшируется на
определенном узле, и чем больше узлов, тем больше размер кэша.
Задача состоит в том, чтобы разместить данные по узлам таким
образом, чтобы локализовать данные – исключить в процессе
обработки обмен данными между узлами. В идеале IMDG вообще
исключает миграцию данных и обладает стабильной топологией.
115
По надежности хранения IMDG не уступают реляционным базам:
поддерживаются требования ACID (Atomicy – «атомарность»,
Consistency – «согласованность», Isolation – «изолированность»,
Durability – долговечность) и, в отличие от NoSQL, данные всегда
непротиворечивы.
В спектре применений grid можно выделить несколько
направлений, для которых преимущества такой архитектуры наиболее
очевидны.
Высокопроизводительные вычисления. Grid может обеспечить
значительную экономию при решении вычислительных задач,
предъявляющих высокие требования к процессорной мощности и
хорошо поддающихся распараллеливанию. Традиционное для
научной сферы применение архитектуры grid оказывается выгодным
и коммерческим предприятиям, поскольку позволяет за приемлемые
время и деньги решать задачи, прежде недоступные из-за высоких
требований к производительности. В сравнении с суперкомпьютерами
соотношение цены и производительности оказывается в пользу grid,
построенного на базе стандартных, недорогих аппаратных
компонентов вроде Intel-серверов или, например, современных
серверов-лезвий.
Конечно, такие предприятия должны быть связаны с
определенным кругом проблем, включающим в себя, например,
задачи вычислительной химии, поисковые механизмы в интернете,
фармацевтические разработки, моделирование климатических
условий, электронных компонентов, расчетные задачи в финансовой
сфере, обработку данных сейсмической разведки, а также
изображений и сигналов. Однако надо помнить, что перенос
приложений в такую среду, возможно, потребует дополнительных
усилий по их распараллеливанию.
Консолидация и организация совместной работы с данными.
Grid-архитектура обеспечивает возможность консолидации данных
116
таким образом, чтобы данные из различных источников и разной
структуры (реляционные базы, файлы, данные приложений) могли
быть представлены с помощью единого сервиса данных,
скрывающего особенности и сложности их размещения, локальной
принадлежности и прикладной инфраструктуры. Для реализации этой
возможности важна поддержка технологий виртуализации систем
хранения. Подобная интеграция данных полезна, в частности, для
приложений, ориентированных на руководителей: панели управления
эффективностью бизнеса, аналитических инструментов маркетинга,
управления взаимодействием с клиентами, систем поиска
закономерностей в данных (data mining).
Оптимизация загрузки ресурсов. Выделенное использование
настольных и серверных систем под нужды определенных
приложений приводит к неоптимальной загрузке их процессорных
ресурсов: как свидетельствует статистика, купленные в расчете на
пиковые нагрузки, они могут проводить в бездействии до 80%
рабочего времени. Среда grid позволяет использовать свободные
ресурсы простаивающих серверов для выполнения пакетных
заданий.
Вычислительные гриды
Для эффективного использования гридов нужно не только
распределить данные по узлам для хранения, но еще и обрабатывать
их на тех же узлах, где лежат данные. Эту задачу решают IMCG,
которые от IMDG отличаются ориентацией на исполнение
распределяемых по тем же узлам кодов. Тесная интеграция между
IMDG и IMCG основывается на том, что они представляют две
стороны одной медали.
Функциональность IMCG можно разделить на следующие
группы.
Внедрение и контроль использования (Distributed Deployment &
Provisioning). Неудобство и большие трудозатраты при выполнении
117
этих действий всегда было слабой стороной гридов, что затрудняло
их использование, а иногда делало это невозможным. Со времен
первых систем гридов (Globus, Grid Engine, DataSynapse, Platform
Computing) и до Hadoop в большинстве проектов внедрение и
внесение серьезных изменений были связаны с большим объемом
ручной работы по перестройке библиотек и повторному запуску всех
сервисов. Распределенность архитектуры IMCG усиливает эту
проблему, поэтому соответствующие технологии, например GridGain,
включают средства, снижающие трудозатраты.
Распределенное управление ресурсами (Distributed Resources
Management). Сюда входит управление физическими устройствами,
виртуальными машинами и операционными системами. В IMCG
одной из важнейших функций является автоматическое поддержание
топологии и обнаружение изменений. Согласованность топологии
необходима для того, чтобы все узлы «видели» все изменения (выход
из строя узлов, подключение новых) единообразно.
Распределенные модели исполнения (Distributed Execution
Models). Эти модели и превращают IMCG в вычислительную
инфраструктуру. Таких моделей может быть несколько, и наиболее
распространенная относится к классу «разветвление с
объединением» (fork-join type) или MapReduce – разделение задачи
на множество подзадач по какому-либо признаку, а затем их
объединение в виде итогового результата. Наиболее популярна
реализация MapReduce, известная как Hadoop, полностью
ориентированная на работу с дисками, а MapReduce в реализации
GridGain делает примерно то же самое, но в оперативной памяти. В
моделях исполнения поддерживаются архитектуры с массовым
параллелизмом (Massively Parallel Processing, MPP) и удаленный
вызов процедур (Remote Procedure Call, RPC), а также
распределенные вычисления с обменом сообщениями, потоковые
вычисления и обработка сложных событий.
118
MapReduce
Фреймворк для параллельной обработки больших объемов
сырых данных. Итак, типичная реализация этого алгоритма получает
на вход 3 аргумента: исходную коллекцию, Map-функцию, Reduce-
функцию, – и возвращает новую коллекцию данных после обработки. Collection MapReduce(Collection source, Function
map, Function reduce)
Алгоритм состоит из нескольких шагов. В качестве первого
шага выполняется Map-функция к каждому элементу исходной
коллекции. Map вернет ноль либо создаст экземпляры Key/Value
объектов. ArrayOfKeyValue Map(object itemFromSourceCollection)
То есть, можно сказать, что обязанность Map-функции
конвертировать элементы исходной коллекции в ноль или несколько
экземпляров Key/Value объектов. Это продемонстрировано ниже на
изображении:
Рис. 18. Map-функции
Следующим шагом, алгоритм отсортирует все пары Key/Value
и создаст новые экземпляры объектов, где все значения (value) будут
сгруппированы по ключу.
119
Рис. 19. Сопоставление «ключ-значение»
Последним шагом выполнится функция Reduce – для каждого
сгруппированного экземпляра Key/Value объекта
ItemResult Reduce(KeyWithArrayOfValues item)
В заключении, функция Reduce вернет новый экземпляр
объекта, который будет включен в результирующую коллекцию.
Рис. 20. Сопоставление «ключ-значение»
GridGain
GridGain − это основанное на Java промежуточное программное
обеспечение для обработки внутри памяти больших данных в
распределенной среде. Основано на высокопроизводительных
платформах данных внутри памяти, в которую интегрирована самая
быстрая в мире реализации MapReduce с технологией In-Memory Data
Grid, обладающей простотой в использовании и простотой в
120
масштабировании. GridGain является бесплатной реализацией
MapReduce с открытым исходным кодом на языке Java.
Работа MapReduce состоит из двух шагов: Map и Reduce. На
Map-шаге происходит предварительная обработка входных данных.
Для этого один из компьютеров (называемый главным узлом – master
node) получает входные данные задачи, разделяет их на части и
передает другим компьютерам (рабочим узлам – worker node) для
предварительной обработки. На Reduce-шаге происходит свертка
предварительно обработанных данных. Главный узел получает ответы
от рабочих узлов и на их основе формирует результат – решение
задачи, которая изначально формулировалась.
Задача In-Memory Data Grid – обеспечить сверхвысокую
доступность данных посредством хранения их в оперативной памяти
в распределенном состоянии. Современные In-Memory Data Grid
способны удовлетворить большинство требований к обработке
больших массивов данных.
Философия системы GridGain такова, что специалисту
необходимо развернуть узлы на некоторых компьютерах,
подключенных в сеть, и они автоматически должны найти друг друга
и создать топологию. Так же специалист может сам указать на одном
узле адрес другого узла в этой сети. Все, что необходимо после этого,
это создать задачи для этих узлов. Задачи создаются с помощью
программ, написанных на JAVA. Цель работы данных программ
заключается в указании данных и участка кода, который будет их
обрабатывать на каждом узле.
Развертывание и настройка узла
Для развертывания GridGain в первую очередь необходимо
скачать дистрибутив с официального сайта
(http://www.gridgain.com/), разархивировать его в любое место на
компьютере, задать переменные окружения GRIDGAIN_HOME и
121
JAVA_HOME (пути к папке инсталляции GridGain и виртуальной
машины JAVA соответственно). Далее, для проверки нужно лишь
запустить файл \bin\ggstart.bat (в случае, если используется
ОС Windows). В данном случае запустится узел GridGain с
настройками по умолчанию.
Запустив два узла на локальном компьютере или в локальной
сети, они обнаружат друг друга и создадут топологию (рис. 21).
Рис. 21. Результат запуска двух узлов с настройками по умолчанию
122
Когда запускается GridGain со стандартной конфигурацией,
запускается стандартная реализация Service provider interface (IP-multicast
обнаружение и основанная на TCP/IP связь). Название сети по
умолчанию «default». Путь к GridGain определяется переменной
среды GRIDGAIN_HOME. Многие другие настройки также задаются
по умолчанию.
Настройка GridGain осуществляется с помощью интерфейса
GridConfiguration. Эта конфигурация применима к методу
GridFactory.start(GridConfiguration). Так же возможна настройка с
помощью конфигурационных файлов Spring Framework, в частности,
если запуск производится с помощью пакетного bat-файла.
Стандартный файл настроек расположен по адресу \config\default-
spring.xml.
123
8. Основы облачных технологий
Первые идеи об использовании вычислений как публичной
услуги были предложены еще в 1960-х известным ученым в области
информационных технологий, изобретателем языка Lisp,
профессором MIT и Стэнфордского университета Джоном Маккарти
(John McCarthy). Реализация первого реального проекта
приписывается компании Salesforce.com, основанной в 1999 году.
Именно тогда и появилось первое предложение нового вида b2b
продукта «Программное обеспечение как сервис» («Software as a
Service», «SaaS»). Определенный успех Salesforce в этой области
возбудил интерес у гигантов ИТ индустрии, которые спешно
сообщили о своих исследованиях в области облачных технологий. И
вот уже первое бизнес-решение под названием «Amazon Web
Services» было запущено в 2005 году компанией Amazon.com, которая
со времен кризиса доткомов (dotcom, dot-com, dot.com; от англ. .com –
термин, применяющийся по отношению к компаниям, чья бизнес-
модель целиком основывается на работе в рамках сети Интернет)
активно занималась модернизацией своих датацентров. Следующим
свою технологию постепенно ввела Google, начав с 2006 года b2b
предложение SaaS сервисов под названием «Google Apps».
И, наконец, свое предложение анонсировала компания Microsoft,
презентовав ее на конференции PDC 2008 под названием «Azure
Services Platform» [18].
Сам факт высокой заинтересованности крупнейших игроков
рынка ИТ демонстрирует определенный статус облачных вычислений
как тренда 2009-2010 годов. Кроме того, с релизом Microsoft Azure
Service Platform множество экспертов связывает новый виток
развития веб-технологий и выход всей сферы облачных вычислений
на новый уровень.
124
Под облачными вычислениями мы понимаем программно-
аппаратное обеспечение, доступное пользователю через Интернет или
локальную сеть в виде сервиса, позволяющего использовать удобный
интерфейс для удаленного доступа к выделенным ресурсам
(вычислительным ресурсам, программам и данным).
На данный момент большинство облачных инфраструктур
развернуто на серверах датацентров, используя технологии
виртуализации, что фактически позволяет любому пользовательскому
приложению использовать вычислительные мощности, совершенно
не задумываясь о технологических аспектах. Тогда можно понимать
облако как единый доступ к вычислениям со стороны пользователя.
Виды облачных вычислений
С понятием облачных вычислений часто связывают такие
сервис-предоставляющие (Everything as a service) технологии, как:
- «Инфраструктура как сервис» («Infrastructure as a Service»,
или «IaaS»)
- «Платформа как сервис» («Platform as a Service», «PaaS»)
- «Программное обеспечение как сервис» («Software as a
Service», или «SaaS»).
8.1. Инфраструктура как сервис (IaaS)
IaaS это предоставление компьютерной инфраструктуры как
услуги на основе концепции облачных вычислений.
IaaS состоит из трех основных компонентов:
1. Аппаратные средства (серверы, системы хранения данных,
клиентские системы, сетевое оборудование).
2. Операционные системы и системное ПО (средства
виртуализации, автоматизации, основные средства управления
ресурсами).
3. Связующее ПО (например, для управления системами).
125
Рис. 22. Компоненты облачной инфраструктуры
IaaS основана на технологии виртуализации, позволяющей
пользователю оборудования делить его на части, которые
соответствуют текущим потребностям бизнеса, тем самым
увеличивая эффективность использования имеющихся
вычислительных мощностей. Пользователь (компания или
разработчик ПО) должен будет оплачивать всего лишь реально
необходимые ему для работы серверное время, дисковое
пространство, сетевую пропускную способность и другие ресурсы.
Кроме того, IaaS предоставляет в распоряжение клиента весь набор
функций управления в одной интегрированной платформе.
126
IaaS избавляет предприятия от необходимости поддержки
сложных инфраструктур центров обработки данных, клиентских и сетевых
инфраструктур, а также позволяет уменьшить связанные с этим
капитальные затраты и текущие расходы. Кроме того, можно
получить дополнительную экономию, при предоставлении услуги в
рамках инфраструктуры совместного использования.
Первопроходцами в IaaS считается компания Amazon, которые
на сегодняшний день предлагают два основных IaaS-продукта: EC2
(Elastic Compute Cloud ) и S3 (Simple Storage Service). Amazon Elastic
Compute Cloud (Amazon EC2) веб-сервис, который предоставляет
вычислительные мощности в облаке. Сервис входит в
инфраструктуру Amazon Web Services.
Простой веб-интерфейс сервиса позволяет получить доступ к
вычислительным мощностям и настроить с минимальными затратами
ресурсы. Он предоставляет пользователям полный контроль над
вычислительными ресурсами, а также доступную среду для работы.
Сервис сокращает время, необходимое для получения и загрузки
нового сервера.
Amazon Simple Storage Service (Amazon S3) онлайновая веб-
служба, предлагаемая Amazon Web Services, предоставляющая
возможность для хранения и получения любого объема данных, в
любое время из любой точки сети, так называемый файловый хостинг.
С помощью Amazon S3 достигается высокая масштабируемость,
надежность, высокая скорость и недорогая инфраструктура хранения
данных. Впервые появилась в марте 2006 года в США и в ноябре 2007
года в Европе.
8.2. Платформа как сервис (PaaS)
PaaS это предоставление интегрированной платформы для
разработки, тестирования, развертывания и поддержки веб-
приложений как услуги.
127
Для разворачивания веб-приложений разработчику не нужно
приобретать оборудование и программное обеспечение, нет
необходимости организовывать их поддержку. Доступ для клиента
может быть организован на условиях аренды.
Такой подход имеет следующие достоинства:
- масштабируемость;
- отказоустойчивость;
- виртуализация;
- безопасность.
Масштабируемость PaaS предполагает автоматическое
выделение и освобождение необходимых ресурсов в зависимости от
количества обслуживаемых приложением пользователей.
PaaS как интегрированная платформа для разработки,
тестирования, разворачивания и поддержки веб-приложений позволит
весь перечень операций по разработке, тестированию и
разворачиванию веб-приложений выполнять в одной
интегрированной среде, исключая тем самым затраты на поддержку
отдельных сред для отдельных этапов.
Способность создавать исходный код и предоставлять его в
общий доступ внутри команды разработки значительно повышает
производительность по созданию приложений на основе PaaS.
Самым известным примером такой платформы является
AppEngine от Google, которая предлагает хостинг для веб-приложений
с возможностью покупать дополнительные вычислительные ресурсы
(например, для тестирования высоких нагрузок).
Google App Engine сервис хостинга сайтов и web-приложений
на серверах Google с бесплатным именем <имя_сайта>.appspot.com,
либо с собственным именем, задействованным с помощью служб
Google.
В отличие от многих обычных размещений приложений на
виртуальных машинах, таких как Amazon EC2, платформа App Engine
128
тесно интегрирована с приложениями и накладывает на
разработчиков некоторые ограничения. Конкурирующие среды
позволяют оперировать множеством программного обеспечения,
созданного под *NIX системами, в то время как App Engine требует от
разработчика обязательного использования языков программирования
Python, Java или Go (последний с мая 2011) и сохранения
информации в собственном хранилище (Datastore) подмножестве
проприетарной базы данных BigTable (en), являющейся ноу-хау
компании Google.
В системах веб-поиска и контекстной рекламы компании Yahoo
используется платформа Hadoop, ориентированная на передачу
больших объемов данных между сетевыми серверами. На базе Hadoop
построены HBase (аналог базы данных Google BigTable), а также
HDFS (Hadoop Distributed File System, аналог Google File System).
Еще одним ярким представителем PaaS являются продукты
компании Mosso:
- Cloud Sites – веб-хостинг (Linux, Windows, Mail) для
нагрузочных веб-проектов с возможностью расширять базовые
бесплатные − возможности за дополнительную плату (трафик,
хранилище данных, вычислительная мощность).
- Cloud Files − файловый cloud-хостинг с ежемесячной
погигабайтной оплатой за объем хранимых файлов. Управление
осуществляется через браузер, либо посредством API (PHP, Python,
Java, .NET, Ruby).
- Cloud Servers − почасовая аренда серверов (RAM в час), с
возможностью выбора серверной ОС. Можно изменять характеристики
сервера, но не в режиме реального времени. В скором времени
разработчики обещают сделать API для управления серверами.
Ну а в центре всей облачной инфраструктуры Microsoft
операционная система Windows Azure. Windows Azure создает
единую среду, включающую облачные аналоги серверных продуктов
129
Microsoft (реляционная база данных SQL Azure, являющаяся аналогом
SQL Server, а также Exchange Online, SharePoint Online и Microsoft
Dynamics CRM Online) и инструменты разработки (.NET Framework и
Visual Studio, оснащенная в версии 2010 года набором Windows Azure
Tools). Так, например, программист, создающий сайт в Visual
Studio 2010, может не выходя из приложения разместить свой сайт в
Windows Azure.
Windows Azure полноcтью реализует две облачные модели
платформы как сервиса (Platform as a Service, PaaS) и инфраструктуры
как сервиса (Infrastructure as Service, IaaS). Работоспособность
платформы Windows Azure обеспечивают 8 глобальных дата центров
Microsoft. В предложении публичного облака клиент оплачивает
только ресурсы и мощности, которые задействованы в приложение и
только за фактическое время использования этих ресурсов. Основные
особенности данной модели:
- оплата только потребленных ресурсов;
- общая, многопоточная структура вычислений;
- абстракция от инфраструктуры.
8.3. Программное обеспечение как сервис (SaaS)
Рис. 23. Вершина айсберга облачных технологий представлена SaaS
130
SaaS – модель развертывания приложения, которая
подразумевает предоставление приложения конечному пользователю
как услуги по требованию (on demand). Доступ к такому приложению
осуществляется посредством сети, а чаще всего посредством
Интернет-браузера. В данном случае основное преимущество модели
SaaS для клиента состоит в отсутствии затрат, связанных с
установкой, обновлением и поддержкой работоспособности
оборудования и программного обеспечения, работающего на нем.
Целевая аудитория конечные потребители.
В модели SaaS:
- приложение приспособлено для удаленного использования;
- одним приложением могут пользоваться несколько клиентов;
- оплата за услугу взимается либо как ежемесячная абонентская
плата, либо на основе суммарного объема транзакций;
- поддержка приложения входит уже в состав оплаты;
- модернизация приложения может производиться
обслуживающим персоналом плавно и прозрачно для клиентов.
С точки зрения разработчиков программного обеспечения,
модель SaaS позволит эффективно бороться с нелицензионным
использованием программного обеспечения, благодаря тому, что
клиент не может хранить, копировать и устанавливать программное
обеспечение.
Программное обеспечение в рамках SaaS можно рассматривать
в качестве более удобной и выгодной альтернативы внутренним
информационным системам.
Развитием логики SaaS является концепция WaaS (Workplace
as a Service – рабочее место как услуга). То есть клиент получает в
свое распоряжение полностью оснащенное всем необходимым для
работы ПО виртуальное рабочее место.
131
По недавно опубликованным данным SoftCloud спросом
пользуются следующие SaaS приложения (в порядке убывания
популярности):
- почта;
- коммуникации (VoIP);
- антиспам и антивирус;
- helpdesk;
- управление проектами;
- дистанционное обучение;
- CRM;
- хранение и резервирование данных.
Рис. 24. Сервисы SaaS имеют наибольшую потребительскую базу
Весьма схожими являются продукты iCloud (Apple), Azure
(Microsoft) и SmartCloud (IBM). Суть данных сервисов в том, что они
предоставляют пользователям доступ к хранению своих данных
(контакты, почта, файлы), а также для совместной работы нескольких
пользователей с документами.
132
Вопросами хранения пользовательских данных в интернете
озадачена и компания Google, которая разработала проект GDrive, он
представляет собой виртуальный жесткий диск, определяемый ОС как
локальный.
Также к SaaS относятся услуги Online backup, или, проще
говоря, резервное копирование данных. Пользователь просто платит
абонентскую плату, а сервисы сами автоматически в определенное
время шифруют данные с компьютера или другого устройства и
отправляют их на удаленный сервер, тем самым данные могут быть
доступны из любой точки земного шара.
Интересное применение cloud-технологиям нашли и
разработчики компьютерных игр: теперь современным компьютерам
и игровым приставкам не будут нужны мощные графические
адаптеры (видеокарты), ведь вся обработка данных и рендеринг будут
производиться cloud-серверами, а игроки будут получать уже
обработанное видео. Одним из первых заявил о себе сервис OnLive, и
совсем недавно об этом объявила и компания Sony, которая внедряет
данную идею в Playstation.
Согласно SaaS-концепции пользователь платит не
единовременно, покупая продукт, а как бы берет его в аренду.
Причем, использует ровно те функции, которые ему нужны.
Например, раз в год вам нужна некая программа, и чаще вы ее
использовать не собираетесь. Так зачем же покупать продукт,
который будет у вас лежать без дела? И зачем тратить на него место
(в квартире, если это коробка с диском, на винчестере, если это
файл)?
Конкуренция в облачной сфере привела к появлению
бесплатных сервисов. Именно по такому пути пошли два конкурента
– Microsoft и Google. Обе компании выпустили наборы сервисов,
позволяющих работать с документами. У Google это Google Docs, у
Microsoft – Office Web Apps.
133
При этом оба сервиса тесно взаимосвязаны с почтой (Gmail в
первом случае и Hotmail во втором) и файловыми хранилищами.
Таким образом, пользователя как бы переводят из привычной ему
оффлайн-среды в онлайн. Важно, что и Google, и Microsoft
интегрируют поддержку своих онлайн-сервисов во все программные
среды – как настольные, так и мобильные (напомним, что Google
создала ОС Android, а Microsoft – Windows Phone 7).
Если Apple интегрирует веб-сервисы в привычные приложения
операционной системы, то Google заходит с противоположной стороны:
разрабатываемая интернет-гигантом операционная система Chrome OS
представляет собой, фактически, один браузер, через который
пользователь взаимодействует с разветвленной сетью веб-сервисов. ОС
ориентирована на нетбуки, отмечаются очень низкие системные
требования и отсутствие необходимости самостоятельной установки
программ. То есть Google предоставляет преимущества облачной
концепции, декламируемые при работе с корпоративными клиентами,
обычным пользователям. Вместе с тем, очевидна невозможность
использования таких нетбуков в странах с недостаточно широким
проникновением широкополосного интернета. Потому что без
интернета нетбук на базе Chrome OS будет совершенно бесполезен.
Все три типа облачных сервисов взаимосвязаны, и представляют
вложенную структуру.
Рис. 25. Взаимосвязь облачных сервисов
134
Помимо различных способов предоставления сервисов
различают несколько вариантов развертывания облачных систем:
Частное облако (private cloud) используется для
предоставления сервисов внутри одной компании, которая является
одновременно и заказчиком, и поставщиком услуг. Это вариант
реализации облачной концепции, когда компания создает ее для себя
самой, в рамках организации. В первую очередь реализация private
cloud снимает один из важных вопросов, который непременно
возникает у заказчиков при ознакомлении с этой концепцией – вопрос
о защите данных с точки зрения информационной безопасности.
Поскольку облако ограничено рамками самой компании, этот вопрос
решается стандартными существующими методами. Для private cloud
характерно снижение стоимости оборудования за счет использования
простаивающих или неэффективно используемых ресурсов. А также
снижение затрат на закупки оборудования за счет сокращения
логистики (не думаем, какие сервера закупать, в каких
конфигурациях, какие производительные мощности, сколько места
каждый раз резервировать и т. д.).
В сущности, мощность наращивается пропорционально
растущей в целом нагрузке, вне зависимости от каждой возникающей
задачи, а в среднем. И становится легче и планировать, и закупать, и
реализовывать – запускать новые задачи в производство.
Публичное облако – используется облачными провайдерами для
предоставления сервисов внешним заказчикам.
Смешанное (гибридное) облако совместное использование
двух вышеперечисленных моделей развертывания.
Вообще одна из ключевых идей Cloud заключается как раз в
том, чтобы с технологической точки зрения разницы между
внутренними и внешними облаками не было, и заказчик мог гибко
перемещать свои задания между собственной и арендуемой ИТ-
инфраструктурой, не задумываясь, где конкретно они выполняются.
135
Рис. 26. Взаимосвязь облаков разных типов
Таким образом, эти технологии при совместном использовании
позволяют пользователям облачных вычислений воспользоваться
вычислительными мощностями и хранилищами данных, которые
посредством определенных технологий виртуализации и высокого
уровня абстракции предоставляются им как услуги.
Достоинства облачных вычислений
Рассмотрим основные преимущества и достоинства технологий
облачных вычислений.
Доступность и отказоустойчивость – всем пользователям из
любой точки, где есть интернет, с любого компьютера, где есть
браузер.
Клиентские компьютеры. Пользователям нет необходимости
покупать дорогие компьютеры с большим объемом памяти и дисков,
чтобы использовать программы через веб-интерфейс. Также нет
необходимости в СD и DVD приводах, так как вся информация и
программы остаются в облаке. Пользователи могут перейти с
136
обычных компьютеров и ноутбуков на более компактные и удобные
нетбуки.
Доступ к документам. Если документы хранятся в облаке, они
могут быть доступны пользователям в любое время и в любом месте.
Больше нет такого понятия, как забытые файлы: если есть Интернет
они всегда рядом.
Устойчивость к потере данных или краже оборудования. Если
данные хранятся в облаке, их копии автоматически распределяются
по нескольким серверам, возможно, находящимся на разных
континентах. При краже или поломке персональных компьютеров
пользователь не теряет ценную информацию, которую он к тому же
может получить с любого другого компьютера.
Надежность. Датацентры управляются профессиональными
специалистами, обеспечивающими круглосуточную поддержку
функционирования виртуальных машин. И даже если физическая
машина «рухнет», благодаря распределению приложения на
множество копий, она все равно продолжит свою работу. Это создает
определенный высокий уровень надежности и отказоустойчивости
функционирования системы.
Экономичность и эффективность плати столько, сколько
используешь, позволь себе дорогие, мощные компьютеры и
программы. Облако позволяет учитывать и оплачивать только
фактически потребленные ресурсы строго по факту их использования;
Аренда ресурсов. Обычные серверы средней компании
загружены на 10-15%. В одни периоды времени есть потребность в
дополнительных вычислительных ресурсах, в других эти
дорогостоящие ресурсы простаивают. Используя необходимое
количество вычислительных ресурсов в облаке в любой момент
времени, компании сокращают затраты на оборудование и его
обслуживание. Это дает возможность заказчику отказаться от закупок
дорогостоящих ИТ-активов в пользу даже не аренды, а
137
операционного потребления по мере надобности, при сокращении
затрат на обслуживание своих систем и получении от поставщика
гарантий уровня сервиса.
Аренда ПО. Вместо приобретения пакетов программ для
каждого локального пользователя, компании покупают нужные
программы в облаке. Данные программы будут использоваться только
теми пользователями, которым эти программы необходимы в работе.
Более того, стоимость программ, ориентированных на доступ через
Интернет, значительно ниже, чем их аналогов для персональных
компьютеров. Если программы используются не часто, то их можно
просто арендовать с почасовой оплатой. Затраты на обновление
программ и поддержку в работоспособном состоянии на всех рабочих
местах вовсе сведены к нулю.
Для поставщика ИТ-услуг экономический смысл облака состоит
в эффекте масштаба (обслуживать большой однородный центр
обработки дешевле, чем множество маленьких разнородных) и
сглаживания нагрузки (когда потребителей много, маловероятно, что
пиковые мощности понадобятся всем им одновременно).
Разработчики ПО тоже получают выгоду от перехода в облака:
теперь им стало проще, быстрее и дешевле разрабатывать,
тестировать под нагрузкой и предлагать клиентам свои решения – это
можно делать прямо в облаке с минимальными затратами. Кроме
того, Облачные вычисления это эффективный инструмент
повышения прибыли и расширения каналов продаж для независимых
производителей программного обеспечения в форме SaaS. Этот
подход позволяет организовать динамическое предоставление услуг,
когда пользователи могут производить оплату по факту и
регулировать объем своих ресурсов в зависимости от реальных
потребностей без долгосрочных обязательств.
Простота – не требуется покупка и настройка программ и
оборудования, их обновление.
138
Обслуживание. Так как физических серверов с внедрением
Cloud Computing становится меньше, их становится легче и быстрее
обслуживать. Что касается программного обеспечения, то последнее
установлено, настроено и обновляется в облаке. В любое время, когда
пользователь запускает удаленную программу, он может быть уверен,
что эта программа имеет последнюю версию без необходимости
что-то переустанавливать или платить за обновления.
Совместная работа. При работе с документами в облаке нет
необходимости пересылать друг другу их версии или
последовательно редактировать их. Теперь пользователи могут быть
уверенными, что перед ними последняя версия документа, и любое
изменение, внесенное одним пользователем, мгновенно отражается у
другого.
Открытые интерфейсы. Облако как правило, имеет
стандартные открытые API (интерфейсы прикладного
программирования) для связи с существующими приложениями и
разработки новых – специально для облачной архитектуры.
Гибкость и масштабируемость – неограниченность
вычислительных ресурсов (память, процессор, диски). Облако
масштабируемо и эластично – ресурсы выделяются и освобождаются
по мере надобности.
Производительные вычисления. По сравнению с персональным
компьютером вычислительная мощь, доступная пользователю
облачных компьютеров, практически ограничена лишь размером
облака, то есть общим количеством удаленных серверов.
Пользователи могут запускать более сложные задачи, с большим
количеством необходимой памяти, места для хранения данных тогда,
когда это необходимо. Иными словами, пользователи могут при
желании легко и дешево поработать с суперкомпьютером без каких-
либо фактических приобретений. Возможность запуска множества
копий приложения на многих виртуальных машинах представляет
139
преимущества масштабируемости: количество экземпляров
приложения способно практически мгновенно увеличиваться по
требованию, в зависимости от нагрузок.
Хранение данных. По сравнению с доступным местом для
хранения информации на персональных компьютерах объем хранилища
в облаке может гибко и автоматически подстраиваться под нужды
пользователя. При хранении информации в облаке пользователи могут
забыть об ограничениях, накладываемых обычными дисками, облачные
размеры исчисляются миллиардами гигабайт доступного места.
Инструмент для стартапов. У компаний, начинающих свой
бизнес основным преимуществом данной технологии является,
отсутствие необходимости закупать все соответствующее
оборудование и ПО, а затем поддерживать их работу.
Недостатки и проблемы облачных вычислений
Есть ли минусы у облачных вычислений? Почему облачные
технологии в России только набирают обороты, а директора
некоторых крупных компаний не спешат переводить
ИТ-инфраструктуру своих предприятий в облака? Итак, отметим
основные недостатки и трудности использования cloud computing:
Постоянное соединение с сетью. Cloud Computing почти всегда
требует соединения с сетью (Интернет). Если нет доступа в сеть нет
работы, программ, документов. Многие облачные программы требуют
хорошего Интернет-соединения с большой пропускной способностью.
Соответственно программы могут работать медленнее, чем на локальном
компьютере. По мнению ведущих российских ИТ-компаний, основным
препятствием широкому развитию облаков, является отсутствие
широкополосного доступа в Интернет (ШПД) – прежде всего в
регионах.
Безопасность
Безопасность данных теоретически может быть под угрозой.
Не все данные можно доверить стороннему провайдеру в интернете,
140
тем более не только для хранения, но еще и для обработки.
Все зависит от того, кто предоставляет облачные услуги. Если этот
кто-то надежно шифрует ваши данные, постоянно делает их
резервные копии, уже не один год работает на рынке подобных
услуг и имеет хорошую репутацию, то угрозы безопасности данных
может никогда не случиться. У пользователя облачных бизнес
приложений могут также возникнуть и юридические проблемы,
например связанные с выполнением требований защиты
персональных данных.
Государство, на территории которого размещен датацентр,
может получить доступ к любой информации, которая в нем
хранится. Например, по законам США, где находится самое большое
количество датацентров, в этом случае компания-провайдер даже не
имеет права разглашать факт передачи конфиденциальной
информации кому-либо, кроме своих адвокатов.
Эта проблема является, наверное, одной из самых существенных
в вопросе вывода конфиденциальной информации в облако. Путей ее
решения может быть несколько. Во-первых, можно шифровать всю
информацию, помещаемую на облако. Во-вторых, можно просто ее
туда не помещать. Однако, во всяком случае, у компаний,
пользующихся облачными вычислениями, это должно быть
определенным пунктом в списке вопросов информационной
безопасности. Кроме того, сами провайдеры должны улучшать свои
технологии, предоставляя некоторые услуги по шифрованию.
Функциональность облачных приложений
Не все программы или их свойства доступны удаленно.
Если сравнивать программы для локального использования и их
облачныe аналоги, последние пока проигрывают в
функциональности. Например, таблицы Google Docs или
приложения Office web application имеют гораздо меньше функций и
возможностей, чем Microsoft Excel.
141
Зависимость от облачного провайдера
Всегда остается риск, что провайдер онлайновых сервисов
однажды не сделает резервную копию данных, как раз перед
крушением сервера. Риск этот, впрочем, вряд ли превышает опасность
того, что пользователь сам упустит свои данные, потеряв или разбив
мобильник или ноутбук, не создав на домашнем ПК резервную
копию. Кроме того, привязавшись к той или иной услуге, мы в какой-
то степени также ограничиваем свою свободу – свободу перехода на
старую версию софта, выбора способов обработки информации и так
далее.
Некоторые эксперты, например Г. Маклеод (Hugh Macleod) в
статье «Самый хорошо охраняемый секрет облаков» утверждает, что
облачные вычисления ведут к созданию огромной, невиданной ранее
монополии. Возможно ли это? Конечно, на рынке облачных
вычислений для помещения в облако какой-либо информации, в
отношении которой существуют правила информационной
безопасности, компании будут скорее использовать таких вендоров,
чье имя «на слуху» и кому они доверяют. Таким образом, существует
определенная опасность того, что все вычисления и данные будут
агрегированы в руках одной сверхмонополии. Однако на данный
момент на рынке уже существуют несколько компаний с примерно
одинаковым высоким уровнем доверия со стороны клиентов
(Microsoft, Google, Amazon), и нет никаких фактов, которые бы
указывали на возможность доминирования одной компании. Поэтому
в ближайшем будущем появление глобальной сверхкомпании,
которая будет координировать и контролировать все вычисления в
мире, очень маловероятно, хотя одна лишь возможность такого
события отпугивает некоторых клиентов.
Препятствия развитию облачных технологий в России
Недостаточное доверие потребителей облачных услуг.
Нередко бизнес относится к облачным услугам несколько
142
настороженно. Причин же недоверчивого отношения малого и
среднего бизнеса к облачным датацентрам может быть несколько.
Скорее всего, это боязнь лишиться контроля над ИТ-ресурсами,
опасения насчет гарантии сохранности и защиты переданной
информации и представление датацентра лишь как площадки для
размещения оборудования.
Каналы связи в большинстве регионов страны характеризуются
отсутствием SLA по качеству предоставляемого сервиса (QoS). Что
толку от того, что ваш основной трафик идет по магистрали с
гарантированным QoS (со своими ограничениями), если конечные
условия подключены к ней через местного оператора, даже не
слышавшего о такой проблеме. При этом стоимость связи для
крупных организаций может составлять до 50% от ИТ-бюджета.
Соответственно переход к облачной модели существенно влияет на
сетевую топологию ваших потоков данных и, скорее всего, QoS будет
хуже, чем во внутренней сети. Или чтобы получить качество
обслуживания на приемлемом уровне, придется заплатить столько
денег, что вся экономия от централизации инфраструктуры или
приложений будет перечеркнута ростом коммуникационных затрат.
Безопасность. Проблема безопасности является серьезным
сдерживающим фактором. Нередко службы безопасности создают
довольно высокий заградительный барьер для идеи вынести какие-
либо данные за периметр своей сети. Часто без какой-либо вменяемой
аргументации.
Распределенные вычисления (grid computing)
Отметим в заключение еще одну технологию, которая, с одной
стороны, также оказала влияние на появление концепции облачных
вычислений, а, с другой стороны, имеет ряд существенных отличий.
Речь идет о коллективных, или распределенных вычислениях (grid
computing), когда большая ресурсоемкая вычислительная задача
распределяется для выполнения между множеством компьютеров,
143
объединенных в мощный вычислительный кластер сетью в общем
случае или интернетом, в частности.
Установление общего протокола в сети Интернет
непосредственно привело к быстрому росту онлайн пользователей.
Это привело к необходимости выполнять больше изменений в
текущих протоколах и к созданию новых. На текущий момент
обширно используется протокол Ipv4 (четвертая версия IP протокола),
но ограничение адресного пространства, заданного ipv4, неизбежно
приведет к использованию протокола ipv6. В течение долгого
времени усовершенствовалось аппаратное и программное
обеспечение, в результате чего удалось построить общий интерфейс в
Интернет. Использование веб-браузеров привело к использованию
модели облака, взамен традиционной модели информационного
центра.
В начале 1990-х, Иэн Фостер и Карл Кесселмен представили их
понятие Грид вычислений. Они использовали аналогию с
электрической сетью, где пользователи могли подключаться и
использовать услугу. Грид вычисления во многом опираются на
методах, используемых в кластерных вычислительных моделях, где
многократные независимые группы, действуют как сеть просто
потому, что они не все расположены в пределах той же области.
В частности, развитие Грид-технологий позволило создать так
называемые GRID-сети, в которых группа участников могла общими
усилиями решать сложные задачи. Так, сотрудники IBM создали
интернациональную команду grid-вычислений, позволившую
существенно продвинуться в области борьбы с вирусом иммунного
дефицита. Целые команды из разных стран присоединяли свои
вычислительные мощности и помогли «обсчитать» и смоделировать
наиболее перспективные формы для создания лекарства от СПИДа...»
На практике границы между этими (grid и cloud) типами
вычислений достаточно размыты. Сегодня с успехом можно
144
встретить облачные системы на базе модели распределенных
вычислений, и наоборот. Однако будущее облачных вычислений все
же значительно масштабнее распределенных систем, к тому же не
каждый облачный сервис требует больших вычислительных
мощностей с единой управляющей инфраструктурой или
централизованным пунктом обработки платежей.
Краткие итоги
Облачные вычисления (Cloud computing, cloud) – это модель
обеспечения повсеместного и удобного сетевого доступа по
требованию к группам вычислительных ресурсов (например, сетям,
серверам, системам хранения, приложениям, сервисам), которые
могут быть быстро предоставлены или возвращены с минимальными
усилиями по управлению и взаимодействию с поставщиком услуг.
Облачная модель обладает пятью основными свойствами и
состоит из трех моделей услуг и четырех моделей развертывания.
Основные свойства
Самообслуживание по требованию (On-demand self-service).
Потребитель имеет возможность получить доступ к предоставляемым
вычислительным ресурсам в одностороннем порядке, по мере
необходимости, автоматически, без необходимости взаимодействия с
сотрудниками каждого поставщика услуг.
Широкий сетевой доступ (Broad network access).
Предоставляемые вычислительные ресурсы доступны по сети через
стандартные механизмы для различных платформ (мобильных
телефонов, планшетов, ноутбуков, рабочих станций и т. п.).
Объединение ресурсов в группы (Resource pooling).
Вычислительные ресурсы поставщика объединяются в пулы для
обслуживания множества потребителей по модели множественной
аренды (multi-tenant). Пулы включают в себя различные физические и
виртуальные ресурсы, которые могут быть динамически назначены и
переназначены в соответствии с потребительским спросом.
145
Нет необходимости в понимании или управлении со стороны
потребителя точным местоположением ресурсов, однако возможно
указать местонахождение на более высоком уровне абстракции
(например, страна, регион или центр обработки данных). Примерами
такого рода ресурсов могут быть системы хранения, вычислительные
процессорные мощности, оперативная память, пропускная
способность сети.
Мгновенная эластичность (Rapid elasticity). Ресурсы могут быть
эластично выделены и освобождены (возвращены поставщику) в
кратчайшие сроки, в некоторых случаях автоматически, для быстрого
масштабирования соразмерно со спросом. Для потребителя
возможности для предоставления ресурсов могут видятся как
неограниченные, могут быть присвоены в любом количестве в любое
время.
Измеримость (Measured service). Облачные системы и сервисы
должны обладать функциями автоматизированного измерения,
управления и оптимизации использования ресурсов на уровне
абстракции, применительно для разного рода сервисов (например,
объемы хранения, обработка, полоса пропускания, или активные
пользовательские сессии). Использованные ресурсы могут
отслеживаться и контролироваться, что обеспечивает прозрачность
как для поставщика, так и для потребителя, использующего сервис.
Модели облачных услуг
Программное обеспечение как услуга (Software as a Service –
SaaS). Возможность предоставления потребителю в использование
приложений поставщика, работающих в облачной
инфраструктуре. Приложения доступны с различных клиентских
устройств или через интерфейсы тонких клиентов, такие, как
веб-браузер (например, веб-почта) или интерфейсы программ.
Потребитель при этом не управляет базовой инфраструктурой
облака, в том числе сетями, серверами, операционными системами,
146
системами хранения, или даже индивидуальными настройками
приложений, за исключением некоторых пользовательских
настроек конфигурации приложения.
Платформа как услуга (Platform as a Service – PaaS).
Возможность предоставления потребителю для развертывания на
облачной инфраструктуре потребительского, созданного или
приобретенного приложения, созданных с помощью языков
программирования, библиотек, служб и средств, поддерживаемых
поставщиком услуг. Потребитель при этом не управляет базовой
инфраструктурой облака, в том числе сетями, серверами,
операционными система и системами хранения данных, но имеет
контроль над развернутыми приложениями и, возможно, некоторыми
параметрами конфигурации среды хостинга.
Инфраструктура как услуга (Infrastructure as a Service – IaaS).
Возможность предоставления потребителю систем обработки,
хранения, сетей передачи данных и других фундаментальных
вычислительных ресурсов, в которых потребитель может развернуть
и запустить произвольное программное обеспечение, включающее в
себя операционные системы и приложения. Потребитель при этом не
управляет базовой инфраструктурой облака, но имеет контроль над
операционными системами, системами хранения и развернутыми
приложениями, и, возможно, ограниченно контролирует выбор
сетевых компонентов (например, хост с сетевыми экранами).
Модели развертывания
Частное облако (Private cloud). Облачная инфраструктура,
подготовленная для эксклюзивного использования единой
организацией, включающей несколько потребителей (например,
бизнес-подразделения либо входящие в состав единого холдинга
организации). Такое облако может находиться в собственности,
управлении и обслуживании самой организации, третьей стороны,
147
или какой-либо комбинации из них, и находится как на территории
организации, так и за ее пределами.
Облако сообщества (Community cloud). Облачная
инфраструктура, подготовленная для эксклюзивного использования
конкретного сообщества потребителей от организаций, имеющих
общие проблемы (например, миссии, требования безопасности,
политики и общие требования). Облако может находиться в
собственности, управлении и обслуживании одной или более
организаций в сообществе, третьей стороны или комбинации из
них, и находиться как на территории организаций, так и за их
пределами.
Общее (или публичное) облако (Public cloud). Облачная
инфраструктура, подготовленная для открытого использования
широкой публикой. Оно может находиться в собственности,
управлении и обслуживании деловыми, научными и
правительственными организациями или какой-либо их комбинацией.
Облако существует на территории облачного поставщика.
Гибридное облако (Hybrid cloud). Облачная инфраструктура
представляет собой композицию из двух или более различных
инфраструктур облаков (частные, общественные или
государственные), имеющих уникальные объекты, но связаны между
собой стандартизованными или собственными технологиями,
позволяющими переносить данные или приложения между
компонентами (например, для балансировки нагрузки между
облаками).
148
Сокращения
ГВС – глобальная вычислительная сеть;
ИС – информационные технологии;
КС – критической секцией;
ЛВС – локальная вычислительная сеть;
ПО – программное обеспечение.
Список контрольных вопросов
1. Понятия распределенного и параллельного приложений, области
применения, особенности построения.
2. Понятие параллельности. Синхронная и асинхронная
параллельность. Нити, мьютексы.
3. Доступ к данным и блокировка. Использование класса Thread.
4. Executors.
5. Параллельные циклы, параллельные запросы LINQ.
6. MPI-приложения для кластерных вычислений.
7. Платформа GridGain.
8. Особенности облачных приложений, особенности разработки
приложений для облака.
9. Разработка служб облачных приложений с использованием
Microsoft Visual Studio 2010.
10. Разработка клиентских приложений для распределенной системы.
149
Заключение
Данное пособие предназначено для формирования у студентов
способностей и навыков по разделению разрабатываемых
приложений на независимые части при создании параллельных
приложений или представление в виде совокупности сервисов в
случае создания распределенных приложений.
Пособие включает материал по разным технологиям
организации распределенных вычислений, а также содержит
практические примеры по созданию приложений для организации
таких вычислений.
Более подробную информацию по рассматриваемым разделам
можно найти в источниках из библиографического списка.
150
Библиографический список 1. Таненбаум, Э. Распределенные системы. Принципы и
парадигмы // Andrew S. Tanenbaum, Maarten van Steen.
«Destributed systems. Principles and paradigms». — Санкт-
Петербург : Питер, 2003. — 877 с.
2. Косяков, М. С. Введение в распределенные системы : учебное
пособие / М. С. Косяков— С.-Петербург, 2014. — 155 с.
3. Тель, Ж. Введение в распределенные алгоритмы : Пер. с англ. /
Ж. Тель. М. : МЦНМО, 2009. 616 с.
4. Kshemkalyani, A. D., Singhal M. Distributed Computing: Principles,
Algorithms, and Systems. Cambridge University Press. 2008.
5. Stallings, W. Operating Systems: Internals and design principles.
Seventh edition. Prentice Hall, 2011.
6. Taneiibaum, A. S., vanSteenM. Distributed Systems: Principles and
Paradigms. Second edition. Pearson Prentice HalL, 2007.
7. Tel, G. Introduction to Distributed Algorithms. Second edition.
Cambridge University Press. 2000.
8. Топорков, В. В. Модели распределенных вычислений /
В. В. Топорков. М. : Физматлит, 2004. 320 с.
9. Хьюз, К. Параллельное и распределенное программирование с
использованием C++. Пер. с англ / К. Хьюз, Т. Хьюз.
М.: Издательский дом «Вильямс». 2004. 672 с. : ил.
10. Эндрюс, Г. Р. Основы многопоточного, параллельного и
распределенного программирования : Пер. с англ. / Г. Р.
Эндрюс. М. : Издательский дом «Вильямс», 2003. 512 с.: ил.
11. Chandy, К. М., Lamport L. Distributed snapshots: determining
global states of distributed systems // ACM Transactions on
Computer Systems, 3(1), 1985.P.63-75.
12. Chandy, К. М., Misra J. The Drinking Philosophers Problem // ACM
TOPLAS, 6:4, October, 1984. P.632-646.
151
13. Chandy, K. M., Misra J. Parallel program design: a foundation.
Addison-Wesley, 1988.
14. ChaiTon-Bost B. Concerning the size of logical clocks in distributed
systems // Information Processing Letters, 39, 1991. P. 11-16.
15. Charron-Bost В., Tel G., Mattem F. Synchronous, asynchronous, and
causally ordered communication // Distributed Computing. 9(4).
1996. P.173-191.
16. Гришагин В.А., Свистунов А.Н. Параллельное
программирование на основе MPI. Учебное пособие – Нижний
Новгород: Изд-во ННГУ им.Н.И. Лобачевского, 2005. - 93 с.
17. Второе рождение гридов
https://www.osp.ru/os/2013/08/13037859/ (дата доступа
01.09.2014)
18. Основы облачных вычислений
http://www.intuit.ru/studies/courses/4081/529/lecture/11917 (дата
доступа 01.09.2014)
Учебное издание
РАСПРЕДЕЛЕННЫЕ ВЫЧИСЛЕНИЯ И ПРИЛОЖЕНИЯ
Учебное пособие
Составитель Романов Антон Алексеевич
Редактор Н.А. Евдокимова
ЭИ № 1127. Объем данных 5,5 Мб
ЛР № 020640 от 22.10.97
Подписано в печать 23.07.2018. Формат 60×84/16. Усл.печ.л. 8,84. Тираж 50 экз. Заказ № 584.
Ульяновский государственный технический университет,
432027, г. Ульяновск, Сев. Венец, д.32. ИПК «Венец» УлГТУ, 432027, г. Ульяновск, Сев. Венец, д.32.
Тел.: (8422) 778-113
E-mail: [email protected] venec.ulstu.ru
