Диссертация (1148255), страница 12
Текст из файла (страница 12)
Обеспечение отказоустойчивостиВ теории обеспечения отказоустойчивости известно [42, с. 428] пять типовсбоев: авария, пропуск сообщения, временной сбой, ошибка отклика, случайнаяошибка (так же известная как византийский сбой). Не углубляясь в обзор каждого из типов, отметим, что большинство из них необходимо рассматривать нанизлежащем относительно DSM сетевом уровне, обеспечивающем упорядоченную доставку широковещательных сообщений. Византийский тип мы принципиально не рассматриваем ввиду экзотичности данного вида сбоя, алгоритмызащиты от которого при этом весьма ресурсоёмки (так как вынуждены учитывать возможность злонамеренного поведения отдельных узлов системы).
Такимобразом, в данной работе рассматривается единственный тип сбоя – «авария»(англ. crash).В связи с тем, что наша система призвана надёжно функционировать вусловиях выхода из строя отдельных узлов, необходимо рассмотреть все потенциально возможные ситуации возникновения аварий и соответствующие сценарии восстановления работоспособности системы.Прежде всего необходимо защититься от ситуации, когда часть данных,представляющих одно логическое сообщение (например, пакет изменений, произошедших на узле в течение блокировки), получена и применена другим узломлишь частично (например, передающий узел вышел из строя не завершив процесс передачи). Способ реализации данного требования описан в разделе 3.4, наданном же этапе нам достаточно отметить факт наличия данного требования.Далее нам достаточно определить все возможные состояния системы иопределить её поведение по нивелированию сбоев в каждом из состояний.
Нарис. 2.4 стр. 65 в предыдущем разделе изображены все возможные типы и на68правления сообщений в МАКС DSM. Разобрав ситуации аварии каждого изузлов в различные моменты относительно отправки и приёма всех возможныхсообщений, мы рассмотрим все потенциально возможные ситуации аварий в системе. Для удобства объединим узлы на рис. 2.4 под номерами 2, 3 и 4 в единыйузел (так как они выполняют одну и ту же роль и нет необходимости рассматривать их независимо). Для удобства представим получившийся результат нарис. 2.5 (попутно уточнив описания курсирующих сообщений) и далее будемрассматривать именно его.Сервер2: дублированиеКопия11a1: запрос к Серверу3: подтверждение4: приказ от Сервера2КлиентРисунок 2.5 – Типы и направления сообщений в МАКС DSMДалее вопрос отказоустойчивости рассматривается в разрезе реализации –в разделе 3.4.2.2.5. Модель прикладного интерфейсаОдна из наиболее существенных характеристик DSM системы – удобство еёиспользования.
Характеристика в целом субъективная, однако некоторые объективные свойства всё же можно выделить. Рассмотренные выше реализации(см. раздел 1.6), как правило, обладали одним или несколькими из следующихсвойств, отрицательно сказывающихся на широком распространении данныхсистем:1. Реализация в виде нового языка программированияЯркий пример – система Orca [12]. Плюсы системы не отменяют факта,69что прикладному программисту в данном случае необходимо изучить новый язык программирования, а при портировании системы на новую платформу, портировать нужно и компилятор, что в общем случае являетсякрайне трудоёмкой задачей.2. Реализация в виде расширения стандартного языка программированияВ данном случае для функционирования системы также необходима поддержка со стороны компилятора.
Как минимум, требуется разработкапрепроцессора, трансформирующего расширенный язык в стандартный.Соответственно, использование и портирование подобных систем осложняется. Характерный пример – система Linda [24].3. Введение новых концепций программированияКак правило, данное свойство сопровождается одним из вышеописанных.В целом, DSM система создаётся именно для того, чтобы предложитьальтернативную, более удобную концепцию программирования, но иногдареализации этой концепции усложняются до такой степени, что разработка ПО под соответствующие системы начинает требовать существенныхтрудозатрат, что входит в некоторое противоречие с желанием упроститьразработку. В качестве примеров можно привести всё те же Linda (с еёконцепцией кортежей) и Orca (с её новым языком программирования).4.
Повышенная нагрузка на прикладного программистаНекоторые системы, обладая высокой производительностью, достигаютеё за счет вовлечения прикладного программиста в процесс оптимизации.Например, система Munin [14, 17, 18] требует определения пользователемкатегории каждой из распределённых переменных, для чего необходимохорошо владеть математическим аппаратом данной системы.5. Отсутствие контроля ошибок на этапе компиляцииДанный пункт в меньшей степени касается прикладного интерфейса систе70мы, однако имеет существенные связи с ним.
К примеру, в системе Midway[15, 16] доступ к распределённым переменным допускается не только внутри секций, гарантирующих консистентность, но и вне их (что являетсяпредметом определения прикладного интерфейса системы, её модели программирования). На фоне отсутствия соответствующих сообщений на этапе компиляции данная возможность приводит к сложнообнаруживаемымошибкам.
При этом ниже будет показано, что данной проблемы можноизбежать даже без привлечения компилятора.С целью избежать свойств, описанных выше, прикладной интерфейс системы МАКС DSM будет соответствовать следующим требованиям:1. Реализация на стандартном языке Си++.2. Классическая концепция DSM интерфейса – маркировка распределённыхпеременных и специальные секции для работы с ними.3. Жесткая связь каждой распределённой переменной с конкретной секцией.Определяется пользователем один раз, в процессе выполнения программыне изменяется.4. Ограничение возможности доступа к распределённым переменным за пределами соответствующих секций.5.
Синтаксическая лаконичность и самоочевидность результирующего прикладного кода.6. Контроль выполнения заданных правил на этапе компиляции.На первый взгляд, описанные требования могут показаться взаимоисключающими и невыполнимыми. Однако ниже будет показано, что задействованиеязыка Си++ и препроцессора (что не типично для ранее создававшихся DSMсистем) позволяет обеспечить выполнение данных принципов.712.3. ВыводыВ данной главе было рассмотрено назначение создаваемого решения, уточнены требования (к решению и его окружению), разработана новая модель усиленной консистентности по выходу, основные алгоритмы, а также принципы(требования) к прикладному интерфейсу, учитывающие недостатки ранее созданных систем.Разрабатываемое решение предназначено для использования в мультиагентных системах в сфере IoT, включая системы АСКУЭ и беспилотные летательные аппараты.
Создаваемая система призвана функционировать на маломощных микроконтроллерах без MMU, интегрируясь и задействуя в качественизлежащего сетевого слоя операционную систему реального времени МАКС.Решение должно обеспечивать создание сетей из полутора десятков устройств,допускающих выход из строя отдельных узлов без потери общей функциональности.Созданные ранее модели консистентности предлагают широкий выбор решений по критериям величины накладных сетевых расходов и удобства программирования. Так как нашей задачей является создание отказоустойчивогомеханизма, основной стратегией был избран write-broadcast [33] подход.
Несмотря на то, что ранее данный подход не был популярен в связи с повышеннойнагрузкой на сеть, в условиях радиоэфира (или иной разделяемой и принципиально широковещательной среды) его недостатки нивелируются, что позволяет эффективно задействовать его с целью минимизации времени, в течениекоторого отдельный узел системы может обладать уникальными данными (которые не могут быть восстановлены в случае выхода данного узла из строя).На основе модели консистентности по выходу, была создана её усиленная версия, включившая такие новые свойства как наличие связи между общими исинхронизационными переменными и разделение захватов на эксклюзивные инеэксклюзивные.72За внешним равноправием и взаимозаменяемостью узлов системы был расположен слой абстракции, вводящий понятие роли узла. Соответственно быларазработана система ролей, их функций а также алгоритм смены роли узлом,отвечающий условиям динамичности системы.
Были разработаны принципыинформационного обмена в сети (верхнеуровневое описание протокола) и принципиальное решение задачи отказоустойчивости. Анализ слабых сторон ранеесозданных DSM систем, отрицательно сказывающихся на их популярности, позволил выработать принципы к созданию прикладного интерфейса, свободногоот выявленных недостатков.Таким образом, в данной главе были решены все поставленные во введениитеоретические задачи и «подготовлена почва» для программной реализациисоздаваемого механизма, рассматриваемой в следующей главе.73Глава 3.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
