Лычев А.В. Распределенные автоматизированные системы

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

Распределенные автоматизированные системы

140

Временные зависимости потоков данных выражаются в виде

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

сделать распределенная система для того, чтобы гарантиро-

вать сохранение в потоке данных заданных временных соотно-

шений. Требования к качеству обслуживания закрепляются в

документе, называемом спецификация передачи. Спецификация

передачи входит в пакет протоколов транспортного уровня мо-

дели OSI.

Для передачи потока данных распределенная система

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

честву обслуживания. Обычно такими ресурсами являются:

1. Пропускная способность каналов связи;

2. Буферная память маршрутизаторов;

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

В мультимедийных системах важное значение имеет взаим-

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

ние между ними строгих временных соотношений. Различают два

типа синхронизации вложенных потоков данных:

1. Простейшая синхронизация. Этот вид синхронизации

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

ных (напр.: показ слайдов со звуковым сопровождением);

2. Синхронизация артикуляции. Синхронизация артикуля-

ции осуществляется между непрерывными потоками данных. Этот

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

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

мыми им звуками. Примером синхронизации артикуляции может

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

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

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

20 мс.

Наиболее просто синхронизация вложенных потоков данных

достигается путем их взаимного мультиплексирования (напр.:

стандарт MPEG – Motion Picture Expert Group).

Глава 2. Миграция процессов

При наличии в распределенной системе бóльшего количе-

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

программы типа «клиент-сервер», возникает соблазн выровнять

загрузку имеющихся процессоров за счет перемещения (мигра-

ции) работающих процессов между ЭВМ сети.

§ 1. Перенос кода (перенос процессов)

Перенос кода (перенос процессов) с одной ЭВМ на другую

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

производительности системы. Перенос производится с сильно

Распределенные автоматизированные системы

141

загруженной машины на слабо загруженную. Загрузка ЭВМ обыч-

но определяется длиной очереди исполняемых программ к про-

цессору. Перенос кода позволяет динамически конфигурировать

модель «клиент-сервер», оперативно перемещая отдельные час-

ти прикладной программы, разбитой по уровням, с одной ЭВМ

на другую.

Модель переноса кода состоит из трех компонент:

1. Сегмент кода. Сегмент кода содержит набор исполняе-

мых инструкций переносимого программного модуля;

2. Сегмент ресурсов. Сегмент ресурсов содержит ссылки

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

программного модуля;

3. Сегмент исполнения. Сегмент исполнения содержит те-

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

точных результатов вычислений.

Модель переноса кода существует в двух вариантах:

1. Модель слабой мобильности. В этом варианте допуска-

ется перенос только сегмента кода, переносимая программа

запускается всегда из своего начального состояния;

2. Модель сильной мобильности. В этом варианте перено-

сится сегмент кода и сегмент исполнения. Работающий процесс

может быть приостановлен, перенесен на другую ЭВМ и его вы-

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

Перенос работающего процесса называется миграцией про-

цесса. Помимо миграции процесса сильная мобильность может

осуществляться за счет удаленного клонирования процесса.

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

няется на удаленной ЭВМ параллельно оригиналу.

Перенос кода может быть инициирован:

1. Отправителем, т.е. ЭВМ, на которой переносимый про-

граммный модуль постоянно размещен или выполняется;

2. Получателем, когда инициатива в переносе кода при-

надлежит ЭВМ-получателю.

С точки зрения переноса сегмента ресурсов различают

три вида ресурсов:

1. Неприсоединенные ресурсы. Эти ресурсы могут быть с

легкостью перенесены с одной ЭВМ на другую (напр.: файлы

данных);

2. Связанные ресурсы. Данный вид ресурсов переносится

с одной ЭВМ на другую с относительно большими затратами

(напр.: базы данных и web-сайты, имеющие мощный ссылочный

аппарат);

3. Фиксированные устройства. К фиксированным устройст-

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

рых с одной ЭВМ на другую не возможен (напр.: устройства

печати, сканеры и другая аппаратура).

Распределенные автоматизированные системы

142

При переносе кода различают три типа привязки процесса

к ресурсам:

1. Привязка по идентификатору. Данный вид привязки

применяется, когда процесс требует в точности тот ресурс,

на который ссылается (напр.: любимый web-сайт пользовате-

ля).

2. Привязка по значению. Такая привязка используется в

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

сурса, а источник этого значения ему безразличен (напр.:

стандартные библиотеки языков программирования – процессу

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

ной функции, ему важно лишь её значение).

