Архитектура распределенных систем. Обзор распределенных систем Уровень представления данных

на основе реконфигурируемой многоконвейерной вычислительной среды 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.

Вконтакте

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

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

Распределенная архитектура AggreGate необычайно гибка. Технически она основана на формировании одноранговых связей между серверами и прикреплении частей единой модели данных одних серверов («поставщиков») к другим («потребителям»).

Цели распределенных операций

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

• Масштабируемость . Серверы нижнего уровня могут быть сильно нагружены, собирая данные и управляя большим количеством устройств в режиме, близком к реальному времени. Однако на практике количество устройств, которые могут обслуживаться с помощью одного сервера, ограничено до нескольких тысяч. При масштабировании системы для управления большим числом устройств разумно установить несколько серверов и объединить их в рамках распределенной установки.
• Балансировка нагрузки . Каждый сервер в распределенной установке решает свою задачу. Серверы управления сетью проверяют доступность и производительность сетевой инфраструктуры, серверы контроля доступа обрабатывают запросы от контроллеров дверей и турникетов. Операции контроля, такие как генерация отчетов и их рассылка по почте, могут выполняться на центральном сервере.
• Защита от вторжений . Вторичные серверы-зонды могут быть установлены в удаленных местах и подключены к центральному серверу. Системные операторы подключаются только к центральному серверу, при этом отпадает необходимость в настройке VPN и проброса портов к этим серверам.
• Централизация . Вторичные серверы могут работать в полностью автоматическом режиме, в то время как их настройка и мониторинг осуществляется через основной сервер, установленный в центральной диспетчерской.

Распределение ролей сервера

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

Крупномасштабная облачная IoT-платформа

Поставщики телекоммуникационных и облачных услуг предлагают IoT-сервисы по моделям IaaS/PaaS/SaaS. В этих случаях речь идёт о миллионах устройств, принадлежащих тысячам пользователей. Обслуживание такой огромной инфраструктуры требует сотни серверов AggreGate, большинство из которых можно объединить в две группы:

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

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

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

Многоуровневая инфраструктура Интернета вещей

Благодаря распределённой инфраструктуре AggreGate любое решение может включать в себя множество серверов разных уровней. Часть из них может работать на IoT-шлюзах, собирая данные, другие - хранить и обрабатывать информацию, а оставшаяся часть - осуществлять высокоуровневую агрегацию и распределённые вычисления.

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

Управление умным городом

Это пример основанной на AggreGate многоуровневой архитектуры для комплексной автоматизации большой группы зданий:

• Уровень 1 : физическое оборудование (сетевые маршрутизаторы, контроллеры, промышленное оборудование и т.д.)
• Уровень 2 : серверы управления (серверы мониторинга сети, серверы контроля доступа, серверы автоматизации зданий и другие)
• Уровень 3 : центры управления серверами зданий (один сервер на здание, который собирает информацию со всех серверов второго уровня)
• Уровень 4 : серверы районов города (конечный пункт назначения для эскалации оповещений более низкого уровня, мониторинг в реальном времени, интеграция с Service Desk-системами)
• Уровень 5 : серверы головного офиса (контроль серверов района, сбор и обобщение отчетов, оповещений)

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

Управление мультисегментной сетью

AggreGate Network Manager построен на платформе AggreGate и является типичным примером использования распределенной архитектуры. Большие сегментированные сети корпораций и операторов связи не могут контролироваться из единого центра из-за ограничений маршрутизации, политики безопасности или ограничений пропускной способности каналов связи с удаленными сегментами сети.

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

• Первичный или центральный сервер, собирающий информацию со всех сегментов сети
• Вторичные серверы или серверы-зонды , выполняющие опрос устройств в изолированных сегментах
• Специализированные серверы, такие как серверы анализа трафика, обрабатывающие миллиарды NetFlow-событий в день

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

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

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

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

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

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

Цифровое предприятие

AggreGate может выступать как координирующая платформа для цифрового предприятия. Каждый из серверов AggreGate может выполнять различные функции, начиная от мониторинга и управления удалёнными объектами и заканчивая высокоуровневыми сервисами, такими как бизнес-аналитика или, например, управление инцидентами.

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

