63425

РАСПРЕДЕЛЕННЫЕ БД

Лекция

Информатика, кибернетика и программирование

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

Русский

2014-06-20

325.5 KB

1 чел.

PAGE  237


EMBED Word.Picture.8

EMBED Word.Picture.8

EMBED Word.Picture.8

  1.  

XI. РАСПРЕДЕЛЕННЫЕ БД

Развитие централизованных и распределенных БД

Распределенные БД - веяние времени

Требования к реализации распределенных вычислений

Проектные решения по созданию распределенных БД

Пример реализации распределенных систем

Развитие централизованных и распределенных БД

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

Рисунок 1 - Развитие архитектуры компьютерных систем [1]

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

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

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

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

По мере роста производительности процессоров и неизбежного усложнения программного обеспечения самостоятельная эксплуатация компьютера становится все сложнее и дороже. А когда стоимость программного обеспечения, необходимого для ведения бизнеса, достигла сотен тысяч долларов, возникли идеи об аренде программного обеспечения. Так, компания Oracle предоставляет свою продукцию на основе аренды СУБД и иных приложений через Интернет. Технология Application Service Provision позволяет использовать сложное программное обеспечение и хранить свои данные не на серверах локальной сети компании и не на рабочих станциях пользователей, а в центрах обработки данных. Они похожи на предприятия, которые четверть века назад назывались вычислительными центрами коллективного пользования. Аренда программных средств снижает уровень контроля пользователя за используемыми ресурсами (программными продуктами, данными, оборудованием).

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

Основными решениями здесь являются – разработка сервисов типа SaaS, интеграция данных.

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

Распределенные БД могут объединить региональные, национальные и даже международные информационные ресурсы.

У централизованной системы можно выделить следующие недостатки и проблемы:

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

Распределенные БД - веяние времени

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

  •  данные хранятся на физически различных серверах;
  •  существует возможность поиска данных одновременно на всех серверах;
  •  имеются средства извлечения (фильтрации) и визуализации найденной информации.

Это минимальные требования, без выполнения которых БД нельзя считать распределенной.

К характеристикам БД можно отнести следующее:

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

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

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

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

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

Использование неоднородных СУБД на разных компьютерах требует создания общего пользовательского интерфейса, за которым находятся разные модели данных.

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

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

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

Положительными моментами распределенного подхода организации БД являются:

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

Применение распределенного подхода обеспечивает следующие преимущества.

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

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

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

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

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

Есть проблемы и у распределенных БД:

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

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

Среди основных направлений использования распределенных БД можно выделить:

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

Корпоративная виртуализированная вычислительная среда масштаба предприятия, должна обеспечивать автоматическое распределение нагрузки по всем доступным серверным мощностям и предоставление пользователям ресурсов по требованию. Здесь могут применяться GRID системы [4]. Концепция GRID системы базируется на разработанных средствах кластеризации и реализуется в исключительно однородной среде. Этот подход позволяет динамически выделять/забирать информационные ресурсы для решения задач предприятия, минимизировать перемещение данных между узлами, упростить администрирование систем.

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

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

Выделяются три типа GRID-проектов:

  •  GRID на основе использования добровольно предоставляемых свободных ресурсов;
  •  научная GRID;
  •  GRID на основе выделения ресурсов по требованию.

Существует четыре типа GRID-инфраструктур:

  •  вычислительные среды - появились в начале 90-х годов для использования «спящих» вычислительных ресурсов;
  •  информационные среды - появились в 2000 году как средство обмена аудиофайлами;
  •  сервисные среды, основанные на Web-сервисах);
  •  интеллектуальные среды - сочетают соединение узлов с возможностью управления системными и сетевыми ресурсами, а также ресурсами систем хранения.