3. Привязка по типу. Эта привязка применяется, когда

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

Как правило, тип определяется для аппаратных ресурсов сис-

темы (напр.: устройство печати, устройство наглядного ото-

бражения и т.д.).

При переносе кода в гетерогенных системах, особенно,

если различные ЭВМ системы построены на различных аппарат-

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

всех этих платформах без перекомпиляции текста программы. В

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

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

пользуемую аппаратную платформу. В случае сильной мобильно-

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

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

программы процессоров разных типов. Сильная мобильность в

гетерогенной системе возможна только при использовании ЭВМ

с одинаковыми аппаратными платформами.

§ 2. Программные агенты

Развитие средств искусственного интеллекта и их инте-

грация в распределенные системы обусловило появление нового

класса процессов – программных агентов. Программный агент –

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

ного интеллекта, работающий автономно или совместно с дру-

гими агентами, способный своевременно реагировать на изме-

нение в своем окружении и инициировать действия, влияющие

на свое окружение.

Различают четыре основных вида программных агентов:

1. Кооперативный агент – это агент, являющийся частью

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

ботая совместно, выполняют общие задачи;

2. Мобильный агент – это агент, способный перемещаться

с одной ЭВМ на другую;

Распределенные автоматизированные системы

143

3. Интерфейсный агент – это агент, помогающий пользо-

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

граммами;

4. Информационный агент – это агент, управляющий ин-

формацией из множества различных источников.

Чаще всего агенты совмещают в себе несколько вышепере-

численных видов – напр.: кооперативный мобильный информаци-

онный агент – это программный агент, управляющий информаци-

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

ся с одной ЭВМ на другую и являющийся частью мультиагентной

системы.

Для того, чтобы лучше представить себе работу про-

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

щенная модель программных агентов. Эта модель включает в

себя четыре уровня:

1. Программа-агент;

2. Компонент управления агентами. Данный компонент от-

слеживает агентов на конкретной ЭВМ, а также предоставляет

механизм создания и уничтожения агентов;

3. Служба каталогов. При помощи службы каталогов агент

может узнать о существовании других агентов;

4. Канал связи между агентами.

Программная реализация четырехуровневой обобщенной мо-

дели программных агентов называется платформой агента.

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

ционного протокола прикладного уровня, называющимся ACL

(Agent Communication Language – язык взаимодействия аген-

тов). Сообщение ACL состоит из заголовка и реального содер-

жания. Заголовок сообщения ACL содержит следующие поля:

1. Поле цели сообщения;

2. Поле адреса отправителя;

3. Поле адреса получателя;

4. Поле онтологии (интерпретации содержания).

В ACL имеется жесткое разделение между целью сообщения

и его содержанием. Идея ACL состоит в том, чтобы агент-

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

общения. По этой причине количество целей в ACL ограничено.

Цель сообщения определяет реакцию получателя.

ACL никак не задает формат или язык содержания сообще-

ния. Формат или язык содержания сообщения определяют всту-

пившие в связь агенты.

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

безопасности информации в распределенной системе. Большин-

ство компьютерных вирусов являются по своей сути мобильными

агентами. Наиболее эффективной защитой от вредоносных по-

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

ся недопущение их проникновения в систему извне с помощью

Распределенные автоматизированные системы

144

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

пропустить в систему мобильного агента извне. При этом не-

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

агента в распределенной системе. Имеются два механизма кон-

троля за поведением агента:

1. Механизм сита. Механизм сита предусматривает поко-

мандный контроль работы агента. При попытке выполнить за-

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

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

выполнение программы агента прекращается. Механизм сита

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

работает как стандартный интерпретатор, имеющий в качестве

входной информации программный код мобильного агента. Стан-

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

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

2. Механизм полигона. Механизм полигона обеспечивает

бóльшую гибкость в реализации контроля за поведением агента

за счет выделения специализированной ЭВМ для выполнения по-

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

темы при этом физически отделены от ЭВМ полигона. Пользова-

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

ному агенту стандартным способом (ACL, RPC и т.д.). Мобиль-

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

гона не может. В механизме полигона используются три метода

соблюдения правил защиты:

а) Метод подписания кода. Этот метод заключается в ау-

тентификации программ вне зависимости от того, откуда они

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

аутентифицируется стандартным образом;

б) Метод расширенного анализа стека. Данный метод за-

ключается в проверке прав доступа к каждому элементу стека

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

к защищенному ресурсу через другие программные модули;