В предыдущей главе нами были рассмотрены сильносвязанные многопроцессорные системы с общей памятью, общими структурами данных ядра и общим пулом, из которого процессы вызываются на выполнение. Часто, однако, бывает желательно в целях обеспечения совместного использования ресурсов распределять процессоры таким образом, чтобы они были автономны от операционной среды и условий эксплуатации. Пусть, например, пользователю персональной ЭВМ нужно обратиться к файлам, находящимся на более крупной машине, но сохранить при этом контроль над персональной ЭВМ. Несмотря на то, что отдельные программы, такие как uucp, поддерживают передачу файлов по сети и другие сетевые функции, их использование не будет скрыто от пользователя, поскольку пользователь знает о том, что он работает в сети. Кроме того, надо заметить, что программы, подобные текстовым редакторам, с удаленными файлами, как с обычными, не работают. Пользователи должны располагать стандартным набором функций системы UNIX и, за исключением возможной потери в быстродействии, не должны ощущать пересечения машинных границ. Так, например, работа системных функций open и read с файлами на удаленных машинах не должна отличаться от их работы с файлами, принадлежащими локальным системам.

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

Рисунок 13.1. Модель системы с распределенной архитектурой

Распределенные системы, хорошо описанные в литературе, традиционно делятся на следующие категории:

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

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

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

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

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

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

Рисунок 13.2. Конфигурация периферийной системы

Рисунок 13.3. Форматы сообщений

Когда периферийный процесс вызывает системную функцию, которую можно обработать локально, ядру нет надобности посылать запрос процессу-спутнику. Так, например, в целях получения дополнительной памяти процесс может вызвать для локального исполнения функцию sbrk. Однако, если требуются услуги центрального процессора, например, чтобы открыть файл, ядро кодирует информацию о передаваемых вызванной функции параметрах и условиях выполнения процесса в некое сообщение, посылаемое процессу-спутнику (Рисунок 13.3). Сообщение включает в себя признак, из которого следует, что системная функция выполняется процессом-спутником от имени клиента, передаваемые функции параметры и данные о среде выполнения процесса (например, пользовательский и групповой коды идентификации), которые для разных функций различны. Оставшаяся часть сообщения представляет собой данные переменной длины (например, составное имя файла или данные, предназначенные для записи функцией write).

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

Для того, чтобы объяснить, каким образом работает периферийная система, рассмотрим ряд функций: getppid, open, write, fork, exit и signal. Функция getppid довольно проста, поскольку она связана с простыми формами запроса и ответа, которыми обмениваются периферийный и центральный процессоры. Ядро на периферийном процессоре формирует сообщение, имеющее признак, из которого следует, что запрашиваемой функцией является функция getppid, и посылает запрос центральному процессору. Процесс-спутник на центральном процессоре читает сообщение с периферийного процессора, расшифровывает тип системной функции, исполняет ее и получает идентификатор своего родителя. Затем он формирует ответ и передает его периферийному процессу, находящемуся в состоянии ожидания на другом конце линии связи. Когда периферийный процессор получает ответ, он передает его процессу, вызвавшему системную функцию getppid. Если же периферийный процесс хранит данные (такие, как идентификатор процесса-родителя) в локальной памяти, ему вообще не придется связываться со своим спутником.

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

Рисунок 13.4. Вызов функции open из периферийного процесса

Если производится обращение к системной функции write, периферийный процессор формирует сообщение, состоящее из признака функции write, дескриптора файла и объема записываемых данных. Затем из пространства периферийного процесса он по линии связи копирует данные процессу-спутнику. Процесс-спутник расшифровывает полученное сообщение, читает данные из линии связи и записывает их в соответствующий файл (в качестве указателя на индекс которого и запись о котором в таблице файлов используется содержащийся в сообщении дескриптор); все указанные действия выполняются на центральном процессоре. По окончании работы процесс-спутник передает периферийному процессу посылку, подтверждающую прием сообщения и содержащую количество байт данных, успешно переписанных в файл. Операция read выполняется аналогично; спутник информирует периферийный процесс о количестве реально прочитанных байт (в случае чтения данных с терминала или из канала это количество не всегда совпадает с количеством, указанным в запросе). Для выполнения как той, так и другой функции может потребоваться многократная пересылка информационных сообщений по сети, что определяется объемом пересылаемых данных и размерами сетевых пакетов.

