Формирование и использование информационного ресурса организации

Существует множество таких научных GRID-проектов. Многие из них были реализованы на базе СУБД Oracle.
Общим недостатком GRID-проектов первого и второго типов было то, что они не были предназначены для реализации стандартных информационно-управляющих систем предприятия (кадры, зарплата, управление производством, CRM и т.д.), требовали создания специализированного системного программного обеспечения для решения каждой новой задачи, были пригодны только для обработки специфических данных (массивы слабо связанных данных). Поэтому эти подходы не годились для создания GRID предприятия.
Третий тип GRID-проектов называют Enterprise GRID (GRID предприятия). Он несколько сужает идеальную концепцию GRID, однако позволяет реализовать стандартные информационно-управляющие системы предприятия в GRID среде уже сегодня. Этот подход позволяет динамически выделять/забирать вычислительные ресурсы для решения задач предприятия, минимизировать перемещение данных между узлами, упростить администрирование систем. Примером платформы для реализации коммерческой GRID является Oracle 10G.
Все механизмы Oracle 10G для реализации GRID предприятия можно разбить на следующие группы (рис. 2.2):
Storage GRID – GRID хранения данных;
Database GRID – GRID серверов БД;
Application GRID – GRID серверов приложений;
Средства самонастройки узлов БД;
GRID Control – система управления GRID;
Средства для разделения информации между узлами GRID.

Рис. 2.2. Архитектура Oracle GRID

