Управляемая распределенная архитектура. Архитектура распределенной системы управления на основе реконфигурируемой многоконвейерной вычислительной среды L-Net

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Принципы создания системы обработки информации в масштабе предприятия

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

Рис. 1. Схема распределенных вычислений

Однако практическая реализация идеи соединения компьютеров в кластеры и сети тормозилась отсутствием технических решений и в первую очередь необходимостью создания стандартов и протоколов взаимодействия. Как известно, первые ЭВМ появились в конце сороковых годов двадцатого века, а первая компьютерная сеть ARPANet, связавшая несколько компьютеров на территории США, - только в 1966 г., почти через двадцать лет. Конечно, такое объединение вычислительных возможностей современную распределенную архитектуру напоминало весьма отдаленно, но тем не менее это был первый шажок в верном направлении.

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

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

Именно в этот период стало очевидно, что основными преимуществами распределенных приложений являются:

· хорошая масштабируемость - при необходимости вычислительная мощность распределенного приложения может быть легко увеличена без изменения его структуры;

· возможность управления нагрузкой - промежуточные уровни распределенного приложения дают возможность управлять потоками запросов пользователей и перенаправлять их менее загруженным серверам для обработки;

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

Шло время, и небольшие островки университетских, правительственных и корпоративных сетей расширялись, объединялись в региональные и национальные системы. И вот на сцене появился главный игрок - Internet.

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

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

Парадигма распределенных вычислений

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

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

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

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

Пространственное разделение. Подразделения организации разнесены в пространстве и зачастую имеют слабо унифицированное программное обеспечение.

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

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

Всем перечисленным требованиям к программному обеспечению масштаба предприятия отвечают распределенные системы - схема распределения вычислений приведена на рис. 1.

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

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

Распределенные вычислительные системы обладают такими общими свойствами, как:

· управляемость - подразумевает способность системы эффективно контролировать свои составные части. Это достигается благодаря использованию управляющего ПО;

· производительность - обеспечивается за счет возможности перераспределения нагрузки на серверы системы с помощью управляющего ПО;

· масштабируемость - при необходимости физического повышения производительности распределенная система может легко интегрировать в своей транспортной среде новые вычислительные ресурсы;

· расширяемость - к распределенным приложениям можно добавлять новые составные части (серверное ПО) с новыми функциями.

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

Рис. 2. Основные уровни архитектуры распределенного приложения

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

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

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

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

· представление данных (пользовательский уровень). Здесь пользователи приложения могут просмотреть необходимые данные, отправить на выполнение запрос, ввести в систему новые данные или отредактировать их;

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

· хранение данных (уровень данных). Это уровень серверов баз данных. Здесь расположены сами серверы, базы данных, средства доступа к данным, различные вспомогательные инструменты.

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

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

Рис. 3. Распределение бизнес-логики по уровням распределенного приложения

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

Таким образом, можно выделить четыре основных уровня распределенной архитектуры (см. рис. 2):

· представление данных (пользовательский уровень);

· правила бизнес-логики (уровень обработки данных);

· управление данными (уровень управления данными);

· хранение данных (уровень хранения данных).

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

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

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

Физическая структура распределенных приложений

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

Распределение бизнес-логики по уровням распределенного приложения

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

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

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

Уровень же обработки данных собственно и предназначен для реализации бизнес-логики приложения, и здесь сконцентрированы все основные правила обработки данных.

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

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

Уровень представления данных

Уровень представления данных - единственный доступный конечному пользователю. Этот уровень моделирует клиентские рабочие места распределенного приложения и соответствующее ПО. Возможности клиентского рабочего места в первую очередь определяются возможностями операционной системы. В зависимости от типа пользовательского интерфейса клиентское ПО делится на две группы: клиенты, использующие возможности ГИП (например, Windows), и Web-клиенты. Но в любом случае клиентское приложение должно обеспечивать выполнение следующих функций:

· получение данных;

· представление данных для просмотра пользователем;

· редактирование данных;

· проверка корректности введенных данных;

· сохранение сделанных изменений;

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

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

Уровень обработки данных

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

· обработка потоков данных в соответствии с бизнес-правилами;

· взаимодействие с уровнем представления данных для получения запросов и возвращения ответов;

· взаимодействие с уровнем хранения данных для передачи запросов и получения ответов.

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

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

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

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

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

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

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

Итак, к функциям уровня управления данными относятся:

· управление частями распределенного приложения;

· управление соединениями и каналами связи между частями приложения;

· управление потоками данных между клиентами и серверами и между серверами;

· управление нагрузкой;

· реализация системных служб приложения.

