Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 14
Текст из файла (страница 14)
Это также проблемы с управлением.Поскольку все машины под управлением сетевой операционной системы независимы, часто и управлять ими можно исключительно независимо. В результатепользователь может получить удаленное соединение с машиной X, только имеяна ней регистрацию. Таким образом, если пользователь хочет использовать одинпароль на «все случаи жизни», то для смены пароля он вынужден будет явносменить его на каждой машине. Рассуждая далее, мы видим, что в основном всеправа доступа относятся к конкретной машине.
Нет простого метода сменитьправа доступа, поскольку всюду они свои. Такой децентрализованный подходк безопасности нередко затрудняет защиту сетевой операционной системы от атакзлоумышленников.Имеются также и преимущества по сравнению с распределенными операционными системами. Поскольку узлы сетевых операционных систем в значительной степени независимы друг от друга, добавить или удалить машину очень легко.В некоторых случаях все, что надо сделать, чтобы добавить узел, — это подсоединить соответствующую машину к общей сети и поставить в известность о ее существовании остальные машины сети.
В Интернете, например, добавление новогосервера происходит именно так. Чтобы сведения о машине попали в Интернет,мы должны просто дать ей сетевой адрес, а лучше символическое имя, котороезатем будет внесено в DNS вместе с ее сетевым адресом.60Глава 1. Введение1.4.3. Программное обеспечениепромежуточного уровняНи распределенные, ни сетевые операционные системы не соответствуют нашему определению распределенных систем, данному в разделе 1.1.
Распределенныеоперационные системы не предназначены для управления набором независимыхкомпьютеров, а сетевые операционные системы не дают представления одной согласованной системы. На ум приходит вопрос: а возможно ли вообще разработатьраспределенную систему, которая объединяла бы в себе преимущества двух «миров» — масштабируемость и открытость сетевых операционных систем и прозрачность и относительную простоту в использовании распределенных операционных систем? Решение было найдено в виде дополнительного уровня программногообеспечения, который в сетевых операционных системах позволяет более или менее скрыть от пользователя разнородность набора аппаратных платформ и повысить прозрачность распределения. Многие современные распределенные системы построены в расчете на этот дополнительный уровень, который получилназвание программного обеспечения промежуточного уровня.
В этом пункте мыкратко рассмотрим, как устроено программное обеспечение промежуточного уровня, чтобы понять его особенности.Позиционирование программного обеспеченияпромежуточного уровняМногие распределенные приложения допускают непосредственное использование программного интерфейса, предлагаемого сетевыми операционными системами. Так, связь часто реализуется через операции с сокетами, которые позволяют процессам на разных машинах обмениваться сообщениями [438]. Кроме того,приложения часто пользуются интерфейсами локальных файловых систем. Какмы понимаем, проблема такого подхода состоит в том, что наличие распределения слишком очевидно.
Решение заключается в том, чтобы поместить междуприложением и сетевой операционной системой промежуточный уровень программной поддержки, обеспечивающий дополнительное абстрагирование. Потому этот уровень и называется промежуточным. Он находится посредине междуприложением и сетевой операционной системой, как показано на рис. 1.16.Каждая локальная система, составляющая часть базовой сетевой операционной системы, предоставляет управление локальными ресурсами и простейшиекоммуникационные средства для связи с другими компьютерами.
Другими словами, программное обеспечение промежуточного уровня не управляет каждымузлом, эта работа по-прежнему приходится на локальные операционные системы.Основная наша задача — скрыть разнообразие базовых платформ от приложений. Для решения этой задачи многие системы промежуточного уровня предоставляют более или менее полные наборы служб и «не одобряют» желания использовать что-то еще для доступа к этим службам, кроме своих интерфейсов.Другими словами, обход промежуточного уровня и непосредственный вызовслужб одной из базовых операционных систем не приветствуется. Мы краткорассмотрим службы промежуточного уровня.1.4. Концепции программных решенийМашина АМашина СМашина В161IРаспределенные приложенияСлужбы программного обеспечения промежуточного уровняСлужбы сетевойСлужбы сетевойСлужбы сетевойоперационнойоперационнойоперационнойсистемысистемысистемыЯдроЯдроЯдроСетьРис.
1.16. Общая структура распределенных системс промежуточным уровнемИнтересно отметить, что промежуточный уровень не был изобретен в академических условиях в попытке обеспечить прозрачность распределения. Послепоявления и широкого распространения сетевых операционных систем многиеорганизации обнаружили, что у них накопилась масса сетевых приложений, которые невозможно легко интегрировать в единую систему [45]. Именно тогда производители и начали создавать независимые от приложений службы верхнегоуровня для этих систем. Типичные примеры обеспечивали поддержку распределенного взаимодействия и улучшенные коммуникационные возможности.Разумеется, дорога к правильному промежуточному уровню была непростой.Была создана организация, призванная определить общий стандарт для решенийна базе промежуточного уровня.
К настоящему времени таких стандартов существует множество. Стандарты в основном несовместимы друг с другом, и что ещехуже, продукты разных производителей, реализующие один и тот же стандарт,редко способны работать вместе. Вероятно, все это ненадолго. Кто-нибудь непременно предложит «программное обеспечение следующего уровня», которое исправит этот недостаток.Модели промежуточного уровняЧтобы сделать разработку и интеграцию распределенных прргложений как можноболее простой, основная часть программного обеспечения промежуточного уровня базируется на некоторой модели, или 7гарадигме, определяющей распределение и связь. Относительно простой моделью является представление всех наблюдаемых объектов в виде файлов.
Этот подход был изначально введен в UNIXи строго соблюдался в Plan 9 [353]. В Plan 9 все ресурсы, включая устройства ввода-вывода, такие как клавиатура, мышь, диск, сетевые интерфейсы и т. д., рассматривались как файлы. Важно, что удаленные и локальные файлы ничем не отличались. Приложение открывало файлы, читало и записывало в них байты изакрывало их. Поскольку файлы могли совместно использоваться несколькимипроцессами, связь сокращалась до простого обращения к одному и тому же файлу.62Глава 1. ВведениеПодобный же подход, но менее строгий, чем в Plan 9, применяется в программном обеспечении промежуточного уровня, построенном по принципу распределенной файловой системы {distiibuted file system).
Во многих случаях этопрограммное обеспечение всего на один шаг ушло от сетевых операционных систем в том смысле, что прозрачность распределения поддерживается только длястандартных файлов (то есть файлов, предназначенных только для храненияданных). Процессы, например, часто должны запускаться исключительно на определенных машинах. Программное обеспечение промежуточного уровня, основанное на модели распределенной файловой системы, оказалось достаточно легко масштабируемым, что способствовало его популярности.Другая важная ранняя модель программного обеспечения промежуточногоуровня основана на удаленных вызовах процедур {Remote Procedure Calls, RPC).В этой модели акцент делается на сокрытии сетевого обмена за счет того, чтопроцессу разрешается вызывать процедуры, реализация которых находится наудаленной машине. При вызове такой процедуры параметры прозрачно передаются на удаленную машину, где, собственно, и выполняется процедура, послечего результат выполнения возвращается в точку вызова процедуры.
За исключением, вероятно, некоторой потери производительности, все это выглядит каклокальное исполнение вызванной процедуры: вызывающий процесс не уведомляется об имевшем место факте сетевого обмена. Мы вернемся к вызовам удаленных процедур в следующей главе.По мере того как все более входит в моду ориентированность на объекты, становится ясно, что если вызов процедуры проходит через границы отдельных машин,он может быть представлен в виде прозрачного обраще1П1я к объекту, находящемуся на удаленной машине. Это привело к появлению разнообразных системпромежуточного уровня, реализующих представле11ие о распределенных объектах {distributed objects).
Идея распределенных объектов состоит в том, что каждый объект реализует интерфейс, который скрывает все внутренние детали объекта от его пользователя. Интерфейс содержит методы, реализуемые объектом,не больше и не меньше. Все, что видит процесс, — это интерфейс.Распределенные объекты часто реализуются путем размещения объекта наодной из машин и открытия доступа к его интерфейсу с мрюжества других. Когдапроцесс вызывает метод, реализация интерфейса на машрп1е с процессом простопреобразует вызов метода в сообщение, пересылаемое объекту.
Объект выполняет запрашиваемый метод и отправляет назад результаты. Затем реализация интерфейса преобразует ответное сообщение в возвращаемое значение, которое передается вызвавшему процессу. Как и в случае с RPC, процесс может оказатьсяне осведомленным об этом обмене.Как модели могут упростить использование сетевых систем, вероятно, наилучшим образом видно на примере World Wide Web. Успех среды Web в основном определяется тем, что она построена на базе потрясаюп^е простой, но высокоэффективной модели распределенных документов {distributed documents).В модели, принятой в Web, информация организована в виде документов, каждый из которых размещен на машине, расположение которой абсолютно прозрачно.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