Oracle 10G позволяет реализовать новый подход к управлению хранением данных. Функция ASM (Automatic Storage Manager) позволяет виртуализировать наборы дисков в единый виртуальный диск, возложить на Oracle функции менеджера файлов и томов. Теперь администратор должен только выполнить команду создания группы дисков (это и есть виртуальный диск) и добавлять вновь подключаемые к системе диски в группу (это тоже одна команда). Oracle сам работает с этой группой дисков (виртуальным диском), размещая на нем свои файлы и управляя ими. Также легко одной командой можно удалять диск из группы.
GRID серверов БД является развитием кластерной архитектуры Oracle. Oracle Real Application Clusters (RAC) хорошо зарекомендовал себя во многих организациях. Если раньше для установки кластера требовалось установить поверх стандартной операционной системы дополнительное специализированное программное обеспечение третьих фирм, то теперь Oracle сам написал такое программное обеспечение (Clasterware) и поставляет его с версией 10G для любых платформ (а не только для Windows и Linux). Теперь установка кластера Oracle может производиться на стандартные операционные системы. Кроме того, Oracle поставляет в составе RAC кластерную файловую систему – Cluster File System. Это позволяет реализовать кластер не на сырых устройствах (Raw device), а на обычной ОС, где могут храниться и данные кластерной БД, и программное обеспечение, и другие файлы.
Для создания GRID-серверов БД необходимо обеспечить возможность автоматического динамического подключения и отключения дополнительных вычислительных ресурсов сервера БД. Это делается на основе понятия “сервис”. Каждое приложение (например, CRM, ERP, кадры, зарплата и т.д.) можно рассматривать как сервис, работающий на нескольких узлах GRID. Администратор GRID может для каждого сервиса определить узлы GRID (кластера), на которых этот сервис запускается сразу при старте сервиса (так называемые PREFERED узлы) и узлы, которые этот сервис будет использовать дополнительно при определенных условиях (так называемые AVAILABLE узлы). На остальных узлах GRID этот сервис запускаться не может.
GRID серверов приложений. Ситуация с серверами приложений похожа на ситуацию с серверами БД. Уже в Oracle 9i можно было организовать кластеры серверов приложений, т.е. транзакция, начавшаяся на одном сервере приложений, могла, в случае его остановки, продолжиться на других серверах приложений кластера. GRID Control Enterprise Manager позволяет добавлять новые узлы в кластер сервера приложений, управлять этими узлами и кластером, стартовать и останавливать эти узлы. При необходимости узлы могут быть исключены из кластера и отданы под другие нужды (web кэш, сервер БД и т.д.).
GRID Control позволяет управлять всеми компонентами сервера приложений (кэшем, инфраструктурой, J2EE, EJB и т.д.). Сервер приложений тесно связан с узлами сервера БД и при выходе из строя узла сервера БД, сервер приложения тут же узнает об этом и переключается на оставшиеся узлы (все это занимает несколько секунд).
Самонастройка СУБД. GRID подразумевает одновременную работу множества серверных узлов и баз данных. Если несколькими узлами администратор БД мог управлять вручную, используя графические средства администрирования, то десятками, сотнями и тысячами серверов БД управлять вручную невозможно. Поэтому Oracle встроил в сервер 10G спеиальную инфраструктуру автоматической диагностики и самонастройки.
Управление GRID (GRID Control). Для управления, конфигурирования, диагностики множества разнородных узлов, составляющих GRID, в составе стандартного средства управления Oracle Enterprise Manager (OEM) имеется компонента GRID Control. OEM позволяет управлять всеми компонентами GRID – серверами БД, серверами приложений, кэшами, Java-машинами, устройствами хранения, сетевыми компонентами, RAC, распространением данных и т.д.
Разделение информации в GRID. Информация хранится в GRID в базах данных и файлах. Множество узлов GRID должно иметь доступ к этой информации, поэтому необходимо организовать разделение информации между узлами. Существует три способа разделения информации:
централизация информации в единой БД;
работы с множеством самостоятельных независимых БД и файлов;
временный вынос необходимой информации на узлы, где она будет обрабатываться (propelling).
Централизация информации – самый простой способ. Вся информация из различных источников собирается в одной БД Oracle и далее кластер Oracle прекрасно решает множество задач, работая с этой БД.
Согласованность работы с распределенной БД обеспечивается за счет реализации алгоритмов двухфазной фиксации изменений (2 phase commit), который Oracle реализует автоматически (при создании пользовательских приложений не надо заботиться о том, в единой или разных БД находятся объекты). Тем самым обеспечивается “прозрачность” работы с распределенной БД.
Быстрый перенос из одной БД в другую больших объемов данных можно осуществить в Oracle с помощью механизма транспортируемых табличных пространств (Transportable tablespace). Вместо того, чтобы экспортировать данные из БД в файл, перемещать файл к другой БД, импортировать данные из файла в новую БД (а все это занимает очень много времени), можно просто скопировать (например, с помощью средств FTP) файлы операционной системы, которые образуют табличное пространство, содержащее необходимые нам большие объекты данных. Далее достаточно перенести с помощью экспорта-импорта из одной БД в другую лишь маленький объем метаинформации о перемещенном табличном пространстве. Механизм транспортируемых табличных пространств работает намного быстрее, чем экспорт-импорт.
Перемещаемые файлы можно, например, записать на СD диск и подключать к различным БД в виде набора открытых только на чтение таблиц (например, справочников). В Oracle 10G реализована возможность транспортировки табличных пространств между различными операционными системами. Например, можно со скоростью работы по FTP протоколу переместить большие таблицы из БД на Windows в БД на Linux или Unix. Это делается с помощью утилиты RMAN.
Для переноса небольших таблиц из БД в БД в Oracle 10G можно использовать новую утилиту Data Pump. Ее функциональность аналогична тому, что умели делать старые утилиты экспорта-импорта, но работает она намного быстрее. Так импорт данных выполняется в Data Pump в 20-30 раз быстрее, чем раньше, используется механизм распараллеливания вычислений, возможен рестарт работы утилиты с той точки, где она прервала свою работу. Data Pump позволяет выполнить прямой перенос данных из одной БД в другую без создания промежуточных файлов на диске.
Для синхронизации данных, хранящихся в различных БД, может использоваться как старый механизм репликации, так и новый, более универсальный механизм Oracle Streams. Streams позволяет разделять между узлами как сообщения (messaging), так и операции с БД на основе единого универсального механизма. Все заказанные изменения в исходной БД захватываются из журналов БД (это не нагружает эксплуатационную БД) и складируются в едином универсальном формате в области хранения (Stage). Все узлы, которым необходимо получить и применить эту информацию об изменениях, подписываются на получение информации об изменениях из области хранения. При появлении новой информации об изменениях в области хранения, подписавшиеся узлы получат нужную им информацию и смогут ее применить.
Единый универсальный механизм Oracle Streams позволяет реализовать репликацию нужных таблиц, передачу сообщений (Advanced Queuing), передачу извещений о событиях (Notification), оперативную подпитку хранилищ данных, упрощая конфигурирование и администрирование этих механизмов. В случае захвата информации обо всех изменениях в исходной БД и применения их к копии этой БД, мы можем реализовать механизм поддержания резервной БД (StandBy Database).
Механизм StandBy Database позволяет поддерживать в нескольких частях GRID копии одной и той же БД. Причем в случае логического StandBy эти копии могут использоваться для выполнения операций чтения к этим БД. Например, на них можно печатать отчеты, выполнять приложения, связанные с анализом данных, и т.д.
Oracle Streams позволяет исключить дублирование информации, передаваемой по сети в разные узлы, обеспечить гибкую маршрутизацию потоков данных, гарантированную доставку изменений. С помощью Oracle Streams легко обеспечить двустороннюю репликацию данных и разрешение возникающих конфликтов репликации (имеются встроенные алгоритмы разрешения конфликтов).
Часто необходимо перенести данные из целевой БД в удаленную БД лишь на время, для их обработки там. Это позволяет сделать механизм Self Propelling, реализованный в Oracle 10G. Практически это объединение механизма транспортируемых табличных пространств и механизма Oracle Streams. С помощью всего одной команды можно организовать перенос информации в другую БД и запуск механизма ее синхронизации с копией в источнике. Таким образом, можно вынести данные и их обработку на менее загруженные узлы GRID.
В GRID часто информация может храниться не в БД, а в файлах операционной системы. Механизм Oracle External Table позволяет использовать средства работы с БД для работы с информацией файлов. Файлы определяются в словаре БД как внешние (external) таблицы и далее с ними можно работать на чтение (и на запись в Oracle 10G) как с обычными таблицами БД. Более того, можно выполнять операции, одновременно работающие с реляционными таблицами БД и информацией файлов операционной системы.
СУБД Oracle поддерживает тип данных Bfiles. Если Вы создадите в БД таблицу с колонкой типа Bfile, то в этой колонке будут храниться лишь ссылки на файлы операционной системы, а сами данные, помещаемые в эту колонку, будут храниться в файлах ОС. Это еще один механизм для работы с файлами операционной системы. Понятно, что и файлы ОС и их описания в словаре БД можно копировать и перемещать между узлами GRID, обеспечивая разделение информации.
3 Практическая часть. Концепция формирования и
эффективного использования информационного
ресурса метеослужбы (в контексте систем
долгосрочного прогнозирования погоды)

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

