Платформа для коммерческих сред Grid

Какие механизмы предлагает Oracle для разработки и эксплуатации приложений в средах Grid? Почему новая версия СУБД получила название Oracle 10G? Что отличает идеальную концепцию Grid от реальности?

Термин Grid относительно недавно начал входить в лексикон ИТ-специалистов, однако, по мнению аналитиков, эта идея способна столь же радикально изменить мир информационных технологий, что и идея Internet. Одним из символов начала новой эпохи стало появление СУБД Oracle 10G, позволяющей создавать и выполнять приложения в среде Grid.

Концепция

О концепции Grid написано уже немало; кратко напомним суть очень простой идеи, давно описанной писателями-фантастами.

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

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

Очень часто в связи с данной концепцией упоминают термин вычислительная коммунальная услуга (computing utility); действительно, Grid позволяет получить вычислительные ресурсы точно так же, как мы получаем другие коммунальные услуги — электричество, газ, воду и т.д. [3]. Часто говорят и о виртуализации: в Grid работают не с множеством мелких компьютеров, а с виртуальным суперкомпьютером, не с множеством дисков, а с общей виртуальной областью хранения данных (рис. 1).

Рис. 1. Модель Grid

В 1969 году, задолго до появления первых работ по Grid [1, 2] один из основоположников Internet Лен Клейнрок предсказывал: «Мы, возможно, станем свидетелями распространения ?computer utilities?, которые, так же, как сегодня телефонные услуги, будут доступны во всех домах и офисах по всей стране». Конечно, это идеальная картина, но приступать к реализации данной концепции в рамках одной организации уже можно. Предоставляя единый вычислительный ресурс, необходимо обеспечить ряд требований. Не должно возникать ситуации, когда пользователь будет ждать выделения ресурса. Еще более сложная задача — сделать необходимую для выполнения вычислений информацию доступной в нужное время и в нужном месте. Так, если речь идет о быстрой переброске огромных массивов данных в ту часть света, где есть свободные вычислительные мощности, то сегодня эта задача невыполнима, но в рамках предприятия и ограниченного числа файлов и баз данных решить ее можно. Необходимо также обеспечить постоянную работоспособность Grid — выход из строя отдельных элементов не должен останавливать работу приложений. Ряд решений в этой области (в том числе, кластеры серверов приложений, резервные базы данных и т.д.) уже позволяют обеспечить высокую надежность [5].

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

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

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

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

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

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

Корпоративные Grid-проекты (Grid предприятия, коммерческие Grid) несколько сужают идеальную концепцию, однако уже сегодня позволяют решать типичные для предприятий задачи в среде Grid. Примером платформы для их реализации как раз и является Oracle 10G.

Механизмы Oracle 10G для реализации Grid

Ведущие системные производители уже начали промышленный выпуск решений, позволяющих строить Grid [3], однако программного обеспечения, которое позволило бы коммерческим приложениям работать в подобной среде, компания Oracle выпустила СУБД Oracle 10G (G означает Grid), которая призвана стать платформой для работы приложений в среде Grid.

Рис. 2. Архитектура Oracle Grid

Механизмы Oracle 10G для реализации коммерческой среды Grid можно разбить на следующие группы (рис. 2):

• среда хранения данных Storage Grid;
• среда серверов баз данных Database Grid;
• среда серверов приложений Application Grid;
• средства самонастройки узлов баз данных;
• система управления Grid Control;
• средства для разделения информации между узлами Grid.

Управление хранением данных

Oracle 10G позволяет реализовать новый подход к управлению хранением данных. Функция ASM (Automatic Storage Manager) формирует из наборов дисков единый виртуальный диск, возлагая на СУБД функции менеджера файлов и томов. Администратору необходимо только выполнить команду создания группы дисков (это и есть виртуальный диск) и добавлять вновь подключаемые к системе диски в группу (это тоже одна команда). СУБД Oracle сама работает с этой группой дисков. На деле СУБД разбивает все пространство виртуального диска на равные кусочки размером в 1 Мбайт и создает из них виртуальные файлы базы данных, табличные пространства, тома и т.д. Администратор может видеть знакомые ему элементы наподобие дисков и файлов, хотя в действительности это лишь логическое представление этих объектов. Oracle не только создает файлы баз данных на этом виртуальном диске, но и обеспечивает на нем зеркалирование и расщепление (striping) данных. Это делается без вмешательства администратора и в случае сбоев блоков на диске позволяет автоматически восстанавливать испорченные блоки.

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

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

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

Database Grid