в) Метод управления пространством имен. Метод заключа-

ется в создании пространства разрешенных имен, не связанно-

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

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

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

При перемещении мобильных агентов с одной ЭВМ на дру-

гую возможны атаки на самих агентов. Полная защита агента

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

вать поведение всех процессов сети, способных оказывать

влияние на мобильного агента. По этой причине для защиты

мобильного агента применяется только контроль целостности

его программного кода при попадании его на каждую ЭВМ сети.

Для контроля целостности программного кода мобильного аген-

та, создается дайджест кода агента, который перемещается

Распределенные автоматизированные системы

145

вместе с агентом и служит для других ЭВМ сети средством

удостовериться в подлинности и целостности мобильного аген-

та. На ЭВМ владельца агента по его возвращению также произ-

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

код программного агента при его перемещениях между ЭВМ сис-

темы.

Кроме защиты непосредственно самого агента, необходимо

защищать информацию, которую собирает этот мобильный агент.

Для защиты информации, собираемой мобильным агентом, ис-

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

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

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

ключу владельца агента. Когда агент перемещается на сервер,

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

бавляет эти данные в журнал, защищает их своей цифровой

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

шифровав её открытым ключом владельца агента. Когда агент

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

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

ра и их целостность по цифровой подписи сервера, целост-

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

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

или цифровых подписей серверов журнал считается сфальсифи-

цированным.

Глава 3. Именование в распределенных системах

Любой человек, хотя бы раз имевший дело с персональным

компьютером, должен был заметить, что любой файл, любая

папка, и даже любой ресурс ЭВМ имеет свое уникальное назва-

ние. В этой главе будет рассмотрено, каким образом эти на-

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

всю необходимую пользователю информацию.

§ 1. Понятие сущности

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

программный доступ, называется сущностью. Любые процессы,

аппаратные или информационные ресурсы, сетевые соединения,

интерфейсные средства и т.д. и т.п. можно назвать сущно-

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

Каждая сущность имеет имя. Имя может быть адресом или

идентификатором. Имена в распределенных системах могут

быть:

1. Глобальными. Глобальное имя обозначает одну и ту же

сущность вне зависимости от того, где в системе это имя ис-

пользуется;

Распределенные автоматизированные системы

146

2. Локальными. Интерпретация локального имени зависит

от того, где в системе это имя используется.

Адрес является локально зависимым именем и указывает

на конкретное размещение сущности, также как адрес места

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

ние на планете. Для доступа к сущности используется точка

доступа, которая, в свою очередь, также является сущностью.

Имя точки доступа является адресом сущности. Можно сказать,

что адрес – это специальный тип имени, указывающий на точку

доступа к сущности. Сущность может иметь более чем одну

точку доступа. Сущность может поменять точку доступа, а

точка доступа может быть перенацелена на другую сущность.

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

но, так как указание на локальное местоположение сущности

не обеспечивает прозрачности переноса и смены местоположе-

ния.

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

но независимым именем – идентификатором. Идентификатор об-

ладает следующими свойствами:

1. Идентификатор ссылается не более чем на одну сущ-

ность;

2. На каждую сущность ссылается не более одного иден-

тификатора;

3. Идентификатор всегда ссылается на одну и ту же сущ-

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

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

циацию: сущность – это гражданин, а идентификатор – его во-

дительское удостоверение. В водительское удостоверение впи-

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

тификатор ссылается не более чем на одну сущность. Гражда-

нин может иметь не более одного водительского удостовере-

ния, два удостоверения – это уже преступление. Таким обра-

зом, на каждую сущность ссылается не более одного идентифи-

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

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

есть идентификатор всегда ссылается на одну и ту же сущ-

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

§ 2. Пространство имен

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

рую сущность, называемую пространство имен. Пространство

имен представляется как граф с двумя типами узлов:

1. Листовой узел. Листовой узел представлен именован-

ной сущностью и не имеет исходящих из него ребер, обычно

содержит информацию о представляемой сущности.

Распределенные автоматизированные системы

147

2. Направляющий узел. В отличие от листового, этот тип

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

Направляющий узел хранит таблицу идентификаторов ребер, на-

зываемую направляющей таблицей.

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

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

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

При этом оно разбивается на три логических уровня:

1. Глобальный уровень. Этот уровень является самым

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

изменяются крайне редко;

2. Административный уровень. Узлы административного

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

узлы глобального уровня;

3. Управленческий уровень. Этот уровень является самым

