История распределенных систем

История распределенных систем
Скорость роста, наблюдавшаяся в компьютерных технологиях в последние полвека
значительна. Развитие пришло от машин, стоивших 100 миллионов долларов и
выполнявших одну команду в секунду, до машин, которые стоят 1000 долларов и
выполняющим
10
миллионов
команд
в
секунду.
Разница
в
соотношении
цена/производительность достигла порядка 1012.
Общая
тенденция
отказа
восьмидесятых годов, когда
от
централизации,
американская
стала
фирма
Intel
возникать
с
середины
предложила
вместо
интегрального модуля с жесткой логикой разработать стандартный логический блок,
конкретное
назначение
которого
можно
создать программируемую интегральную
многофункциональный цифровой
определить
схему.
после его изготовления, т.е.
Так появился микропроцессор -
микроэлектронный модуль с программируемой
логикой, сделавший революцию в электронике и технике обработки информации.
Немаловажен
факт
изобретения
высокоскоростных
компьютерных
сетей.
Локальные сети {Local-Area Networks, LAN) соединяют сотни компьютеров, находящихся
в здании, таким образом, что машины в состоянии обмениваться небольшими порциями
информации за несколько микросекунд. Большие массивы данных передаются с машины
на машину со скоростью от 10 до 1000 Мбит/с.
Быстрое проникновение информационных технологий в коммерцию, банковское
дело, образование и сферу развлечений в совокупности с неуклонно
увеличивающейся мощностью компьютеров и емкостью устройств хранения данных
предъявляет все большие требования к сетям связи.
Позже, локальные сети уже формировали глобальные сети (Wide-Area Networks,
WAN) позволяющие миллионам машин во всем мире обмениваться информацией со
скоростями, варьирующимися от 64 кбит/с до гигабит в секунду.
В результате развития этих технологий сегодня не просто возможно, но и достаточно легко
можно собрать компьютерную систему, состоящую из множества компьютеров, соединенных
высокоскоростной сетью, которая обычно и называется компьютерной сетью, или распределенной
системой (distributed system), в отличие от предшествовавших ей централизованных (centralized
systems), или однопроцессорных (single-processor systems), систем, состоявших из одного
компьютера, его периферии и, возможно, нескольких удаленных терминалов.
1.1. Понятие распределенной системы
В литературе множество расхождений по определению распределенных систем,
причем ни одно из них не является удовлетворительным и не согласуется с остальными.
Часто при определении распределенной системы во главу угла ставят разделение ее
функций между несколькими компьютерами. При таком подходе распределенной
является любая вычислительная система, где обработка данных разделена между двумя и
более компьютерами.
Распределенная
система
—
это
набор
независимых
компьютеров,
представляющийся их пользователям единой объединенной системой.
В этом определении оговариваются два одинаково важных момента:
1) по отношению к аппаратуре: все машины автономны.
2) касается программного обеспечения: пользователи думают, что имеют дело с
единой системой.
Возможно, вместо того чтобы рассматривать определения, разумнее будет
сосредоточиться на важных характеристиках распределенных систем. Первая из таких
характеристик состоит в том, что от пользователей скрыты различия между
компьютерами и способы связи между ними. То же самое относится и к внешней
организации распределенных систем. Другой важной характеристикой распределенных
систем является способ, при помощи которого пользователи и приложения единообразно
работают в распределенных системах, независимо от того, где и когда происходит их
взаимодействие.
Распределенные
системы
должны
также
относительно
легко
поддаваться
расширению, или масштабированию. Эта характеристика является прямым следствием
наличия независимых компьютеров, но в то же время не указывает, каким образом эти
компьютеры на самом деле объединяются в единую систему. Распределенные системы
обычно существуют постоянно, однако некоторые их части могут временно выходить из
строя. Пользователи и приложения не должны уведомляться о том, что эти части
заменены или починены или что добавлены новые части для поддержки дополнительных
пользователей или приложений.
Для того чтобы поддержать представление различных компьютеров и сетей в виде
единой
системы,
организация
распределенных
систем
часто
включает
в
себя
дополнительный уровень программного обеспечения, находящийся между верхним
уровнем, на котором находятся пользователи и приложения, и нижним уровнем,
состоящим из операционных систем, как показано на рис. 1.1. Соответственно, такая
распределенная
система
обычно
называется
системой
промежуточного
уровня
(middleware).
Машина А
Машина В
Машина С
Распределенные приложения
Служба промежуточного уровня
Локальная ОС
Локальная ОС
Локальная ОС
Сеть
Рис. 1.1. Распределенная система организована в виде службы промежуточного уровня.
(распределен среди множества компьютеров)
Рассмотрим некоторые примеры распределенных систем. В качестве первого
примера возьмем сеть рабочих станций в университете или отделе компании. Вдобавок к
персональной рабочей станции каждого из пользователей имеется пул процессоров
машинного зала, не назначенных заранее ни одному из пользователей, но динамически
выделяемых им при необходимости. Эта распределенная система может обладать единой
файловой системой, в которой все файлы одинаково доступны со всех машин с
использованием постоянного пути доступа. Кроме того, когда пользователь набирает
команду, система может найти наилучшее место для выполнения запрашиваемого
действия, возможно, на собственной рабочей станции пользователя, возможно, на
простаивающей рабочей станции, принадлежащей кому-то другому, а может быть, и на
одном из свободных процессоров машинного зала. Если система в целом выглядит и ведет
себя как классическая однопроцессорная система с разделением времени (то есть
многопользовательская), она считается распределенной системой. В качестве второго
примера
рассмотрим
автоматическую
работу
обработку
информационной
заказов.
Обычно
системы,
которая
поддерживает
подобные
системы
используются
сотрудниками нескольких отделов, возможно в разных местах. Так, сотрудники отдела
продаж могут быть разбросаны по обширному региону или даже по всей стране. Заказы
передаются с переносных компьютеров, соединяемых с системой при помощи телефонной
сети, а возможно, и при помощи сотовых телефонов. Приходящие заказы автоматически
передаются в отдел планирования, превращаясь там во внутренние заказы на поставку,
которые поступают в отдел доставки, и в заявки на оплату, поступающие в бухгалтерию.
Система автоматически пересылает эти документы имеющимся на месте
сотрудникам, отвечающим за их обработку. Пользователи остаются в полном неведении о
том, как заказы на самом деле курсируют внутри системы, для них все это представляется
так, будто вся работа происходит в централизованной базе данных.
Как основу описания взаимодействия двух сущностей рассмотрим общую модель
взаимодействия клиент-сервер, в которой одна из сторон (клиент) инициирует обмен
данными, посылая запрос другой стороне (серверу). Сервер обрабатывает запрос и при
необходимости посылает ответ клиенту (рис. 1.2).
Рис. 1.2. Модель взаимодействия клиент сервер
Взаимодействие в рамках модели клиент сервер может быть как синхронным, когда
клиент ожидает завершения обработки своего запроса сервером, так и асинхронным, при
котором клиент посылает серверу запрос и продолжает свое выполнение без ожидания
ответа сервера. Модель клиента и сервера может использоваться как основа описания
различных взаимодействий. Для данного курса важно взаимодействие составных частей
программного обеспечения, образующего распределенную систему.
Рис. 1.3. Логические уровни приложения
Рассмотрим некое типичное приложение, которое в соответствии с современными
представлениями может быть разделено на следующие логические уровни (рис. 1.3):
пользовательский интерфейс (ИП), логика приложения (ЛП) и доступ к данным (ДД),
работающий с базой данных (БД).
Пользователь системы взаимодействует с ней через интерфейс пользователя, база
данных хранит данные, описывающие предметную область приложения, а уровень логики
приложения реализует все алгоритмы, относящиеся к предметной области.
Поскольку на практике разных пользователей системы обычно интересует доступ к
одним и тем же данным, наиболее простым разнесением функций такой системы между
несколькими компьютерами будет разделение логических уровней приложения между
одной серверной частью приложения, отвечающим за доступ к данным, и находящимися
на нескольких компьютерах клиентскими частями, реализующими интерфейс
пользователя. Логика приложения может быть отнесена к серверу, клиентам, или
разделена между ними (рис. 1.4).
Рис. 1.4. Двухзвенная архитектура
Архитектуру построенных по такому принципу приложений называют клиент
серверной или двухзвенной. На практике подобные системы часто не относят к классу
распределенных, но формально они могут считаться простейшими представителями
распределенных систем.
Развитием архитектуры клиент-сервер является трехзвенная архитектура, в которой
интерфейс пользователя, логика приложения и доступ к данным выделены в
самостоятельные составляющие системы, которые могут работать на независимых
компьютерах (рис. 1.5).
Рис. 1.5. Трехзвенная архитектура
Запрос пользователя в подобных системах последовательно обрабатывается
клиентской частью системы, сервером логики приложения и сервером баз данных. Однако
обычно под распределенной системой понимают системы с более сложной архитектурой,
чем трехзвенная.
Таким образом, в обиходе под распределенной системой часто подразумевают рост
многозвенной архитектуры "в ширину", когда запросы пользователя не проходят
последовательно от интерфейса пользователя до единственного сервера баз данных.
В качестве другого примера распределенной системы можно привести сети
прямого обмена данными между клиентами (peer-to-peer networks), рис. 1.6. Подобные
системы являются в настоящий момент, вероятно, одними из крупнейших существующих
распределенных систем, объединяющие миллионы компьютеров.
Рис. 1.6. Система прямого обмена данными между клиентами
1.2. Программные компоненты
В распределенных системах функции одного уровня приложения могут быть
разнесены между несколькими компьютерами. С другой стороны, программное
обеспечение, установленное на одном компьютере, может отвечать за выполнение
функций, относящихся к разным уровням. Поэтому подход к определению
распределенной системы, считающей ее совокупностью компьютеров, условен. Для
описания и реализации распределенных систем было введено понятие программной
компоненты.
Программная компонента – это единица программного обеспечения, исполняемая
на одном компьютере в пределах одного процесса, и предоставляющая некоторый набор
сервисов, которые используются через ее внешний интерфейс другими компонентами, как
выполняющимися на этом же компьютере, так и на удаленных компьютерах.
Ряд компонент пользовательского интерфейса предоставляют свой сервис
конечному пользователю.
Рис. 1.7. Компоненты распределенной системы
Применительно к программам с использованием платформы CLI, под процессом в
приведенном определении компоненты следует понимать домен приложения (application
domain), который можно рассматривать как аналог процесса в управляемом коде.
Основываясь на определении программной компоненты, можно дать более точное
определение распределенной системы. Согласно нему, распределенная система есть набор
взаимодействующих программных компонент, выполняющихся на одном или нескольких
связанных компьютерах и выглядящих с точки зрения пользователя системы как единое
целое (рис. 1.7). Прозрачность является атрибутом распределенной системы. При
исправном функционировании системы от конечного пользователя должно быть скрыто,
где и как выполняются его запросы.
Программная компонента является минимальной единицей развертывания
распределенной системы. В ходе модернизации системы одни компоненты могут быть
обновлены независимо от прочих компонент.
В хорошо спроектированной системе функции каждой компоненты относятся
только к одному уровню приложения. Однако разделение только на три уровня
представляется недостаточным для классификации компонент.
Например, часть компонент пользовательского интерфейса могут
взаимодействовать с пользователем, а часть – предоставлять свои сервисы другим
компонентам, но с пользователем не взаимодействовать.
Классификации подобного рода существуют, однако они не являются
общепринятыми и часто в значительной степени привязаны к приложениям
автоматизации деятельности предприятия, что все-таки не является синонимом
распределенной системы.
1.2.1 Взаимодействие программной компоненты
Ключевым сервисом промежуточной среды для создания распределенных систем
является обеспечение обмена данными между компонентами распределенной системы. В
настоящий момент существуют две концепции взаимодействия программных компонент:
обмен сообщениями между компонентами и вызов процедур или методов объекта
удаленной компоненты по аналогии с локальным вызовом процедуры. Поскольку в
настоящее время любое взаимодействие между удаленными компонентами в конечном
итоге основано на сокетах TCP/IP, первичным с точки зрения промежуточной среды
является низкоуровневый обмен сообщениями на основе сетевых сокетов, сервис которых
никак не определяет формат передаваемого сообщения. На базе протоколов TCP или
HTTP затем могут быть построены прикладные протоколы обмена сообщений более
высокого уровня абстракции для реализации более сложного обмена сообщениями или
удаленного вызова процедур.
Удаленный вызов является моделью, происходящей от языков программирования
высокого уровня, а не от реализации интерфейса транспортного уровня сетевых
протоколов. Поэтому протоколы удаленного вызова должны обязательно базироваться на
какой либо системе передачи сообщений, включая как непосредственное использование
сокетов TCP/IP, так и основанные на нем другие промежуточные среды для обмена
сообщениями. Реализация высокоуровневых служб обмена сообщениями, в свою очередь,
может использовать удаленный вызов процедур, основанный на более низкоуровневой
передаче сообщений, использующей, например, непосредственно сетевые сокеты. Таким
образом, одна промежуточная среда может использовать для своего функционирования
сервисы другой промежуточной среды, аналогично тому, как один протокол
транспортного или сетевого уровня может работать поверх другого протокола при
туннелировании протоколов.
Для
полного
формального
описания
взаимодействий
двух
компонент
распределенной системы необходимы в общем случае три языка:
-
язык
передаваемых
в
распределенной
системе
сообщений,
обычно
описывающий результат сериализации объектов;
-
язык
описания
спецификаций
сообщений,
определяющий
корректные
сообщения для сервисов компоненты;
-
язык описания интерфейса компоненты, определяющий набор ее сервисов.
Языки описания интерфейса и спецификаций сообщений часто представлены на
практике одним языком.
1.2.2 Описание программной компоненты.
Для работы с сервисами программной компоненты обращающийся к ним клиент
должен иметь полное представление об интерфейсе используемой компоненты. Несмотря
на значительные отличия модели передачи сообщений и модели удаленного вызова, для
них обеих интерфейс компоненты распределенной системы можно описать как
совокупность
адресов
и
форматов
сообщений
ее
сервисов.
В
роли
сервиса,
предоставляемой программной компонентой выступает одно из следующих понятий:
-
методы активируемого сервером объекта;
-
активируемый клиентом объект вместе со своими полями, свойствами и
методами;
-
очередь с сообщениями запросами, которые считываются программной
компонентой.
Адрес сервиса зависит от промежуточной среды и является совокупностью
сетевого адреса компоненты и некоторого публичного имени сервиса. Сетевой адрес
программной компоненты основан на имени ее компьютера для систем удаленного вызова
или на адресе менеджера очереди для систем обмена сообщениями. Данный адрес
является адресом нижестоящего протокола, на котором основана данная промежуточная
среда. В роли него может выступать HTTP, TCP, NetBIOS, или протокол нижестоящей
промежуточной среды. Второй составляющей адреса сервиса является идентификатор
сервиса. В роли него может выступать некий идентификатор активируемого класса для
сред удаленного вызова или же имя очереди сообщений, из которой сервис считывает
сообщения запросы. Хотя имя вызываемого метода часто фактически описывается в
самом сообщении, его следует рассматривать как составную часть адреса сервиса,
поскольку форматы сообщений, очевидно, различаются для различных методов одного и
того же класса.
Если компонента системы передачи сообщений посылает сообщения ответы
клиенту, то можно считать, что сервис такой компоненты имеет два адреса – один для
очереди запросов и второй для очереди ответов (имя очереди ответов может быть задано и
в сообщении запросе).
Кроме информации о полном адресе сервиса, клиенту компоненты необходимо
знать формат сообщений, получаемых и возвращаемых сервисом. К первым относятся
сообщения с параметрами удаленного вызова и сообщения запросы в очередях
сообщений, ко вторым – сообщения с результатом выполнения метода и сообщения
ответы. К параметрам удаленного метода следует отнести и некоторый идентификатор
активированного объекта сервера для случая активации объектов по запросу клиента.
Можно постулировать, что каждому сервису компоненты должна соответствовать
единственная спецификация формата принимаемых им сообщений и единственная
спецификация принимаемых от него сообщений (в частном случае это спецификация
информирует об отсутствии ответа компоненты).
Важным различием систем обмена сообщениями от систем удаленного вызова
является отсутствие ограничений на формат сообщения. Таким образом, формально в них
существует возможность использования для описания формата сообщения, например,
контекстно свободных формальных грамматик. Однако было бы естественным считать,
что формат сообщения должен быть эквивалентен описанию полей некоторого класса
CLI. Объект данного класса преобразуется в результате сериализации в передаваемое
сообщение.
Если и каждое сообщение в системах очередей сообщений, и параметры
удаленного вызова метода будут представлять собой единственный сериализованный
объект
некоторого
сложного
типа
данных,
то
различие
между
системами
с
активируемыми сервером объектами и системами передачи сообщений становится
минимальным. Кроме того, ранее было показано, что единственный параметр удаленного
вызова является хорошим решением проблемы недоступности свойств активируемых
сервером объектов. Поэтому существует рекомендация создавать удаленные методы с
единственным параметром сложного типа. Этот объект должен маршализироваться по
значению, как и все его поля и свойства.
Итого,
каждый
сервис
программной
компоненты
характеризуется
тремя
сущностями:
-
полным адресом сервиса;
-
единственной спецификацией принимаемых сервисом сообщений (запросов);
-
единственной спецификацией принимаемых от сервиса сообщений (ответов).
Совокупность спецификаций всех сервисов программной компоненты образует ее
интерфейс (рис. 1.8).
Рис. 1.8. Интерфейс компоненты распределенной системы
Для
полного
формального
описания
взаимодействий
двух
компонент
распределенной системы необходимы в общем случае три языка:
-
язык
передаваемых
в
распределенной
системе
сообщений,
обычно
описывающий результат сериализации объектов;
-
язык
описания
спецификаций
сообщений,
определяющий
корректные
сообщения для сервисов компоненты;
-
язык описания интерфейса компоненты, определяющий набор ее сервисов.
Языки описания интерфейса и спецификаций сообщений часто представлены на
практике одним языком.
Поскольку сообщение обычно представлено результатом сериализации того или
иного класса, то одной из спецификаций сообщения можно считать совокупность
сериализуемых полей и свойств маршализируемого по значению объекта. Для систем
удаленного вызова спецификацией интерфейса может являться описание класса .NET.
Таким образом, метаданные из сборок с описанием интерфейса или класса удаленного
объекта и классами параметров его методов полностью определяют интерфейс
программной компоненты. Однако такой подход часто неудобен, поскольку не только
уменьшает
открытость
системы, привязывая описание интерфейса программной
компоненты к используемому для ее создания средству разработки, но и требует
предоставления в общем случае сборок с классами компоненты клиенту. Поэтому
существует потребность в общепринятых и независимых от средств разработки
программных компонент языках описания интерфейса компоненты.
1.3. Требования к распределенным системам
Распределенные системы имеют следующие характерные черты:
1.
Первым аспектом является отдаленность. Компоненты распределенной системы
всегда
пространственно разделены друг с другом. Во взаимодействия вступают или локально или
удаленно.
2.
Компоненты распределенной системы могут работать параллельно, из-за чего
скорость работы возрастает по сравнению с последовательными.
3.
Локальные рассмотрения состояния.
4.
Компоненты работают независимо и могут «выпадать» также независимо друг от
друга. Распределенные системы подлежат, таким образом, частичному системному
выпадению.
5.
Система работает асинхронно. Процессы коммуникации и обработки не
управляются глобальным системным временем. Изменения и процессы
синхронизируются.
6.
В Распределенной системе могут функции управления распределяются между
автономными различными компонентами, так называемыми авторитетами. При этом
никакой отдельный авторитет не может осуществлять весь контроль. Это гарантирует
определенную меру автономии.
7.
Распределенная система может возникать из общих концов от уже существующих
систем. Следовательно, требуется контекстно-полное управление именами, которое дает
возможность однозначно интерпретировать фамилии (имена) в границах
административной или технологической области. Говорят в этой связи о федеративном
управлении именами.
8.
Чтобы повысить мощность распределенной системы, программы и данные могут
перемещаться между различными узлами, эта концепция называется миграцией. При этом
нужно приобщать дополнительные механизмы, которые протоколируют положение
программ и данных.
9.
Распределенная система должна быть в состоянии предпринимать динамичные
изменения структуры. Эта динамичная реконфигурация требуется, к примеру, тогда, если
в течение времени должны появляться новые соединения.
10.
Архитектуры компьютера могут использовать различные топологии и механизмы,
в частности, если продукты поступают от различных производителей. Эта характеристика
называется гетерогенностью.
11.
Распределенная система подлежит эволюции. Т.е. за время ее жизни происходят
различные изменения.
12.
Источники сведений, единицы обработки и пользователи могут быть физически
мобильны. Программы и данные могут перемещаться между узлами, для получения
мобильности системы или увеличения мощности.
Чтобы достигнуть цели своего существования – улучшения выполнения запросов
пользователя – распределенная система должна удовлетворять некоторым необходимым
требованиям. Можно сформулировать следующий набор требований, которым в
наилучшем случае должна удовлетворять распределенная вычислительная система.
Соединение пользователей с ресурсами, облегчить пользователям доступ к
удаленным ресурсам и обеспечить их совместное использование, регулируя этот процесс.
Ресурсы могут быть виртуальными, однако традиционно они включают в себя принтеры,
компьютеры, устройства хранения данных, файлы и данные. Web-страницы и сети также
входят в этот список. Существует множество причин для совместного использования
ресурсов. Одна из очевидных — это экономичность. Например, гораздо дешевле
разрешить совместную работу с принтером нескольких пользователей, чем покупать и
обслуживать отдельный принтер для каждого пользователя. Точно так же имеет смысл
совместно использовать дорогие ресурсы, такие как суперкомпьютеры или
высокопроизводительные хранилища данных.
Открытость. Все протоколы взаимодействия компонент внутри распределенной
системы в идеальном случае должны быть основаны на общедоступных стандартах. Это
позволяет использовать для создания компонент различные средства разработки и
операционные системы. Каждая компонента должна иметь точную и полную
спецификацию своих сервисов. В этом случае компоненты распределенной системы могут
быть созданы независимыми разработчиками. При нарушении этого требования может
исчезнуть возможность создания распределенной системы, охватывающей несколько
независимых организаций.
Масштабируемость. Масштабируемость вычислительных систем имеет
несколько аспектов. Наиболее важный из них для данного курса – возможность
добавления в распределенную систему новых компьютеров для увеличения
производительности системы, что связано с понятием балансировки нагрузки (load
balancing) на серверы системы. К масштабированию относятся так же вопросы
эффективного распределения ресурсов сервера, обслуживающего запросы клиентов.
Поддержание логической целостности данных. Запрос пользователя в
распределенной системе должен либо корректно выполняться целиком, либо не
выполняться вообще. Ситуация, когда часть компонент системы корректно обработали
поступивший запрос, а часть – нет, является наихудшей.
Устойчивость. Под устойчивостью понимается возможность дублирования
несколькими компьютерами одних и тех же функций или же возможность
автоматического распределения функций внутри системы в случае выхода из строя одного
из компьютеров. В идеальном случае это означает полное отсутствие уникальной точки
сбоя, то есть выход из строя одного любого компьютера не приводит к невозможности
обслужить запрос пользователя.
Безопасность. Каждый компонент, образующий распределенную систему, должен
быть уверен, что его функции используются авторизированными на это компонентами
или пользователями. Данные, передаваемые между компонентами, должны быть
защищены как от искажения, так и от просмотра третьими сторонами.
Эффективность. В узком смысле применительно к распределенным системам под
эффективностью будет пониматься минимизация накладных расходов, связанных с
распределенным характером системы. Поскольку эффективность в данном узком смысле
может противоречить безопасности, открытости и надежности системы, следует отметить,
что требование эффективности в данном контексте является наименее приоритетным.
Например, на поддержку логической целостности данных в распределенной системе
могут тратиться значительные ресурсы времени и памяти, однако система с
недостоверными данными вряд ли нужна пользователям. Желательным свойством
промежуточной среды является возможность организации эффективного обмена данными,
если взаимодействующие программные компоненты находятся на одном компьютере.
Эффективная промежуточная среда должна иметь возможность организации их
взаимодействия без затрагивания стека TCP/IP. Для этого могут использоваться
системные сокеты (unix sockets) в POSIX системах или именованные каналы (named
pipes).
Устойчивость распределенной системы связана с понятием масштабируемости, но
не эквивалентна ему. Допустим, система использует набор обрабатывающих запросы
серверов и один диспетчер запросов, который распределяет запросы пользователей между
серверами. Такая система может считаться достаточно хорошо масштабируемой, однако
диспетчер является уязвимой точкой такой системы. С другой стороны, система с
единственным сервером может быть устойчива, если существует механизм его
автоматической замены в случае выхода его из строя, однако она вряд ли относится к
классу хорошо масштабируемых систем. На практике достаточно часто встречаются
распределенные системы, не удовлетворяющие данным требованиям: например, любая
система с уникальным сервером БД, реализованным в виде единственного компьютера,
имеет уникальную точку сбоя. Выполнение требований устойчивости и
масштабируемости обычно связано с некоторыми дополнительным расходами, что на
практике может быть не всегда целесообразно. Однако используемые при построении
распределенных систем технологии должны допускать принципиальную возможность
создания устойчивых и высоко масштабируемых систем.
Классическим примером системы, в значительной мере отвечающей всем
представленным выше требованиям, является система преобразования символьных имен в
сетевые IP-адреса (DNS). Система имен – организованная иерархически распределенная
система, с дублированием всех функций между двумя и более серверами (рис. 1.8).
Рис. 1.8. Система DNS
Запрос пользователя на преобразование имени (например, w3c.org) в сетевой адрес
передается серверу распознавания имен поставщика услуг Интернета. Сервер
распознавания имен по очереди опрашивает серверы из иерархии службы имен. Опрос
начинается с корневых серверов, который возвращает адреса серверов, ответственных за
зону домена. Затем опрашивается сервер, ответственный за зону (в данном случае – .org),
возвращающий адреса серверов, ответственных за домен второго уровня, и так далее.
Серверы имен кэшируют информацию о соответствии имен и адресов для уменьшения
нагрузки на систему. Программное обеспечение на компьютере пользователя обычно
имеет возможность соединиться с как минимум двумя различными серверами
распознавания имен.
Тем не менее, и в системе распознавания имен не все требования к распределенным
системам выполнены. В частности, она не содержит каких-либо явных механизмов
обеспечения безопасности. Это приводит к регулярным атакам на серверы имен в надежде
вывести их из строя, например, большим количеством запросов.
1.4 Понятие программной среды
В категорию «Программная среда» включены данные о конфигурации системы, в
том числе сведения о системных драйверах, переменных среды и имеющихся заданиях
печати. Далее перечислены элементы, входящие в категорию «Программная среда»
сведений о системе.