Применение концепции GRID позволяет задействовать имеющиеся, но не используемые ресурсы, динамически управляя емкостью, пропускной способностью и вычислительной мощностью множества разрозненных компьютеров. В GRID каждое приложение использует свой набор компьютеров (например, несколько компьютеров – сервера БД; другие компьютеры – сервера приложений и т.д.). С единого пульта можно добавить или удалить компьютеры в/из пула серверов, переместить часть компьютеров серверов приложений в пул серверов и т д. Можно увеличить мощность тех пулов, у которых сейчас нагрузка максимальна.

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

Одновременно с GRID-системами развивается другое направление, связанное с распределенными БД, - «облачные технологии». Они могут быть реализованы в виде [2]:

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

«Облака» это набор технологий. Он представляет собой комбинацию современных технологий (вычисления в grid-сетях, вычисления как коммунальная услуга, “программное обеспечение как сервис”, онлайновое хранение данных), предназначенных для реализации новой парадигмы предоставления ИТ-услуг.

“Облачные” вычисления должны удовлетворять следующим требованиям [3].

  •  сервис-ориентированность;
  •  масштабируемость и гибкость;
  •  совместное использование данных;
  •  плата за использование.

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

Требования к реализации распределенных БД

Инструментальные средства распределенных БД должны позволять выполнять удаленные вычисления, удаленный доступ, интеграцию данных и приложений. При этом должны использоваться службы распределенных БД - аутентификация, управление ресурсами, управление распределенными данными (обнаружение ошибок функционирования); открытые протоколы передачи, обмена данными, web-сервисов (http, ftp, UDDI, WSDL, SOAP, др.).

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

  •  доступ к распределенным данным;
  •  управление данными;
  •  мониторинг информационных ресурсов;
  •  управление иерархической массовой памятью (создание средств эффективного переноса с одного уровня памяти на другой).

Распределенная инфраструктура должна обеспечить функционально надежный, согласованный, устойчивый и недорогой доступ к распределенным БД. Это обеспечивается хорошо развитой службой метаданных. Служба метаданных управляет каталогами с именем и указателем на расположение единичных или реплицированных файлов, информацией по мониторингу (объем ресурсов, пропускная способность и т.п.), информацией по конфигурации (описание сетей, коммутаторов, кластеров, узлов и программных средств), стратегиями гибкого динамического управления. Схема выполнения запроса зависит от ряда динамических и статических характеристик созданной инфраструктуры: размер БД, к которым требуется доступ; уровень загрузки СУБД для обслуживания запроса; метод/протокол, по которым будет осуществлен доступ и перенос данных; пропускная способность сети, расстояние и трафик; стратегия управления удаленным доступом.

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

Для описания среды виртуального центра и политик по управлению этой средой разработан XML стандарт Data Center Markup Language (DCML). Он помогает решать задачу управления гетерогенной вычислительной средой и прокладывает путь к вычислительным моделям, основанным на сервисах. Компоненты DCML снабжают сетевых администраторов и менеджеров виртуального центра инструментами, чтобы описывать элементы виртуального центра и желаемые функциональные связи между ними. Компоненты также пригодятся для отображения всей инфраструктуры виртуального центра со всеми взаимосвязями компонентов, конфигурациями, операционными политиками и управленческими процессами. Описательные средства DCML могут легко адаптироваться к различным средам, вариациям аппаратных платформ и сетей; они могут отображать множество управленческих ситуаций в виртуальном центре. Такой уровень гибкости важен в реализации политики предоставления сервисов по требованию, где принципиальное значение имеют обмен информацией между различными компонентами и способность автоматического переключения вычислительных ресурсов для добавления мощности.

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

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

Проектные решения по созданию распределенных БД

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

  •  обеспечить своевременное и полное поступление качественных данных;
  •  создать распределенные БД;
  •  разработать средства доступа к данным.

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

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

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

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

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

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

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

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

При проектировании распределенных БД используются следующие принципы:

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

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

Примеры реализации распределенных систем

