Краткий обзор некоторых распределённых систем

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

1. Распределённые СПС. Системы этого типа довольно многочисленны. Большая их часть является результатом исследовательских проектов крупных университетов США и Европы. Большинство таких систем не достигают уровня коммерческой реализации. Для нашего обзора выделим 4 основных проверенных временем архитектур промежуточного слоя: RPC, CORBA, COM, Java/RMI.

1.1 Remote Procedure Call (RPC) - технология вызова удалённых процедур, разработанная компанией Sun Microsystems в начале 80-х годов, как часть её UNIX-подобной операционной системы SunOS.

Для декларирования вызываемой функциональности RPC использует специальный язык определения интерфейсов (IDL), определяющий входные и выходные параметры вызываемых удалённых процедур (другими словами, их интерфейсы). На основе описания интерфейса IDL-компилятор (в UNIX он называется rpcgen) генерирует на клиентской и серверной машинах специальные программные заглушки. Клиентская заглушка является представителем удалённой процедуры в адресном пространстве клиента, обеспечивая прозрачность её вызова так, как если бы эта процедура была локальной. Серверная заглушка имитирует клиентский вызов процедуры в адресном пространстве сервера. Для осуществления удалённого вызова клиентская заглушка переводит входные данные в стандартизированную форму (при необходимости выравнивает структуры, меняет порядок байтового представления чисел, представление строк, и др.), производит перевод стандартизированного представления данных в последовательный поток байтов и отправляет заявку по сети. Серверная заглушка производит обратные операции (приём заявки, перевод и преобразование потока байтов), адаптируя аргументы клиента к вызываемой процедуре. По окончанию работы процедуры её выходные данные пересылаются клиенту, т. е. повторяется вышеописанный процесс пересылки, но в обратном направлении. Узнать о RPC более подробно можно читая одноимённую главу книги [1].

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

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

1.2 Common Object Request Broker Architecture (CORBA) – спецификация общей архитектуры брокера объектных заявок, принятая некоммерческой организацией OMG (Object Management Group) в 1992 году.

Под CORBA понимается спецификация архитектуры, а не конкретная её реализация. Базируется на объектно-ориентированной метамодели, поддерживающей множественное наследование. Объекту реализации соответствует интерфейс IDL, посредством которого тот может обрабатывать заявки. Объект может одновременно выступать как клиентом, так и сервером для других объектов. Вызов функциональности сервера осуществляется посредством объектной ссылки. Кроме статических вызовов (используя заглушки) поддерживается динамическое формирование заявок, основанное на рефлексии. Объектные заявки пересылаются от клиента к серверу при помощи базового сервиса, называемым Брокером объектных заявок (ORB), который скрывает неоднородность и распределение. Каждому объекту ставится в соответствие специальный объектный адаптер, обеспечивающий связь между его бинарной реализацией и брокером объектных заявок. Адаптер отвечает за активацию (загрузку объекта в оперативную память, его подготовку к выполнению заявок) и деактивацию объекта. Метаданные, описывающие типы IDL, хранятся в репозитории интерфейсов, представляющий собой обычный объект CORBA, поддерживающий собственный интерфейс. CORBA определяет множество стандартных сервисов, являющихся надстройкой базовой архитектуры. К таким сервисам относятся сервис распределённых транзакций, сервис именования объектов и другие. Сервис именования поддерживает составные имена объектов, каждое из которых состоит из последовательности имён вложенных пакетов, а также имени самого объекта. По составному имени объекта может быть получена соответствующая объектная ссылка. Подробную информацию об архитектуре CORBA можно почерпнуть из книги [2].

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

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

1.3 Component Object Model (COM) - компонентная модель объектов, разработанная компанией Microsoft в 1993 году как развитие технологии OLE.