Database Grid — это развитие архитектуры Oracle Real Application Clusters (RAC). Однако если раньше для организации кластера требовалось установить поверх стандартной операционной системы дополнительное специализированное программное обеспечение третьих фирм, то теперь у Oracle имеется собственный инструментарий Clusterware, поставляемый с 10G для любых платформ. Кроме того, в составе RAC поставляется кластерная файловая система Cluster File System, позволяющая реализовать кластер баз данных не на «сырых устройствах»» (raw device), а поверх обычной операционной системы. Раньше приходилось размещать разделяемые узлами RAC файлы кластерной базы данных на сырые устройства (СУБД Oracle работала с файлами напрямую, в обход файловой системы, обеспечивая одновременное использование этих файлов разными компьютерами, при том, что администрирование сырых устройств сложнее, чем работа с файлами). Программное обеспечение Oracle размещалось в каталогах операционной системы и не разделялось узлами. Теперь же, Oracle Cluster File System заменяет обычную файловую систему, и в ней могут размещаться и совместно использоваться как файлы кластерной базы данных, так и файлы программ Oracle. Администрирование файлов Cluster File System не сложнее, чем администрирование файлов обычной операционной системы.

Для создания среды Grid серверов баз данных необходимо обеспечить возможность автоматического динамического подключения и отключения дополнительных вычислительных ресурсов сервера баз данных. Каждое приложение (CRM, ERP, кадры, зарплата и т.д.) можно рассматривать как сервис, работающий на нескольких узлах Grid. Администратор Grid может для каждого сервиса определить узлы, на которых этот сервис запускается сразу при старте (PREFERED-узлы), и узлы, которые этот сервис будет использовать дополнительно при определенных условиях (AVAILABLE-узлы); на остальных узлах Grid этот сервис запускаться не может.

Oracle RAC 9.2 позволяет динамически, не останавливая работу приложения, подключать/отключать новые экземпляры Oracle. Эта технология используется и в версии 10G: администратор описывает правила «переползания» сервиса на дополнительные узлы. Допустим, сервис CRM запустился на двух узлах и работает с базой данных. СУБД постоянно измеряет нагрузку на узлы и если она превысит заданный в правилах предел, то на одном из разрешенных дополнительных узлов автоматически запустится новый экземпляр Oracle; при этом часть пользовательских сеансов автоматически «переползет» на новый узел, а вычислительный ресурс для сервиса увеличится. При дальнейшем увеличении нагрузки будут запускаться новые экземпляры Oracle на AVAILABLE-узлах. При снижении нагрузки узлы будут освобождаться, и их смогут использовать другие сервисы: один и тот же узел может быть описан как дополнительный сразу для нескольких сервисов.

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

Администратор может подключать новые компьютеры к Grid и добавлять их в список основных и дополнительных узлов сервиса. Можно создать несколько вариантов списков узлов и политик для сервисов и активизировать разные варианты в разные периоды времени (скажем, можно создать отдельный вариант для конца квартала). Администратор, используя компонент Grid Control Enterprise Manager, может управлять сервисами — стартовать их, останавливать, подключать и конфигурировать узлы и т.д.

Перенос обычных приложений Oracle в среду Grid не требует изменения кода, достаточно указать, что приложение работает не с конкретным узлом, а с сервисом. Так, при соединении клиента SCOTT с паролем TIGER с сервисом myservice надо просто написать в строке связи:

SCOTT/TIGER@//myVIP/myservice.

Application Grid

Уже в Oracle 9i можно было организовать кластеры серверов приложений: транзакция, начавшаяся на одном сервере приложений, могла в случае его остановки продолжиться на других серверах кластера. Grid Control Enterprise Manager позволяет добавлять новые узлы в кластер сервера приложений, управлять этими узлами и кластером, стартовать и останавливать эти узлы. При необходимости узлы могут быть исключены из кластера и отданы под другие нужды (Web-кэш, сервер баз данных и т.д.).

Grid Control позволяет управлять всеми компонентами сервера приложений. Сервер приложений тесно связан с узлами сервера баз данных; при выходе из строя узла сервера баз данных, сервер приложения тут же узнает об этом и переключается на оставшиеся узлы.

Самонастройка СУБД

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

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

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

Кроме того, в состав инфраструктуры настройки входит набор предустановленных программ анализа и фиксации проблем Automatic Maintenance Tasks. Они могут запускаться по расписанию или по запросу администратора, анализировать накопленные за длительное время данные из AWR и выполнять более тонкие настройки СУБД, SQL и т.д.

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

Grid Control

Для управления, конфигурирования и диагностики множества разнородных узлов, составляющих Grid, в составе стандартного средства управления Oracle Enterprise Manager появился модуль Grid Control, позволяющий управлять всеми компонентами Grid: серверами баз данных, серверами приложений, кэшами, Java-машинами, устройствами хранения, сетевыми компонентами, RAC, распространением данных и т.д. Поскольку индивидуально управлять каждым компонентом сложно, их можно объединить в группы. Например, группа компонентов, на которых работает приложение, может включать серверы баз данных, серверы приложений, кэши и т.д. Для группы можно установить сводные характеристики (работоспособность всех компонентов, наличие проблем или извещений в группе и т.д.). Администратор будет отслеживать состояние не отдельных объектов, а групп объектов, и проводить операции с ними. Впрочем, при желании можно спуститься и до уровня отдельного компонента группы.

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

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

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

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