Необходимо отметить, что часто уровень управления данными создается на основе готовых решений, поставляемых на рынок программного обеспечения различными производителями. Если разработчики выбрали для своего приложения архитектуру CORBA, то в ее составе имеется брокер объектных запросов (Object Request Broker, ORB), если платформу Windows, - к их услугам разнообразные инструменты: технология COM+ (развитие технологии Microsoft Transaction Server, MTS), технология обработки очередей сообщений MSMQ, технология Microsoft BizTalk и др.

Уровень хранения данных

Уровень хранения данных объединяет серверы SQL и базы данных, используемые приложением. Он обеспечивает решение следующих задач:

· хранение данных в БД и поддержание их в работоспособном состоянии;

· обработка запросов уровня обработки данных и возврат результатов;

· реализация части бизнес-логики распределенного приложения;

· управление распределенными базами данных при помощи административного инструментария серверов БД.

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

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

Подключение к базам данных серверов SQL осуществляется в основном при помощи клиентского ПО серверов. Помимо этого дополнительно могут использоваться различные технологии доступа к данным, например ADO (ActiveX Data Objects) или ADO.NET. Но при проектировании системы необходимо учитывать, что функционально промежуточные технологии доступа к данным не относятся к уровню хранения данных.

Расширения базовых уровней

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

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

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

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

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

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

При реализации приложений на платформе Windows чаще всего используется технология доступа к данным ADO, так как она обеспечивает универсальный способ доступа к самым разнообразным источникам данных - от серверов SQL до электронных таблиц. Для приложений на платформе.NET служит технология ADO.NET.

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

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

1.1 Принципы построения распределенных веб-систем

Что именно означает создание и управление масштабируемым веб-сайтом или приложением? На примитивном уровне это просто соединение пользователей с удаленными ресурсами через Интернет. А ресурсы или доступ к этим ресурсам, которые рассредоточены на множестве серверов и являются звеном, обеспечивающим масштабируемость веб-сайта.

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

• Доступность: длительность работоспособного состояния веб-сайта критически важна по отношению к репутации и функциональности многих компаний. Для некоторых более крупных онлайновых розничных магазинов, недоступность даже в течение нескольких минут может привести к тысячам или миллионам долларов потерянного дохода. Таким образом, разработка их постоянно доступных и эластичных к отказу систем и является и фундаментальным деловым и технологическим требованием. Высокая доступность в распределенных системах требует внимательного рассмотрения избыточности для ключевых компонентов, быстрого восстановления после частичных системных отказов и сглаженного сокращения возможностей при возникновении проблем.
• Производительность: Производительность веб-сайта стала важным показателем для большинства сайтов. Скорость веб-сайта влияет на работу и удовлетворенность пользователей, а также ранжирование поисковыми системами - фактор, который непосредственно влияет на удержание аудитории и доход. В результате, ключом является создание системы, которая оптимизирована для быстрых ответов и низких задержек.
• Надежность: система должна быть надежной, таким образом, чтобы определенный запрос на получение данных единообразно возвращал определенные данные. В случае изменения данных или обновления, то тот же запрос должен возвращать новые данные. Пользователи должны знать, если что-то записано в систему или храниться в ней, то можно быть уверенным, что оно будет оставаться на своем месте для возможности извлечения данных впоследствии.
• Масштабируемость: Когда дело доходит до любой крупной распределенной системы, размер оказывается всего лишь одним пунктом из целого списка, который необходимо учитывать. Не менее важным являются усилия, направленные на увеличение пропускной способности для обработки больших объемов нагрузки, которая обычно и именуется масштабируемость системы. Масштабируемость может относиться к различным параметрам системы: количество дополнительного трафика, с которым она может справиться, насколько легко нарастить ёмкость запоминающего устройства, или насколько больше других транзакций может быть обработано.
• Управляемость: проектирование системы, которая проста в эксплуатации еще один важный фактор. Управляемость системы приравнивается к масштабируемости операций «обслуживание" и «обновления». Для обеспечения управляемости необходимо рассмотреть вопросы простоты диагностики и понимания возникающих проблем, легкости проведения обновлений или модификации, прихотливости системы в эксплуатации. (То есть, работает ли она как положено без отказов или исключений?)
• Стоимость: Стоимость является важным фактором. Она, очевидно, может включать в себя расходы на аппаратное и программное обеспечение, однако важно также рассматривать другие аспекты, необходимые для развертывания и поддержания системы. Количество времени разработчиков, требуемое для построения системы, объем оперативных усилий, необходимые для запуска системы, и даже достаточный уровень обучения - все должно быть предусмотрено. Стоимость представляет собой общую стоимость владения.

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

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

1.2 Основы

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

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

Пример: Приложение хостинга изображений

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