Системные драйверы

Подписанные драйверы

Переменные среды

Задания печати

Элемент «Сетевые подключения» из раздела «Сведения о системе»

Выполняемые задачи

Загруженные модули

Службы

Группы программ

Регистрация OLE(Object Linking and Embedding)
Аппаратура важна для распределенных систем, однако от программного
обеспечения значительно сильнее зависит, как такая система будет выглядеть на самом
деле. Распределенные системы очень похожи на традиционные операционные системы.
Прежде всего, они работают как менеджеры ресурсов (resource managers) существующего
аппаратного обеспечения, которые помогают множеству пользователей и приложений
совместно использовать такие ресурсы, как процессоры, память, периферийные
устройства, сеть и данные всех видов. Во-вторых, что, вероятно, более важно,
распределенная система скрывает сложность и гетерогенную природу аппаратного
обеспечения, на базе которого она построена, предоставляя виртуальную машину для
выполнения приложений.
Чтобы
понять
природу
распределенной
системы,
рассмотрим
сначала
операционные системы с точки зрения распределенности. Операционные системы для
распределенных компьютеров можно вчерне разделить на две категории — сильно
связанные и слабо связанные системы. В сильно связанных системах операционная
система в основном старается работать с одним, глобальным представлением ресурсов,
которыми она управляет. Слабо связанные системы могут представляться несведущему
человеку набором операционных систем, каждая из которых работает на собственном
компьютере. Однако эти операционные системы функционируют совместно, делая
собственные службы доступными другим.
Это деление на сильно и слабо связанные системы связано с классификацией
аппаратного обеспечения, приведенной в предыдущем разделе. Сильно связанные
операционные
системы
обычно
называются
распределенными
операционными
системами (Distributed Operating System, DOS) и используются для управления
мультипроцессорными и гомогенными мультикомпьютерными системами. Как и у
традиционных однопроцессорных операционных систем, основная цель распределенной
операционной
системы состоит
в сокрытии тонкостей
управления аппаратным
обеспечением, которое одновременно используется множеством процессов.
Слабо связанные сетевые операционные системы (Network Operating Systems,
NOS) используются для управления гетерогенными мультикомпьютерными системами.
Хотя управление аппаратным обеспечением и является основной задачей сетевых
операционных систем, они отличаются от традиционных. Это отличие вытекает из того
факта, что локальные службы должны быть доступными для удаленных клиентов. В
следующих пунктах мы рассмотрим в первом приближении те и другие.
Чтобы
действительно
составить
распределенную
систему,
служб
сетевой
операционной системы недостаточно. Необходимо добавить к ним дополнительные
компоненты, чтобы организовать лучшую поддержку прозрачности распределения. Этими
дополнительными
компонентами
будут
средства,
известные
как
системы
промежуточного уровня (middleware), которые и лежат в основе современных
распределенных систем.
2. Концепции аппаратных решений
Существует разделение распределенных компьютерных систем на гомогенные
(homogeneous)
и
гетерогенные
(heterogeneous).
Это
разделение
применяется
исключительно к мультикомпьютерным системам.
Для гомогенных мультикомпьютерных систем характерна одна соединяющая
компьютеры сеть, использующая единую технологию. Каждый процессор напрямую
связан со своей локальной памятью. Одинаковы также и все процессоры, которые в
основном имеют доступ к одинаковым объемам собственной памяти. Гомогенные
мультикомпьютерные
системы
нередко
используются
в
качестве
параллельных
(работающих с одной задачей), в точности как мультипроцессорные.
В отличие от них гетерогенные мультикомпьютерные системы могут содержать
целую гамму независимых компьютеров, соединенных разнообразными сетями. Так,
например, распределенная компьютерная система может быть построена из нескольких
локальных компьютерных сетей.
2.1. Операционные системы для однопроцессорных компьютеров
Операционные системы традиционно строились для управления компьютерами с
одним процессором. Основной задачей этих систем была организация легкого доступа
пользователей и приложений к разделяемым устройствам, таким как процессор, память,
диски и периферийные устройства. Говоря о разделении ресурсов, мы имеем в виду
возможность использования одного и того же аппаратного обеспечения различными
приложениями изолированно друг от друга. Для приложения это выглядит так, словно эти
ресурсы находятся в его полном распоряжении, при этом в одной системе может
выполняться одновременно несколько приложений, каждое со своим собственным
набором ресурсов. В этом смысле говорят, что операционная система реализует
виртуальную
машину
мультизадачности.
(virtual
machine),
предоставляя
приложениям
средства
2.2. Мультипроцессорные операционные системы
Важным, но часто не слишком очевидным расширением однопроцессорных
операционных систем является возможность поддержки нескольких процессоров,
имеющих доступ к совместно используемой памяти. Концептуально это расширение
несложно. Все структуры данных, необходимые операционной системе для поддержки
аппаратуры, включая поддержку нескольких процессоров, размещаются в памяти.
Основная разница заключается в том, что теперь эти данные доступны нескольким
процессорам и должны быть защищены от параллельного доступа для обеспечения их
целостности.
Однако
многие
операционные
системы,
особенно
предназначенные
для
персональных компьютеров и рабочих станций, не могут с легкостью поддерживать
несколько процессоров. Основная причина такого поведения состоит в том, что они были
разработаны как монолитные программы, которые могут выполняться только в одном
потоке управления. Адаптация таких операционных систем под мультипроцессорные
означает повторное проектирование и новую реализацию всего ядра. Современные
операционные системы изначально разрабатываются с учетом возможности работы в
мультипроцессорных системах.
2.3. Модель клиент-сервер
До этого момента мы вряд ли сказали что-то о действительной организации
распределенных систем, более интересуясь тем, как в этих системах организованы
процессы. Несмотря на то, что достичь согласия по вопросам, связанным с
распределенными системами, было нелегко, по одному из вопросов исследователи и
разработчики все же договорились. Они пришли к выводу о том, что мышление в
понятиях клиентов, запрашивающих службы с серверов, помогает понять сложность
распределенных систем и управляться с ней. В этом разделе мы кратко рассмотрим
модель клиент-сервер.
2.4. Клиенты и серверы
В базовой модели клиент-сервер все процессы в распределенных системах делятся
на две возможно перекрывающиеся группы. Процессы, реализующие некоторую службу,
например службу файловой системы или базы данных, называются серверами (servers).
Процессы, запрашивающие службы у серверов путем посылки запроса и последующего
ожидания ответа от сервера, называются клиентами (clients). Взаимодействие клиента и
сервера, известное также под названием режим работы запрос-ответ (request-reply
behavior), иллюстрирует рис. 2.1.
Рис. 2.1. Обобщенное взаимодействие между клиентом и сервером
Если базовая сеть так же надежна, как локальные сети, взаимодействие между
клиентом и сервером может быть реализовано посредством простого протокола, не
требующего установления соединения. В этом случае клиент, запрашивая службу,
облекает свой запрос в форму сообщения с указанием в нем службы, которой он желает
воспользоваться, и необходимых для этого исходных данных. Затем сообщение
посылается серверу. Последний, в свою очередь, постоянно ожидает входящего
сообщения, получив его, обрабатывает, упаковывает результат обработки в ответное
сообщение и отправляет его клиенту.
Использование не требующего соединения протокола дает существенный выигрыш
в эффективности. До тех пор пока сообщения не начнут пропадать или повреждаться,
можно вполне успешно применять протокол типа запрос-ответ. К сожалению, создать
протокол, устойчивый к случайным сбоям связи, — нетривиальная задача. Все, что мы
можем сделать, — это дать клиенту возможность повторно послать запрос, на который не
был получен ответ. Проблема, однако, состоит в том, что клиент не может определить,
действительно ли первоначальное сообщение с запросом было потеряно или ошибка
произошла при передаче ответа. Если потерялся ответ, повторная посылка запроса может
привести к повторному выполнению операции.
Рассматривая множество приложений типа клиент-сервер, предназначенных для
организации доступа пользователей к базам данных, многие рекомендовали разделять их
на три уровня.