3.1. Анализ информационной структуры системы задач долгосрочного прогноза температуры воздуха.

Наряду с традиционными функциями, которые выполняют автоматизированные метеорологические системы (прием, обработка и архивация информации метеорологических станций и постов; отображение метеорологической информации в виде карт и таблиц; выдача предупреждений об опасных явлениях; формирование стандартных выводов по результатам наблюдений за различные периоды осреднения; выдача справочного материала в виде таблиц, карт и бланков на бумажных носителях за различные периоды по архивным данным), программно-аппаратный комплекс долгосрочного прогнозирования средней температуры воздуха выполняет следующее:
1. Опциональный выбор метода прогноза.
Заключается в эмпирическом выборе экспертом-метеорологом концепции долгосрочного прогноза (“идеальный прогноз” – Perfect Prognosis, PP; “выходные статистико-гидродинамические модели” –Model Output Statistic, MOS) и метода прогноза (например, на базе разностей с использованием годовых циклов или на основе полиномиально-гармонического самоорганизующегося базиса моделей).
2. Организация кластерных распределенных, мейнфреймовых централизованных (использование специализированных программных сервисов в локальных вычислительных сетях) или комбинированных кластерно-мэйнфреймовых вычислений долгосрочного прогноза средней температуры воздуха на базе программных и аппаратных терминалов.
Метеостанции являются территориально удаленными объектами и поэтому аппаратный комплекс имеет адекватную распределенную архитектуру, обработка информации в которой проводится по кластерным технологиям, где автоматически выполняется распараллеливание вычислительных структур. В некоторых случаях вычислительные структуры концентрированно обрабатываются на мэйнфреймах, где на локальные компьютеры пользователей устанавливаются специализированные программные сервисы. Для передачи данных на значительной территории целесообразно использовать космические технологии (например, спутниковая система “ГлобалСтар”), что особенно актуально для автоматических метеостанций, расположенных в труднодоступных районах, где отсутствуют традиционные средства связи. Рекомендация по использованию спутниковой системы “ГлобалСтар” обусловлена следующим: минимальная задержка (~250 мсек, что сравнимо с наземными сотовыми сетями); многоспутниковый захват; малогабаритная антенна; низкая потребляемая мощность; сравнительно низкая стоимость оборудования и эксплуатации; сертификация в Росгидромете; территориальное расположение (общим серьезным недостатком системы “ГлобалСтар” является ограничение по зоне возможного применения – приблизительно 70 градусом северной и южной широты). Вычислительный комплекс также может строиться по комбинированному кластерно-мэйнфреймовому принципу, когда вычисление прогноза производится параллельно на центральном сервере и на локальных компьютерах региональных метеостанций.
3. Экспертная система (ЭС) поддержки принятия решений метеоролога для редукции множества вариантов и уточнения прогнозов.
Предметная область метеорологии характеризуется: нечеткостью постановки задач; неполнотой исходных данных; отсутствием в общем случае точного алгоритма решения; большим числом прогнозов; отсутствием возможности полной формализации задач; существенным использованием механизма индукции и других нетрадиционных логических исчислений. В этих условиях целесообразно использовать ЭС поддержки принятия решений, которая повышает оправдываемость прогнозов и сокращает множество прогнозируемых вариантов на базе комплексного учета эмпирических знаний и опыта специалистов-метеорологов. Применению ЭС также способствует следующее: эксперт-метеоролог не в состоянии быстро накапливать и усваивать знания в силу его психофизиологических ограничений; эксперта-метеоролога не представляется возможным использовать в системах долгосрочного прогнозирования реального времени (существующий регламент сбора метеоданных обязывает строго соблюдать временной интервал 20 мин., в течение которых необходимо осуществлять сбор данных с датчиков и передачу в региональный центр – данное ограничение предлагается пролонгировать на программно-аппаратный комплекс долгосрочного прогнозирования) из-за нестабильности его характеристик.
Указанные задачи наряду с традиционными функциями автоматизированных метеорологических систем индуктивно составляют концепцию программно-аппаратного комплекса долгосрочного прогнозирования средней температуры воздуха на базе статистико-гидродинамических моделей.
3.2. Предложения по организации программно-аппаратного комплекса долгосрочного прогноза температуры воздуха и его описание.
Предлагается следующая структура комплекса долгосрочного прогнозирования средней температуры воздуха (рис. 3.1). Аппаратура приема-передачи метеоданных производит прием-передачу информации по доступным каналам связи (телефонная, радио, спутниковая, Internet/Intranet, др.). Блок обработки метеоданных распределяет вычислительную нагрузку расчета долгосрочного прогноза в зависимости от концепции (мэйнфреймовая – расчет выполняется на центральном сервере хранения и обработки метеоданных, кластерная – распределенно на компьютеризированных комплексах сбора и первичной обработки метеоданных, комбинированная – параллельно на центральном сервере и локальных компьютерах региональных метеостанций). Метод прогноза выбирается экспертами-метеорологами в региональных метеоцентрах или централизованно – специализированными научно-техническими советами гидрометеорологического центра и научно-исследовательского гидрометеорологического института (в данном случае используются процедуры ранжирования и оценки достоверности). Методология прогнозирования может варьироваться в зависимости от региона. Полученный прогноз (множество вариантов прогноза) уточняется (уменьшается мощность множества вариантов) в региональных метеоцентрах с использованием ЭС поддержки принятия решений метеоролога.


