E1Distributed operating system project
ГлавнаяАрхитектура Е1ДокументыКоманда
Rus
Eng
Архитек...Концепциии E1
Архитектура E1
Концепциии E1
Распределенный объект
Обзор архитектуры
Домены защиты
Междоменные вызовы
Потоки
Компонентные сервисы
Репликация
Разработка ПО
Требования

Естественным требованием к любой распределенной ОС является обеспечение удобного, эффективного и надежного доступа к ресурсам компьютерной сети.

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

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

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

Рассмотрим, каким образом Е1 реализует каждое из указанных требований.

Прозрачный доступ к ресурсам посредством абстракции распределенного объекта

Распределенная ОС должна предоставлять приложениям удобный интерфейс ко всем ресурсам компьютерной сети. С этой целью в Е1 реализована абстракция образа единой системы. Это означает, что для прикладного ПО распределенная вычислительная система выглядит как централизованная. Данное свойство позволяет разработчику абстрагироваться от физического расположения ресурсов, с которыми взаимодействует приложение и сосредоточиться на функциональности, которую они предоставляют.

Реализация образа единой системы в Е1 основана на абстракции распределенного объекта. Состояние и функциональность всех компонентов ОС инкапсулируется распределенными объектами. Каждый объект предоставляет набор четко определенных интерфейсов, которые могут вызываться другими объектами. Объекты глобально, единообразно доступны посредством своих интерфейсов из всех узлов вычислительного комплекса.

В Е1 единая объектная модель используется как для подсистем ОС, так и для прикладного ПО. Т.е., приложения Е1 также разрабатываются на основе распределенных объектов. С точки зрения прикладного программиста сеть ЭВМ представляет собой единый виртуальный компьютер, программное обеспечение которого структурировано в виде набора объектов. Доступ к аппаратным и программным ресурсам, а также взаимодействие между компонентами программной системы сводится к вызовам методов интерфейсов соответствующих объектов.

Репликация для обеспечения эффективности и надежности доступа

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

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

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

Репликация может выступать не только как средство обеспечения эффективного доступа к объекту, но и как механизм избыточности. Например, поддерживая когерентные копии объекта в n различных узлов, возможно достичь устойчивости объекта к выходу из строя любых n-1 узлов [46]. Таким образом, репликация позволяет использовать аппаратную избыточность распределенной компьютерной системы для обеспечения устойчивого функционирования приложений.

Поддержка компонентной модели

Еще один важный принцип, лежащий в основе архитектуры Е1 - поддержка компонентной модели. В соответветствии с данным принципом, модель реплицированных объектов расширяется до полноценной компонентной модели. Такая архитектура делает Е1 удобной платформой для разработки распределенных приложений.

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

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

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

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

Единая компонентная модель может поддерживаться в нескольких узлах сети. Такая среда удобна для разработки распределенных приложений, поскольку, помимо других преимуществ компонентно-ориентированной архитектуры, обеспечивает прозрачность сети, т.е., компоненты, расположенные в различных узлах, могут вызывать методы друг друга так же как в локальном случае. Данный подход реализован в системах промежуточного ПО, таких как COM [33], Corba [35], EJB [53].

Любопытно, что многие современные распределенные ОС предоставляют набор абстракций и сервисов, близких по содержанию к распределенным компонентным моделям промежуточного ПО. Вероятно, это объясняется тем, что их разработчики преследовали сходные цели: построить среду, обеспечивающую удобную и эффективную поддержку распределенных приложений. Для унификации доступа к ресурсам распределенные ОС, как правило, предоставляют объектно-ориентированный интерфейс. В некоторых реализациях объект является одним из основных примитивов ОС ([55], [21], [11]), в то время как другие системы предоставляют более простые примитивы, такие как порты сообщений в Mach[4] и Chorus[43] или порталы в Opal[10], на основе которых абстракция объекта реализуется объектно-ориентированной средой выполнения приложений. Для управления распределенными объектами ОС предоставляет сервисы, аналогичные ключевым сервисам компонентных моделей. В первую очередь, это механизм защищенного взаимодействия, позволяющий единообразно вызывать методы любого объекта при наличии соответствующих прав. Кроме того, все распределенные ОС поддерживают механизм глобального именования объектов, позволяющий получить доступ к объекту посредством некоторого уникального идентификатора. Некоторые распределенные ОС поддерживают также персистентность объектов [11, 10, 12, 49, 15].

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

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

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

Рассмотрим, чем компонентная модель Е1 отличается от объектных моделей существующих распределенных ОС. Наиболее существенным отличием являются примитивы выполнения Е1. В традиционных ОС основной абстракцией выполнения является процесс или задача, представляющая собой экземпляр программы, загруженной в память. Задача выполняется в изолированном адресном пространстве. С задачей может быть связано несколько потоков выполнения. Такая модель плохо адаптируется для поддержки взаимодействующих объектов средней гранулярности [18]. Поэтому мы отказываемся от нее в пользу новой модели выполнения, ориентированной на поддержку компонентных систем. В Е1 весь исполняемый код и данные принадлежат объектам. Все объекты расположены в едином 64-битном адресном пространстве. Для защиты объектов используется механизм страничной защиты памяти процессора. В Е1 используется модель мигрирующих потоков[18], в которой поток, выполняющий вызов метода объекта, переносит выполнение в вызываемый объект. Такая модель позволяет отойти от клиент-серверного подхода к разработке объектов, когда каждый объект должен запускать один или несколько потоков для обработки вызовов его методов.

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

Помимо механизма репликации объектов, компонентная модель Е1 включает следующие элементы:

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

В рамках единой компонентной модели Е1 разрабатываются как объекты ОС, так и всё прикладное ПО. Поэтому важнейшими требованиями к реализации модели являются минимизация связанных с ней накладных расходов, высокая гибкость и эффективность.

Copyright E1 Team 2003
mail:team@E1OS.org