Назад в библиотеку

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

Автор: Ривкин Марк
Источник: «Открытые системы», № 12, 2003

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


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

Концепция

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

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

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

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

Модель Grid

Рис. 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.

Архитектура Oracle Grid

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

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

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

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 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 можно начать реализовывать уже сегодня, но для реализации идеальной концепции придется еще решить множество трудноразрешимых проблем. Среди них:

Литература

  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.