Рис. 3.1. Структура комплекса долгосрочного прогноза средней
температуры воздуха на базе статистико-гидродинамических моделей
ЗАКЛЮЧЕНИЕ

В работе проведен анализ формирования и использования информационного ресурса предприятия. Индуктивно данная задача решена на базе следующих каузальных составляющих:
1. Состояние вопроса предметной области информационных технологий и информационных систем в управлении организаций (классификация информационных технологий и систем; взаимосвязь организаций и информационных систем; виды информационных систем в организации).
2. Анализ технологий Oracle в контексте формирования и использования информационного ресурса организации (Oracle Application Server Portal; концепция GRID и ее реализация в Oracle).
3. Концепция формирования и эффективного использования информационного ресурса метеослужбы (в контексте систем долгосрочного прогнозирования погоды).

СПИСОК ЛИТЕРАТУРЫ

1. Душин В.К. Теоретические основы информационных процессов и систем. – Изд-во: Дашков и Ко, 2002. – 250 с.
2. Гринберг А.С., Король И.А. Информационный менеджмент. – Изд-во: Юнити-Дана, 2003. – 416 с.
3. Барановская Т.П. и др. Информационные системы и технологии в экономике Изд-во: Финансы и статистика, 2003. – 416 с.
4. Гаскаров Д.В. Интеллектуальные информационные системы. – Изд-во: Высшая школа, 2003. – 432 с.
5. Меняев М.Ф. Информационные технологии управления. Кн 3. Системы управления организацией. – 2003. – 464 с.
6. Волокитин А.В. и др. Средства информатизации государственных организаций и коммерческих фирм. Справочное пособие. – Изд-во: ФИОРД-ИНФО, 2002. – 272 с.
7. Когаловский М.Р. Перспективные технологии информационных систем. – Изд-во: ДМК Пресс, Компания АйТи, 2003. – 288 с.
8. Зубов Д.А., Ульшин В.А., Жариков Э.В., Григоренко М.С. Концепция программно-аппаратного комплекса долгосрочного прогнозирования средней температуры воздуха на базе статистико-гидродинамических моделей // Сборник научных трудов Украинского государственного геолого-исследовательского института. – 2007. – № 4. – С.223-226.