Единственной функцией, требующей внесения изменений при работе на центральном процессоре, является системная функция fork. Когда процесс исполняет эту функцию на ЦП, ядро выбирает для него периферийный процессор и посылает сообщение специальному процессу - серверу, информируя последний о том, что собирается приступить к выгрузке текущего процесса. Предполагая, что сервер принял запрос, ядро с помощью функции fork создает новый периферийный процесс, выделяя запись в таблице процессов и адресное пространство. Центральный процессор выгружает копию процесса, вызвавшего функцию fork, на периферийный процессор, затирая только что выделенное адресное пространство, порождает локальный спутник для связи с новым периферийным процессом и посылает на периферию сообщение о необходимости инициализации счетчика команд для нового процесса. Процесс-спутник (на ЦП) является потомком процесса, вызвавшего функцию fork; периферийный процесс с технической точки зрения выступает потомком процесса-сервера, но по логике он является потомком процесса, вызвавшего функцию fork. Процесс-сервер не имеет логической связи с потомком по завершении функции fork; единственная задача сервера состоит в оказании помощи при выгрузке потомка. Из-за сильной связи между компонентами системы (периферийные процессоры не располагают автономией) периферийный процесс и процесс-спутник имеют один и тот же код идентификации. Взаимосвязь между процессами показана на Рисунке 13.5: непрерывной линией показана связь типа "родитель-потомок", пунктиром - связь между равноправными партнерами.

Рисунок 13.5. Выполнение функции fork на центральном процессоре

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

Рисунок 13.6. Выполнение функции fork на периферийном процессоре

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

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

алгоритм sighandle /* алгоритм обработки сигналов */

if (текущий процесс является чьим-то спутником или имеет прототипа)

if (сигнал игнорируется)

if (сигнал поступил во время выполнения системной функции)

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

послать сообщение о сигнале периферийному процессу;