Вообразите систему, где пользователи имеют возможность загрузить свои изображения на центральный сервер, и при этом изображения могут запрашиваться через ссылку на сайт или API, аналогично Flickr или Picasa. Для упрощения описания давайте предположим, что у этого приложения есть две основные задачи: возможность загружать (записывать) изображения на сервер и запрашивать изображения. Безусловно, эффективная загрузка является важным критерием, однако приоритетом будет быстрая доставка по запросу пользователей (например, изображения могут быть запрошены для отображения на веб-странице или другим приложением). Эта функциональность аналогична той, которую может обеспечить веб-сервер или граничный сервер Сети доставки контента (Content Delivery Network, CDN). Сервер CDN обычно хранит объекты данных во многих расположениях, таким образом, их географическое/физическое размещение оказывается ближе к пользователям, что приводит к росту производительности.

Другие важные аспекты системы:

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

Другая потенциальная проблема с этим дизайном состоит в том, что у веб-сервера, такого как Apache или lighttpd обычно существует верхний предел количества одновременных соединений, которые он в состоянии обслужить (значение по умолчанию - приблизительно 500, но оно может быть намного выше), и при высоком трафике записи могут быстро израсходовать этот предел. Так как чтения могут быть асинхронными или использовать в своих интересах другую оптимизацию производительности как gzip-сжатие или передача с делением на порции, веб-сервер может переключить чтения подачи быстрее и переключиться между клиентами, обслуживая гораздо больше запросов, чем максимальное число соединений (с Apache и максимальным количеством соединений, установленном в 500, вполне реально обслуживать несколько тысяч запросов чтения в секунду). Записи, с другой стороны, имеют тенденцию поддерживать открытое соединение на протяжении всего времени загрузки. Так передача файла размером 1 МБ на сервер могла занять больше 1 секунды в большинстве домашних сетей, в результате веб-сервер сможет обработать только 500 таких одновременных записей.

Рисунок 1.2: Разделение чтения и записи

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

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

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

К примеру, Flickr решает эту проблему чтения-записи, распределяя пользователи между разными модулями, таким образом, что каждый модуль может обслуживать только ограниченное число определенных пользователей, и когда количество пользователи увеличиваются, больше модулей добавляется к кластеру (см. презентацию масштабирования Flickr,
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html). В первом примере проще масштабировать аппаратные средства на основе фактической нагрузки использования (число чтений и записей во всей системе), тогда как масштабировние Flickr просиходит на основе базы пользователей(однако, здесь используется предположение равномерного использования у разных пользователей, таким образом, мощность нужно планировать с запасом). В прошлом недоступность или проблема с одной из служб приводили в нерабочее состояние функциональность целой системы (например, никто не может записать файлы), тогда недоступность одного из модулей Flickr будет влиять только на пользователей, относящихся к нему. В первом примере проще выполнить операции с целым набором данных - например, обновляя службу записи, чтобы включить новые метаданные, или выполняя поиск по всем метаданным изображений - тогда как с архитектурой Flickr каждый модуль должен был быть подвергнут обновлению или поиску (или поисковая служба должна быть создана, чтобы сортировать те метаданные, которые фактически для этого и предназначены).

Что касается этих систем - не существует никакой панацеи, но всегда следует исходить из принципов, описанных в начале этой главы: определить системные потребности (нагрузка операциями «чтения» или «записи» или всем сразу, уровень параллелизма, запросы по наборам данных, диапазоны, сортировки, и т.д.), провести сравнительное эталонное тестирование различных альтернатив, понять условия потенциального сбоя системы и разработать комплексный план на случай возникновения отказа.

Избыточность

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

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

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

.

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

.

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

Рисунок 1.3: Приложение хостинга изображений с избыточностью

Сегментирование

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

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

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

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

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

Рисунок 1.4: Приложение хостинга изображений с избыточностью и сегментированием

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

Другая потенциальная проблема возникает в форме
несогласованности (неконсистетности) .Когда различные сервисы выполняют считывание и запись на совместно используемом ресурсе, потенциально другой службе или хранилище данных, существует возможность возникновения условий «состязания» - где некоторые данные считаются обновленными до актуального состояния, но в реальности их считывание происходит до момента актуализации - и таком случае данные неконсистентны. Например, в сценарии хостинга изображений, состояние состязания могло бы возникнуть в случае, если бы один клиент отправил запрос обновления изображения собаки с изменением заголовка «Собака» на «Гизмо», в тот момент, когда другой клиент считывал изображение. В такой ситуации неясно, какой именно заголовок, «Собака» или «Гизмо», был бы получен вторым клиентом.

.

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

1.3. Структурные компоненты быстрого и масштабируемого доступа к данным

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

Самые простые веб-приложения, например, приложения стека LAMP, схожи с изображением на .

Рисунок 1.5: Простые веб-приложения

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

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

