Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

1.5. Модель клиент-сервер 71

понятна. В следующих пунктах мы ближе рассмотрим некоторые дополнитель-

ные аспекты модели клргент-сервер.

Листинг 1.4. Пример сервера

#1nclucie <heacler.h>

void ma1n(vo1ci) {

struct message ml.

m2:

1nt

whlle(TRUE)

{

receive(FILE_SERVER,

switch(mi.opcode)

{

case CREATE:

case READ:

case WRITE:

case DELETE:

default:

/'^

входящее

исходящее сообщения

1'^

код

результата

сервер работает непрерывно

&ml):

блок ожидания сообщения

/* в

зависимости

от

типа запроса

do_create(&ml. &m2); break:

do_read(&ml.

&m2) break:

do_wr1te(&ml.

&m2): break;

do_delete(&ml. &m2): break:

BAD

OPER;

m2.result

= r:

send(m1.sowvz^, &m2):

вернуть результат клиенту

послать ответ

Листинг 1.5. Клиент, использующий сервер из листинга 1.4 для копирования файла

#1nclucle <header.h>

1'^ процедура копирования файла

1nt copyCchar *src. char *dst)i

struct message ml:

long position:

long client

110:

initializeO:

position

= 0:

{

ml.opcode

READ:

ml.offset

position:

ml.

count

BUFJIZE:

strcpy(&ml.name, src):

sendCFILESERVER. &ml):

receiveCclient. &ml):

Записать полученные данные

ml.opcode

WRITE:

ml.offset

position:

ml.count

ml.result:

strcpy(&ml.name,

cist):

send(FILE_SERVER. &ml):

receive(client. &ml):

position

ml.result:

} whileC ml.result

> 0 ):

1'^ вернуть

OK или код

ошибки

returnCml.result

>= 0 ? OK :

через сервер

•ki

буфер сообщения

текущая позиция

файле

адрес клиента

подготовиться

выполнению

операция чтения

текущая позиция

файле

сколько байт прочитать

скопировать

имя

читаемого

файла*/

послать сообщение

на

файловый сервер*/

блок ожидания ответа

файл-приемник.

операция: запись

текущая позиция

файле

сколько байт записать

скопировать

имя

записываемого

файла*/

послать сообщение

на

файловый сервер

блок ожидания ответа

в ml.result содержится

количество записанных байтов

повторять

до

окончания

I-'

.result):

72 Глава 1. Введение

1.5.2. Разделение приложений по уровням

Модель клиент-сервер была предметом множества дебатов и споров. Один из

главных вопросов состоял в том, как точно разделить клиента и сервера. Понят-

но,

что обычно четкого различия нет. Например, сервер распределенной базы

данных может постоянно выступать клиентом, передающим запросы на различ-

ные файловые серверы, отвечающие за реализацию таблиц этой базы данных.

В этом случае сервер баз данных сам по себе не делает ничего, кроме обработки

запросов.

Однако рассматривая множество приложений типа клиент-сервер, предна-

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

комендовали разделять их на три уровня.

> уровень пользовательского интерфейса;

уровень обработки;

> уровень данных.

Уровень пользовательского интерфейса содержит все необходимое для непо-

средственного общения с пользователем, например для управление дисплеем.

Уровень обработки обычно содержит приложения, а уровень данных — собст-

венно данные, с которыми происходит работа. В следующих пунктах мы обсу-

дим каждый из этих уровней.

Уровень пользовательского интерфейса

Уровень пользовательского интерфейса обычно реализуется на клиентах. Этот

уровень содержит программы, посредством которых пользователь может взаимо-

действовать с приложением. Сложность программ, входящих в пользовательский

интерфейс, весьма различна.

Простейший вариант программы пользовательского интерфейса не содержит

ничего, кроме символьного (не графического) дисплея. Такие интерфейсы обыч-

но используются при работе с мэйнфреймами. В том случае, когда мэйнфрейм

контролирует все взаимодействия, включая работу с клавиатурой и монитором,

мы вряд ли можем говорить о модели клиент-сервер. Однако во многих случаях

терминалы пользователей производят некоторую локальную обработку, осуще-

ствляя, например, эхо-печать вводимых строк или предоставляя интерфейс

форм, в котором можно отредактировать введенные данные до их пересылки на

главный компьютер.

В наше время даже в среде мэйнфреймов наблюдаются более совершенные

пользовательские интерфейсы. Обычно на клиентских машинах имеется как ми-

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

выпадающие меню и множество управляющих элементов, доступных для мыши

или клавиатуры. Типичные примеры таких интерфейсов — надстройка X-Win-

dows,

используемая во многих UNIX-системах, и более ранние интерфейсы, раз-

работанные для персональных компьютеров, работающих под управлением MS-

DOS и Apple Macintosh.

1.5. Модель клиент-сервер 73

Современные пользовательские интерфейсы значительно более функцио-

нальны. Они поддерживают совместную работу приложений через единст-

венное графическое окно и в ходе действий пользователя обеспечивают через

это окно обмен данными. Например, для удаления файла часто достаточно

перенести значок, соответствующий этому файлу, на значок мусорной кор-

зины. Аналогичным образом многие текстовые процессоры позволяют поль-

зователю перемегцать текст документа в другое место, пользуясь только мы-

шью.

Мы вернемся к пользовательским интерфейсам в главе 3.

Уровень обработки

Многие приложения модели клиент-сервер построены как бы из трех различных

частей: части, которая занимается взаимодействием с пользователем, части, кото-

рая отвечает за работу с базой данных или файловой системой, и средней части,

реализующей основную функциональность приложения. Эта средняя часть логи-

чески располагается на уровне обработки. В противоположность пользователь-

ским интерфейсам или базам данных на уровне обработки трудно выделить об-

щие закономерности. Однако мы приведем несколько примеров для разъяснения

вопросов, связанных с этим уровнем.

В качестве первого примера рассмотрим поисковую машину в Интернете.

Если отбросить все анимированные баннеры, картинки и прочие оконные укра-

шательства, пользовательский интерфейс поисковой машины очень прост: поль-

зователь вводит строку, состоящую из ключевых слов, и получает список заго-

ловков web-страниц. Результат формируется из гигантской базы просмотренных

и проиндексированных web-страниц. Ядром поисковой машины является про-

грамма, трансформирующая введенную пользователем строку в один или не-

сколько запросов к базе данных. Затем она помещает результаты запроса в спи-

сок и преобразует этот список в набор HTML-страниц. В рамках модели клиент-

сервер часть, которая отвечает за выборку информации, обычно находится на

уровне обработки. Эта структура показана на рис. 1.19.

Уровень

пользовательского

интерфейса

Пользовательский

интерфейс

le /

Выражение

с ключевыми /

словами /

HTML-страница

ч со списком

Генератор

запросов

Генератор

HTML-страниц

Запросы

к базе данных

База данных

web-страниц

Компонент

упорядочивания

Упорядоченный

список

заголовков

страниц

Заголовки web-страниц

с метаинформацией

Уровень

обработки

Рис. 1.19. Обобщенная организация трехуровневой поисковой машины для Интернета

74 Глава 1. Введение

В качестве второго примера рассмотрим систему поддержки принятия penie-

ний для фондового рынка. Так же как PI В ПОИСКОВОЙ машине, эту систему можно

разделР1ть на внепрнрпр ригтерфейс, реалргзующий работу с пользователем, внут-

ренрпою часть, отвечающую за доступ к базе с финансовор! информацией,

проме-

жуточную программу анализа. Анализ финансовых данных может потребовать

замысловатых методик и технологий на основе статистических методов и искус-

ственного интеллекта. В некоторых случаях для того, чтобы обеспечить требуе-

мые производительрюсть и время отклика, ядро системы поддержки финансовых

решений должно выполняться на высокопроизводительных компьютерах.

Нашим последнихм примером будет типичный офисный пакет, состоя1ций из

текстового процессора, приложения для работы с электронными таблицами, ком-

муникационных утилит и т. д. Подобные офисные пакеты обычно поддерживают

обобщенный пользовательский интерфейс, возможность создания составных до-

кументов и работу с файлами в домашнем каталоге пользователя. В этом случае

уровень обработки будет включать в себя относительно большой набор про-

грамм, каждая из которых призвана поддерживать какую-то из функций обра-

ботки.

Уровень данных

Уровень данных в модели клиент-сервер содержит программы, которые предо-

ставляют данР1ые обрабатывающим их приложениям. Спецр1фр1ческим свойством

этого уровня является требование сохранности (persistence). Это означает, что

когда приложение не работает, данные должны сохраняться в определенном мес-

те в расчете на дальнейшее использование. В простейшем варианте уровень дан-

ных реализуется файловой системой, но чаще для его реализации задействуется

полномасштабная база данных. В модели клиент-сервер уровень данных обычно

находится на стороне сервера.

Кроме простого храненрш информациР1 уровень данных обычно также отвеча-

ет за поддержание целостности данных для различных приложений. Для базы

данных поддержание целостности означает, что метаданные, такие как описания

таблиц, огранР1чения и специфические метаданные прршожений, также хранятся

на этом уровне. Например, в приложенрп! для банка мы можем пожелать сформи-

ровать уведомление, если долг клиента по кредитной карте достигнет определен-

ного значения. Это может быть сделано при помощи трр1ггера базы данных, кото-

рый в нужный момент активизирует процедуру, связанную с этим триггером.

Обычно в деловой среде уровень данных организуется в форме реляционной

базы данных. Ключевым здесь является независимость данных. Данные органи-

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

не влияли на приложения, а прршожения не оказывали влияния на организацию

данных. Использование реляционных баз данных в модели клиент-сервер помо-

гает нам отделить уровень обработки от уровня данных, рассматривая обработку

и данные независР1мо друг от друга.

Однако существует обширный класс приложений, для которых реляционные

базы данных не являются наилучшим выбором. Характерной чертой таких при-

ложений является работа со сложными типами данных, которые проще модели-

1.5. Модель клиент-сервер

ровать в понятиях объектов, а не отношений. Примеры таких типов данных

—

от

простых наборов прямоугольников и окружностей до проекта самолета в случае

систем автоматизированного проектирования. Также и мультимедийным систе-

мам значительно проще работать с видео- и аудиопотоками, используя специ-

фичные для них операции, чем с моделями этих потоков в виде реляционных

таблиц.

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

нятиях работы с объектами, имеет смысл реализовать уровень да}П1ых средства-

ми объектно-ориентированных баз данных. Подобные базы данных не только

поддерживают организацию сложных данных в форме объектов, но и хранят реа-

лизации операций над этими объектами. Таким образом, часть функцрюнально-

сти,

приходившейся на уровень обработки, мигрирует в этом случае на уровень

данных.

1.5.3.

Варианты архитектуры клиент-сервер

Разделение на три логических уровня, обсуждавшееся в предыдущем пункте, на-

водит на мысль о множестве вариантов физического распределения по отдель-

ным компьютерам приложений в модели клиент-сервер. Простейшая организа-

ция предполагает наличие всего двух типов машин.

> Клиентские машины, на которых имеются программы, реализующие толь-

ко пользовательский интерфейс или его часть.

-f Серверы, реализующие все остальное, то есть уровни обработки и данных.

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

является распределенной: все происходит на сервере, а клиент представляет со-

бой не что иное, как простой терминал. Существует также множество других

возможностей, наиболее употребительные из них мы сейчас рассмотрим.

Многозвенные архитектуры

Один из подходов к организации клиентов и серверов

—

это распределение про-

грамм, находящихся на уровне приложений, описанном в предыдущем пункте, по

различным машинам, как показано на рис. 1.20 [216,

467].

В качестве первого ша-

га мы рассмотрим разделение на два типа машин: на клиенты и на серверы, что

приведет нас к физически двухзветюй архитектуре {physically two-tiered archi-

tecture).

Один из возможных вариантов организации

—

поместить на клиентскую сторону

только терминальную часть пользовательского интерфейса, как показано на

рис.

1.20,

а,

позволив приложению удаленно контролировать представление данных.

Альтернативой этому подходу будет передача клиенту всей работы с поль-

зовательским интерфейсом (рис. 1.20, б). В обоих случаях мы отделяем от при-

ложения графический внешний интерфейс, связанный с остальной частью при-

ложения (находящейся на сервере) посредством специфичного для данного

приложения протокола. В подобной модели внешний интерфейс делает только

то,

что необходимо для предоставления рн1терфейса приложения.

76 Глава 1. Введение

Клиентская машина

Пользовательский

интерфейс

Пользовательский

интерфейс |

Приложение

База данных

Пользовательский

интерфейс

-1

Приложение

База данных

Пользовательский

интерфейс

1 Приложение

Приложение

База данных

Пользовательский

интерфейс

Приложение

База данных

Пользовательский

интерфейс

Приложение

База данных

Серверная машина

а 6 Q г д

Рис. 1.20. Альтернативные формы организации архитектуры клиент-сервер

Продолжим линию наших рассуждений. Мы можем перенести во внешний

интерфейс часть нашего приложения, как показано на рис. 1.20, в. Примером мо-

жет быть вариант, когда приложение создает форму непосредственно перед ее

заполнением. Внешний интерфейс затем проверяет правильность и полноту за-

полнения формы и при необходимости взаимодействует с пользователем. Дру-

гим примером органР1зации системы по образцу, представленному на рис. 1.20, в,

может служить текстовый процессор, в котором базовые функции редактирова-

ния осуществляются на стороне клиента с локально кэшируемыми или находя-

ш[имися в памяти данными, а специальная обработка, такая как проверка орфо-

графии или грамматики, выполняется на стороне сервера.

Во многих системах клиент-сервер популярна организация, представленная

на рис. 1.20, г и Э. Эти типы организации применяются в том случае, когда кли-

ентская машина

—

персональный компьютер или рабочая станция

—

соединена

сетью с распределенной файловой системой или базой данных. Большая часть

приложения работает на клиентской машине, а все операции с файлами или ба-

зой данных передаются на сервер. Рисунок 1.20, Ъ отражает ситуацию, когда

часть данных содержится на локальном диске клиента. Так, например, при рабо-

те в Интернете клиент может постепенно создать на локальном диске огромный

кэш наиболее часто посеплаемых web-страниц.

Рассматривая только клиенты и серверы, мы упускаем тот момент, что серве-

ру иногда может понадобиться работать в качестве клиента. Такая ситуация, от-

раженная на рис. 1.21, прр1водит нас к

физически трехзвепной

архитектуре {phy-

sically three-tiered

architecture^.

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

выносятся на отдельный сервер, но дополнительно могут частично находиться

и на машинах клиентов и серверов. Типичный пример трехзвепной архитекту-

ры

—

обработка транзакций. В этом случае отдельный процесс

—

монитор тран-

закций

—

координирует все транзакции, возможно, на нескольких серверах дан-

ных. Мы вернемся к обработке транзакций в следующих главах.

1.5. Модель клиент-сервер 77

Пользовательский

интерфейс

(представление)

Сервер

приложений

Ожи дан ие J^esjm

ьт_а_та_

иервер

баз данных Время •

Рис. 1.21. Пример сервера, действующего как клиент

Современные варианты архитектуры

Многозвенные архитектуры клиент-сервер являются прямым продолжением

разделения приложений на уровни пользовательского интерфейса, компонентов

обработки Pi данных. Различные звенья взаимодействуют в соответствии с логи-

ческой организацией приложения. Во множестве бизнес-приложений распределен-

ная обработка эквивалентна организации многозвенной архитектуры приложе-

ний клиент-сервер. Мы будем называть такой тип распределения вертикальным

распределением {vertical distribution). Характеристической особенностью вертикаль-

ного распределения является то, что оно достигается размещением логически

различных компонентов на разных машинах. Это понятие связано с концепцией

вертикального разбиения {vertical fragmentation), используемой в распределенных

реляционных базах данных, где под этим термином понимается разбиенрге по

столбцам таблиц для их хранения на различных машинах

[337].

Однако вертикальное распределение

—

это лишь один из возможных спосо-

бов организации приложений клиент-сервер, причем во многих случаях наименее

интересный. В современных архитектурах распределение на клиенты и серверы

происходит способом, известным как горизонтальное распределение {horizontal

distribution). При таком типе распределения клиент или сервер может содержать

физически разделенные части логически однородного модуля, причем работа

с каждой из частей может происходить независимо. Это делается для выравни-

вания загрузки.

В качестве распространенного примера горизонтального распределения рас-

смотрим web-сервер, peплициpoвapн^ый на несколько машгн! локальной сети, как

показано на рис. 1.22. На каждом из серверов содержится один и тот же набор

web-страниц, и всякий раз, когда одна из web-страниц обновляется, ее копии не-

замедлительно рассылаются на все серверы. Сервер, которому будет передан

приходящий запрос, выбирается по правилу «карусели» (round-robin). Эта фор-

ма горизонтального распределения весьма успешно используется для выравни-

вания нагрузки на серверы популярных web-сайтов.

Таким же образом, хотя и менее очевидно, могут быть распределены и клиен-

ты.

Для несложного приложения, предназначенного для коллективной работы,

мы можем не иметь сервера вообще. В этом случае мы обычно говорим об одно-

ранговом распределении {peer-to-peer distribution). Подобное происходит, напри-

78 Глава 1, Введение

мер,

если пользователь хочет связаться с другим пользователем. Оба они долж-

ны запустить одно и то же приложение, чтобы начать сеанс. Третий клиент

может общаться с одним из них или обоими, для чего ему нужно запустить то же

самое приложение.

Встреча

и обработка

входящих

запросов

Реплицированные web-серверы,

каждый из которых содержит

одни и те же web-страницы

Запросы

обрабатываемые

способом

«карусели»

- Диски

Рис. 1.22. Пример горизонтального распределения web-службы

Число альтернативных организаций архитектуры клиент-сервер обсуждается

в книге [3]. В следующих главах мы рассмотрим множество других вариантов

организации распределенных систем, в частности мы познакомимся с система-

ми,

распределенными одновременно и по вертикали, и по горизонтали.

1.6. Итоги

Распределенные системы состоят из автономных компьютеров, которые работа-

ют совместно, представая в виде единой связной системы. Их важное преимуще-

ство состоит в том, что они упрощают интеграцию различных приложений, рабо-

тающих на разных компьютерах, в единую систему. Еще одно их преимущество

—

при правильном проектировании распределенные системы хорошо масштабиру-

ются. Их размер ограничивается только размером базовой сети. Платой за эти

преимущества часто является очень сложное программное обеспечение, падение

производительности и особенно проблемы с безопасностью. Тем не менее заинте-

ресованность в построении и внедрении распределенных систем наблюдается по-

всеместно.

Существуют различные типы распределенных систем. Распределенные опе-

рационные системы используются для управления аппаратным обеспечением взаи-

мосвязанных компьютерных систем, к которым относятся мультипроцессорные

и гомогенные мультикомпьютерные системы. Эти распределенные системы на

самом деле не состоят из автономных компьютеров, но успешно воспринимают-

ся в виде единой системы. Сетевые операционные системы, с другой стороны,

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

1.6. Итоги 79

своих операционных систем, так что пользователи с легкостью могут получать

доступ к локальным службам каждого из узлов. Однако сетевые операционные

системы не создают ощущения работы с единой системой, которое характерно

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

Современные распределенные системы обычно содержат поверх сетевой опе-

рационной системы дополнительный уровень программного обеспечения. Этот

уровень, называемый промежуточным, предназначен для того, чтобы скрыть ге-

терогенность и распределенную природу базового набора компьютеров. Распре-

деленные системы с промежуточным уровнем обычно требуют специфическую

модель распределения и связи. Известные модели основаны на удаленном вызо-

ве процедур, а также на распределенных объектах, файлах или документах.

Для каждой распределенной системы важна схема ее внутренней организа-

ции. Широко применяется модель, в которой процессы клиента запрашивают

службы у процессов сервера. Клиент посылает на сервер сообщение и ожидает,

пока тот вернет ответ. Эта модель тесно связана с традиционным программиро-

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

Дальнейшее уточнение обычно состоит в подразделении на уровень пользова-

тельского интерфейса, уровень обработки и уровень данных. Сервер обычно от-

вечает за уровень данных, а уровень пользовательского интерфейса реализуется

на стороне клиента. Уровень обработки может быть реализован на клиенте, на

сервере или поделен между ними.

В современных распределенных системах для построения крупномасштабных

систем такой вертикальной организации приложений модели клиент-сервер не-

достаточно. Необходимо горизонтальное распределение, при котором клиенты

и серверы физически распределены и реплицируются на несколько компьюте-

ров.

Типичным примером успешного применения горизонтального распределе-

ния является World Wide Web.

Вопросы и задания

Какова роль программного обеспечения промежуточного уровня в распреде-

ленных системах?

Объясните, что такое прозрачность (распределения) и приведите примеры

различных видов прозрачности.

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

и восстановление после него?

Почему реализация максимально возможной степени прозрачности

—

это не

всегда хорошо?

Что такое открытая распределенная система и какие преимущества дает от-

крытость?

6. Опишите точно, что такое масштабируемая система.

Масштабируемости можно добиться, используя различные методики. Что это

за методики?

80 Глава 1. Введение

8. Чем мультипроцессорная система отличается от мультикомпьютерной?

9. Мультикомпьютерная система с 256 процессорами организована в виде

решетки 16x16. Какая в такой системе может быть максимальная задержка

(в хопах)?

10.

Рассмотрим 256-процессорный гиперкуб. Какая максимальная задержка мо-

жет наблюдаться в нем (снова в хопах)?

И. В чем состоит разница между распределенными и сетевыми операционными

системами?

12.

Расскажите, как можно использовать микроядро для организации операцион-

ной системы, работающей в режиме клиент-сервер.

13.

Опишите основные принципы работы распределенной системы с совместно

используемой памятью страничной организации.

14.

Какова причина разработки распределенных систем с совместно используе-

мой памятью? В чем, по-вашему, состоит главная трудность их эффективной

реализации?

15.

Расскажите, что такое ошибочное разделение в распределенных системах

с совместно используемой памятью. Какие решения этой проблемы вы може-

те предложить?

16.

Экспериментальный файловый сервер 3/4 времени работает, а 1/4 времени

«лежит» по причине ошибок. Сколько реплик этого сервера должно быть сде-

лано,

чтобы его доступность составляла хотя бы 99 %?

17.

Что такое трехзвенная архитектура клиент-сервер?

18.

В чем состоит разница между горизонтальным и вертикальным распределе-

ниями?

19.

Рассмотрим цепочку процессов Р],

Р2,

..., Р„, которая реализована в много-

звенной архитектуре клиент-сервер. Процесс Pi является клиентом процесса

Pf+i, возвращая, в свою очередь, результат процессу P/_i только после того,

как сам получит результат от процесса P/+i- Какова будет главная проблема

подобной организации, когда мы станем рассматривать производительность

запроса-ответа для процесса Р^?