Архитектура распределённых приложений. Распределённая архитектура

В крупных холдингах работают десятки тысяч пользователей в дочерних компаниях. В каждой организации налажены свои внутренние бизнес-процессы: согласование документов, выдача поручений и т.д. При этом некоторые процессы выходят за пределы одной компании и затрагивают сотрудников другой. Например, руководитель головного офиса выдает поручение в дочернюю организацию, или сотрудник дочерней отправляет договор на согласование с юристами головной компании. Это требует создания сложной архитектуры с использованием нескольких систем.

Кроме того, в пределах одной компании используется множество систем для решения разных задач: ERP-система для учетных операций, отдельные инсталляции ЕСМ-систем для организационно-распорядительной документации, для проектно-сметной документации и т.д.

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

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

• организация сквозных бизнес-процессов и синхронизация данных между несколькими системами одной компании и в холдинге;
• обеспечение доступа к данным разных инсталляций ECM-систем. Например, выполнить поиск документа по нескольким специализированным системам: с финансовой документацией, с проектно-сметной документацией и пр.
• администрирование множества систем и сервисов из единой точки управления и создание комфортной IT-инфраструктуры;
• удобное распространение разработки в распределенные продуктивные системы.

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

Механизмы межсистемного взаимодействия (DCI)

Механизмы DCI используются для организации сквозных бизнес-процессов и синхронизации данных между разными системами внутри одной или нескольких организаций (холдинга).

Решение соединяет существующие в компаниях локальные бизнес-процессы в единый сквозной процесс. Сотрудники и их руководители работают с уже знакомым интерфейсом задач, документов и справочников. При этом действия сотрудников прозрачны на каждом этапе: они могут видеть текст переписки со смежной компанией, посмотреть состояние согласования документа с головной организацией и пр.

К DCI можно подключать разные инсталляции DIRECTUM и другие классы систем (ERP, CRM и пр.). Как правило, инсталляции делятся по направлениям бизнеса, с учетом территориального или юридического размещения организаций и других факторов.

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

Механизмы DCI позволяют передавать большие объемы данных и выдерживают пиковые нагрузки. Кроме того, они обеспечивают отказоустойчивость при сбое связи и защиту передаваемых данных.

Федеративный поиск

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

Федеративный поиск позволяет:

• посмотреть через веб-клиент ход согласования исходящего документа в дочерней организации;
• найти договоры, заключенные с контрагентом во всех дочерних организациях, например, для подготовки переговоров. При этом можно перейти к задачам, в которые вложены договоры;
• проверить статус исполнения поручения, отправленного из головной организации в дочернюю, или документы и задачи, созданные по нему;
• найти документы одновременно в нескольких системах с разной специализацией, например, с организационно-распорядительными документами и с договорами;
• найти первичные учетные документы для аудита или сверки с контрагентом сразу в рабочей системе и в системе с архивом документов;
• обменяться ссылками на результаты поиска с коллегами.

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

Центр администрирования служб DIRECTUM

Система DIRECTUM решает множество разных задач: взаимодействие сотрудников, хранение документов и др. Это возможно благодаря надежной работе ее служб. А в крупных компаниях выделяют целые инсталляции системы DIRECTUM со своим набором служб под конкретную задачу, например, под хранение архивных документов. Инсталляции и службы разворачивают на нескольких серверах. Эту инфраструктуру необходимо администрировать.

Центр администрирования служб DIRECTUM — это единая точка входа администратора для конфигурирования, мониторинга и управления службами и системами DIRECTUM. Центр представляет собой сайт с инструментами управления сервером сеансов, службой Workflow, службой обработки событий, службой файловых хранилищ , службами ввода и преобразования , федеративным поиском и веб-справкой.

Удобная визуальная настройка удаленных систем и служб упрощает работу администратора. Ему не нужно заходить на каждый сервер и вручную вносить изменения в конфигурационные файлы.

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

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

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

Каждый компонент управляемой распределенной архитектуры можно использовать отдельно, но в совокупности они принесут вашей организации больший бизнес-эффект.

Архитектура распределенных систем

В настоящее время практически все большие программные системы являются распределенными. Распределенной называется такая система, в которой обработка информации сосредоточена не на одной вычислительной машине, а распределена между несколькими компьютерами. При проектировании распределенных систем, которое имеет много общего с проектированием любого другого ПО, все же следует учитывать ряд специфических особенностей. Некоторые из них уже упоминалось во введении к главе 10 при рассмотрении архитектуры клиент/сервер, здесь они обсуждаются более подробно.