Являясь главным конкурентом CORBA, технология COM имеет очень схожую с ней архитектуру. Получила распространение исключительно на платформе Windows. Первоначально COM была разработана для построения бинарных компонентов на локальном компьютере, доступных сторонним программам независимо от используемого языка программирования. Такие компоненты были необходимы, в частности, для интеграции документов приложений Microsoft Office и поддержки отображения активных web-страниц браузером Internet Explorer. Позже Microsoft была добавлена возможность удалённого вызова функциональности COM-объектов. Поддерживается объектно-ориентированная метамодель на основе множественного наследования интерфейсов, а также рефлексивные динамические вызовы. Наследование реализации не поддерживается. Технология COM во многом ориентирована на достижение высокой эффективности. Как следствие, она предоставляет программисту меньший уровень абстракции по сравнению с CORBA. Например, COM не поддерживает исключения. Вместо них в качестве результата операции возвращается числовое значение HRESULT, по которому прикладной программист должен судить о возможных ошибках выполнения заявки. Как и CORBA, COM поддерживает иерархически структурированное пространство имён. Книга [4] поможет познакомиться с архитектурой COM гораздо ближе.

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

К недостаткам архитектуры COM отнесём отсутствие поддержки наследования реализации, высокую сложность разработки и развёртывания COM-компонентов, а также низкую степень абстракции базовых интерфейсов. Кроме того, COM реализована только для платформы Windows.

1.4 Java/RMI (Remote Method Invocation in Java) – удалённый вызов методов языка Java, реализуемый Sun Microsystems начиная с версии 1.1 (1996 год).

Промежуточный слой Java/RMI представлен виртуальной машиной, интерпретирующей независящий от платформы байт-код. Интерфейс прямо или косвенно расширяющий системный интерфейс Java. rmi. Remote называется удалённым интерфейсом. Если объект поддерживает удалённый интерфейс, то он называется удалённым объектом, и соответствующие ему методы могут быть вызваны из другой Java-машины на локальном или удалённом хосте. Рефлексия и динамические вызовы языка Java не распространяются на удалённые вызовы объектов. Реестр Java/RMI реализует именование объектов, но без непосредственной поддержки иерархичности пространства имён. Привязка имён к объектам возможна лишь для локальных процессов содержащего реестр хоста, что нарушает прозрачность доступа. Подробнее познакомиться с Java/RMI поможет книга [5].

К преимуществам Java/RMI можно отнести прозрачность вызова функциональности удалённых объектов, поддерживаемая средствами языка Java. Это, несомненно, положительно сказывается на простоте создания распределённых приложений. Нельзя не отметить также высокую переносимость, обеспечиваемую виртуальной машиной.

К недостаткам Java/RMI можно причислить низкую производительность, связанную с применением виртуальной машины. Среди языков программирования поддерживается только Java. Кроме того, Java/RMI не поддерживает рефлексию и прозрачный доступ к реестру именования.

2 Распределённые ОС. Среди таких систем фактически не наблюдается ни одной коммерчески успешной. Для нашего обзора выделим три системы, представляющие собой законченные программные продукты, практически достигшие уровня коммерческих реализаций. Мы рассмотрим локальную распределённую систему Amoeba, а также две системы семейства Plan 9 (собственно, Plan 9 и её прямого потомка Inferno), доводящие парадигму UNIX до логического завершения.

2.1 Amoeba - распределённая система для локальной сети, спроектированная и реализованная проф. Э. Таненбаумом и его студентами в начале 90-х годов.

Система базируется на группе машин единой архитектуры (поддерживается x86, SPARC, и другие), соединённых в локальную сеть. Архитектура Amoeba гетерогенна - каждая машина может быть пулом процессоров, сервером (именования, файлов и др.) или терминалом. Межпроцессное взаимодействие базируется на RPC. В целях обеспечения высокой производительности создатели Amoeba отказались от свопинга – все процессы располагаются в оперативной памяти. Система самостоятельно справляется с распределением ресурсов и балансировкой нагрузки. Таким образом, Amoeba предоставляет пользователю простой интерфейс, имитируя единый виртуальный компьютер. Система практически в полном объёме поддерживают стандарт POSIX на уровне исходных кодов. Эту возможность обеспечивает специальная библиотека AJAX для эмуляции системных вызовов POSIX. Статья [6] поможет познакомиться с Amoeba поближе.

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

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

2.2 Plan 9 – распределённая операционная система, разрабатываемая Bell Labs с конца 80-х годов и призванная заменить UNIX в эру преобладания персональных рабочих станций.