else { /* периферийный процесс */

/* поступил ли сигнал во время выполнения системной функции или нет */

послать сигнал процессу-спутнику;

алгоритм satellite_end_of_syscall /* завершение системной функции, вызванной периферийным процессом */

входная информация: отсутствует

выходная информация: отсутствует

if (во время выполнения системной функции поступило прерывание)

послать периферийному процессу сообщение о прерывании, сигнал;

else /* выполнение системной функции не прерывалось */

послать ответ: включить флаг, показывающий поступление сигнала;

Рисунок 13.7. Обработка сигналов в периферийной системе

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

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

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

3. Если по получении сигнала процесс-спутник прерывает выполнение системной функции (по longjmp), он информирует об этом периферийный процесс и сообщает ему номер сигнала.

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

Рисунок 13.8. Прерывание во время выполнения системной функции

Предположим, например, что периферийный процесс вызывает функцию чтения с терминала, связанного с центральным процессором, и приостанавливает свою работу на время выполнения функции процессом-спутником (Рисунок 13.8). Если пользователь нажимает клавишу прерывания (break), ядро ЦП посылает процессу-спутнику соответствующий сигнал. Если спутник находился в состоянии приостанова в ожидании ввода с терминала порции данных, он немедленно выходит из этого состояния и прекращает выполнение функции read. В своем ответе на запрос периферийного процесса спутник сообщает код ошибки и номер сигнала, соответствующий прерыванию. Периферийный процесс анализирует ответ и, поскольку в сообщении говорится о поступлении сигнала прерывания, отправляет сигнал самому себе. Перед выходом из функции read периферийное ядро осуществляет проверку поступления сигналов, обнаруживает сигнал прерывания, поступивший от процесса-спутника, и обрабатывает его обычным порядком. Если в результате получения сигнала прерывания периферийный процесс завершает свою работу с помощью функции exit, данная функция берет на себя заботу об уничтожении процесса-спутника. Если периферийный процесс перехватывает сигналы о прерывании, он вызывает пользовательскую функцию обработки сигналов и по выходе из функции read возвращает пользователю код ошибки. С другой стороны, если спутник исполняет от имени периферийного процесса системную функцию stat, он не будет прерывать ее выполнение при получении сигнала (функции stat гарантирован выход из любого приостанова, поскольку для нее время ожидания ресурса ограничено). Спутник доводит выполнение функции до конца и возвращает периферийному процессу номер сигнала. Периферийный процесс посылает сигнал самому себе и получает его на выходе из системной функции.

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

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

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

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

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

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

"sftig!/fs1/mjb/rje"

идентифицирует файл "/fs1/mjb/rje", находящийся на машине "sftig". Такая схема идентифицирования файла соответствует соглашению, установленному программой uucp относительно передачи файлов между системами типа UNIX. В другой схеме удаленные файлы идентифицируются добавлением к имени специального префикса, например:

/../sftig/fs1/mjb/rje

где "/../" - префикс, свидетельствующий о том, что файл удаленный; вторая компонента имени файла является именем удаленной машины. В данной схеме используется привычный синтаксис имен файлов в системе UNIX, поэтому в отличие от первой схемы здесь пользовательским программам нет необходимости приноравливаться к использованию имен, имеющих необычную конструкцию (см. ).

Рисунок 13.9. Формулирование запросов к файловому серверу (процессору)

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

open("/../sftig/fs1/mjb/rje/file", O_RDONLY);

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

Чтобы выполнять запросы клиента, спутник должен иметь на удаленной машине те же права доступа к файлам, что и клиент. Другими словами, пользователь "mjb" должен иметь и к удаленным, и к локальным файлам одинаковые права доступа. К сожалению, не исключена возможность того, что код идентификации клиента "mjb" может совпасть с кодом идентификации другого клиента удаленной машины. Таким образом, администраторам систем на работающих в сети машинах следует либо следить за назначением каждому пользователю кода идентификации, уникального для всей сети, либо в момент формулирования запроса на сетевое обслуживание выполнять преобразование кодов. Если это не будет сделано, процесс-спутник будет иметь на удаленной машине права другого клиента.

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

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

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

Когда процесс вызывает функцию fork, соответствующая библиотечная подпрограмма посылает сообщения каждому спутнику. Процессы - спутники выполняют операцию ветвления и посылают идентификаторы своих потомков клиенту-родителю. Процесс-клиент запускает системную функцию fork, которая передает управление порождаемому потомку; локальный потомок ведет диалог с удаленным потомком-спутником, адреса которого сохранила библиотечная подпрограмма. Такая трактовка функции fork облегчает процессам-спутникам контроль над открытыми файлами и текущими каталогами. Когда процесс, работающий с удаленными файлами, завершается (вызывая функцию exit), подпрограмма посылает сообщения всем его удаленным спутникам, чтобы они по получении сообщения проделали то же самое. Отдельные моменты реализации системных функций exec и exit затрагиваются в упражнениях.

Преимущество связи типа Newcastle состоит в том, что обращение процесса к удаленным файлам становится "прозрачным" (незаметным для пользователя), при этом в ядро системы никаких изменений вносить не нужно. Однако, данной разработке присущ и ряд недостатков. Прежде всего, при ее реализации возможно снижение производительности системы. В связи с использованием расширенной Си-библиотеки размер используемой каждым процессом памяти увеличивается, даже если процесс не обращается к удаленным файлам; библиотека дублирует функции ядра и требует для себя больше места в памяти. Увеличение размера процессов приводит к удлинению продолжительности периода запуска и может вызвать большую конкуренцию за ресурсы памяти, создавая условия для более частой выгрузки и подкачки задач. Локальные запросы будут исполняться медленнее из-за увеличения продолжительности каждого обращения к ядру, замедление может грозить и обработке удаленных запросов, затраты по пересылке которых по сети увеличиваются. Дополнительная обработка удаленных запросов на пользовательском уровне увеличивает количество переключений контекста, операций по выгрузке и подкачке процессов. Наконец, для того, чтобы обращаться к удаленным файлам, программы должны быть перекомпилированы с использованием новых библиотек; старые программы и поставленные объектные модули без этого работать с удаленными файлами не смогут. Все эти недостатки отсутствуют в системе, описываемой в следующем разделе.

Термин "прозрачное распределение" означает, что пользователи, работающие на одной машине, могут обращаться к файлам, находящимся на другой машине, не осознавая того, что тем самым они пересекают машинные границы, подобно тому, как на своей машине они при переходе от одной файловой системе к другой пересекают точки монтирования. Имена, по которым процессы обращаются к файлам, находящимся на удаленных машинах, похожи на имена локальных файлов: отличительные символы в них отсутствуют. В конфигурации, показанной на Рисунке 13.10, каталог "/usr/src", принадлежащий машине B, "вмонтирован" в каталог "/usr/src", принадлежащий машине A. Такая конфигурация представляется удобной в том случае, если в разных системах предполагается использовать один и тот же исходный код системы, традиционно находящийся в каталоге "/usr/src". Пользователи, работающие на машине A, могут обращаться к файлам, расположенным на машине B, используя привычный синтаксис написания имен файлов (например: "/usr/src/cmd/login.c"), и ядро уже само решает вопрос, является файл удаленным или же локальным. Пользователи, работающие на машине B, имеют доступ к своим локальным файлам (не подозревая о том, что к этим же файлам могут обращаться и пользователи машины A), но, в свою очередь, не имеют доступа к файлам, находящимся на машине A. Конечно, возможны и другие варианты, в частности, такие, в которых все удаленные системы монтируются в корне локальной системы, благодаря чему пользователи получают доступ ко всем файлам во всех системах.

Рисунок 13.10. Файловые системы после удаленного монтирования

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

Интересная проблема связана с именами путей, включающих "..". Если процесс делает текущим каталог из удаленной файловой системы, последующее использование в имени символов ".." скорее вернет процесс в локальную файловую систему, чем позволит обращаться к файлам, расположенным выше текущего каталога. Возвращаясь вновь к Рисунку 13.10, отметим, что когда процесс, принадлежащий машине A, выбрав предварительно в качестве текущего каталог "/usr/src/cmd", расположенный в удаленной файловой системе, исполнит команду

текущим каталогом станет корневой каталог, принадлежащий машине A, а не машине B. Алгоритм namei, работающий в ядре удаленной системы, получив последовательность символов "..", проверяет, является ли вызывающий процесс агентом процесса-клиента, и в случае положительного ответа устанавливает, трактует ли клиент текущий рабочий каталог в качестве корня удаленной файловой системы.

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

Рисунок 13.11. Открытие удаленного файла

Рассмотрим процесс, который открывает удаленный файл "/usr/src/cmd/login.c", где "src" - точка монтирования. Выполняя синтаксический разбор имени файла (по схеме namei-iget), ядро обнаруживает, что файл удаленный, и посылает на машину, где он находится, запрос на получение заблокированного индекса. Получив желаемый ответ, локальное ядро создает в памяти копию индекса, корреспондирующую с удаленным файлом. Затем ядро производит проверку наличия необходимых прав доступа к файлу (на чтение, например), послав на удаленную машину еще одно сообщение. Выполнение алгоритма open продолжается в полном соответствии с планом, приведенным в главе 5, с посылкой сообщений на удаленную машину по мере необходимости, до полного окончания алгоритма и освобождения индекса. Взаимосвязь между структурами данных ядра по завершении алгоритма open показана на Рисунке 13.11.

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

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

В случае с системной функцией open запрос на исполнение функции, посылаемый на удаленную машину, включает в себя часть имени файла, оставшуюся после исключения компонент имени пути поиска, отличающих удаленный файл, а также различные флаги. В рассмотренном ранее примере с открытием файла "/usr/src/cmd/login.c" ядро посылает на удаленную машину имя "cmd/login.c". Сообщение также включает в себя опознавательные данные, такие как пользовательский и групповой коды идентификации, необходимые для проверки прав доступа к файлам на удаленной машине. Если с удаленной машины поступает ответ, свидетельствующий об успешном выполнении функции open, локальное ядро выбирает свободный индекс в памяти локальной машины и помечает его как индекс удаленного файла, сохраняет информацию об удаленной машине и удаленном индексе и по заведенному порядку выделяет новую запись в таблице файлов. В сравнении с реальным индексом на удаленной машине индекс, принадлежащий локальной машине, является формальным, не нарушающим конфигурацию модели, которая в целом совпадает с конфигурацией, используемой при вызове удаленной процедуры (Рисунок 13.11). Если вызываемая процессом функция обращается к удаленному файлу по его дескриптору, локальное ядро узнает из индекса (локального) о том, что файл удаленный, формулирует запрос, включающий в себя вызываемую функцию, и посылает его на удаленную машину. В запросе содержится указатель на удаленный индекс, по которому процесс-спутник сможет идентифицировать сам удаленный файл.

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

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

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

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

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

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

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

Рисунок 13.12. Концептуальная схема взаимодействия с удаленными файлами на уровне ядра

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

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

*1. Опишите реализацию системной функции exit в системе с периферийными процессорами. В чем разница между этим случаем и тем, когда процесс завершает свою работу по получении неперехваченного сигнала? Каким образом ядру следует сохранить дамп содержимого памяти?

2. Процессы не могут игнорировать сигналы типа SIGKILL; объясните, что происходит в периферийной системе, когда процесс получает такой сигнал.

*3. Опишите реализацию системной функции exec в системе с периферийными процессорами.

*4. Каким образом центральному процессору следует производить распределение процессов между периферийными процессорами с тем, чтобы сбалансировать общую нагрузку?

*5. Что произойдет в том случае, если у периферийного процессора не окажется достаточно памяти для размещения всех выгруженных на него процессов? Каким образом должны производиться выгрузка и подкачка процессов в сети?

6. Рассмотрим систему, в которой запросы к удаленному файловому серверу посылаются в случае обнаружения в имени файла специального префикса. Пусть процесс вызывает функцию execl("/../sftig/bin/sh", "sh", 0); Исполняемый модуль находится на удаленной машине, но должен выполняться в локальной системе. Объясните, каким образом удаленный модуль переносится в локальную систему.

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

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

*9. Как показано в разделе 13.2, вызов системной функции exit в системах со связью типа Newcastle приводит к посылке сообщения процессу-спутнику, заставляющего последний завершить свою работу. Это делается на уровне библиотечных подпрограмм. Что происходит, когда локальный процесс получает сигнал, побуждающий его завершить свою работу в режиме ядра?

*10. Каким образом в системе со связью типа Newcastle, где удаленные файлы идентифицируются добавлением к имени специального префикса, пользователь может, указав в качестве компоненты имени файла ".." (родительский каталог), пересечь удаленную точку монтирования?

11. Из главы 7 нам известно о том, что различные сигналы побуждают процесс сбрасывать дамп содержимого памяти в текущий каталог. Что должно произойти в том случае, если текущим является каталог из удаленной файловой системы? Какой ответ вы дадите в том случае, если в системе используется связь типа Newcastle?

*12. Какие последствия для локальных процессов имело бы удаление из системы всех процессов-спутников или серверов?

*13. Подумайте над тем, как в "прозрачной" распределенной системе следует реализовать алгоритм link, параметрами которого могут быть два имени удаленных файлов, а также алгоритм exec, связанный с выполнением нескольких внутренних операций чтения. Рассмотрите две формы связи: вызов удаленной процедуры и вызов удаленной системной функции.

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

Рисунок 13.13. Конфигурация с терминальным сервером

*15. Когда пользователь регистрируется в системе, дисциплина терминальной линии сохраняет информацию о том, что терминал является операторским, ведущим группу процессов. По этой причине, когда пользователь на клавиатуре терминала нажимает клавишу "break", сигнал прерывания получают все процессы группы. Рассмотрим конфигурацию системы, в которой все терминалы физически подключаются к одной машине, но регистрация пользователей логически реализуется на других машинах (Рисунок 13.13). В каждом отдельном случае система создает для удаленного терминала getty-процесс. Если запросы к удаленной системе обрабатываются с помощью набора процессов-серверов, следует отметить, что при выполнении процедуры открытия сервер останавливается в ожидании подключения. Когда выполнение функции open завершается, сервер возвращается обратно в серверный пул, разрывая свою связь с терминалом. Каким образом осуществляется рассылка сигнала о прерывании, вызываемого нажатием клавиши "break", по адресам процессов, входящих в одну группу?

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

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

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

*19. Когда процесс обращается к удаленному файлу, не исключена возможность того, что в поисках файла процесс обойдет несколько машин. В качестве примера возьмем имя "/usr/src/uts/3b2/os", где "/usr" - каталог, принадлежащий машине A, "/usr/src" - точка монтирования корня машины B, "/usr/src/uts/3b2" - точка монтирования корня машины C. Проход через несколько машин к месту конечного назначения называется "мультискачком" (multihop). Однако, если между машинами A и C существует непосредственная сетевая связь, пересылка данных через машину B была бы неэффективной. Опишите особенности реализации "мультискачка" в системе со связью Newcastle и в "прозрачной" распределенной системе.

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

Начинают применяться на практике мобильные архитектуры. Это относится как к системам баз данных, так и к приложениям Web.

Возрождается подход к построению распределенных систем, основанный на одноранговой архитектуре (Peer-to-Peer), при котором, в отличие от доминирующей сегодня в распределенных системах архитектуры «клиент-сервер», роли взаимодействующих сторон в сети не фиксируются. Они назначаются в зависимости от ситуации в сети, от загруженности ее узлов.

В связи с интенсивным развитием коммуникационных технологий активно развиваются мобильные АИС. Разработаны технические средства и программное обеспечение для их создания. Благодаря этому стали развиваться мобильные системы баз данных. Многие научные коллективы проводят исследования специфических особенностей таких систем, создают разнообразные их прототипы. Важным инструментом для разработки мобильного программного обеспечения стали технологии Java.

Создан стандарт протокола беспроводного доступа приложений в Web (Wireless Application Protocol - WAP), который уже поддерживается некоторыми моделями сотовых телефонов. На основе WAP и языка XML консорциум W3C разработал язык разметки для беспроводных коммуникаций WML (Wireless Markup Language).

В разработках АИС больше внимания стали уделять метаданным. Здесь предпринимаются шаги в двух направлениях - стандартизация представления метаданных и обеспечение их поддержки в системе.

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

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

Вероятно, первым стандартом де-факто этой категории был язык описания данных CODASYL для баз данных сетевой структуры. Из более поздних стандартов следует назвать: стандарт языка запросов SQL для реляционных баз данных, содержащий определение так называемой информационной схемы - совокупности представлений схем реляционных баз данных; компонент стандарта объектных баз данных ODMG, описывающий интерфейсы репозитория объектных схем; международный стандарт IRDS (Information Resource Dictionary Systems), описывающий системы для создания и поддержки справочников информационных ресурсов организации.

Далее следует упомянуть разработанный консорциумом OMG стандарт CWM (Common Warehouse Metamodel) представления метаданных хранилищ данных, основанный на ранее созданном для более широких целей стандарте OIM (Open Information Model) консорциума MDC (Meta Data Coalition).

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

К числу стандартов метаданных Web относится подмножество языка XML, используемое для описания логической структуры XML-документов некоторого типа. Это описание называется DTD (Document Type Definition). Кроме того, платформа XML включает стандарт XML Schema, предлагающий более развитые возможности для описания XML-документов. Стандарт RDF (Resource Definition Framework) определяет простой язык представления знаний для описания содержимого XML-документов. Наконец, разрабатываемый стандарт OWL (Ontology Web Language) определяет формальный язык описания онтологии, предназначенный для семантического Web.

Стандарт языка UML (Unified Modeling Language), обеспечивающий представление метаданных инструментов CASE для визуального объектного анализа и проектирования, разработан консорциумом OMG. Этот язык поддерживается во многих программных продуктах CASE. Консорциум OMG создал также стандарт XMI (XML Metadata Interchange) для обмена метаданными между инструментами CASE, использующими язык UML.

Следует упомянуть здесь также стандарт Дублинского ядра (Dublin Core - DC) - набора элементов метаданных для описания содержания документов различной природы. Этот стандарт быстро приобрел популярность и нашел, в частности, широкое применение в среде Web (см. разд. 3.3).

Работы по развитию существующих и созданию новых стандартов представления метаданных для АИС продолжаются. Более подробные сведения о рассматриваемых стандартах можно найти в энциклопедии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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