Поскольку в наши дни распределенные системы получили широкое распространение, разработчики ПО должны быть знакомы с особенностями их проектирования. До недавнего времени все большие системы в основном являлись централизованными, которые запускались на одной главной вычислительной машине (мэйнфрейме) с подключенными к ней терминалами. Терминалы практически не занимались обработкой информации – все вычисления выполнялись на главной машине. Разработчикам таких систем не приходилось задумываться о проблемах распределенных вычислений.

Все современные программные системы можно разделить на три больших класса.

1. Прикладные программные системы, предназначенные для работы только на одном персональном компьютере или рабочей станции. К ним относятся текстовые процессоры, электронные таблицы, графические системы и т.п.

2. Встроенные системы, предназначенные для работы на одном процессоре либо на интегрированной группе процессоров. К ним относятся системы управления бытовыми устройствами, различными приборами и др.

3. Распределенные системы, в которых программное обеспечение выполняется на слабо интегрированной группе параллельно работающих процессоров, связанных через сеть. К ним относятся системы банкоматов, принадлежащих какому-либо банку, издательские системы, системы ПО коллективного пользования и др.

В настоящее время между перечисленными классами программных систем существуют четкие границы, которые в дальнейшем будут все более стираться. Со временем, когда высокоскоростные беспроводные сети станут широкодоступными, появится возможность динамически интегрировать устройства со встроенными программными системами, например электронные органайзеры с более общими системами.

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

1. Совместное использование ресурсов. Распределенные системы допускают совместное использование аппаратных и программных ресурсов, например жестких дисков, принтеров, файлов, компиляторов и т.п., связанных посредством сети. Очевидно, что разделение ресурсов возможно также в многопользовательских системах, однако в этом случае за предоставление ресурсов и их управление должен отвечать центральный компьютер.

2. Открытость. Это возможность расширять систему путем добавления новых ресурсов. Распределенные системы – это открытые системы, к которым подключают аппаратное и программное обеспечение от разных производителей.

3. Параллельность. В распределенных системах несколько процессов могут одновременно выполняться на разных компьютерах в сети. Эти процессы могут (но не обязательно) взаимодействовать друг с другом во время их выполнения.

4. Масштабируемость. В принципе все распределенные системы являются масштабируемыми: чтобы система соответствовала новым требованиям, ее можно наращивать посредством добавления новых вычислительных ресурсов. Но на практике наращивание может ограничиваться сетью, объединяющей отдельные компьютеры системы. Если подключить много новых машин, пропускная способность сети может оказаться недостаточной.

5. Отказоустойчивость. Наличие нескольких компьютеров и возможность дублирования информации означает, что распределенные системы устойчивы к определенным аппаратным и программным ошибкам. Большинство распределенных систем в случае ошибки, как правило, могут поддерживать хотя бы частичную функциональность. Полный сбой в работе системы происходит только в случае сетевых ошибок.

6. Прозрачность. Это свойство означает, что пользователям предоставлен полностью прозрачный доступ к ресурсам и в то же время от них скрыта информация о распределении ресурсов в системе. Однако во многих случаях конкретные знания об организации системы помогают пользователю лучше использовать ресурсы.

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

Сложность. Распределенные системы сложнее централизованных. Намного труднее понять и оценить свойства распределенных систем в целом, а также тестировать эти системы. Например, здесь производительность системы зависит не от скорости работы одного процессора, а от полосы пропускания сети и скорости работы разных процессоров. Перемещая ресурсы из одной части системы в другую, можно радикально повлиять на производительность системы.

Безопасность. Обычно доступ к системе можно получить с нескольких разных машин, сообщения в сети могут просматриваться или перехватываться. Поэтому, в распределенной системе намного сложнее поддерживать безопасность.

Управляемость. Система может состоять из разнотипных компьютеров, на которых могут быть установлены разные версии операционных систем. Ошибки на одной машине могут распространиться на другие машины с непредсказуемыми последствиями. Поэтому требуется значительно больше усилий, чтобы управлять и поддерживать систему в рабочем состоянии.

Непредсказуемость. Как известно всем пользователям Web-сети, реакция распределенных систем на определенные события непредсказуема и зависит от полной загрузки системы, ее организации и сетевой нагрузки. Так как все эти параметры могут постоянно меняться, время, затраченное на выполнение запроса пользователя, в тот или иной момент может существенно различаться.

При обсуждении преимуществ и недостатков распределенных систем определяется ряд критических проблем проектирования таких систем (табл. 9.1).

