 |
Архитектура распределенных информационных ресурсов. Модели и структура информационных ресурсов.
|
|
|
|
См. вопрос 6
13. Корпоративная информационная система — это совокупность технических и программных средств предприятия, реализующих идеи и методы автоматизации. Человеко-машинная система. По второй части см. вопрос 11.
Открытая информационная система - это система, которая состоит из компонентов, взаимодействующих друг с другом через стандартные интерфейсы. Исчерпывающий и согласованный набор международных стандартов информационных технологий и профилей функциональных стандартов, которые специфицируют интерфейсы, службы и поддерживающие форматы, чтобы обеспечить мобильность приложений, данных и персонала. Архитектура информационной сети - концепция, определяющая основные элементы информационной сети, характер и топологию взаимодействия этих элементов, и представляющая логическую, функциональную и физическую организацию технических и программных средств сети. Информационная сеть предназначена для хранения информации и состоит из информационных систем. На базе коммуникационной сети может быть построена группа информационных сетей. Сеть может быть построена по одной из трех схем: сеть на основе одноранговых узлов – одноранговая сеть; сеть на основе клиентов и серверов – сеть с выделенными серверами; сеть, включающая узлы всех типов – гибридная сеть.
Архитектура распределенных информационных ресурсов. Модели и структура информационных ресурсов.
В последние 2-3 года резко возрос интерес к так называемым распределенным системам. Под распределенными системами обычно понимают программные комплексы, составные части которых функционируют на разных компьютерах в сети. Эти части взаимодействуют друг с другом, используя ту или иную технологию различного уровня - от непосредственного использования сокетов TCP/IP до технологий с высоким уровнем абстракции, таких, как RMI или CORBA.
|
|
|
Рост популярности распределенных систем вызван существенным ужесточением требований, предъявляемых заказчиком к современным программным продуктам. Пожалуй, важнейшими из этих требований являются следующие:
· Обеспечение масштабируемости систем, т.е. способности эффективно обслуживать как малое, так и очень большое количество клиентов одновременно.
· Надежность создаваемых приложений. Программный комплекс должен быть устойчив не только к ошибкам пользователей (это определяется главным образом качеством клиентских приложений), но и к сбоям в системе коммуникаций. Надежность подразумевает использование транзакций, т.е. гарантированного перехода системы в процессе функционирования из одного устойчивого и достоверного состояния в другое.
· Возможность непрерывной работы в течение длительного времени (так называемый режим 24x7, т.е. режим круглосуточной работы в течение недель и месяцев).
· Высокий уровень безопасности системы, под которой понимается не только контроль доступности тех или иных ресурсов системы и защищенность информации на всех этапах функционирования, но и отслеживание выполняемых действий с высокой степенью достоверности.
· Высокая скорость разработки приложений и простота их сопровождения и модификации с использованием программистов средней квалификации.
Оказалось, что обеспечить соответствие этим требованиям, используя традиционные технологии - а именно, двухзвенные системы “клиент-сервер”, в которых в качестве серверов выступают системы управления базами данных, почти невозможно.
Заметим, что далеко не для всех приложений вышеперечисленные требования являются существенными. Легко представить распределенную систему, которая функционирует на небольшом (до 100) количестве компьютеров, работающих в локальной сети, где нет проблем с перезапуском одного или двух-трех серверов в случае необходимости, а главными задачами, для решения которых используются распределенные технологии, являются задачи использования функциональности нескольких стандартных серверов приложений (например, текстовых процессоров, броузеров и электронных таблиц) в интересах клиентских задач. Необходимо иметь в виду, что термин “распределенные системы” относится к огромному числу задач самого разного класса.
|
|
|
Причины построении распределенной системы. Приведем некоторые из них:
· Размещение часто используемых данных ближе к клиенту, что позволяет минимизировать сетевой трафик.
· Расположение часто меняющихся данных в одном месте, обеспечивающее минимизацию затрат по синхронизации копий данных.
· Увеличение надежности комплекса к единичным отказам серверов (горячее резервирование).
· Понижение стоимости системы за счет использования группы небольших серверов вместо одного мощного центрального сервера.
Если в информационной системе наличествуют все перечисленные факторы, то распределенная база данных может оказаться хорошим решением. Часто распределение базы данных изначально определяется требованиями бизнеса, например когда объединяется информация нескольких крупных подразделений одной компании и требуется постоянный обмен данными между филиалами.
Решение о распределенной базе данных оправданно и для систем, где есть четко выраженные группа меняющихся данных и группа устойчивых данных, по которым выполняются отчеты. Тогда в самом простом варианте работают два сервера: один обслуживает часто меняющиеся данные — это, как правило, OLTP (On-Line Transaction Processing. — Прим. ред.), второй — отчеты, то есть DSS (Decision Support System. — Прим. ред.). Ряд СУБД не очень хорошо совмещает обработку OLTP- и DSS-потоков запросов, поскольку для этих двух типов потоков запросов оптимальные параметры конфигурации серверов будут различаться. Решение такой базы данных как распределенной может оказаться более выгодным.
Преимущества создания распределенной системы имеют свою цену — должны быть обеспечены:
|
|
|
· Непротиворечивость данных, независимо от того, какой клиент к какому серверу обратился.
· Производительность распределенной базы данных должна удовлетворять требованиям заказчика, а это может оказаться более сложной задачей, чем в случае централизованной базы данных.
· Надежность распределенной базы данных не должна уступать надежности централизованной базы данных.
Современные СУБД позволяют осуществлять запрос данных, находящихся на разных узлах распределенной сети в одном SQL-запросе. Прозрачность доступа СУБД также обеспечивают — в каких-то реализациях хуже, в каких-то лучше. Одна из самых распространенных проблем — более сложная обработка транзакций. Практически все промышленные реализации поддерживают только двухфазную фиксацию транзакций, а в этом режиме не все типы отказов разрешимы. Распределенный deadlock (взаимоблокировка. — Прим. ред.) также может представлять значительную проблему, и большинство реализаций используют только таймауты для его детектирования.
Как бы то ни было, стратегия распределения данных должна определяться не политикой предприятия (что обычно пытается навязать руководство), а требованиями надежности и производительности системы. При построении распределенной базы данных следует уделить особое внимание проектированию топологии сети. Узлы распределенной базы данных должны быть соединены скоростными надежными линями связи. Это же касается линий соединения узлов базы данных и серверов приложений. Наличие низкоскоростного и ненадежного канала связи между узлами распределенной базы данных резко повышает количество детектируемых отказов сети.
· В распределенной базе данных могут быть использованы следующие типы вызовов:
· Удаленные DDL- и DML- операции, а также выборка данных.
· Синхронные удаленные вызовы процедур.
· Асинхронные удаленные вызовы процедур.
· Непротиворечивые снимки.
· Асинхронная симметричная репликация.
· Синхронная симметричная репликация.
· Вызов распределенного запроса (запрашивает данные на чтение и модификацию с нескольких узлов).
|
|
|
Распределенная база данных может обеспечить горизонтальную фрагментацию; например, в филиале чаще всего используют данные о клиентах, находящихся в городе N (CLIENT_PLACE = ‘N’). В этом случае на узле распределенной базы данных этого филиала может быть расположен фрагмент таблицы данных, выделенный согласно условию CLIENT_PLACE = ‘N’.
Стратегия распределения данных для каждой СУБД определяется по-своему и достойна отдельной книги. Определение стратегии преследует две цели: сократить нагрузку на сеть и сервер и/или повысить уровень готовности данных.
Следует отметить, что проектировщики должны четко представлять себе особенности реализации распределенной базы данных используемой СУБД. Не владеющий этой информацией проектировщик рискует создать нерабочую или плохо работающую схему, причем проявится это даже не на моделях, а в реальной эксплуатации. Если вы решили строить распределенную базу данных, позаботьтесь о наличии в штате квалифицированного администратора. Есть одно простое правило: проектировщик не может принять окончательного решения об определении стратегии распределения данных без администратора баз данных. Редко встречаются проектировщики, которые имеют практический опыт администрирования 2-3 серверов баз данных и которые реально работали на них с распределенными базами данных. Для каждой СУБД принципы, влияющие на детали распределения базы данных, индивидуальны.
Особый интерес представляет неоднородная распределенная база данных. Это то, что постоянно, но безуспешно пытаются изживать и проектировщики, и администраторы баз данных. Никто не любит иметь дело со шлюзами данных. Но если неоднородной распределенной базы избежать не удалось, уделите особое внимание выбору шлюзов данных, а также ПО, обеспечивающему синхронизацию информации базах данных под управлением разных СУБД. Если синхронизация данных на узлах под управлением одной СУБД может быть обеспечена самой СУБД (что реализуется большинством производителей), то синхронизация данных на узлах под управлением разных СУБД обеспечивается, как правило, специальным ПО. Тщательно оцените, что будет дешевле: использовать это ПО или импортировать данные и схему и сделать распределенную базу данных однородной.
Следует также отметить, что в подавляющем большинстве реализаций каждый из узлов распределенной базы данных может обслуживаться параллельным сервером баз данных, и это является важным критерием повышения производительности системы. Промышленные СУБД также используют параллельный доступ к хранилищам данных; RAID, например, могут размещать данные, используя не файловую систему операционной системы, а свою файловую систему. Реализация всех этих возможностей существенно различается у различных СУБД. Это означает, что выбор параллельного сервера баз данных должен осуществляться только после серьезных консультаций с администраторами тех СУБД, которые рассматриваются как возможные претенденты на роль сервера баз данных в проекте.
|
|
|
Метод распределения данных по дискам для поддержки параллельных вычислений во многом зависит и от особенностей реализации СУБД. Администратор базы данных не может выбрать такой метод в отрыве от особенностей конкретной информационной системы. Еще одна возможность параллельной обработки данных, предоставляемая СУБД: обработка одного запроса несколькими менеджерами ресурсов. В реализациях также имеется возможность использования одного хранилища данных несколькими серверами баз данных (Parallel Server). Такая архитектура может быть эффективно использована на кластерах.
16. Интеграция меняющихся Технологических Платформ. При создании ТП имеет место инновационный поход. Сегодня, вектор развития нашей промышленности является поступательным. Между текущим состоянием промышленности и науки и условиями необходимыми для успешного создания ТП существует значительный разрыв. ТП способны обеспечить серьезный скачек в нашем экономическом и общественном развитии. Этапы внедрения: Этап 1 — Перспективный облик сектора на долгосрочную перспективу ( Оценка ключевых вызовов; Определение стратегических целей и возможных путей технологической модернизации; Временные рамки; Оценка научно-технологического потенциала; Возможная «повестка» для проведения исследований и разработок ). Этап 2 — Стратегическая программа исследований ( Определение приоритетов в проведении НИОКР, основных потенциальных участнико в; Выстраивание научной кооперации, определение возможных консорциумов; Определение необходимых направлений развития научной инфраструктуры; Формирование программ обучения; Определение направлений и принципов развития стандартов, системы сертификации; Оценка необходимого финансирования ). Этап 3 — План внедрения стратегической программы исследований ( Определение различных возможных источников финансирования; Создание организационной структуры для мониторинга прогресса и проблем,уточнения необходимых направлений исследований и разработок; Определение инструментов взаимодействия в определении приоритетов и обменедостигнутыми результатами; Определение «дорожной карты»; Генерация постоянно-уточняемого «портфеля проектов», подчиненная решениюстратегических задач с учетом ресурсных «рамок».
|
|
|