Улучшен механизм применения заплат; все заплаты для разных продуктов, платформ и версий выкладываются на сайт metalink, к которому может обратиться Grid Control, проанализировать наличие еще не установленных заплат и сообщить об этом администратору. Если администратор «даст добро», система выгрузит заплаты и применит к тем узлам, где это необходимо.

Поскольку в Grid работает множество пользователей, приложений, баз данных и серверов приложений, особую актуальность приобретает проблема управления правами доступа пользователей к этим ресурсам. Grid Control обеспечивает единую точку входа (Single Sign-On) для пользователей многих ресурсов. Понятие «пользователь» отделено от понятия Account (пользователь конкретной базы данных, конкретного сервера приложений и т.д.). Информация о пользователях Grid хранится в каталоге LDAP, который сопоставляет пользователю его права для входа в различные компоненты Grid.

Когда система самонастройки сервера выявляет проблемы, требующие вмешательства администратора, она посылает извещение Grid Control; оператор узнает о проблеме и получает возможность исправить ситуацию. Мощная система советов и подсказок Advisory Infrastructure выполняет за администратора значительную часть работы по решению проблемы; часто ему остается лишь подтвердить свое согласие на внесение изменений в настройку.

Grid Control позволяет управлять ресурсами сервера, доступными пользователю. Oracle Resource Manager позволяет ограничить максимальное время выполнения запросов, степень использования процессоров, максимальное количество одновременных сеансов, степень распараллеливания при выполнении запросов и т.д. План использования ресурсов Resource Plan можно быстро переключать (например, включать дневной или ночной план).

Разделение информации между узлами

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

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

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

СУБД Oracle умеет распознавать распределенные запросы и оптимизировать их выполнение с учетом характеристик используемых узлов и баз данных. Если надо организовать работу со структурированным объектом (таблицей), части которого хранятся в различных базах, то с помощью оператора объединения UNION можно создать виртуальное представление всего объекта и работать с ним, а уж Oracle преобразует операции с объектом в операции с его частями в разных базах. Работа с распределенной базой данных требует, чтобы в момент выполнения операций существовала хорошая связь со всеми используемыми базами. Если связь прервется, то запрос выполнен не будет. Кроме того, если базы сильно удалены друг от друга, необходимо иметь очень хорошие быстрые сети передачи данных; поэтому часто используется механизм создания в каждой группе узлов Grid локальной базы данных, содержащей копии объектов основной базы. Для создания таких локальных баз надо обеспечить быстрый перенос части данных из одной базы данных в другую, а также постоянную синхронизацию данных.

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

Перемещаемые файлы можно, например, записать на компакт-диск и подключать к различным базам данных в виде набора открытых только на чтение таблиц. В Oracle 10G реализована возможность транспортировки табличных пространств между различными операционными системами. Так, с помощью утилиты RMAN можно со скоростью работы по протоколу FTP переместить большие таблицы из базы данных в Windows в базу в ОС Linux. Для переноса небольших таблиц можно использовать новую утилиту Data Pump, функциональность которой аналогична тому, что умели делать старые утилиты экспорта/импорта, но работает она намного быстрее. Так, импорт данных выполняется в Data Pump в 20-30 раз быстрее, чем раньше. Используется механизм распараллеливания вычислений, возможен рестарт работы утилиты с той точки, где она прервала свою работу. Data Pump позволяет выполнить прямой перенос данных из одной базы данных в другую без создания промежуточных файлов на диске.

В Grid часто информация может храниться не в базе данных, а в файлах операционной системы. Механизм Oracle External Table позволяет использовать средства работы с базой данных для работы с информацией файлов. Файлы определяются в словаре базы данных как внешние таблицы, и далее с ними можно работать на чтение (и на запись в Oracle 10G) как с обычными таблицами. Более того, можно выполнять операции, одновременно работающие с реляционными таблицами баз данных и информацией файлов операционной системы.

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

Grid и реальность

Конечно, Oracle 10G — только первый шаг на длинном пути развертывания корпоративных Grid-вычислений. Сегодняшние предложения по реализации Grid сильно отличаются от идеальной концепции, сужая ее, однако позволяют уже сейчас начать пользоваться преимуществами Grid.

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

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

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

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

Литература

1. I. Foster, C. Kesselman, S. Tuecke. The Anatomy of the Grid: Enabling Scalable Virtual Organizations. International Journal, Supercomputer Applications, 15 (3), 2001, http://www.globus.org/research/papers.html.
2. I. Foster, C. Kesselman, J. Nick, S. Tuecke, The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration. Open Grid Service Infrastructure WG, Global Grid Forum, June 22, 2002, http://www.globus.org/research/papers.html.
3. Наталья Дубова, Учет и контроль для "коммунальных вычислений". // Открытые системы, 2003, № 1.
4. Павел Анни, Этот Grid - неспроста. // Открытые системы, 2003, № 1.
5. Марк Ривкин, Новые возможности Oracle 9.2. // Открытые системы, 2002, № 11.
6. Марк Ривкин, Распределенные СУБД. // Мир ПК, 1993, № 5.