Таблица 9.1. Проблемы проектирования распределенных систем

Задача разработчиков распределенных систем – спроектировать программное или аппаратное обеспечение так, чтобы предоставить все необходимые характеристики распределенной системы. А для этого требуется знать преимущества и недостатки различных архитектур распределенных систем. Здесь выделяется два родственных типа архитектур распределенных систем.

1. Архитектура клиент/сервер. В этой модели систему можно представить как набор сервисов, предоставляемых серверами клиентам. В таких системах серверы и клиенты значительно отличаются друг от друга.

2. Архитектура распределенных объектов. В этом случае между серверами и клиентами нет различий и систему можно представить как набор взаимодействующих объектов, местоположение которых не имеет особого значения. Между поставщиком сервисов и их пользователями не существует различий.

В распределенной системе разные системные компоненты могут быть реализованы на разных языках программирования и выполняться на разных типах процессоров. Модели данных, представление информации и протоколы взаимодействия – все это не обязательно будет однотипным в распределенной системе. Следовательно, для распределенных систем необходимо такое программное обеспечение, которое могло бы управлять этими разнотипными частями и гарантировать взаимодействие и обмен данными между ними. Промежуточное программное обеспечение относится именно к такому классу ПО. Оно находится как бы посередине между разными частями распределенных компонентов системы.

Распределенные системы обычно разрабатываются на основе объектно-ориентированного подхода. Эти системы создаются из слабо интегрированных частей, каждая из которых может непосредственно взаимодействовать как с пользователем, так и с другими частями системы. Эти части по возможности должны реагировать на независимые события. Программные объекты, построенные на основе таких принципов, являются естественными компонентами распределенных систем. Если вы еще не знакомы с концепцией объектов.

на основе реконфигурируемой многоконвейерной вычислительной среды L-Net

Одной из актуальных задач в области систем управления является разработка программного обеспечения для распределенных отказоустойчивых систем управления. Существующие в этой области на сегодняшний день решения являются проприетарными, как следствие, дорогостоящими и не всегда эффективными

Эти решения не предусматривают эффективного использования ресурсов резервирующих баз, технической и программной, что негативно сказывается как на отказоустойчивости, так и на масштабируемости таких решений. При нарушении архитектуры сети отсутствует возможность динамического реконфигурирования как процессов обработки информации, так и передачи потоков данных (как управляющих, так и информационных). Использование специфических микроконтроллеров, применение DCS/SCADA усложняет разработку и поддержку систем, расширение их функционала.

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

Обобщенная типовая архитектура распределенной системы управления (РСУ) включает в себя три иерархически связанных уровня: операторский уровень, уровень управления и уровень ввода-вывода (см. рис.1) .

Основной задачей операторского уровня является предоставление человеко-машинного интерфейса (ЧМИ) для обеспечения настройки и контроля функционирования всей системы. Уровень управления отвечает за получение и обработку данных с датчиков, передачу данных на операторский уровень и выработку управляющих воздействий на исполнительные устройства. Уровень ввода-вывода представляет собой датчики и исполнительные устройства, непосредственно связанные с объектом управления.

Задача программного обеспечения, в рамках обобщенной архитектуры РСУ, состоит в обеспечении функционирования операторского уровня и его связи с уровнем управления системы. Следовательно, основополагающим уровнем при проектировании ПО и решении вопросов его взаимодействия с аппаратным обеспечением является операторский. Программное обеспечение должно максимально эффективно использовать доступные аппаратные ресурсы системы и при этом обладать максимальной независимостью от внутренней архитектуры аппаратного обеспечения.

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

Требования к РСУ

Требования к РСУ относятся не только к системе в целом, но и к ее аппаратной и программной составляющим по отдельности, так как конкретные подходы к удовлетворению данных требований для этих составляющих могут принципиально различаться. РСУ должна быть в первую очередь отказоустойчивой. Простейшим методом повышения отказоустойчивости является резервирование (дублирование) функциональных узлов или их совокупности. Вторым важным свойством является масштабируемость. Масштабируемость основывается на реализации специальных алгоритмов в ПО и аппаратной возможности замены и добавления новых узлов или их составных частей. При этом система должна оставаться простой для ее эксплуатации, разработки новых узлов или модулей и модификации ее архитектуры.

Обзор архитектур РСУ

Для проведения обзора архитектур РСУ были выбраны РСУ Siemens SIMATIC PCS 7 как одна из самых востребованных на рынке и RTS S3 как РСУ, реализованная на базе ОСРВ QNX.

