63425
РАСПРЕДЕЛЕННЫЕ БД
Лекция
Информатика, кибернетика и программирование
Достигнутый уровень технического развития отдельных ведомственных центров данных принципиально позволяет уже сейчас обеспечить достаточно высокую оперативность доступа пользователей. В связи с растущей сложностью и разнообразием данных представляющих интерес для различных отраслей экономики...
Русский
2014-06-20
325.5 KB
1 чел.
PAGE 237
EMBED Word.Picture.8
EMBED Word.Picture.8
EMBED Word.Picture.8
XI. РАСПРЕДЕЛЕННЫЕ БД
Развитие централизованных и распределенных БД
Распределенные БД - веяние времени
Требования к реализации распределенных вычислений
Проектные решения по созданию распределенных БД
Пример реализации распределенных систем
Развитие централизованных и распределенных БД
Более полувека длится эпоха компьютеризации и за это время произошли кардинальные изменения в аппаратном, программном и информационном обеспечениях. Если на заре становления компьютерных технологий организации имели в своем распоряжении в лучшем случае лишь несколько единиц вычислительной техники, то сегодня инфраструктуру предприятий составляет множество соединенных между собой устройств с выходом в высокоскоростные глобальные сети. Повышение эффективности обеспечения пользователей информацией может быть достигнуто за счет создания системы распределенных БД (РБД). Развитие прикладных архитектур показано на рис.1.
Рисунок 1 - Развитие архитектуры компьютерных систем [1]
Достигнутый уровень технического развития отдельных ведомственных центров данных принципиально позволяет уже сейчас обеспечить достаточно высокую оперативность доступа пользователей. Но на обслуживание в одном центре требуется много усилий для поддержания актуальности БД.
В связи с растущей сложностью и разнообразием данных, представляющих интерес для различных отраслей экономики страны, обеспечение потребителей информацией из одного центра неизбежно стало сложнее. В централизованных БД ведомственных центров данных пользователи тратили много времени на поиск сведений о данных (дни и даже недели) и доступ (минуты, часы, а при больших объемах данных и дни) к данным. Трудоемкость создания информационной системы с огромной БД обусловливается сложностью современных СУБД, их настройкой, а особенно разработкой реальных схем обслуживание пользователей, организации работ по созданию БД, обеспечению их надежности и безопасности.
Создание распределенных БД базируется не на пустом месте. На первом этапе развития централизованной обработки данных в шестидесятых, начале семидесятых годов были заложены основы сбора данных на технических носителях, на втором этапе - середина семидесятых начало восьмидесятых годов - разработаны АСУ, АИС, Автоматизированные системы для научных исследований (АСНИ), на третьем в конце восьмидесятых годов - были созданы базы и банки данных. Последние десятилетия характеризуются развитием Интернет технологий, которые позволяют связать распределенные Интернет-узлы в одну сеть. Эти этапы отражают преемственность в развитии системы переработки информации. Решение задач на каждом из них осуществлялось в соответствии с реальным уровнем развития методов автоматизированной обработки данных, программного и технического обеспечения и создало предпосылки для перехода к очередному этапу созданию распределенных БД и удаленной обработки данных. Централизованный сбор данных позволил сократить трудозатраты на сбор, поиск и систематизацию данных, уменьшить сроки обработки больших массивов данных, увеличить полноту обрабатываемых данных, в т.ч. за счет международного и межведомственного обмена, обеспечить одноразовое занесение данных на носитель. Последнее позволило обеспечить многие учреждения копиями основных массивов данных на сменных технических носителях, без чего переход к следующему этапу был бы намного трудней, так как не был бы накоплен опыт обработки данных в региональных организациях, не было бы профессиональных коллективов в них.
Многие крупные компании уже много лет разрабатывают средства, позволяющие повысить эффективность доступа к удаленным узлам. Так в России еще в восьмидесятые годы были созданы оперативные системы доведения информации до пользователей, например, система СИГМА-ОКА, (ВНИИГМИ-МЦД), DIALOG (ВИНИТИ) и др. Эти системы, как правило, были уникальными, удовлетворяющими нужды отдельных пользователей. Средства этих систем позволяли обеспечить доступ по выделенным каналам связи через центр коммутации сообщений с выдачей результатов поиска на экран видеотерминала и печатающее устройство. К сожалению, из-за высокой стоимости эксплуатации таких систем, недостаточной надежности каналов связи, сбоев ЭВМ, работающих в этих центрах, они не нашли широкого применения.
По мере роста производительности процессоров и неизбежного усложнения программного обеспечения самостоятельная эксплуатация компьютера становится все сложнее и дороже. А когда стоимость программного обеспечения, необходимого для ведения бизнеса, достигла сотен тысяч долларов, возникли идеи об аренде программного обеспечения. Так, компания Oracle предоставляет свою продукцию на основе аренды СУБД и иных приложений через Интернет. Технология Application Service Provision позволяет использовать сложное программное обеспечение и хранить свои данные не на серверах локальной сети компании и не на рабочих станциях пользователей, а в центрах обработки данных. Они похожи на предприятия, которые четверть века назад назывались вычислительными центрами коллективного пользования. Аренда программных средств снижает уровень контроля пользователя за используемыми ресурсами (программными продуктами, данными, оборудованием).
Уже имеются программные средства, которые позволяют осуществлять доставку приложений на компьютеры и карманные персональные цифровые устройства непосредственно с сервера. Такая разработка предполагает хранение программ - сервисов в одном месте, откуда приложения вызываются с тонких клиентов, установленных на рабочих местах пользователей. Подобная модель является недорогой (с точки зрения расходов на установку и обслуживание). Мониторинг обращений к приложениям и данным централизован, доступ можно получить через web-интерфейс. Когда клиентские устройства находятся в режиме онлайн, система проводит синхронизацию информации, расположенной на сервере. Можно использовать практически любые клиентские устройства, чтобы взаимодействовать друг с другом, получать доступ к данным и приложениями, а также управлять ими в любое время и из любого места, где это только необходимо.
Основными решениями здесь являются разработка сервисов типа SaaS, интеграция данных.
Для интеграции имеющихся информационных и вычислительных ресурсов, находящихся в разных частях планеты требуются мощные вычислительные установки, которые не могут функционировать без квалифицированного персонала, имеющего практический опыт организации крупномасштабных вычислений. При удаленной работе пользователь использует результаты труда этого персонала. Это обстоятельство оказывается таким же важным, как и наличие доступа к мощным вычислительным ресурсам. Пользователи передают по сети свои требования на ресурсы, а затем используют предоставленные ресурсы.
Распределенные БД могут объединить региональные, национальные и даже международные информационные ресурсы.
У централизованной системы можно выделить следующие недостатки и проблемы:
Распределенные БД - веяние времени
Распределенная БД это набор компьютеров-серверов с установленными на них СУБД и базами данных, который пользователи воспринимают как единую среду для работы. Распределенные системы строятся либо для файловых систем, либо для БД, а в настоящее время для разнородных и распределенных систем, т.е. для БД, файлов и приложений одновременно. БД можно считать распределенной, если она удовлетворяет, как минимум, следующим требованиям:
Это минимальные требования, без выполнения которых БД нельзя считать распределенной.
К характеристикам БД можно отнести следующее:
Распределенные БД имеют следующие преимущества по сравнению с централизованной системой: обеспечивается большая надежность работы, хранения копий или частей БД, данные становятся ближе к точкам их использования, что ускоряет обращение к данным и сокращает затраты на их передачу. Кроме того, преимуществами распределенной БД являются [1] неявность адресации и тиражирования, независимость от конфигурации, использование неоднородных СУБД, тиражирование данных, расчленение БД, фрагментация данных.
Неявность адресации позволяет пользователю обращаться к данным, не зная и не интересуясь, в каком центре они расположены.
Неявность тиражирования связана с тем, что, если существуют копии данных, то при извлечении данных необходимо извлекать одну копию данных, а при внесении изменений в данные необходимо обновлять все копии. Выбор одной копии при извлечении данных и обеспечение обновления всех копий должна автоматически выполнять система, позволяя пользователю сосредоточиться на информационных запросах.
Независимость от конфигурации позволяет организации добавлять или заменять оборудование, не изменяя существующих компонент программного обеспечения РБД. Независимость от конфигурации позволяет расширить систему в случае, если существующее оборудование перестает удовлетворять пользователей.
Использование неоднородных СУБД на разных компьютерах требует создания общего пользовательского интерфейса, за которым находятся разные модели данных.
Тиражирование данных означает поддержку нескольких одинаковых копий таблиц. Тиражирование применяется с целью повышения доступности данных и надежности их хранения. Кроме того, несколько пользователей могут параллельно обращаться к одним и тем же данным. Например, это могут быть, во-первых, копии данных для отдельных регионов, во-вторых, метаданные. Издержками этого подхода является необходимость дополнительного объема памяти и поддержания согласованности данных в разных копиях. Для согласованности данных можно поддерживать централизованную БД, а копии выделяют для локального использования. Потери данных на одном центре восстанавливаются при помощи централизованной БД. Недостатком такого подхода является слишком долгое время загрузки централизованной БД. Поэтому загрузка новых данных, касающихся локальной БД, в региональном и главном центрах системы происходит одновременно. Применяется также тиражирование данных по времени отсечения. Например, в региональном центре данные хранятся только за последний год.
При расчленении БД улучшается защита данных, особенно если разделенные сегменты нуждаются в разных видах защиты. При этом варианте реализации один пользовательский запрос может требовать обращения к нескольким БД, реализованных в разных организациях на разных подходах. Хотя сложности реализации скрыты от пользователя, действительные операции, например, соединение нескольких таблиц, является сложным процессом.
Фрагментация данных связана с тем, каким образом таблицы могут быть разделены и распределены между центрами. Это продолжение стратегии расчленения данных, которая обычно означает распределение по центрам таблиц (или файлов) целиком. При фрагментации таблица делится на несколько частей (подмножеств). Объединение этих фрагментов составит исходную таблицу. Фрагментация может быть горизонтальной (данные для разных географических районов в отдельные фрагменты) и вертикальной (разные атрибуты в отдельные фрагменты). Для случая одного типа данных лучше применить горизонтальную фрагментацию. Здесь имеется проблема пересечения данных, т.е. одни те же данные могут дублироваться на границах регионов, например, в области гидрометеорологии БД для Арктического региона, кроме Северного ледовитого океана, включает данные, относящиеся к Северной части Атлантического океана.
Положительными моментами распределенного подхода организации БД являются:
Применение распределенного подхода обеспечивает следующие преимущества.
Надежность. Хорошо спроектированная распределенная сеть должна быть чрезвычайно устойчива, позволять использовать несколько маршрутов взаимодействия между узлами. Это облегчает обслуживание и замену компонентов в случае сбоя с минимальным влиянием на доступность системы в целом.
Производительность. Те же факторы, что обеспечивают надежность, повышают производительность систем. Отсутствие необходимости в центральном коммутаторе со многими портами избавляет от появления потенциальной проблемы узкого места, а применение балансировки нагрузки между несколькими узлами обеспечивает постоянство производительности всей сети. Распределенные БД позволяют перемещать приложения между серверами в целях оптимизации производительности, не прерывая при этом обслуживания пользователей.
Масштабируемость. К имеющейся конфигурации сети можно добавлять новые узлы. Производительность возрастает практически пропорционально росту суммарной производительности серверов. Необходимо чтобы выполняемые функции стали независимы от конкретной аппаратной составляющей. Сервисы и программное обеспечение должны иметь возможность быстрой настройки. Таким образом, достигается требуемая гибкость системы. Средства мониторинга позволят провести анализ того, каким пользователям и какие ресурсы требуются в первую очередь. Причем приложение доступно пользователю в любой момент за счет постоянного мониторинга, позволяющего предотвратить отказ компонентов системы еще до возникновения инцидента. Распределенная БД требует применения единой политики безопасности.
Распределенные файловые системы обеспечивают удобный интерфейс для удаленного ввода/вывода, но не поддерживают копии данных в разных узлах системы и возможности коллективного и управляемого ввода/вывода. Системы удаленного выполнения заданий позволяют производить спланированное выполнение заданий на удаленных компьютерах, но не поддерживают интерфейсов параллельного ввода/вывода или доступа к параллельным файловым системам.
Важной тенденцией в развитии концепции распределенных БД является применение идей виртуализации и автоматического предоставления ресурсов не только на техническом уровне для серверов, систем хранения, программного обеспечения, но и на уровне приложений и сервисов. Например, функция идентификации пользователей реализуется как единый для всех приложений сервис, благодаря чему средства идентификации не придется встраивать отдельно в каждое приложение; работа с объектами метаданных тоже может рассматриваться как сервисы.
Есть проблемы и у распределенных БД:
Следует учитывать также время задержки и стоимость передачи значительных объемов данных. Нельзя не учитывать и желание владельца данных сохранять контроль над принадлежащими ему ресурсами и получать результаты как можно быстрее.
Корпоративная виртуализированная вычислительная среда масштаба предприятия, должна обеспечивать автоматическое распределение нагрузки по всем доступным серверным мощностям и предоставление пользователям ресурсов по требованию. Здесь могут применяться GRID системы [4]. Концепция GRID системы базируется на разработанных средствах кластеризации и реализуется в исключительно однородной среде. Этот подход позволяет динамически выделять/забирать информационные ресурсы для решения задач предприятия, минимизировать перемещение данных между узлами, упростить администрирование систем.
Если имеется регистр веб-сервисов, то пользователь может определить, какой сервис ему нужен, а система сама определит, какие данные нужны этому сервису, где они находятся, сама доставит их этому сервису, а пользователь будет видеть только результат работы сервиса. В будущем большинство пользователей не будут поддерживать БД, а будут пользоваться облачными системами и платить за их использование. Поэтому в создаваемых ОС для GRID основными функциями становятся учетные функции, чтобы каждый пользователь получал счет за предоставленные ему ресурсы.
Есть несколько серьезных проблем, мешающих реализации GRID-сетей (безопасность данных, а также наличие доступной полосы пропускания). Работая в архитектуре «клиент-сервер» процессоры использовались локально, потому что крупные центры данных дорогие, а полоса пропускания слишком узкая. Теперь пытаются перенести в центр данных как можно больше приложений. В распределенной кластерной среде с высокопроизводительными процессорами каждый узел будет обрабатывать свой массив данных, но при этом он должен сверяться с другими узлами, чтобы обеспечить непротиворечивость данных.
Выделяются три типа GRID-проектов:
Существует четыре типа GRID-инфраструктур:
Применение концепции 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 - технологий. Сложность и масштабность вычислительных проблем впечатляют, например, для прогноза поля давления по всему Земному шару требуется несколько часов работы супер-ЭВМ. Для получения климатических характеристик в отдельных квадратах Мирового океан требуются:
В ЕСИМО работает распределенная структура, в составе которой действуют центры, обеспечивая развитие единой информационной среды. В качестве базовых узлов предложены научные учреждения, имеющие наиболее продвинутые технологии и опыт эксплуатации систем. В ЕСИМО создана инфраструктура, позволяющая использовать информацию на всех уровнях управления экономикой.
Технической основой такой интегрированной информационной среды является единая телекоммуникационная сеть учреждений и бюджетных организаций. В Обнинске (ФГБУ «ВНИИГМИ-МЦД») создан современный телекоммуникационный узел, обеспечивающий подключение учреждений к широкополосному внешнему каналу для связи с Москвой. Созданная сеть является базой для информационной структуры ЕСИМО, и в дальнейшем она будет развиваться и совершенствоваться. Имеющаяся в настоящий момент телекоммуникационная инфраструктура позволяет уже сейчас решать многие содержательные информационные задачи, такие как, зеркалирование центрального узла в ФГБУ «ГВЦ Росгидромета».
Основой распределенной системы является портал ЕСИМО (http://www.esimo.ru/), выполняющий функции виртуального центра данных. Здесь созданы типовые сервисные функции: информационная часть, доставка персонифицированной информации, возможность совместной работы, мониторинг ИР и другие службы.
В организационном плане можно выделить зональные (территориальные), региональные, тематические и ведомственные центры данных, рис.2. Для ЕСИМО, как составной части международных систем МООД, GOOS и других должно быть предусмотрено сотрудничество с МОК, ВМО, ЮНЕП, МЦД-А, МЦД-В, МЦД-С и другими международными организациями.
Рисунок 2 - Структура ЕСИМО
Для реализации всей совокупности функций распределенной системы необходимо выделить соответствующие региональные учреждения. Это можно сделать путем предоставления таких полномочий одной из мореведческих организаций региона. Это учреждение должно выполнять руководящие функции в отношении всех других мореведческих организаций, занимающихся сбором, обработкой и распространением информации о морской среде, являясь в то же время равноправным звеном в сети региональных центров и постоянным партнером координационного центра и информационных систем других отраслей регионального уровня. На рис.3 представлена структурная схема связей регионального центра с территориальными ведомственными ИС, на рис.4 структурная схема связей главного центра ЕСИМО с ИС различных ведомств.
Рисунок 3 - Структурная схема связей регионального центра ЕСИМО с территориальными ведомственными ИС
Рисунок 4 - Структурная схема связей КЦ ЕСИМО с отраслевыми ИС
В ЕСИМО создан координационный центр. Важным моментом является то, что в каждом регионе имеется свой центр ЕСИМО.
Характерной особенностью ЕСИМО является то, что в ней всю исходную информацию собирают и хранят отраслевые центры, а координационный центр хранит только метаданные (сведения об информационных ресурсах). При этом сведения о БД, источниках данных и другие реферируются и периодически обновляются с помощью ведомственных и региональных центров. Подготовку исходных данных на носителях осуществляют либо авторы ИР, либо центры ЕСИМО.
На верхнем уровне управления ЕСИМО взаимодействует с Ситуационным центром Президента и Правительства, ведомствами (Миннауки для принятия решения по производству научных исследования в экономической зоне России, МЧС для оценки вероятности морских стихийных явлений по месяцам, Минэкономики для оценки грузооборота на морском транспорте, вылова рыбы и др.). На региональном уровне это могут быть информационные системы Администрации субъектов федерации, транспортных организаций, ресурсодобывающих организаций.
Необходимость сочетания отраслевой региональной и межотраслевой информации в ЕСИМО обуславливает наличие вертикального и горизонтального взаимодействия. Вертикальные связи отражают соподчиненность центров в рамках отрасли, горизонтальные - необходимость координации функционирования центров на одном уровне (отраслевом или региональном).
Выводы
Управление распределенной базой данных (выработка способов функционирования) в ситуации, когда сеть распадается на две или более несвязанные группы узлов, становится сложной задачей. Оператор должен иметь возможность вносить в БД записи или изменять содержимое БД, несмотря на то, что один из серверов отключен. Из соображений эффективности данные тиражируются на двух узлах и поддерживается идентичность копий. В ситуациях, когда связь нарушается, в копиях могут появиться различия. После восстановления связи должен включаться механизм согласования, который формирует некоторую копию, отражающую все сделанные изменения.
Применение распределенных технологий оправдано практически в любой компании, имеющей достаточно масштабную ИТ инфраструктуру. Pа последние годы в сфере создания транспортных протоколов достигнут значительный прогресс, в частности, в области Web-сервисов.
Причиной бурного развития концепции распределенных систем является то, что она позволяет получить результат быстрее и дешевле. Более эффективное использование оборудования и включение простаивающего оборудования снизят стоимость эксплуатации и количество закупаемого и поддерживаемого оборудования.
Модель распределенных вычислений отражает представление об имеющихся потребностях и о реальном распределении технических, финансовых и административных возможностей. Механизм должен позволить приложениям прозрачным образом передавать базовой сети требования на ресурсы. В конечном итоге необходимо создать множество использующих естественные языки визуальных интерфейсов для доступа к вычислительным и коммуникационным ресурсам. Необходимые компоненты для создания эффективных распределенных вычислений уже имеются.
Для реализации же идеальной концепции распределенных систем придется еще решить огромное множество проблем, среди которых есть такие, как:
Переход в среду распределенных систем связан с немалыми затратами, так требуется поддержка нового протокола IPv6, для чего придется менять сетевое оборудование (прямые затраты стоимость техники, обучение). А еще косвенные затраты (неизбежное уменьшение производительности сотрудников на время настройки сети, риск возможных осложнений).
Противостояние катастрофическим последствиям за счет осуществления следующих решений.
Распределенные архитектуры наиболее эффективное и мощное средство предотвращения катастрофических последствий для хранилищ данных. Физически серверы располагаются в далеко расположенных друг от друга местах, идеальный случай в разных концах страны или мира. Внедрение хранилищ данных одновременно на нескольких ОС (Linux, Unix, Windows) сильно снижает уязвимость хранилищ данных от червей, атак с помощью социальной инженерии и хакеров, использующих специфические уязвимости.
Параллельных путей коммуникаций даже распределенное хранилище данных может быть уязвимо, если оно зависит от слишком малого количества путей коммуникации. Интернет это сложная коммуникационная сеть, которая сильно распараллелена и непрерывно подстраивается под постоянно изменяющуюся топологию. Интернет локально уязвим, если ключевые центры коммутации подвергаются атаке. Предоставление дополнительных мультирежимных путей доступа, таких как выделенные линии и спутниковые каналы к сети Интернет также уменьшают уязвимость.
Сети хранения данных (СХД) это комбинация высокопроизводительных дисковых накопителей и устройств резервного копирования, соединенных посредствам технологии высокоскоростных оптоволоконных каналов. Дисковые накопители, архивные системы и устройства резервирования могут быть расположены в разных зданиях на достаточно большом расстоянии. Когда все диски СХД будут объединенным ресурсом, различные приложения могут быть сконфигурированы для параллельного доступа к данным, это наиболее существенно для «read-only» сред.
Ежедневное резервирование на носители, хранящихся в надёжном месте - ничто другое не предоставляет защиты надёжнее, чем хранение физических носителей в безопасном месте.
Стратегически размещённые шлюзы фильтрации пакетов необходимо изолировать ключевые серверы хранилищ данных таким образом, чтобы они не были доступны из внешних сетей.
Аутентификация и доступ на основе ролей хранилищам данных наиболее просто навредить при наличии многих слишком разных путей доступа к ним, и если безопасность не контролируется централизовано.
Список литературы
Перечень вопросов для самопроверки
А также другие работы, которые могут Вас заинтересовать | |||
35854. | Ранг матрицы. Теорема о базисном миноре | 169.21 KB | |
Ранг матрицы Пусть прямоугольная матрица размера : . Назовем арифметическими мерными векторами упорядоченные наборы чисел строки матрицы и обозначим их через . Элементы стоящие на пересечении выбранных строк и столбцов образуют определитель порядка который называется минором порядка матрицы . | |||
35858. | Понятие системы. Виды систем | 423.67 KB | |
Понятие системы. Виды систем: конкретные реальные системы объекты явления процессы и абстрактные системы являющиеся определенными отображениями моделями реальных объектов. Конкретные системы делятся на естественные природные и искусственные созданные человеком. Искусственные системы имеют определенные цели функционирования назначения и управление. | |||
35860. | Методи використання тренажерів на уроках теоретичного навчання | 393 KB | |
Методи використання тренажерів на уроках теоретичного навчання У машинобудівній галузі верстати з числовим програмним управлінням у найближчому майбутньому займуть пріоритетне становище у верстатному парку. Одним з найбільш ефективних методів інтенсивного навчання є використання компютерних засобів або компютерні навчаючі програми а також компютерні тренажери або компютерні тренажериімітатори роботи верстатів. Навчання на тренажерах проводиться у кабінеті навчального закладу під наглядом викладача тому воно позбавлене недоліків... | |||
35861. | Алгоритмы кэширования современных микропроцессоров | 387.5 KB | |
Процесс выполнения программы можно представить как последовательность обращения к строкам основной памяти. Вся информация хранится в основной памяти а часть в кэш памяти. ОПТ оптимальный известна вероятность обращения к строкам памяти. Физически реализуемые Алгоритмы выбора строки из кэш памяти. | |||