Введение

Мотивация

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

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

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

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

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

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

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

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

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

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

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

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

Примеры распределенных систем

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

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

С одной стороны, Интернет является ярким примером системы, построенной по архитектуре P2P (о ней речь пойдет ниже), - все узлы в нем независимы. С другой стороны, если мы поднимемся на уровень сервисов, то увидим примеры практически всех известных архитектур.

Интернет, кроме того что является самой известной распределенной системой, видимо, является и самой большой из них.

Другим примером распределенной системы может служить интранет. Под интранетом обычно понимают сообщество сетей, объединенных по какому-либо признаку (сети крупного предприятия, например). В интранете представлены узлы, доступ к которым необходим для его пользователей. Это узлы, предоставляющие определенные сервисы, - серверы печати, серверы баз данных, файл-серверы, почтовые серверы, серверы приложений и т.д. Создание подобных сетей диктуется двумя основными потребностями - потребностью в обмене той или иной информацией и потребностью в обеспечении совместного доступа к "дорогим" разделяемым ресурсам (принтеры и другое разделяемое оборудование, доступ в Интернет, доступ к корпоративным данным и т.д.).

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

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

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

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

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

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

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

Предъявляемые требования

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

Открытость

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

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

Безопасность - важное свойство любой программной системы и распределенной в частности. Под безопасностью обычно понимают совокупность следующих свойств:

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

Важной проблемой при проектировании распределенного приложения является задача обеспечения качества обслуживания ( Quality of Service ). Под качеством обслуживания обычно понимают некие соглашения по выполнению запросов клиента (например, запрос должен обрабатываться не позднее, чем через 2 секунды после получения и т.д.). Жестким нарушением качества обслуживания является ситуация отказа в обслуживании ( Denial of Service ) - она может возникнуть, если злоумышленник бомбардирует сервер запросами, которые тот не успевает обрабатывать. Решение этой проблемы в общем виде может быть очень сложным, однако существуют рекомендации, позволяющие обходить ее в большинстве случаев. Другой важной проблемой безопасности является использование мобильного кода (кода, пришедшего по сети и исполняемого локально). Здесь решение состоит в применении интерпретируемого кода и виртуальных машин.

Масштабируемость

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

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

Обработка ошибок

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

Параллельность

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

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

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

Прозрачность

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

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

Управляемость

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

Сложность реализации

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

Зависимость от выбранной архитектуры

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

Гетерогенная среда

Поскольку различные части распределенного программного комплекса могут выполняться на разных узлах системы, которые могут отличаться аппаратной, сетевой, программной архитектурой, это влечет за собой серьезные проблемы в программировании таких систем. Достаточно сказать, что даже представление такого фундаментального понятия, как тип данных, зависит от используемого языка программирования и от аппаратной архитектуры. Наилучшим выходом из этой ситуации может считаться либо использование принятых и поддерживаемых стандартов (таких как протокол TCP/IP для сетевого взаимодействия или POSIX для системных вызовов), либо применение специальных промежуточных средств ( middleware ), маскирующих гетерогенность ( CORBA, Java RMI, . NET и т.д.). Интересным решением проблемы гетерогенности является использование виртуальных машин (например, jvm ), исполняющих некоторый независимый от используемой целевой системы код. При этом могут быть созданы системы, работающие и взаимодействующие друг с другом на любых платформахНа любых, для которых существует реализация виртуальной машины . Попутно решается еще ряд серьезных проблем, связанных, например, с безопасностью. Одним из серьезных недостатков такого подхода является то, что при этом снижается производительность (за счет ввода дополнительного посредника - виртуальной машины). Однако то, что ведущие игроки на рынке - Sun, IBM и Microsoft - в настоящее время активно работают в этом направлении, говорит о том, что этот подход перспективен. Альтернативным методом ("метод грубой силы") является подход, при котором все модули системы компилируются под все платформы, на которых система будет использоваться (применяется в настоящее время очень часто).

Сложность развертывания

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

Сложность отладки

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

Шаблоны решений

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

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

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

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

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

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

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

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

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

Два нижних слоя часто объединяют общим термином "платформа".

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

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

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