Siemens SIMATIC PCS 7

Архитектура системы имеет все свойства обобщенной архитектуры РСУ . В качестве операторских станций выступают компьютеры на базе процессорной архитектуры x86 с ОС Windows и пакетом Siemens WinCC, предоставляющим ЧМИ. Имеются серверы с базами данных. Станции операторов, инженерные станции и серверы связаны локальной сетью на основе Ethernet. Операторский уровень связан с уровнем управления зарезервированной сетью Industrial Ethernet. На уровне управления находятся программируемые логические контроллеры (ПЛК) с возможностью резервирования за счет дублирования функционала. Имеется возможность подключаться к внешним системам и сетям и организовать удаленный доступ к системе.

RTS S3

Данная архитектура аналогично состоит из уровней обобщенной структуры РСУ . Операторские станции основаны на той же аппаратной платформе, что и в РСУ SIMATIC, но могут находиться под управлением как ОС Windows, так и Linux. Инженерные станции объединены с операторскими. Системой предоставляется единая среда разработки приложений. Сеть Ethernet соединяет узлы внутри операторского уровня и сам операторский уровень с уровнем управления с использованием стека протоколов TCP/IP. На уровне управления находятся промышленные компьютеры под управлением ОС QNX с собственной базой данных и возможностью резервирования путем дублирования функционала узла.

Недостатки описанных систем

В описанных выше системах для операторского уровня и уровня управления используется разная аппаратно-программная платформа. В пределах операторского уровня возможно использование только одной процессорной архитектуры, а для настройки и разработки уровня управления требуется специальная инженерная станция. Данные РСУ предлагают в качестве способа повышения отказоустойчивости только аппаратное резервирование с дублированием функционала резервируемого узла, что является нерациональным использованием резервирующего аппаратного обеспечения.

Характеристики и функциональные особенности системы L-Net

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

• Динамическая реконфигурация с полным восстановлением работоспособности с минимальными потерями в случае отказа хоста или нарушения топологии сети.
• Эффективное распределение задач по имеющимся работоспособным узлам сети.
• Дублирование каналов связи между узлами с динамической реконфигурацией потоков передачи данных.
• Легкость эксплуатации и масштабирования системы.
• Переносимость и работоспособность системы на любой аппаратной платформе, предназначенной для построения систем управления и встраиваемых систем.

Для построения системы с вышеописанными характеристиками требуется операционная система, предназначенная преимущественно для создания систем управления и встраиваемых систем. Анализ существующих операционных систем показал, что наиболее подходящей операционной системой является ОС QNX 6 (Neutrino), которая обладает весьма эффективными ресурсораспределяющими и сетевыми возможностями . Широкие сетевые возможности обеспечиваются сетевым протоколом Qnet. Он решает задачу надежности и динамической балансировки нагрузки каналов связи, но при этом не решаются проблемы отказоустойчивости системы в целом . В результате была разработана инновационная система управления, основанная на распределенной реконфигурируемой многоконвейерной вычислительной среде. Разработанная система имеет одноранговую архитектуру, включающую три логических блока: блок ввода-вывода, блок коммутаторов общего назначения и блок реконфигурируемой вычислительной среды (РВС) (см. рис.2).

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

• Одноранговый тип
• Децентрализованность
• Масштабируемость
• Пространственная распределенность

Функциональные особенности данной архитектуры:

• Конвейерная обработка данных
• Аппаратное резервирование
• Распределение нагрузки
• Реконфигурация «на лету»

На первом уровне архитектуры находится блок ввода-вывода (I/O), включающий в себя: узлы ввода-вывода, коммутатор узлов ввода-вывода, интерфейс ввода-вывода, датчики и исполнительные устройства. Блок отвечает за базовые механизмы формирования управляющих воздействий на основании данных с локальных датчиков и данных, полученных от других уровней системы управления. Поставленные задачи распределяются между работоспособными узлами ввода-вывода на основании их текущей относительной производительности или вручную оператором. Датчики и исполнительные устройства подключены с помощью шины ко всем узлам ввода-вывода в блоке, что позволяет любому узлу опрашивать любой датчик или вырабатывать воздействие на любое исполнительное устройство. Коммутатор узлов ввода-вывода обеспечивает связь между всеми узлами ввода-вывода для обмена данными между ними и другими уровнями архитектуры системы для получения управляющих и информационных данных. При наличии соответствующих аппаратных возможностей узлы связываются между собой и с узлами и коммутаторами на других уровнях системы непосредственно, что уменьшает время реакции в сети. Прямая связь между узлами и определенная загруженность узлов в текущем режиме работы блока ввода-вывода позволяет организовывать в блоке конвейерные вычисления, необходимые для функционирования этого блока без обращения к внешним вычислительным мощностям системы управления (РВС), что позволяет эффективно использовать свободные ресурсы, предоставленные для резервирования узлов блока ввода-вывода на момент отказа.