Рисунок 1.6: Упрощенное веб-приложение

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

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

Рисунок 1.7: Доступ к определенным данным

Это особенно трудно, потому что загрузка терабайтов данных в память может быть очень накладной и непосредственно влияет на количество дисковых операций ввода-вывода. Скорость чтения с диска в несколько раз ниже скорости чтения из оперативной памяти - можно сказать, что доступ к памяти с так же быстр, как Чак Норрис, тогда как доступ к диску медленнее очереди в поликлинике. Эта разность в скорости особенно ощутима для больших наборов данных; в сухих цифрах доступ к памяти 6 раз быстрее, чем чтение с диска для последовательных операций чтения, и в 100,000 раз - для чтений в случайном порядке (см. «Патологии Больших Данных», http://queue.acm.org/detail.cfm?id=1563874).). Кроме того, даже с уникальными идентификаторами, решение проблемы нахождения местонахождения небольшой порции данных может быть такой же трудной задачей, как и попытка не глядя вытащить последнюю конфету с шоколадной начинкой из коробки с сотней других конфет.

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

Кэши

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

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

Рисунок 1.8: Размещение кэша на узле уровня запроса

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

Рисунок 1.9: Системы кэшей

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

Глобальный кэш

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

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

Рисунок 1.10: Глобальный кэш, где кэш ответственен за извлечение

Рисунок 1.11: Глобальный кэш, где узлы запроса ответственны за извлечение

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

Распределенный кэш

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

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

Рисунок 1.17: Многоуровневые индексы

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

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

Инвертированный индекс, который может отобразить Index1 в схеме выше, будет выглядеть примерно так: каждое слово или набор слов служат индексом для тех книг, которые их содержат.

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

И это ключевой момент в крупномасштабных системах, потому что даже будучи сжатыми, эти индексы могут быть довольно большими и затратными для хранения. Предположим, что у нас есть много книг со всего мира в этой системе, - 100,000,000 (см. запись блога «Внутри Google Books»)- и что каждая книга состоит только из 10 страниц (в целях упрощения расчетов) с 250 словами на одной странице: это суммарно дает нам 250 миллиардов слов. Если мы принимаем среднее число символов в слове за 5, и каждый символ закодируем 8 битами (или 1 байтом, даже при том, что некоторые символы на самом деле занимают 2 байта), потратив, таким образом, по 5 байтов на слово, то индекс, содержащий каждое слово только один раз, потребует хранилище емкостью более 1 терабайта. Таким образом, вы видите, что индексы, в которых есть еще и другая информация, такая, как наборы слов, местоположение данных и количества употреблений, могут расти в объемах очень быстро.

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

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

Балансировщики нагрузки

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

Рисунок 1.18: Балансировщик нагрузки

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

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

Рисунок 1.19: Множественные балансировщики нагрузки

Как и прокси, некоторые балансировщики нагрузки могут также направлять запросы по-разному, в зависимости от типа запроса. Они также известны как реверсивные (обратные) прокси.

Управление данными, специфичными для определенного сеанса пользователя, является одной из проблем при использовании балансировщиков нагрузок. На сайте электронной коммерции, когда у Вас есть только один клиент, очень просто позволить пользователям помещать вещи в свою корзину и сохранять ее содержимое между визитами (это важно, так как вероятность продажи товара значительно возрастает, если по возвращении пользователя на сайт, продукт все еще находится в его корзине). Однако если пользователь направлен к одному узлу для первого сеанса, и затем к другому узлу во время его следующего посещения, то могут возникать несоответствия, так как новый узел может не иметь данных относительно содержимого корзины этого пользователя. (Разве вы не расстроитесь, если поместите упаковку напитка Mountain Dew в Вашу корзину, и, когда вернетесь, ее там уже не будет?) Одно из решений может состоять в том, чтобы сделать сеансы «липкими», так чтобы пользователь был всегда направлен к тому же узлу. Однако использование в своих интересах некоторых функций надежности, таких как автоматическая отказоустойчивость, будет существенно затруднено. В этом случае корзина пользователя всегда будет иметь содержание, но если их липкий узел станет недоступным, то будет необходим особый подход, и предположение о содержании корзины не будет больше верно (хотя, стоит надеяться, что это предположение не будет встроено в приложение). Конечно, данную проблему можно решить при помощи других стратегий и инструментов, как описанных в этой главе, таких как службы, так и многих других (как кэши браузера, cookie и перезапись URL).

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

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

Очереди

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

Рисунок 1.20: Синхронный запрос

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

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

Рисунок 1.21: Использование очередей для управления запросами

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

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

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

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

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

Начинают применяться на практике мобильные архитектуры. Это относится как к системам баз данных, так и к приложениям 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).

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

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

Вконтакте