Plan 9 значительно развивает файловую парадигму UNIX – практически всё в системе, включая устройства, процессы, удалённые хосты и сетевые протоколы представлены в виде файлов. К файлу могут быть применены операции открытия, закрытия, чтения и записи. Системный интерфейс ориентирован на работу с текстовыми строками в кодировке Unicode (UTF-8). Так, например, для передачи команды устройству необходимо открыть соответствующий ему файл в папке /dev и записать в него текстовую строку в формате, понятном данному устройству. Ресурсы распределённой системы представлены в виде иерархии вложенных пространств имён файлов, причём общая структура дерева файлов является стандартной для любого хоста. Например, для каждого компьютера под управлением Plan 9 в папке /proc располагаются файлы текущих процессов. Пространства имён могут монтироваться к другим пространствам, копироваться, демонтироваться и удаляться. Такая функциональность позволяет получать идентичную среду на произвольном компьютере – пользователю нужно лишь зарегистрироваться под своей учётной записью. Манипулирование ресурсами производится при помощи простого, но мощного протокола 9P, команды которого обозначают атомарные файловые транзакции. 9P опирается на специальный транспортный протокол IL поверх IP и заменяющий собою другие протоколы транспортного уровня (TCP, UDP). Не смотря на последовательность разработчиков в реализации идеи «всё есть файл” Plan 9 имеет системные вызовы, не связанные с файлами (создание процессов, работа с разделяемой памятью и др.). Наряду с собственным интерфейсом прикладного программирования, система также обеспечивает среду эмуляции POSIX. Подробнее архитектура Plan 9 описана в статье [7].

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

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

2.3 Inferno – распределённая операционная система, разработанная в 1996 году английской компанией Vita Nuova во главе с Бобом Пайком, главным архитектором Plan 9, и продолжающая её архитектурную линию.

Inferno представляет собою компактную легко переносимую операционную систему, архитектурно схожую с Plan 9. Inferno может запускаться как в качестве полноценной операционной системы, надстраивающейся над оборудованием компьютера, так и в качестве приложения под распространёнными операционными системами, обеспечивая пользователям идентичную среду независимо от машинной архитектуры и способа своей загрузки. В Inferno роль протокола 9P играет усовершенствованный протокол Stix. Потоки программ выполняются в едином адресном пространстве. Защиту памяти обеспечивает виртуальная машина Dis, промежуточный код для которой может выполняться как в режиме интерпретации, так и в режиме JIT-компиляции. Интерфейс ядра представлен в виде вызовов системных компонентов через инструкции промежуточного кода. Dis поддерживает оптимизированную сборку мусора. Основным языком программирования высокого уровня в Inferno является компактный язык Limbo имеющий C-подобный синтаксис, но концептуально наследующий от компонентного языка Oberon. Ядро системы имеет развитую модель безопасности, включая встроенную поддержку шифрования. Более подробную информацию об Inferno можно найти в статье [8].

Множество архитектурных преимуществ Inferno были унаследованы от системы Plan 9. Выявляя собственные положительные стороны Inferno, нельзя не отметить следующие качества. Имеется возможность запуска, как в режиме операционной системы, так и в режиме приложения под существующую систему. Реализация виртуальной машины Dis проста, удобна и эффективна. Единый промежуточный код, не зависящий от архитектуры компьютера, обеспечивает полную переносимость программ на любые системы под управлением Inferno. Язык Limbo компактен и гибок, кроме того, содержит средства распределённого программирования. Система имеет встроенную поддержку безопасности на уровне ядра.

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

Ссылки:

1. Programming in C - UNIX System Calls and Subroutines using C, A. D. Marshall. 1994-2005;

2. Engineering distributed objects, Wolfgang Emmerich. University College London, John Wiley & Sons, Ltd, 2000;

3. The Rise and Fall of CORBA, Michi Henning. ACM Queue, Volume 4, Number 5, June 2006;

4. Essential COM, Don Box. Addison-Wesley Professional, 464 pp, 1997;

5. Java RMI, William Grosso. O’Reilly Media, 572 pp, 2001;

6. Amoeba: a distributed operating system for the 1990s, Mullender, S. J., van Rossum, G., Tananbaum, A. S., van Renesse, R., van Staveren, H. Computer Volume 23, Issue 5, May 1990;

7. Plan 9 from Bell Labs, Rob Pike, Dave Presotto, Sean Dorward, Bob Flandren, Ken Thompson, Howard Trickey, Phil Winterbottom. Bell Laboratories, Murray Hill;

8. Inferno: An Overview. Operating system for network application development. Vita Nuova;