Блок коммутаторов общего назначения, находящийся на втором уровне архитектуры, организовывает линии связи между блоками ввода-вывода и РВС и внешними системами. Каждый коммутатор может соединять между собой различные узы и коммутаторы во всей системе управления. Количество линий связи определяется аппаратными возможностями входящих в состав блоков узлов и коммутаторов. Так как сеть Qnet позволяет динамически распределять потоки передачи данных, масштабирование этого блока осуществляется простым подключением новых устройств и не требует настройки, а при выходе из строя одного из коммутаторов передача данных между узлами не будет прервана, если другой коммутатор обеспечивает аналогичную связь между узлами или они связаны напрямую. При этом необходимо позаботиться о достаточной пропускной способности сети, необходимой для резервирования вышедшего из строя коммутатора.

Блок реконфигурируемой вычислительной сети (РВС), находящийся на третьем уровне архитектуры, обеспечивает систему управления высокими вычислительными мощностями для решения сложных задач обработки информации, принятия решений, распознавания и т.д. Блок отвечает за инициализацию всей системы управления: проверка работоспособности коммутаторов и узлов, целостности сети, построение графов сети всей системы, установка стартовых параметров работы блоков ввода-вывода. Узлы этого блока предусматривают архивирование как собственных данных, так и данных с блоков ввода-вывода. Каждый узел этого блока может исполнять роль машины оператора, предназначенной для мониторинга работы системы и внесения корректировок в программы работы как этого узла, так и всех узлов системы, выполнения реконфигурации по запросу.

Распределение нагрузки

Одной из основных задач системы L-Net является распределение вычислительной нагрузки на узлах сети. Решение данной задачи основывается на построении вычислительных конвейеров. Для построения вычислительного конвейера предварительно строится граф задачи – схема обмена потоками данных от источника к получателю. В качестве источника выступают датчики, а в качестве получателя – исполнительные механизмы. Сам вычислительный конвейер представляет собой отображение графа задачи (см. рис.3) на граф вычислительной сети (см. рис.4) с учетом требований задачи к вычислительным ресурсам системы и текущему ее состоянию.

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

Отказоустойчивость

Основной проблемой функционирования подобной системы является полное нарушение работоспособности вычислительных конвейеров при отказе любого узла этого конвейера или при нарушении передачи данных между ними. Базовыми средствами протокола Qnet достигается восстановление связей между узлами при частичном их нарушении за счет резервных линий, предусмотренных архитектурой. Система L-Net решает проблему восстановления работоспособности при полном отказе хоста вычислительной системы путем динамической реконфигурации вычислительного конвейера, т.е. использованием рабочих ресурсов для замещения сбойного блока. Система предусматривает три сценария восстановления (реконфигурации), отличающихся временем реакции на факт отказа, временем восстановления и используемыми аппаратными ресурсами: по факту отказа, с пассивной готовностью, с активной готовностью.

• Реконфигурация по факту отказа – после обнаружения отказа производятся поиск доступного аппаратного обеспечения и его включение в граф задачи.
• Реконфигурация с пассивной готовностью – резервирующее аппаратное обеспечение определяется заранее, запускается процесс, обеспечивающий реализацию вершины графа задачи на узле, устанавливаются соединения, но процесс не производит обработку данных, если не произошел отказ основного узла.
• Реконфигурация с активной готовностью – вершина графа задачи реализуется на нескольких узлах, которые параллельно выполняют обработку данных и передают результат.

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

Заключение

Разработанная система L-Net в отличие от существующих аналогов предполагает использование широкого спектра аппаратных характеристик узлов РСУ при полной их программной совместимости. При работе узлов под управлением одной операционной системы (QNX Neutrino) обеспечивается возможность их построения на различных процессорных архитектурах (x86, ARM, MIPS и т.д.) с разнообразными наборами интерфейсов и периферийных устройств. Реализация узлов возможна в виде настольных, промышленных ПК, носимых ПК и одноплатных компьютеров. Все составляющие комплекса программного обеспечения разрабатываемой РСУ могут быть запущены на любом ее узле с ОС QNX, при этом остается возможность использования узлов с другой операционной системой. Такой подход позволяет использовать каждый узел для решения задач как операторского уровня, так и уровня управления. Следовательно, имеется гибкая система взаимодействия между одноранговыми узлами без жесткой иерархии уровней, присущей обобщенной архитектуре РСУ и системам использующих данную архитектуру как базовую. Одноранговость сети упрощает процессы развертывания, эксплуатации, масштабирования и отладки системы.