В настоящее время основным направлением развития распределенных подходов хранения данных является создание GRID - систем. Например, NASA реализует для своих нужд сеть высокопроизводительных компьютеров, роботизированных устройств массовой памяти, высокоскоростных каналов связи, научных инструментов и продвинутых интерфейсов для пользователя под названием Information Power GRID, Проект Legion (http://www.cs.virginia.edu/~legion) нацелен на разработку объектно-ориентированной программной среды, объединяющей несколько тысяч различных компьютеров в сети. Проект Grid Physics Network (http://www.phys.ufl.edu/~avery/mre/) ставит своей задачей создание вычислительной инфраструктуры для научных исследований, где приходится иметь дело с большим объемом данных.

Целью проекта DataGRID (http://grid.web.cern.ch/grid/proposal/ august/DataGridAnnex1V1.8.doc) является разработка программных компонент. В рамках проекта DataGrid построена тестовая инфраструктура вычислений и обмена данными в Европе.

Проект Enabling Grids for E-Science in Europe (EGEE) направлен на создание сервисной панъевропейской grid-инфраструктуры с максимальным уровнем готовности; объединение существующих национальных, региональных и тематических разработок в области GRID в единую инфраструктуру для поддержки научных исследований. Сейчас сформированная инфраструктура успешно применяется в физике высоких энергий, биомедицине и геомониторинге. В максимальной конфигурации тестовая платформа объединяет более 1000 компьютеров и свыше 15 Тбайт данных, размещенных в 25 организациях Европы, России и Тайваня. Россия, получившая статус одного из пяти центров базовой инфраструктуры EGEE, объединила в консорциум по развитию GRID такие институты, как Объединенный институт ядерных исследований, Институт физики высоких энергий в Протвино, НИИ ядерной физики МГУ и др. Одна из центральных задач проекта EGEE — поддержка GRID-инфраструктуры для хранения и анализа реальных и смоделированных данных экспериментов, ведущихся в CERN.

В 2005 г. запущена в эксплуатацию магистральная инфраструктура научно-образовательных сетей России производительностью 2,5 Гбит/с, включающая узлы в Москве, Санкт-Петербурге и Стокгольме. Эта инфраструктура используется совместно сетями RUNNet (http://www.runnet.ru) и RBnet (http://www.rbnet.ru) для обеспечения связности всех российских научно-образовательных сетей и международной связности, подключившись к единой европейской научно-образовательной сети GEANT. Емкость сети в канале в дальнейшем будет достигать 10 Гб/с. GEANT объединяет 3500 научных центров мира. В этой сети работают 3 миллиона ученых. GEANT является основой многих крупных проектов, осуществляемых в Европе.

GRID-сеть Управления охраны окружающей среды США создана на базе IBM Grid Toolbox, ОС Red Hat Linux Enterprise, серверов IBM. В развернутой GRID - среде производится моделирование процессов загрязнения воздуха, исполняются другие вычислительные задачи для нужд экологии. GRID используется в среде разработки программного обеспечения мобильных коммуникаций.

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

В области океанографии в рамках проекта SeaDataNet (http://www.seadatanet.org/ создается распределенная инфраструктура обмена данных между Национальными центрами океанографических данных Европы.

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

В ЕСИМО сосредоточены огромные массивы данных в сотни терабайт. В анализе этих данных могут принимать участие сотни исследователей из разных стран мира, необходимой предпосылкой успешного выполнения анализа данных о состоянии природной среды является максимально широкий доступ к данным наблюдений. В  настоящее время для этих целей используется международный обмен данными по каналам Глобальной сети телесвязи (оперативные данные), на сменных носителях данных, с помощью Web - технологий. Сложность и масштабность вычислительных проблем впечатляют, например, для прогноза поля давления по всему Земному шару требуется несколько часов работы супер-ЭВМ. Для получения климатических характеристик в отдельных квадратах Мирового океан требуются:

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

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

Технической основой такой интегрированной информационной среды является единая телекоммуникационная сеть учреждений и бюджетных организаций. В Обнинске (ФГБУ «ВНИИГМИ-МЦД») создан современный телекоммуникационный узел, обеспечивающий подключение учреждений к широкополосному внешнему каналу для связи с Москвой. Созданная сеть является базой для информационной структуры ЕСИМО, и в дальнейшем она будет развиваться и совершенствоваться. Имеющаяся в настоящий момент телекоммуникационная инфраструктура позволяет уже сейчас решать многие содержательные информационные задачи, такие как, зеркалирование центрального узла в ФГБУ «ГВЦ Росгидромета».

Основой распределенной системы является портал ЕСИМО (http://www.esimo.ru/), выполняющий функции виртуального центра данных. Здесь созданы типовые сервисные функции: информационная часть, доставка персонифицированной информации, возможность совместной работы, мониторинг ИР и другие службы.

В организационном плане можно выделить зональные (территориальные), региональные, тематические и ведомственные центры данных, рис.2. Для ЕСИМО, как составной части международных систем МООД, GOOS и других должно быть предусмотрено сотрудничество с МОК, ВМО, ЮНЕП, МЦД-А, МЦД-В, МЦД-С и другими международными организациями.

Рисунок 2 - Структура ЕСИМО

Для реализации всей совокупности функций распределенной системы необходимо выделить соответствующие региональные учреждения. Это можно сделать путем предоставления таких полномочий одной из мореведческих организаций региона. Это учреждение должно выполнять руководящие функции в отношении всех других мореведческих организаций, занимающихся сбором, обработкой и распространением информации о морской среде, являясь в то же время равноправным звеном в сети региональных центров и постоянным партнером координационного центра и информационных систем других отраслей регионального уровня. На рис.3 представлена структурная схема связей регионального центра с территориальными ведомственными ИС, на рис.4 – структурная схема связей главного центра ЕСИМО с ИС различных ведомств.

Рисунок 3 - Структурная схема связей регионального центра ЕСИМО с территориальными ведомственными ИС

Рисунок 4 - Структурная схема связей КЦ ЕСИМО с отраслевыми ИС

В ЕСИМО создан координационный центр. Важным моментом является то, что в каждом регионе имеется свой  центр ЕСИМО.

Характерной особенностью ЕСИМО является то, что в ней всю исходную информацию собирают и хранят отраслевые центры, а координационный центр хранит только метаданные (сведения об информационных ресурсах). При этом сведения о БД, источниках данных и другие реферируются и периодически обновляются с помощью ведомственных и региональных центров. Подготовку исходных данных на носителях осуществляют либо авторы ИР, либо центры ЕСИМО.

На верхнем уровне управления ЕСИМО взаимодействует с Ситуационным центром Президента и Правительства, ведомствами (Миннауки – для принятия решения по производству научных исследования в экономической зоне России, МЧС для оценки вероятности морских стихийных явлений по месяцам, Минэкономики – для оценки грузооборота на морском транспорте, вылова рыбы и др.). На региональном уровне это могут быть информационные системы Администрации субъектов федерации, транспортных организаций, ресурсодобывающих организаций.

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

Выводы

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

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

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

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

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

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

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

Противостояние катастрофическим последствиям за счет осуществления следующих решений.

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

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

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

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

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

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

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

  1.  Таненбаум Э.,М. ван Стеен, «Распределенные системы. Принципы и парадигмы». — ПИТЕР, 2003. — 878 с.
  2.  Преймсбергер Крис. Десять фактов о “вычислениях в облаке” // Журнал PC Week/RE 25 — 31 августа 2009. №31 (685). http://www.pcweek.ru/its/article/detail.php?ID=119704
  3.  Гореткина Е. Пять характеристик “облаков” // PC Week/RE. 7 — 20 июля 2009. №24 — 25 (678 — 679)
  4.  Ривкин М. Платформа для коммерческих сред Grid // Открытые системы. – 2003. – № 12. – С. 58-64.

Перечень вопросов для самопроверки

  1.  Назовите преимущества централизованных и распределенных БД
  2.  Сравните понятия расчлененная и тиражируемая БД. Когда одна из них предпочтительнее, чем другая?
  3.  Опишите, чем отличаются распределенные и централизованные системы БД