уровень пользовательского интерфейса;

уровень обработки;

уровень данных.
Уровень
пользовательского
интерфейса
содержит
все
необходимое
для
непосредственного общения с пользователем, например для управление дисплеем.
Уровень обработки обычно содержит приложения, а уровень данных — собственно
данные, с которыми происходит работа.
Итоги
Распределенные системы состоят из автономных компьютеров, которые работают
совместно, представая в виде единой связной системы. Их важное преимущество состоит
в том, что они упрощают интеграцию различных приложений, работающих на разных
компьютерах, в единую систему. Еще одно их преимущество — при правильном
проектировании
распределенные
системы
хорошо
масштабируются.
Их
размер
ограничивается только размером базовой сети. Платой за эти преимущества часто
является очень сложное программное обеспечение, падение производительности и
особенно проблемы с безопасностью. Тем не менее, заинтересованность в построении и
внедрении распределенных систем наблюдается повсеместно.
Существуют
различные
типы
распределенных
систем.
Распределенные
операционные системы используются для управления аппаратным обеспечением
взаимосвязанных компьютерных систем, к которым относятся мультипроцессорные и
гомогенные мультикомпьютерные системы. Эти распределенные системы на самом деле
не состоят из автономных компьютеров, но успешно воспринимаются в виде единой
системы. Сетевые операционные системы, с другой стороны, с успехом объединяют
различные компьютеры, работающие под управлением своих операционных систем, так
что пользователи с легкостью могут получать доступ к локальным службам каждого из
узлов. Однако сетевые операционные системы не создают ощущения работы с единой
системой, которое характерно для распределенных операционных систем.
Современные
распределенные
системы
обычно
содержат
поверх
сетевой
операционной системы дополнительный уровень программного обеспечения. Этот
уровень,
называемый
гетерогенность
и
промежуточным,
распределенную
предназначен
природу
для
базового
того,
набора
чтобы
скрыть
компьютеров.
Распределенные системы с промежуточным уровнем обычно требуют специфическую
модель распределения и связи. Известные модели основаны на удаленном вызове
процедур, а также на распределенных объектах, файлах или документах.
Для каждой распределенной системы важна схема ее внутренней организации.
Широко применяется модель, в которой процессы клиента запрашивают службы у
процессов сервера. Клиент посылает на сервер сообщение и ожидает, пока тот вернет
ответ. Эта модель тесно связана с традиционным программированием, в котором службы
реализуются в виде процедур в отдельных модулях. Дальнейшее уточнение обычно
состоит в подразделении на уровень пользовательского интерфейса, уровень обработки и
уровень данных. Сервер обычно отвечает за уровень данных, а уровень пользовательского
интерфейса реализуется на стороне клиента. Уровень обработки может быть реализован
на клиенте, на сервере или поделен между ними.
В современных распределенных системах для построения крупномасштабных
систем такой вертикальной организации приложений модели клиент-сервер недостаточно.
Необходимо горизонтальное распределение, при котором клиенты и серверы физически
распределены и реплицируются на несколько компьютеров. Типичным примером
успешного применения горизонтального распределения является World Wide Web.