Для реализации вычислительного потенциала резервирующего аппаратного обеспечения в разрабатываемой системе предлагаются алгоритмы динамического конфигурирования и реконфигурирования, основанные на сетевом протоколе Qnet и программном обеспечении сети L-Net. Алгоритм динамического конфигурирования основан на распределении вычислительной нагрузки по всем узлам путем конвейеризации и распараллеливания задач и динамической балансировки нагрузки на каналы передачи данных между узлами. Алгоритм реконфигурации системы предполагает наличие трех сценариев восстановления работоспособности при отказе в зависимости от имеющегося аппаратного обеспечения, приоритетов и задач, возложенных на систему: по факту отказа, с пассивной готовностью (выделение ресурсов) и с активной готовностью (использование ресурсов). Алгоритмы динамического конфигурирования и реконфигурирования позволяют повысить производительность и надежность за счет имеющихся в системе аппаратных резервов.

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

Вывод

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

1. http://kazanets.narod.ru/DCSIntro.htm .
2. http://kazanets.narod.ru/PCS7Overview.htm .
3. http://www.rts.ua/rus/news/678/0/409 .
4. Зыль С. QNX Momentics: основы применения. – СПб: БХВ-Петербург, 2005.
5. Кртен Р. Введение в QNX Neutrino. Руководство для разработки приложений реального времени. – СПб: БХВ-Петербург, 2011.

Ключевые слова: распределенная система управления, информационное обеспечение систем управления, распределенные реконфигурируемые системы.

Architecture of a distributed control system based on reconfigurable multi-pipeline computing environment L-Net

Sergey Yu. Potomskiy, Assistant Professor of National Research University «Higher School of Economics».

Nikita A. Poloyko, Fifth-year student of National Research University «Higher School of Economics». Study assistant. Programmer. Field of training: «Control and informatics in the technical systems».

Abstract. The article is devoted to a distributed control system based on reconfigurable multi-pipeline computing environment. The architecture of the system is given. Also, the basic characteristics and functional properties of the system are given too. The article presents a rationale for the choice of the operating system. The basic advantages of the system in comparison with existing similar developments are shown in the article.

Keywords: distributed control system, systems software support, distributed reconfigurable.

Вконтакте

Гетерогенные мультикомпьютерные системы

Наибольшее число существующих в настоящее время распределенных систем построено по схеме гетерогенных мультикомпьютерных. Это означает, что компьютеры, являющиеся частями этой системы, могут быть крайне разнообразны, например, по типу процессора, размеру памяти и производительности каналов ввода-вывода. На практике роль некоторых из этих компьютеров могут исполнять высокопроизводительные параллельные системы, например мультипроцессорные или гомогенные мультикомпьютерные.

Соединяющая их сеть также может быть сильно неоднородной.

Примером гетерогенности является создание крупных мультикомпьютерных систем с использованием существующих сетей и каналов. Так, например, не является чем-то необычным существование университетских распределенных систем, состоящих из локальных сетей различных факультетов, соединенных между собой высокоскоростными каналами. В глобальных системах различные станции могут, в свою очередь, соединяться общедоступными сетями, например сетевыми службами, предлагаемыми коммерческими операторами связи, например SMDS или Frame relay .

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

Переходя к вопросам масштабирования, присущим гетерогенным системам, и учитывая необходимость глобального подхода, присущую большинству из них, заметим, что создание приложений для гетерогенных мультикомпьютерных систем требует специализированного программного обеспечения. С этой проблемой распределенные системы справляются. Чтобы у разработчиков приложений не возникало необходимости волноваться об используемом аппаратном обеспечении, распределенные системы предоставляют программную оболочку, которая защищает приложения от того, что происходит на аппаратном уровне (то есть они обеспечивают прозрачность).

Наиболее ранней и фундаментальной распределенной архитектурой является «клиент-сервер», в которой одна из сторон (клиент) инициирует обмен данными, посылая запрос другой стороне (серверу). Сервер обрабатывает запрос и при необходимости посылает ответ клиенту (рис. 2.7).

Рис. 2.7. Модель взаимодействия клиент сервер

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

