CC BY
55
Шибанов С.В. , Илюшкин А.С., Шевченко О.А., Макарычев П.П. ОБМЕНОМ ИНФОРМАЦИЕЙ В РАСПРЕДЕЛЁННЫХ ИНФОРМАЦИОННЫХ СИСТЕМАХ С ИСПОЛЬЗОВАНИЕМ АКТИВНОГО ПАКЕТА
Предлагается концепция активного пакета для осуществления операций сбора и распространения
данных в распределённой системе. Рассматривается обобщенная архитектура системы и принципы обмена
информацией с использованием рассматриваемого метода. Описывается внутреннее устройство пакета и алгоритмы его поведения и взаимодействия с системой исполнения. Освещается архитектура и функционирование узлов распределённой информационной системы для взаимодействия с активным пакетом. Делается вывод об эффективности применения предложенного подхода при разработке подсистем обмена с использованием декларативного описания процесса обмена в распределённых системах.
Введение
Основной задачей при распространении и синхронизации данных и метаданных в распределённых системах является обеспечение актуальности информации на узлах. При этом стоит выделить три основных критерия, по которым можно осуществлять оценку эффективности выбранного метода: скорость доставки информации от отправителя к получателю, надёжность и удобство разработки.
В основе большинства систем распространения и репликации данных и метаданных лежит понятие па-
кета. Зачастую он имеет различные названия. В рамках данной статьи под пакетом будем понимать минимальную логическую единицу обмена между узлами распределённой информационной системы (РИС).
Во всех существующих коммерческих продуктах прохождением пакета по сети и получением необходимых от него сведений управляют сами узлы. Среди известных средств синхронизации и репликации стоит выделить Microsoft Sync Framework, а среди систем для распространения данных — системы управления пакетами различных linux-дистрибутивов, например RPM и dpkg.
Предлагается возложить обязанности по управлению пакетом на него самого и рассматривать его в качестве действующего субъекта. При этом со стороны каждого узла пакету предоставляется гарантированный интерфейс, который пакет использует для осуществления своей деятельности.
Обобщенная архитектура РИС и принципы обмена информацией на основе активного пакета
Назовём среду существования пакета системой исполнения узла (Node Execution Environment — NEE) [4]. В простейшем случае задачей пакета является копирование собственного тела на локальную машину и передача его дальше по сети. Данный стиль поведения позаимствован из концепции самовоспроиз-водящихся компьютерных программ типа «сетевой червь».
Задавшись целью универсализации предлагаемого подхода, а так же для объяснения общих принципов работы системы, допустим, что NEE API состоит лишь из одного метода — Execute, в который передаются команды для исполнения узлом. Таким образом, узел предоставляет пакету свои вычислительные ресурсы. Активность со стороны узла проявляется только в момент получения нового пакета. Узел должен прочитать заголовок инициализации пакета (Packet Header — PH) и, используя метод Execute, выполнить присутствующий там код. После этого пакет сможет управлять своей жизнью самостоятельно, планируя время своего следующего запуска системой исполнения при помощи входящей в её состав системы программирования расписаний (Schedule Programming System — SPS), управление которой так же осуществляется через метод Execute.
Стоит отметить, что корректное функционирование такой системы без наложения каких-либо ограничений на пакет возможно только в сети с высокой степенью доверия между узлами, так как действия, производимые пакетом в принимающей системе не должны нанести ей вред. Однако в настоящее время в большинстве случаев построение распределённой системы осуществляется на основе сети Интернет, где уровень доверия между узлами низкий. Поэтому для защиты возможно исполнение команд пакета в среде так называемой «песочницы» с ограниченным доступом к определённым ресурсам узла (по аналогии с ограничениями на исполнение JavaScript в браузерах, или скриптов на стороне HTTP-серверов).
Естественно, обмен пакетами может осуществляться только между узлами, имеющими соответствующий интерфейс. Возможно так же распространение через пакеты самого NEE API, который узел предоставляет пакету (такой подход может использоваться для обновления системы).
Структура пакета является иерархической с внутренними перекрёстными ссылками. Пакет может содержать внутри себя другие пакеты, а так же может модифицировать свою структуру во время нахождения в узле, получая требуемые сведения из репозитория уровня узла или локальной базы данных.
Таким образом, предлагаемый подход позволяет, как распространять, так и собирать информацию, абстрагируясь при этом от используемых средств связи между узлами (например, в случае, если узел находится за маршрутизатором, то извне к нему подключиться нельзя без явного перенаправления портов или использования UPnP) [6].
Распространение адресов узлов так же может осуществляться посредством пакетов. Это может использоваться, если выпускающему пакеты узлу изначально не известны все участники обмена. Перенос информации подобного рода может осуществляться так же через дополнительную логическую сеть.
В случае сбора информации пакет должен сохранять внутри себя, если это требуется, помимо полезных данных ещё и адреса узлов, где они были получены. При распространении информации пакет должен так же хранить версии для каждой составляющей [1]. В случае изменения собственной структуры пакет должен увеличить версии подвергнутых воздействию компонентов.
Рис. 1. Общая архитектура системы
Одновременно в распределённой системе не может существовать два пакета с одинаковой версией и набором идентификаторов. Для этого каждый пакет имеет уникальный идентификатор (например, GUID или адрес узла) [1] идентифицирующий именно текущую его версию и отдельный идентификатор для определения семейства пакетов (всей группы пакетов в цепочке родитель-потомок). Идентификатор группы может использоваться при распространении совместимых обновлений, которые могут устанавливаться поверх существующей установки (по аналогии с UpgradeCode в Windows Installer). Если версия несёт информацию об истории создания пакета, то идентификатор версии нужен для разрешения конфликтов, когда два различных узла генерируют два пакета с одинаковой версией.
Общая архитектура системы представлена на рисунке 1.
Внутренняя организация и сценарии поведения активного пакета
В рамках предложенной модели распространения и сбора данных в распределённой системе с использованием концепции активного пакета остановимся на его рассмотрении более подробно.
В своей базовой конфигурации активный пакет состоит из следующих основных компонентов [3]: заголовка инициализации (PH);
системы хранения (локального репозитория — Packet Local Repository — PLR).
Пакет представляет собой логическую сущность, так как может быть представлен как набором файлов и каталогов файловой системы, так и комбинацией набора файлов и базы данных СУБД или монолитным бинарным или текстовым файлом. Его активность может быть реализована при помощи исполняемых файлов или скриптов на интерпретируемом языке (Perl, Bash, Python) входящих в его состав и размещающихся на общих основаниях в PLR.
Заголовок инициализации необходим для первичной идентификации пакета системой исполнения узла и запуска на исполнение содержащегося в нём кода.
Предполагается, что код PH работающий в рамках NEE обратится к PLR с запросом требуемых элементов хранилища (по известному ему алгоритму) и передаст на исполнение соответствующую программу, реализующую активное поведение пакета.
NEE предоставляет пакету минимальный гарантированный набор системных вызовов, составляющих API среды исполнения, через которые пакет осуществляет свои действия в рамках узла.
Таким образом, после того как NEE вызывает PH, а тот извлекает из PLR необходимый код для начала своей жизни в рамках узла, пакету остаётся выполнить его при помощи вызова соответствующего метода NEE API .
PLR представляет собой, в простейшем случае, древовидное хранилище с внутренними ссылками, которые нужны в основном для уменьшения размера пакета (например, при большом количестве дублирующихся файлов входящих в состав пакета), созданное на основе базы данных или локальной файловой системы узла. Оно может содержать в себе данные различного рода, как файлы, так и фрагменты БД, метаданные особого формата и т.п. При передаче между узлами PLR может подвергаться сжатию различными алгоритмами архивации, при этом за распаковку отвечает PH (в случае если пакет изначально поставляется в упакованном виде), либо программы, реализующие активность (в случае если требуется распаковать какую-либо единицу хранения внутри PLR). При этом за предоставление пакету услуг программы- архиватора отвечает NEE API.
Следует выделить следующие возможные состояния, в которых может пребывать пакет:
пассивное (транспортное);
активное;
ожидание;
сон;
зомби (утилизация).
Пакет находится в пассивном состоянии (p) во время своей передачи по сети. В общем случае пассивным считается состояние, когда пакет находится вне пределов досягаемости NEE. Активное состояние (a) — программа пакета находится на исполнении в NEE (пакет выполняет часть своей программы). Ожидание (w) — пакет не выполняет свою программу, но запрограммировал SPS на своё пробуждение
через определённое время, и ожидает его. Сон (s) — пакет не программировал SPS на своё пробуждение, поэтому он может пробудиться только от внешнего события в виде вызова от другого пакета либо иного типа события. Зомби (z) — пакет игнорирует вызов своего заголовка (либо он закончил выполнение своей программы, либо обладает неправильной внутренней структурой), такие пакеты, как правило, утилизируются при помощи NEE и их существование в системе нежелательно, так как это противоречит общей концепции.
Отдельно обозначим события выпуска пакета — C и ликвидации — D.
Рис. 2. Диаграмма состояний пакета
На данной диаграмме представлен общий случай жизни пакета в системе, с неблагополучным исходом в виде перехода его в z-состояние. Стоит отметить, что явно перейти в z-состояние пакет может только самостоятельно. Неявные переходы, например, когда во время активной фазы работы пакета происходит сбой или имеет место отказ SPS, возможны из всех состояний кроме p, так как потеря пакета в сети приводит к его ликвидации.
Можно выделить следующие закономерности переходов. Из состояния p пакет может перейти только в состояние s. Из состояний s и w пакет может перейти только в состояние a. Из состояния a пакет может перейти в любое из оставшихся четырёх состояний: w, s, z или p. Последнее утверждение следует из концепции предоставления пакету максимальной степени свободы в действиях относительно его самого.
В каждом из состояний пакет может находиться неограниченное количество времени.
Список всех возможных переходов:
явные: p ^ s; s | w ^ a; a ^ w | s | z | p,
неявные: a | w | s ^ z.
Связи событий C и D с состояниями пакета: С s; p | a | w | s | z D.
Архитектура и функционирование узлов РИС при взаимодействии с активным пакетом
Мы уже ввели понятие системы исполнения узла, теперь предположим, что NEE сама не управляет приёмом и получением пакетов через сетевой интерфейс. Этим занимается файловый сервер, который лишь информирует NEE о поступлении новых пакетов и гарантирует, что они получены без утраты целостности и это именно активные пакеты, а не файлы другого формата. NEE узнаёт о поступлении пакета от файлового сервера через callback-вызов или аналогичным образом.
Вызов заголовка пакета узлом не обязательно приводит к исполнению внутреннего кода пакета. Так, например, пакет может проигнорировать вызов (рис. 3). Хотя пакет не может программировать вызов другого пакета по расписанию (для выполнения правила, что пакет сам определяет причину своего вызова), он, используя NEE API, может производить поиск нужных ему соседних пакетов в узле с использованием идентификатора группы пакетов и версии и вызывать их синхронно.
Рис. 3. Диаграмма деятельности для вызова пакета
Если пакету требуется новый набор методов со стороны NEE, то он может содержать соответствующее обновление для узла. Для этого заголовок пакета должен соответствовать предыдущей версии системы (до обновления), чтобы узел мог прочитать его. Вопросы безопасности при этом не рассматриваются.
Как сказано ранее, в простейшем случае NEE API может предоставлять пакету всего один метод для выполнения текстовых команд. Более приемлемой является реализация с использованием ООП. Рассмотрим возможный вариант интерфейса на языке C#.
Обработка пакетов:
PackageRef[] Find(int groupId) — поиск группы пакетов;
PackageRef Find(int packageld) — поиск конкретного пакета по идентификатору;
PackageRef[] Find(int groupId, int version) — поиск пакетов по идентификатору группы с определённой версией;
void RemoveMe() — удалить текущий пакет;
void SendMe(Address address) — отправить текущий пакет по адресу;
object Invoke(PackageRef packageRef) — вызов PH указанного пакета в синхронном режиме с возвратом результата выполнения.
Система программирования расписаний:
void Schedule(TimeSpan timeSpan) — установка временного интервала до момента следующего вызова PH текущего пакета.
Локальный репозиторий пакета (данная часть используется в случае, если пакет не имеет прямого доступа к некоторым элементам локального репозитория, например, когда часть PLR отображается на реляционную базу данных на стороне узла):
ItemRef GetItemRef(Path path) — получить ссылку на элемент внутреннего репозитория;
Item GetItem(ItemRef) — получить элемент внутреннего репозитория;
void PutItem(Item item) — записать элемент во внутренний репозиторий;
void DeleteItem(ItemRef itemRef) — удалить элемент из внутреннего репозитория;
void ExecuteItem(Item item) — выполнить содержимое элемента.
Дополнительные средства:
byte[] ^mpress^yten data) — упаковать массив байт;
byte[] Decompress(byte[] data) — распаковать массив байт.
Система программирования расписаний (Schedule Programming System — SPS) [5] входит в состав NEE API и позволяет пакету программировать NEE для периодического своего пробуждения (такое поведение, например, может использоваться для сбора пакетом статистики). Каждый пакет может программировать только собственный вызов и не может напрямую управлять вызовом PH другого пакета.
Здесь стоит отметить, что пакет гарантированно вызывается NEE при поступлении в узел. Однако при этом он может произвести свои действия однократно, вообще проигнорировать вызов, или, выполнив необходимые операции, запрограммировать SPS для последующего своего однократного вызова через определённое время. Между вызовами пакет пребывает в состоянии w и помнит свой текущий внутренний статус. Поэтому, при каждом вызове, он точно знает, с какой целью его вызывает NEE. В этой связи можно выделить два состояния пакета: ожидание и сон. В режиме ожидания пакет ждёт срабатывания
SPS через определённое время. Режим сна достигается, например, когда пакет игнорирует инициирующий вызов PH или после активного периода существования не программирует SPS на дальнейшие срабатывания. Спящие пакеты могут пробудиться только от внешнего воздействия со стороны одного из датчиков (которые описаны далее) NEE.
Отметим два подхода к реализации подобного рода систем. В первом, наиболее предпочтительном в рамках данной статьи, предполагается вынести большую часть логики SPS на сторону пакета. Второй вариант предполагает реализацию большей части SPS на стороне узла. В данном случае требуется расширенный вариант NEE API, позволяющий кроме программирования простых расписаний на однократное срабатывание выполнять многократное периодическое срабатывание с проверкой условий приводящих к исполнению PH. Например, в зависимости от определённого состояния узла или внешнего воздействия. Это может использоваться при восстановлении после сбоев и т.п., в случаях, когда регулярное поведение не ожидается, однако создаёт определённые сложности в распространении NEE API из-за его громоздкости. К тому же использование последнего варианта невольно преобразует систему в аналогичную большинству существующих коммерческих образцов с пассивными единицами обмена.
Реализация алгоритмов SPS на стороне пакета позволяет ему самому управлять логикой обработки. Каждый находящийся в узле пакет становится независимым от NEE относительно составления расписаний и, соответственно, независимым от других пакетов.
Взаимодействие пакета с внешним миром осуществляется через систему датчиков, которые, для унификации процесса взаимодействия пакета и NEE, реализуются через интерфейс SPS. NEE выступает в качестве инициатора всех воздействий, так как только она имеет доступ со своей стороны к внешнему миру за пределами песочницы, в которой находится пакет. Для пакета такие внешние воздействия выглядят как вызовы, не являющиеся инициирующими или запланированными по расписанию. Другими словами, пакет самостоятельно определяет тип вызова (не из его идентификатора или имени) по времени его поступления (рис. 3). Таким образом, датчики являются понятием, используемым только на стороне узла. Для пакета же это просто очередной вызов.
Заключение
По мере усложнения API может возникнуть вопрос, а целесообразно ли использовать подобные конструкции для реализации, подчас, достаточно простых действий? Основное преимущество данного подхода состоит в унификации процесса разработки. Разработчику предлагается готовое решение, позволяющее оперировать достаточно небольшим набором логических примитивов (активный пакет и среда исполнения) и декларативно описывать процессы сбора и распространения информации в распределённой информационной системе в синхронном и асинхронном режимах. При этом появляется возможность осуществлять обмен информацией различного рода: файлами, фрагментами БД, метаданными, приложениями и т.п.
Стоит отметить, что использование данного подхода создаёт в распределённой информационной системе уровень равноправных улов. Ни за кем не закрепляется жёстко определённая роль. Каждый из узлов может выступать в роли сервера или клиента по команде от пакета.
В дальнейшем планируется разработать прототип системы. Создать модульную NEE с подключаемыми компонентами для системы программирования расписаний и файлового сервера. Произвести исследование зависимости изменения основных показателей, таких как скорость обмена и надёжность при использовании различных алгоритмов обработки пакетов на динамических сетевых конфигурациях. Создать интерфейс для отображения PLR на различные виды баз данных и файловую систему.
ЛИТЕРАТУРА
1. A.D. Kshemkalyani, M. Sighal , Distributed Computing. Principles, Algorithms, and Systems, Cambridge, Cambridge University Press, 2008
2. С.В. Шибанов, О.А. Шевченко, А.С. Илюшкин, Активная система тиражирования и синхронизации
метаданных в корпоративных информационных системах, Известия высших учебных заведений. Поволжский регион. Технические науки — №1, Пенза, Изд-во ПГУ, 2010
3. А.С. Илюшкин, С.В. Шибанов, О.А. Шевченко, Концепция активного пакета для распространения
данных в распределённых системах. Технологии Microsoft в теории и практике программирования. Материалы конференции, Нижний Новгород: Изд-во ННГУ, 20і0
4. А.С. Илюшкин, С.В. Шибанов, О.А. Шевченко, Система исполнения активного пакета в узлах распределённой системы. Технологии Microsoft в теории и практике программирования. Материалы конференции, Нижний Новгород: Изд-во ННГУ, 2010
5. А.С. Илюшкин, С.В. Шибанов, О.А. Шевченко, Система программирования расписаний выполнения
активного пакета в узлах распределённой системы. Технологии Microsoft в теории и практике про-
граммирования. Материалы конференции, Нижний Новгород: Изд-во ННГУ, 2010
6. J. Heidemann, F. Silva, D. Estrin, Matching Data Dissemination Algorithms to Application Requirements, Los Angeles, SenSys'03 November 5-7, 2003
