CC BY
14Адаптивные домены: последовательность операций изменения конфигурации и алгоритм пассивации
Мотузенко П. В. ([email protected]) Software Experts UK
Введение
Рост Интернета за последние годы, и в особенности популярность World Wide Web, обозначила рост глобальных распределенных систем, обрабатывающих запросы миллионов компьютеров и пользователей. Такой рост определил высокую потребность в системах, способных самостоятельно адаптироваться к окружению в своей конфигурации.
Однако сама по себе адаптация распределенных информационных систем не является задачей простой и обладает многими аспектами. Выделяют следующие основные аспекты адаптации автономных программных систем: самостоятельное конфигурирование, самостоятельное лечение, самостоятельная оптимизация [6].
Адаптивные домены
Для реализации множественных аспектов адаптации динамических систем представлена концепция адаптивных доменов [1]. Адаптивным доменом называется домен управления [4] с дополнительными функциями адаптации и самоадаптации, которые определяют его архитектуру и применение. Семантически адаптивный домен отражает заданный аспект адаптации распределенной информационной объектной системы или какой-либо ее части.
К функциям адаптации и самоадаптации доменов относятся:
1. Коммуникации с внешним миром вне границ системы посредством внешних сенсоров и реакция на внешние события адаптации, относящиеся к заданному аспекту адаптации домена.
2. Коммуникации с модулями и подсистемами системы посредством внутренних сенсоров и реакция на внутренние события адаптации, относящиеся к заданному аспекту адаптации домена.
3. Коммуникации с другими адаптивными доменами системы и реакция на внутренние события адаптации и команды адаптации, относящиеся к заданному аспекту адаптации домена.
4. Генерация команд адаптации изменения архитектурной метамодели системы, в рамках заданного аспекта адаптации домена.
5. Генерация событий и команд адаптации, адресованных другим адаптивным доменам системы.
6. Реализация адаптационной логики заданного аспекта адаптации в терминах событий и команд адаптации.
Рис. 1 Адаптивный домен и его взаимодействия
При реализации адаптационной логики следует выделить функциональные возможности службы адаптивных доменов:
1. Возможность создавать независимую от настроек конкретной инсталляции системы адаптационную логику.
2. Возможность создавать реактивную, проактивную и ретроактивную адаптационную логику.
3. Возможность выполнения в системе операций адаптации по нескольких аспектам одновременно.
Формальная модель
Для реализации адаптационной логики адаптивным доменом в рамках архитектурной метамодели системы необходимо представить основные термины этой метамодели, которые имеют значение для изменения конфигурации системы.
Представим формальную модель архитектуры распределенной объектной системы как направленный граф, где вершинами являются объекты, из которых состоит эта система, а ребрами являются соединения этих объектов между собой. Между двумя объектами может быть ноль или более соединений (См. рисунок ниже). Любой домен управления, таким образом, будет являться подмножеством множества вершин графа.
Рис. 2 Направленный граф конфигурации системы
Транзакцией называют посылку сообщения объектом-инициатором объекту-исполнителю и получение ответа объектом-инициатором на это сообщение от объекта-исполнителя. Транзакция может иметь место только в случае, если между объектами установлено соединение. Транзакция выполняется в системе всегда за конечное количество времени и объект-инициатор всегда знает о том, завершена ли транзакция или нет. В общем случае, объекты системы не должны создавать ситуаций взаимоблокировок1 и активных тупиков2.
Если завершение транзакции t зависит от результатов выполнения производных транзакций (или субтранзакции) ... (пишут t / ...), то такая транзакция
называется зависимой транзакцией. Если завершение транзакции t не зависит от результатов выполнения других транзакций, то такая транзакция называется независимой транзакцией.
Изменением конфигурации в терминах формальной модели будем считать операции создания нового объекта (вершины графа), удаление объекта, создание соединения (ребра графа), удаление соединения, изменение состояния объекта, удаления, добавления и перенос объекта в домен управления (включение/исключение из подмножества объектов домена управления).
Рассмотрим изменение конфигурации в системе с адаптивными доменами. В такой системе могут иметь место изменения конфигурации по разным аспектам адаптации (и,
1 Взаимоблокировка (англ. deadlock) - ошибка состояния системы, возникающая при блокировании двух потоков выполнения, когда каждый поток ждет освобождения ресурса, используемого другим потоком.
2 Активный тупик (англ. livelock) - ошибка состояния системы, при которой критический участок задания не может быть завершен системой из-за поступления от его клиентов дополнительных запросов на обслуживание до наступления момента исключения их из очереди.
Объект-инициатор Объект-исполнитель
соединение
следовательно, разным адаптивным доменам). Каждый домен выполняет изменение конфигурации только тех объектов, которые являются его прямыми или косвенными членами. При изменении конфигурации в период исполнения системы необходимо учитывать, что существующие состояния работающих объектов системы не должны быть потеряны и соединения объектов, не участвующих в изменении конфигурации, не должны быть разрушены. Работоспособность объектов, не участвующих в изменении конфигурации, и предоставляющих услуги, являющиеся услугами всей системы также не должна быть нарушена при изменении конфигурации системы.
Переконфигурация
Для достижения указанных выше целей обеспечения работоспособности системы при изменении ее конфигурации предлагается метод динамического переконфигурирования, разработанный К. Моазами Гоударзи и Дж. Крамером [2] и примененный здесь для модели адаптивных доменов.
Для обеспечения безопасного изменения конфигурации объектов выделим два основных конфигурационных состояния объекта: активное состояние и состояние ожидания транзакции. В активном состоянии объект исполняет запрос на транзакцию от других объектов, либо сам инициирует транзакцию. В состояние ожидания объект переходит в случае, если инициированная им транзакция завершена и нет никаких запросов на транзакцию от других объектов.
Рассмотрим систему, в которой нет взаимоблокировок, и в такой системе все транзакции исполняются без влияния друг на друга1. Также в этой системе нет транзакций с зависимостями, приводящими к ожиданию одной транзакции окончания другой независимой транзакции. Пусть эта система состоит из двух объектов 01 и 02 и каждый объект инициирует транзакцию на другом. 01 не может исполнить транзакцию (инициированную 02) до тех пор, пока транзакция, которую он инициировал не завершится. Однако 02 также не может исполнить никаких субтранзакций, так как он должен дождаться окончания своей транзакции, которую исполняет 01. В этом случае взаимоблокировка будет иметь место.
Две транзакции ^и ^ имеют циклическую зависимость, если они взаимно зависят друг от друга, т.е. ^ и Достаточным условием для отсутствия в системе
взаимоблокировок, таким образом, является отсутствие циклических зависимостей между любыми транзакциями системы.
Как следствие, если система является открытой, у нее отсутствуют взаимоблокировки и транзакции не влияют друг на друга, то в такой системе каждая транзакция исполняется так, как если бы она была одной транзакцией, которая исполняется на данный момент в системе.
1 Это означает, что объект, который исполняет транзакции, в момент исполнения одной транзакции не будет исполнять никаких других не связанных с ней транзакций, способных изменить результат работы текущей исполняемой транзакции. Также он не будет инициировать никаких своих транзакций не связанных с текущей исполняемой транзакцией и способных изменить результат окончания ее работы.
Последовательность операций
Рассмотрим алгоритм изменения конфигурации в открытой системе, у которой нее отсутствуют взаимоблокировки, и транзакции которой не влияют друг на друга. Расширим последовательность операций изменения конфигурации и адаптации заданного адаптивного домена, предложенную Дж. Крамером [3]:
1. Пассивация объектов домена. Состояние объектов системы является непротиворечивым. Нет исполняемых транзакций.
2. Отсоединение связей объектов.
3. Удаление объектов.
4. Создание новых объектов.
5. Соединение объектов.
6. Удаление объектов из домена.
7. Добавление объектов в домен.
8. Изменение состояния объекта.
9. Активизация объектов и начало работы системы в новой конфигурации.
Предложенная последовательность изменения конфигурации и адаптации адаптивного домена обладает следующими особенностями по сравнению с последовательностью предложенной Дж. Крамером:
1. Так как мы рассматриваем понятие конфигурации как совокупность состояний объектов этой системы и их связей, то изменение конфигурации подразумевает возможное изменение состояний объектов, участвующих в изменении конфигурации (см. пункт 8).
2. Предложенная последовательность изменения конфигурации и адаптации учитывает подход работы с адаптивными доменами. Каждому объекту при изменении конфигурации может быть добавлено или удалено членство в заданном домене адаптации. Так реализуется механизм динамического изменения адаптационной логики объекта во время исполнения системы. Объект может, как приобрести определенную адаптационную логику, позволяющую ему адаптироваться к заданным условиям исполнения, так и потерять адаптационную логику, в которой он более не нуждается.
При пассивации объектов домена (см. пункт 1) требуется наличие непротиворечивого состояния объектов системы и отсутствие исполняемых транзакций. Задачей пассивации в период исполнения системы является достижение в конечный промежуток времени непротиворечивого состояния объектов системы, которые принимают участие в изменении конфигурации.
Состояние в котором объект обладает непротиворечивым внутренним состоянием
-ч-
ч
ч
ч
ч
ч
Создать
Получен запрос на транзакцию
Состояние в котором объект может не обладать непротиворечивым внутренним состоянием
-1-
I
Состояние ожидания транзакции
Окончание транзакции
Активное состояние
Получен запрос домена на продолжение работы
Получен запрос домена на блокировку
Изменение конфигурации завершено
Объект заблокирован
[ Нет больше незавершенных транзакций]
Получен запрос на транзакцию
Транзакция завершена
Объект разблокирован
Пассивное состояние
Удалить
Состояние в котором осуществляется изменение конфигурации системы
Добавить /удалить соединение
Изменить Добавить состояние /удалить объекта включение в домен
Рис. 3 Диаграмма конфигурационных состояний объекта при изменении конфигурации
Пассивация
Для решения этой задачи введем конфигурационное состояние «объект заблокирован». Объект переходит в это конфигурационное состояние, в случае, если он получил команду на блокировку от одного из своих адаптивных доменов. После того, как объект перешел в «объект заблокирован», он посылает подтверждение своему домену. После того, как все объекты домена, участвующие в изменении конфигурации подтвердили блокировку, мы можем быть уверены в том, что система находится в непротиворечивом состоянии. Рис. 3 иллюстрирует состояния и переходы между ними.
Целью алгоритма пассивации объектов системы является предотвращение начала новых транзакций и завершение всех начатых к моменту пассивации транзакций.
Пусть Da - множество всех адаптивных доменов системы. Бг ^ Ба - подмножество доменов, которые осуществляют изменение конфигурации г Пусть - множество
объектов заданного адаптивного домена, где п е Б г. ^, множество объектов,
принимающих участие в изменении конфигурации ^ тогда ^ ^ .
Рассмотрим сначала множество В$>е1п{, как изолированную систему объектов, в
которую запросов на исполнение транзакций извне не поступает. Так как, в множестве таких объектов могут исполняться транзакции и субтранзакции, то для того, чтобы обеспечить возможность завершения всех транзакций и их субтранзакций введем конфигурационное состояние «объект разблокирован». В это состояние объект переходит в случае, если для завершения определенной транзакции объекту Ох е { необходимо,
чтобы выполнилась субтранзакция на объекте О2 е ^, который уже находится в
конфигурационном состоянии «объект заблокирован». Для этого объект 02 переходит в конфигурационное состояние «объект разблокирован» для того чтобы обслужить субтранзакции объекта 01 и если, это необходимо, инициировать свои транзакции. После того, как все субтранзакции исполнены, объект 02 переходит обратно в «объект заблокирован».
Покажем, что такой алгоритм пассивации приведет к тому, что все объекты множества ^ окажутся в конфигурационном состоянии «объект заблокирован» через
конечный промежуток времени.
Так как в нашей системе каждая транзакция исполняется так, как если бы она была одной транзакцией, которая исполняется на данный момент, то мы покажем, что алгоритм работает для одной транзакции и, следовательно, он будет работать и для многочисленных транзакций.
Действительно, рассмотрим В$>е1п{, где все объекты находятся в
конфигурационном состоянии «объект заблокирован», кроме одного объекта 0к, который инициировал субтранзакцию объекта 0я . Объект 0я переходит в конфигурационное состояние «объект разблокирован». Возможны два варианта поведения объекта после перехода в это состояние:
1. Простое исполнение всех субтранзакций и переход в «объект заблокирован».
2. Инициация новой транзакции с объектом 0п, п ^ к, 0^ В$>е1п{. В этом
случае для 0п также возможны два варианта поведения, как и для 0з после перехода в конфигурационное состояние «объект разблокирован». Случай, когда 0з исполняет все субтранзакции и переходит в конфигурационное состояние «объект заблокирован» тривиален. Рассмотрим случай образования цепочки таких транзакций. Максимальное количество таких
транзакций может составить -1. Ограничивающим условием в этом
случае является отсутствие циклических зависимостей транзакций как следствие из отсутствия взаимоблокировок в системе.
Таким образом, исходя из конечной длительности исполнения транзакции, мы получаем, что все объекты множества В$>е1п{ окажутся в конфигурационном состоянии
«объект заблокирован» через конечный промежуток времени.
Рассмотрим теперь множество В$>е1п{, как неизолированную систему объектов, в
которую могут приходить запросы на исполнение транзакций извне. Предложенный алгоритм пассивации не будет работать в таком случае, так как объекты, не принадлежащие множеству В$>е1п { не ограничены в своем поведении и могут запрашивать
исполнение транзакций объектами из В$>е1п{ бесконечное количество раз. В этом случае
переход объектов из В$>е1п { в состояние «объект заблокирован» не произойдет никогда.
Решением здесь представляется задерживание вызовов на исполнение транзакции от объектов не из В$>е1п{ к объектам из В$>е1п{ до окончания изменения конфигурации
(см. пункт 9 последовательности операций выше). Однако не все такие запросы могут быть задержаны до окончания изменения конфигурации. Возникают несколько ситуаций, когда такое задерживание может привести к невозможности достижения состояние «объект заблокирован» объектами из В$>е1п ^.
1. Запрос объекта не из { на исполнение транзакции объектом из В$>е1п {, как результат обращения какого-либо объекта из В$>е1п {. Например, объект 01 е В£>еХп { выполняет запрос на объект 020 £ В£>еХп {, который в свою очередь выполняет обращение к 03 е В£>еХп ^. Так как запрос от 020 к 03 будет задержан, то 01 никогда не достигнет состояния «объект заблокирован» и произойдет взаимоблокировка.
2. Запрос на исполнение транзакции объектом из В$>е1п{ ожидает окончания выполнения транзакции инициированной объектом не из В$>е1п{ .Такой запрос тоже будет задержан и произойдет взаимоблокировка.
Для решения этих и подобных ситуаций расширим В$>е1п ^ до В8е^п ^ динамически
добавляя в это множество объекты, которые получают запросы на исполнение транзакций от объектов из В^е1п {.
Очевидно, что в общем случае, после добавления новых объектов множество В$>е1'п { & . Целью такого расширения множества В$>е1п { является достижение
конфигурационного состояния «объект заблокирован» для всех объектов из В$>е1п {. Как
только это условие удовлетворяется, объекты, которые были добавлены, переходят обратно в «состояние ожидания транзакции» по запросу адаптивного домена.
Таким образом, задерживая вызовы от объектов не из В^е1'п { к объектам из В^е1'п {, мы сводим задачу к изолированной системе, решение которой представлено выше.
Множество объектов, вызовы которых были задержаны, обозначим С$>е1п г. Множество объектов, которые были динамически добавлены в В8в?п г, но не принадлежат первоначальному множеству г обозначим Р$>е1„ г, таким образом,
р$егп1 и В$егП1 = В$ег'п,г.
Конфигурационное состояние объекта не является атрибутом любого из доменов, членом которых он является. При пассивации объекта одним их адаптивных доменов он становится недоступным для участия в изменении конфигурации любым другим доменом, членом которого он является. Однако в случае, если адаптивные домены выполняют изменение конфигурации разных множеств доменов, то такая одновременная переконфигурация становится возможной при определенных условиях.
Одновременная переконфигурация
При выполнении одновременной адаптации доменов может возникнуть необходимость в выполнении одновременной переконфигурации системы вследствие адаптации. Рассмотрим условия выполнения одновременной переконфигурации различными адаптивными доменами в системе в соответствии с последовательностью изменения конфигурации, рассмотренной ранее.
Рассмотрим сначала пассивацию объектов домена (см. пункт 1 последовательности). Так как при пассивации объекта одним их адаптивных доменов он становится недоступным для участия в пассивации любым другим доменом, то необходимым условием выполнения пассивации является условие г п г = 0, Уп, к е Бг. Однако, это условие не является достаточным в случае
наличия в системе транзакций от объектов, не принадлежащих г.
Так как вызовы таких объектов будут задержаны и все транзакции в системе исполняются без влияния друг на друга, то объекты-инициаторы этих транзакций не могут быть доступны для изменения из конфигурационного состояния до тех пор, пока не завершится изменение конфигурации.
N Объект из BSet
Объект из PSet
Объект из CSet
Рис. 4 Множества BSet, и С8е1 при пассивации
Таким образом, для любого домена, выполняющего одновременную пассивацию,
имеет место условие
BSet'_ n CSetk = 0, Vn, к е D „
. Однако объекты-инициаторы могут BSet'
следовательно, условие
С8егп г п С$е1к г =0, Мп, к е Бг Т б
п,г к,г г может не выполняться в общем случае. Также, объекты
инициировать несколько транзакций к объектам из разных
= 0, М
принадлежащие п,г и ожидающие окончания пассивации не могут быть временно
заблокированы другим адаптивным доменом при расширении своего множества к,г
ВЪеГ г п ВЪеГ, г = 0, Мп, к е В„ Таким образом, п,г к ,г
Следует отметить, что, несмотря на наличие двух этапов блокирования объектов при переконфигурации (из конфигурационного состояния «ожидание транзакции» в «объект заблокирован» и из «объект заблокирован» в «пассивное состояние»), применение алгоритма двухфазной блокировки (two-phase locking, 2PL) [5] не представляется возможным. Изменение порядка включения объектов в PSetn f при
пассивации, в общем случае, может привести к нарушению непротиворечивости состояний объектов системы. Таким образом, BSet'n t n BSet'k t = 0, Vn, к е D r.
Отсюда, достаточным условием одновременного выполнения пассивации для нескольких доменов будет:
(CSett u BSetnj u PSetnj) n (BSetkj u PSetkj) = 0, Vn, к е Dr
Рассмотрим теперь одновременное изменение конфигурации доменами, которые успешно выполнили пассивацию и выполняют последующие пункты в последовательности изменения конфигурации.
Р$е1п1 = 0
Множества по окончании пассивации, т.к. расширение множества
"•' объектами из "•' выполнялось только для достижения конфигурационного
С В^п г
состояния «пассивное состояние» всеми объектами из п,г.
В$е1п г п В$е1к г = 0, Уп, к е Л ,
Условие п г к ^ г Г имеет место при изменении конфигурации,
так как объект в пассивном конфигурационном состоянии становится недоступным для
участия в изменении конфигурации любым другим доменом, кроме того домена, что
перевел объект в это состояние.
Таким образом, достаточным условием одновременного изменения конфигурации для нескольких доменов будет:
(С$е1п г и В$е1п г) п В$е1к г = 0, Уп, к е Бг
Адаптивный домен
"А"
С:)
N Объект из BSet
Объект из PSet
Объект из CSet
Рис. 5 Множества BSet и С8е1 при изменении конфигурации
Заключение
В статье рассмотрена формальная модель представления конфигурации распределенной объектной системы и предложена новая последовательность операций изменения конфигурации с учетом адаптивных доменов, которая позволяет, в частности, изменять членство заданного объекта в адаптивном домене. Так реализуется механизм изменения адаптационной логики объекта во время исполнения системы. Объект может, как приобрести определенную адаптационную логику, позволяющую ему адаптироваться к заданным условиям исполнения, так и потерять адаптационную логику, в которой он более не нуждается.
Также в этой статье представлен модифицированный алгоритм изменения конфигурации системы для адаптивных доменов. Рассмотрен алгоритм пассивации состояний объектов участвующих в изменении конфигурации. Предложены достаточные условия выполнения в системе операций пассивации и изменения конфигурации для нескольких адаптивных доменов одновременно.
Список литературы
1. Мотузенко П. В., Адаптивные домены: применение в распределенных объектных системах с множественными аспектами адаптации, Журнал "Естественные и технические науки", № 5, 2003
2. Kaveh Moazami Goudarzi, Jeff Kramer, "Maintaining Node Consistency in the Face of Dynamic Change", Imperial College, London, 1996
3. Jeff Kramer, Jeff Magee, "The Evolving Philosophers Problem: Dynamic Change Management", IEEE TSE 16, 1990
4. Becker K., Raabe U., M. Sloman, K. Twidle, "Domain and Policy Service Specification", IDSM Deliverable D6, 1993
5. K.P. Eswaran, J.N. Gray, R.A. Lorie, and I.L. Traiger, "The Notions of Consistency and Predicate Locks in a Database System", IBM Research Laboratory, ACM Communications, Volume 19, Number 11, November 1976
6. "An Architectural Blueprint For Autonomic Computing", IBM and autonomic computing, April 2003.