Рис. 2.8. Логические уровни приложения

Рассмотрим некое типичное приложение, которое в соответствии с современными представлениями может быть разделено на следующие логические уровни (рис. 2.8): пользовательский интерфейс (ИП), логика приложения (ЛП) и доступ к данным (ДД), работающий с базой данных (БД). Пользователь системы взаимодействует с ней через интерфейс пользователя, база данных хранит данные, описывающие предметную область приложения, а уровень логики приложения реализует все алгоритмы, относящиеся к предметной области.

Поскольку на практике разных пользователей системы обычно интересует доступ к одним и тем же данным, наиболее простым разнесением функций такой системы между несколькими компьютерами будет разделение логических уровней приложения между одной серверной частью приложения, отвечающим за доступ к данным, и находящимися на нескольких компьютерах клиентскими частями, реализующими интерфейс пользователя. Логика приложения может быть отнесена к серверу, клиентам, или разделена между ними (рис. 2.9).

Рис. 2.9. Двухзвенная архитектура

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

Развитием архитектуры клиент-сервер является трехзвенная архитектура , в которой интерфейс пользователя, логика приложения и доступ к данным выделены в самостоятельные составляющие системы, которые могут работать на независимых компьютерах (рис 2.10).

Рис. 2.10. Трехзвенная архитектура

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

Рис. 2.11. Распределенная система розничных продаж

Применительно к приложениям автоматизации деятельности предприятия, распределенными обычно называют системы с логикой приложения, распределенной между несколькими компонентами системы, каждая из которых может выполняться на отдельном компьютере. Например, реализация логики приложения системы розничных продаж должна использовать запросы к логике приложения третьих фирм, таких как поставщики товаров, системы электронных платежей или банки, предоставляющие потребительские кредиты (рис. 2.11).

В качестве другого примера распределенной системы можно привести сети прямого обмена данными между клиентами (peer-to-peer networks) . Если предыдущий пример имел "древовидную" архитектуру, то сети прямого обмена организованы более сложным образом, рис 2.12. Подобные системы являются в настоящий момент, вероятно, одними из крупнейших существующих распределенных систем, объединяющие миллионы компьютеров.

Рис. 2.12. Система прямого обмена данными между клиентами

