Системы с распределенной разделяемой памятью
Многопроцессорные системы делят на две группы: мультипроцессоры (имеющие общую память) и мультикомпьютеры (без нее). Строить большие мультипроцессоры трудно, поскольку необходимо поддерживать согласованное сотояние памяти для, может быть, тысяч процессоров. С другой стороны, такие системы проще программируются. Процессы могут прямо разделять переменные, могут синхронизироваться при помощи семафоров, мониторов и других хорошо известных приемов.
Мультикомпьютеры, напротив, легко построить, поскольку каждая пара процессор-память независима от других. Их, однако, тяжелее программировать, особенно параллельные приложения. В последние годы разработана гибридная форма, моделирующая разделяемую память на мультикомпьютерах. Ее называют распределенной разделяемой памятью. Распределенные вычисления базируются на модели передачи сообщений, в которой данные передаются от процессора к процессору в виде сообщений. Удаленный вызов процедур фактически является той же самой моделью (или очень близкой).
DSM - виртуальное адресное пространство, разделяемое всеми узлами (процессорами) распределенной системы. Программы получают доступ к данным в DSM примерно так же, как они работают с данными в виртуальной памяти традиционных ЭВМ. В системах с DSM данные перемещаются между локальными памятями разных компьютеров аналогично тому, как они перемещаются между оперативной и внешней памятью одного компьютера.
Характеристики разделяемой памяти (DSM)
Конкретную реализацию разделяемой памяти характеризуют:
• уровень реализации (аппаратный, программный, аппаратно-программный);
• структура разделяемых данных (слово, кэш-строка, страница, сегмент, фрагмент, объект и т.д.);
• модель состоятельности памяти, определяющая допустимые последовательности доступа в память (SRSW — «один читатель/один писатель», MRSW — «много читателей/один писатель», MRMW — «много читателей/много писателей»);
• политика обеспечения когерентности данных (модификация, объявление несостоятельными);
• механизм управления распределением памяти и размещением данных (централизованный/распределенный, статический/динамический).
Программное обеспечение промежуточного уровня
Распределенные операционные системы не предназначены для управления набором независимых компьютеров, а сетевые операционные системы не дают представления одной согласованной системы. Возможно ли разработать распределенную систему, которая объединяла бы в себе преимущества масштабируемости и открытости сетевых операционных систем и прозрачность и относительную простоту в использовании распределенных операционных систем? Решение было найдено в виде дополнительного уровня программного обеспечения, который в сетевых операционных системах позволяет более или менее скрыть от пользователя разнородность набора аппаратных платформ и повысить прозрачность распределения. Многие современные распределенные системы построены в расчете на этот дополнительный уровень, который получил название программного обеспечения промежуточного уровня.
Позиционирование программного обеспечения промежуточного уровня
Многие распределенные приложения допускают непосредственное использование программного интерфейса, предлагаемого сетевыми операционными системами. Так, связь часто реализуется через операции с сокетами, которые позволяют процессам на разных машинах обмениваться сообщениями. Кроме того, приложения часто пользуются интерфейсами локальных файловых систем. Как мы понимаем, проблема такого подхода состоит в том, что наличие распределения слишком очевидно. Решение заключается в том, чтобы поместить между приложением и сетевой операционной системой промежуточный уровень программной поддержки, обеспечивающий дополнительное абстрагирование. Потому этот уровень и называется промежуточным. Он находится посредине между приложением и сетевой операционной системой, как показано на рис. 1.16.
Каждая локальная система, составляющая часть базовой сетевой операционной системы, предоставляет управление локальными ресурсами и простейшие коммуникационные средства для связи с другими компьютерами. Другими словами, программное обеспечение промежуточного уровня не управляет каждым узлом, эта работа по-прежнему приходится на локальные операционные системы.
Основная задача — скрыть разнообразие базовых платформ от приложений. Для решения этой задачи многие системы промежуточного уровня предоставляют более или менее полные наборы служб и «не одобряют» желания использовать что-то еще для доступа к этим службам, кроме своих интерфейсов. Другими словами, обход промежуточного уровня и непосредственный вызов служб одной из базовых операционных систем не приветствуется.
Промежуточный уровень не был изобретен в академических условиях в попытке обеспечить прозрачность распределения. После появления и широкого распространения сетевых операционных систем многие организации обнаружили, что у них накопилась масса сетевых приложений, которые невозможно легко интегрировать в единую систему. Именно тогда производители и начали создавать независимые от приложений службы верхнего уровня для этих систем. Типичные примеры обеспечивали поддержку распределенного взаимодействия и улучшенные коммуникационные возможности.
Была создана организация, призванная определить общий стандарт для решений на базе промежуточного уровня. Но таких стандартов существует множество. Они в основном несовместимы друг с другом, а продукты разных производителей, реализующие один и тот же стандарт, редко способны работать вместе.
Модели промежуточного уровня
Чтобы сделать разработку и интеграцию распределенных приложений как можно более простой, основная часть программного обеспечения промежуточного уровня базируется на некоторой модели, или парадигме, определяющей распределение и связь. Относительно простой моделью является представление всех наблюдаемых объектов в виде файлов. Этот подход был изначально введен в UNIX и строго соблюдался в Plan 9. В Plan 9 все ресурсы, включая устройства ввода-вывода, такие как клавиатура, мышь, диск, сетевые интерфейсы и т. д., рассматривались как файлы. Важно, что удаленные и локальные файлы ничем не отличались. Приложение открывало файлы, читало и записывало в них байты и закрывало их. Поскольку файлы могли совместно использоваться несколькими процессами, связь сокращалась до простого обращения к одному и тому же файлу.
Подобный же подход, но менее строгий, чем в Plan 9, применяется в программном обеспечении промежуточного уровня, построенном по принципу распределенной файловой системы (distributed file system). Во многих случаях это программное обеспечение всего на один шаг ушло от сетевых операционных систем в том смысле, что прозрачность распределения поддерживается только для стандартных файлов (то есть файлов, предназначенных только для хранения данных). Процессы, например, часто должны запускаться исключительно на определенных машинах. Программное обеспечение промежуточного уровня, основанное на модели распределенной файловой системы, оказалось достаточно легко масштабируемым, что способствовало его популярности.
Другая важная ранняя модель программного обеспечения промежуточного уровня основана на удаленных вызовах процедур (Remote Procedure Calls, RFC). В этой модели акцент делается на сокрытии сетевого обмена за счет того, что процессу разрешается вызывать процедуры, реализация которых находится на удаленной машине. При вызове такой процедуры параметры прозрачно передаются на удаленную машину, где, собственно, и выполняется процедура, после чего результат выполнения возвращается в точку вызова процедуры. За исключением, вероятно, некоторой потери производительности, все это выглядит как локальное исполнение вызванной процедуры: вызывающий процесс не уведомляется об имевшем место факте сетевого обмена. Мы вернемся к вызовам удаленных процедур в следующей главе.
По мере того как все более входит в моду ориентированность на объекты, становится ясно, что если вызов процедуры проходит через границы отдельных машин, он может быть представлен в виде прозрачного обращения к объекту, находящемуся на удаленной машине. Это привело к появлению разнообразных систем промежуточного уровня, реализующих представление о распределенных объектах (distributed objects). Идея распределенных объектов состоит в том, что каждый объект реализует интерфейс, который скрывает все внутренние детали объекта от его пользователя. Интерфейс содержит методы, реализуемые объектом, не больше и не меньше. Все, что видит процесс, — это интерфейс.
Распределенные объекты часто реализуются путем размещения объекта на одной из машин и открытия доступа к его интерфейсу с множества других. Когда процесс вызывает метод, реализация интерфейса на машине с процессом просто преобразует вызов метода в сообщение, пересылаемое объекту. Объект выполняет запрашиваемый метод и отправляет назад результаты. Затем реализация интерфейса преобразует ответное сообщение в возвращаемое значение, которое передается вызвавшему процессу. Как и в случае с RPC, процесс может оказаться не осведомленным об этом обмене.
Как модели могут упростить использование сетевых систем, вероятно, наилучшим образом видно на примере World Wide Web. Успех среды Web в основном определяется тем, что она построена на базе потрясающе простой, но высокоэффективной модели распределенных документов (distributed documents). В модели, принятой в Web, информация организована в виде документов, каждый из которых размещен на машине, расположение которой абсолютно прозрачно. Документы содержат ссылки, связывающие текущий документ с другими. Если следовать по ссылке, то документ, с которым связана эта ссылка, будет извлечен из места его хранения и выведен на экран пользователя. Концепция документа не ограничивается исключительно текстовой информацией. Например, в Web поддерживаются аудио и видеодокументы, а также различные виды документов на основе интерактивной графики.
Службы промежуточного уровня
Существует некоторое количество стандартных для систем промежуточного уровня служб. Все программное обеспечение промежуточного уровня неизменно должно тем или иным образом реализовывать прозрачность доступа путем предоставления высокоуровневых средств связи (communication facilities), скрывающих низкоуровневую пересылку сообщений по компьютерной сети. Интерфейс программирования транспортного уровня, предоставляемый сетевой операционной системой, полностью заменяется другими средствами. Способ, которым поддерживается связь, в значительной степени зависит от модели распределения, предлагаемой программным обеспечением промежуточного уровня пользователям и приложениям. Мы уже упоминали удаленный вызов процедур и обращение к распределенным объектам. Кроме того, многие системы промежуточного уровня предоставляют средства для прозрачного доступа к удаленным данным, такие как распределенные файловые системы или распределенные базы данных. Прозрачная доставка документов, реализуемая в Web, — это еще один пример коммуникаций высокого уровня (однонаправленных).
Важная служба, общая для всех систем промежуточного уровня, — это именование (naming). Службы именования сравнимы с телефонными книгами или справочниками типа «Желтых страниц». Они позволяют совместно использовать и искать сущности (как в каталогах). Хотя присвоение имен на первый взгляд кажется простым делом, при масштабировании возникают серьезные трудности. Проблема состоит в том, что для эффективного поиска имени в большой системе местоположение разыскиваемой сущности должно считаться фиксированным.Такое допущение, в частности, принято в среде World Wide Web, в которой любой документ поименован посредством URL. URL содержит имя сервера, на котором находится документ с данным URL адресом. Таким образом, если документ переносится на другой сервер, его URL перестает работать.
Многие системы промежуточного уровня предоставляют специальные средства хранения данных, также именуемые средствами сохранности (persistence). В своей простейшей форме сохранность обеспечивается распределенными файловыми системами, но более совершенное программное обеспечение промежуточного уровня содержит интегрированные базы данных или предоставляет средства для связи приложений с базами данных.
Если хранение данных играет важную роль для оболочки, то обычно предоставляются и средства для распределенных транзакций (distributed transactions). Важным свойством транзакций является возможность множества операций чтения и записи в ходе одной атомарной операции. Под атомарностью мы понимаем тот факт, что транзакция может быть либо успешной (когда все операции записи завершаются успешно), либо неудачной, что оставляет все задействованные данные не измененными. Распределенные транзакции работают с данными, которые, возможно, разбросаны по нескольким машинам.
Предоставление таких служб, как распределенные транзакции, особенно важно в свете того, что маскировка сбоев для распределенных систем нередко затруднена. К сожалению, транзакции легче масштабировать на нескольких географически удаленных машинах, чем на множестве локальных.
Ну и, наконец, практически все системы промежуточного уровня, используемые не только для экспериментов, предоставляют средства обеспечения защиты(security). По сравнению с сетевыми операционными системами проблема защиты в системах промежуточного уровня состоит в том, что они распределены. Промежуточный уровень в принципе не может «надеяться» на то, что базовые локальные операционные системы будут адекватно обеспечивать защиту всей сети. Соответственно, защита отчасти ложится на программное обеспечение промежуточного уровня. В сочетании с требованием расширяемости защита превращается в одни из наиболее трудно реализуемых в распределенных системах служб.
Промежуточный уровень и открытость
Современные распределенные системы обычно создаются в виде систем промежуточного уровня для нескольких платформ. При этом приложения создаются для конкретной распределенной системы и не зависят от платформы (операционной системы). К сожалению, эта независимость часто заменяется жесткой зависимостью от конкретной системы промежуточного уровня. Проблема заключается в том, что системы промежуточного уровня часто значительно менее открыты, чем утверждается.
Как мы обсуждали ранее, истинно открытая распределенная система определяется полнотой (завершенностью) ее интерфейса. Полнота означает реальное наличие всех необходимых для создания систем описаний. Неполнота описания интерфейса приводит к тому, что разработчики систем вынуждены добавлять свои собственные интерфейсы. Таким образом, мы можем прийти к ситуации, когда разными командами разработчиков в соответствии с одним и тем же стандартом создаются разные системы промежуточного уровня и приложения, написанные под одну из систем, не могут быть перенесены под другую без значительных усилий.
Не менее неприятна ситуация, когда неполнота приводит к невозможности совместной работы двух реализаций, несмотря на то, что они поддерживают абсолютно одинаковый набор интерфейсов, но различные базовые протоколы. Так, если две реализации основаны на несовместимых коммуникационных протоколах, поддерживаемых сетевой операционной системой, маловероятно, что удастся с легкостью добиться их совместной работы. Необходимо, чтобы и протоколы промежуточного уровня, и его интерфейсы были одинаковы, как показано на рис. 1.17.
Еще один пример. Для гарантии совместной работы различных реализаций необходимо, чтобы к сущностям разных систем можно было одинаково обращаться. Если к сущностям в одной системе обращение идет через URL, а в другой системе — через сетевой адрес, понятно, что перекрестные обращения приведут к проблемам. В подобных случаях определения интерфейсов должны точно предписывать вид ссылок.