нижним и формируется из регулярно изменяемых узлов. В отли-

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

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

нистраторами, но и пользователями.

Распределенность пространства имен по множеству серве-

ров имен затрудняет процесс поиска информации, называемый

разрешение имени. Каждый клиент имеет доступ к локальной

процедуре разрешения имен, реализующей процесс разрешения.

Имеется два способа разрешения имен:

1. Итеративное разрешение имени. В процессе разрешения

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

ждым сервером имен, начиная с корневого сервера глобального

уровня, до тех пор, пока не найдет конечную сущность. Сер-

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

поиска процедуре разрешения имен;

2. Рекурсивное разрешение имени. В процессе разрешения

процедура разрешения имен связывается с корневым сервером

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

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

руженному серверу имен, и далее каждый последующий сервер

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

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

ность.

Недостаток рекурсивного разрешения имен заключается в

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

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

поддерживают только итеративное разрешение имен.

В случае мобильных сущностей итеративное и рекурсивное

разрешение имен не применимо, так как имена в этих способах

разрешения привязаны к постоянному местоположению. Размеще-

ние мобильной сущности определяется посредством службы ло-

кализации. Служба локализации использует в качестве исход-

Распределенные автоматизированные системы

148

ных данных идентификатор сущности и возвращает текущий ад-

рес соответствующей ему сущности. При наличии нескольких

копий одной сущности будет возвращено несколько адресов.

Реализация службы локализации возможна пятью способами:

1. Широковещательная рассылка. В случае локализации

сущности с помощью широковещательной рассылки идентификатор

сущности доносится до каждой ЭВМ, которые проверяют наличие

у них запрашиваемой сущности. ЭВМ, которые могут предоста-

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

общение, содержащее адрес точки входа (напр.: протокол раз-

решения адресов Интернета ARP). Широковещательная рассылка

с ростом сети теряет эффективность;

2. Групповая рассылка. Групповая рассылка является ва-

риантом широковещательной рассылки, но не для всей сети, а

только для ограниченного числа ЭВМ сети;

3. Передача указателей. При передаче указателей сущ-

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

ром месте ссылку на свое новое местоположение. Преимущество

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

традиционной службы именования (итеративной или рекурсив-

ной) для поиска текущего адреса по цепочке оставленных ука-

зателей. В то же время, реализация службы локализации с по-

мощью передачи указателей не лишена ряда недостатков:

а) При большой двигательной активности мобильной сущ-

ности цепочка указателей может стать излишне длинной, что

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

б) Имеется необходимость сохранения указателей все то

время, пока существует мобильная сущность;

в) Высокая уязвимость к потере ссылок. При потере хотя

бы одной ссылки сущность становится недоступной.

Рассмотренные первые три способа реализации службы ло-

кализации, а именно: широковещательная и групповая рассылки

и передача указателей обеспечивают плохую масштабируемость

распределенной системы;

4. С помощью базовой точки. Локализация сущности с по-

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

была создана сущность, базовой точки, из которой отслежива-

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

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

бильной сущности при каждом её перемещении в новое место.

Подход на основе базовой точки используется в качестве ава-

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

указателей.

5. Иерархический подход. В иерархической схеме сеть

делится на домены. Домен верхнего уровня охватывает всю

сеть целиком. Каждый домен делится на несколько поддоменов,

называемых дочерними доменами. Для дочерних доменов ближай-

Распределенные автоматизированные системы

149

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

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

меном и соответствует локальной сети или соте в мобильной

сети. Каждый домен имеет ассоциированный с ним направляющий

узел, который отслеживает сущности домена. Направляющий

узел содержит таблицу идентификаторов всех сущностей своего

домена.

Направляющий узел домена верхнего уровня называется

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

сущностях сети.

Для отслеживания местонахождения сущностей каждая из

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

узле. Локализующая запись содержит текущий адрес сущности в

своем домене. Таким образом, текущий адрес конечной сущно-

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

правляющего узла. Направляющие узлы более высоких уровней

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

Рис. 5. Иерархическая схема локализации сущности.

Кл – клиент

Сщ - сущность

Клиент, желающий найти сущность, посылает запрос на-

правляющему узлу своего домена. Если этот направляющий узел

не содержит идентификатор запрашиваемой сущности, узел пе-

ресылает запрос своему родителю. Запрос передается вверх по

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

узел, содержащий нужный идентификатор.

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

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

далее запрос передается вниз по уровням узлов, содержащих

идентификатор запрашиваемой сущности до тех пор, пока не