(Материал сайта http://se.math.spbu.ru)

Введение.

В настоящее время практически все большие программные системы являются распределенными. Распределенная система - система, в которой обработка информации сосредоточена не на одной вычислительной машине, а распределена между несколькими компьютерами. При проектировании распределенных систем, которое имеет много общего с проектированием ПО в общем, все же следует учитывать некоторые специфические особенности.

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

1. Совместное использование ресурсов. Распределенные системы допускают совместное использование как аппаратных (жестких дисков, принтеров), так и программных (файлов, компиляторов) ресурсов.
2. Открытость. Это возможность расширения системы путем добавления новых ресурсов.
3. Параллельность. В распределенных системах несколько процессов могут одновременно выполнятся на разных компьютерах в сети. Эти процессы могут взаимодействовать во время их выполнения.
4. Масштабируемость . Под масштабируемостью понимается возможность добавления новых свойств и методов.
5. Отказоустойчивость. Наличие нескольких компьютеров позволяет дублирование информации и устойчивость к некоторым аппаратным и программным ошибкам. Распределенные системы в случае ошибки могут поддерживать частичную функциональность. Полный сбой в работе системы происходит только при сетевых ошибках.
6. Прозрачность. Пользователям предоставляется полный доступ к ресурсам в системе, в то же время от них скрыта информация о распределении ресурсов по системе.

Распределенные системы обладают и рядом недостатков.

1. Сложность . Намного труднее понять и оценить свойства распределенных систем в целом, их сложнее проектировать, тестировать и обслуживать. Также производительность системы зависит от скорости работы сети, а не отдельных процессоров. Перераспределение ресурсов может существенно изменить скорость работы системы.
2. Безопасность . Обычно доступ к системе можно получить с нескольких разных машин, сообщения в сети могут просматриваться и перехватываться. Поэтому в распределенной системе намного труднее поддерживать безопасность.
3. Управляемость . Система может состоять из разнотипных компьютеров, на которых могут быть установлены различные версии операционных систем. Ошибки на одной машине могут распространиться непредсказуемым образом на другие машины.
4. Непредсказуемость . Реакция распределенных систем на некоторые события непредсказуема и зависит от полной загрузки системы, ее организации и сетевой нагрузки. Так как эти параметры могут постоянно изменятся , поэтому время ответа на запрос может существенно отличаться от времени.

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

1. Идентификация ресурсов . Ресурсы в распределенных системах располагаются на разных компьютерах, поэтому систему имен ресурсов следует продумать так, чтобы пользователи могли без труда открывать необходимые им ресурсы и ссылаться на них. Примером может служить система URL(унифицированный указатель ресурсов), которая определяет имена Web-страниц.
2. Коммуникация . Универсальная работоспособность Internet и эффективная реализация протоколов TCP/IP в Internet для большинства распределенных систем служат примером наиболее эффективного способа организации взаимодействия между компьютерами. Однако в некоторых случаях, когда требуется особая производительность или надежность, возможно использование специализированных средств.
3. Качество системного сервиса . Этот параметр отражает производительность, работоспособность и надежность. На качество сервиса влияет ряд факторов: распределение процессов, ресурсов, аппаратные средства и возможности адаптации системы.
4. Архитектура программного обеспечения . Архитектура ПО описывает распределение системных функций по компонентам системы, а также распределение этих компонентов по процессорам. Если необходимо поддерживать высокое качество системного сервиса, выбор правильной архитектуры является решающим фактором.

Задача разработчиков распределенных систем - спроектировать программное и аппаратное обеспечение так, чтобы предоставить все необходимые характеристики распределенной системы. А для этого требуется знать преимущества и недостатки различных архитектур распределенных систем. Выделяется три типа архитектур распределенных систем.

1. Архитектура клиент/сервер . В этой модели систему можно представить как набор сервисов, предоставляемых серверами клиентам. В таких системах серверы и клиенты значительно отличаются друг от друга.
2. Трехзвенная архитектура . В этой модели сервер предоставляет клиентам сервисы не напрямую, а посредством сервера бизнес-логики .

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

1. Архитектура распределенных объектов . В этом случае между серверами и клиентами нет различий и систему можно представить как набор взаимодействующих объектов, местоположение которых не имеет особого значения. Между поставщиком сервисов и их пользователями не существует различий.

Эта архитектура широко применяется в настоящее время и носит также название архитектуры веб-сервисов . Веб-сервис - это приложение, доступное через Internet и предоставляющее некоторые услуги, форма которых не зависит от поставщика (так как используется универсальный формат данных - XML) и платформы функционирования. В данное время существует три различные технологии, поддерживающие концепцию распределенных объектных систем. Это технологии EJB, CORBA и DCOM.

Для начала несколько слов о том, что такое XML вообще. XML - универсальный формат данных, который используется для предоставления Web-сервисов. В основе Web-сервисов лежат открытые стандарты и протоколы: SOAP, UDDI и WSDL.

1. SOAP (Simple Object Access Protocol ), разработанный консорциумом W3C, определяет формат запросов к Web-сервисам. Сообщения между Web-сервисом и его пользователем пакуются в так называемые SOAP-конверты (SOAP envelopes , иногда их ещё называют XML-конвертами). Само сообщение может содержать либо запрос на осуществление какого-либо действия, либо ответ - результат выполнения этого действия.
2. WSDL (Web Service Description Language). Интерфейс Web-сервиса описывается в WSDL-документах (а WSDL - это подмножество XML). Перед развертыванием службы разработчик составляет ее описание на языке WSDL, указывает адрес Web-сервиса, поддерживаемые протоколы, перечень допустимых операций, форматы запросов и ответов.
3. UDDI (Universal Description, Discovery and Integration) - протокол поиска Web- сервисов в Internet (http://www.uddi.org/ ). Представляет собой бизнес-реестр, в котором провайдеры Web-сервисов регистрируют службы, а разработчики находят необходимые сервисы для включения в свои приложения.

Из доклада может показаться, что Web-сервисы - наилучшее и безальтернативное решение, и вопрос только в выборе средств разработки. Однако это не так. Альтернатива Web-службам существует, это семантический Web (Semantic Web ), о необходимости создания которого уже пять лет назад говорил создатель WWW Тим Бернерс-Ли .

Если задача Web-сервисов - облегчить коммуникацию между приложениями, то семантический Web призван решить гораздо более сложную проблему - с помощью механизмов метаданных повысить эффективность ценность информации, которую можно найти в Сети. Сделать это можно, отказавшись от документно-ориентированного подхода в пользу объектно-ориентированного.

Список литературы

1. Соммервилл И. Инженерия программного обеспечения.
2. Драница А. Java против.NET. - "Компьютерра ", #516.
3. Ресурсы интернет.