Интересно для всех

Крис Смит
Platform Computing

Вычислительные Grid-сети встречаются с базами данных
(Computational Grids Meet the Database, by Chris Smith, Platform Computing)

Источник: конференция OracleWorld2003, San Frncisco, https://www.oracleworld2003.com/published/36686/36686_Smith.doc

Введение

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

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

В этой статье для решения специфических проблем организации предлагаются три примера использования grid-технологий:

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

В каждом случае решение проблемы базируется на технологиях Oracle и компании Platform Computing.

Автоматизация пакетных процессов

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

Чтобы обеспечить такие возможности в средах, работающих с несколькими базами данных и несколькими вычислительными механизмами, не использующими базы данных, программный продукт Platform JobScheduler был интегрирован с пакетом DBMS_JOB, входящим в состав Oracle Database 9i. Кроме того, планируется его интеграция с пакетом DBMS_SCHEDULER, входящим в состав Oracle Database 10g.

Интегрированное решение дает возможность компаниям упростить их среду планирования. Пользователи могут проектировать и контролировать планирование и выполнение заданий базы данных, используя Platform JobScheduler. Несколько типов заданий, включая задания базы данных Oracle или обычные программы, исполняемые из командной строки, могут быть спланированы с использованием того же самого планового решения. Задания для всего предприятия могут быть сохранены в центральном репозитории, а для планирования и управления этими заданиями может быть использован единый графический интерфейс. Задания базы данных могут быть включены в сложные бизнес-потоки, которые могут использоваться для запуска других заданий или потоков заданий.

Интеграция Platform JobScheduler и Oracle DBMS_JOB обеспечивает для планируемых заданий и потоков заданий улучшенные операционные характеристики. Размещенные с использованием Platform JobScheduler задания базы данных пользуются всеми преимуществами механизма восстановления Oracle DBMS_JOB. В случае отказа задания базы данных, которые выполнялись в тот момент, когда база данных вышла из строя, закончатся аварийно, и все их незафиксированные изменения будут отменены. Задание базы данных будет автоматически перезапущено при повторном открытии базы данных. Если в процессе выполнения этих заданий базы данных происходят ошибки, база данных будет пытаться повторно запустить их. Предоставление Platform JobScheduler возможности размещать задания базы данных в Oracle DBMS_JOB позволяет более эффективно использовать ресурсы базы данных.

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

Рисунок 1: Архитектура планировщика заданий
Надписи на рисунке

Проектирование процессов/ управление процессами	Планирование времени, заданий, файлов и других событий	Инфраструктура выполнения приложений с возможностью работы в grid-структурах
Загрузка XML Сохранение XML	Регистрация	База данных Oracle
Клиент	Сервер Jobflow (потоков заданий)	Ведущее устройство и агенты Grid

На рисунке 1 показана архитектура Platform JobScheduler. Клиенты, как при проектировании потоков, так и при контроле/управлении потоками, подключаются к серверу Jobflow, который является ответственным за координацию индивидуальные заданий потоков, а также за управление зависимостями между заданиями, календарными событиями, исключительными ситуациями и другими внешними событиями. Сервер Jobflow в свою очередь связывается с промежуточными сетевыми программными средствами, которые выполняют либо задания командной строки, либо задания DBMS_JOB.

Сама интеграция структурирована, как это показано на рисунке 2, а различные ее компоненты описываются ниже.

Рисунок 2: Интеграция Platform JobScheduler и планировщика Oracle
Надписи на рисунке
1 - Клиент Platform JobSheduler
2 - Сервер Platform JobSheduler
3 - Главный хост-компьютер LSF
4 - Хост-компьютер LSF
      Кластер LSF
      Клиент Oracle
C & B - Экземпляры Oracle

1. Редактор потоков (Flow Editor) Platform JobScheduler используется для определения потока. Шаблон приложения Oracle используется редактором потоков для создания одного или более заданий Oracle (хранимых процедур или анонимных блоков PL/SQL).

   К числу параметров определения задания Oracle относятся:

   • Имя сервиса Oracle
   • Имя пользователя Oracle и пароль
   • Имя хранимой процедуры
   • Параметры хранимой процедуры
2. Полное определение потока затем размещается на сервере Platform JobScheduler. Поток либо планируется к выполнению в конкретное время, инициируемое завершением другого потока или поступлением файла, либо инициируется вручную с использованием менеджера потоков Platform JobScheduler. При инициации потока сервер Platform JobScheduler управляет зависимостями внутри потока. Когда задание готово к выполнению, сервер Platform JobScheduler размещает его на главном хост-компьютере сети.
3. Главный хост-компьютер сети (grid) управляет всеми зависимостями ресурса, которые могут иметься у задания, и отсылает задание Oracle соответствующему хост-компьютеру сети. Задание Oracle запускает на хосте сети сценарий orajobstart. Сценарий orajobstart подключается к базе данных Oracle, используя информацию для подключения, предоставленную при определении задания Oracle. Затем задание Oracle размещается в базе данных Oracle для выполнения, используя процедуру DBMS_JOB.SUBMIT.
4. При завершении задания Oracle результат посылают назад на главный хост-компьютер сети, который в свою очередь посылает его назад серверу Platform JobScheduler, а статус задания отражается в менеджере потоков Platform JobScheduler. Внешний администратор системы информационного обслуживания загрузки (external load information manager – elim) собирает информацию о загрузке Oracle, которая может использоваться для заданий Oracle как регулятор, чтобы конкретный сервер базы данных был не перегружен запросами на выполнение заданий.

Для посылки работы планировщику базы данных Oracle применяемый сегодня способ интеграции использует интерфейс DBMS_JOB, который обеспечивает достаточные функциональные возможности для размещения заданий и мониторинга их исполнения. В будущем планируется переработать интеграцию с использованием нового пакета DBMS_SCHEDULER, введенного в Oracle Database 10g. Мало того, что этот механизм более эффективен при размещении и заданий и управлении ими, новый способ интеграции усовершенствован так, чтобы поддерживать:

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

Platform JobScheduler балансирует нагрузку между несколькими экземплярами базы данных, предоставленных для задания, а задания Oracle “убиваются” через интерфейс Platform JobScheduler.

Типично Platform JobScheduler, интегрированний Oracle, используется в потоках заданий по извлечению, преобразованию и загрузке (Extract Transform and Load – ETL) для хранилищ данных. Обычно такие задания агрегируют данные из различных источников, как из базы данных, так и из файлов, и часто представляют собой смесь утилит командной строки и хранимых процедур Oracle, которые должны быть запущены, чтобы выполнить шаги, связанные с загрузкой, преобразованием и очисткой данных. Дополнительно, как только хранилище данных загружено, можно инициировать еще ряд последующих задач, включая агрегирование частей данных и загрузку их в витрины данных (data marts), а также порождение отчетов, базирующихся на новой информации.

На рисунке 3 показан типичный поток ETL. В конкретное время – каждый день, когда готовы рыночные данные, – выполняется поток, который принимает рыночные данные в формате простого файла, и комбинирует их с данными о торговле для филиала брокерской фирмы, которые хранятся в базе данных Oracle, и извлекаются с использованием хранимых процедур. Выполняются две внешние программы, которые проводят некоторую очистку (шаг FX_step), после чего данные объединяются и загружаются в базу данных, используя SQL*Loader. В завершение, прежде чем можно будет отрапортовать о потоке, как о завершенном, выполняются некоторые хранимые процедуры, проводящие анализ торговой деятельности за день.

Рисунок 3: Поток заданий ETL

Вычисление пропускной способности многоузловой конфигурации

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

Чтобы использовать имеющиеся вычислительные ресурсы внутри предприятия, многие компании развернут Platform MultiCluster для агрегации компьютеров между различными отделами и местоположениями в организации. Когда местные вычислительные ресурсы будут полностью загружены, планировщик Platform MultiCluster начнет пересылать задания в отдаленные узлы сети, обеспечивая, таким образом, более быстрое завершение высокоприоритетных проектов, так как у них имеется больший пул вычислительных мощностей, доступных для применения при изучении пространства параметров.

Но при таком подходе имеется проблема, зависящая от требований ввода/вывода (IO) распределяемого приложения, – местоположение данных. Обычно при подобных моделированиях продуцируется большое количество данных, которые постоянно находятся в центральных базах данных. Эти данные могли бы быть моделями компонентов чипа, данными о соединениях, программными библиотеками и т.д. Так как у многих компаний нет сетей с очень высокой пропускной способностью, передача данных для каждого задания становится очень дорогим, а время задержки, обусловленное перемещением гигабайтов данных, может часто начинает превосходить время непосредственного выполнения моделирования. Решением может стать кэширование баз данных, которые могли бы использоваться при моделировании в удаленных узлах сети.

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

Для разрешения этих проблем управления можно применить решение, интегрирующее Oracle Streams, имеющемся в Oracle Database 10g, и встроенный в менеджер ресурсов Platform LSF модуль планирования, который “знает о базе данных". Это служит гарантией, что кэши будут отслеживаться, а перемещаться (из узла в узел) будут только данные, необходимые для исследований.

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

В том случае, когда Platform MultiCluster посылает задание в удаленный узел сети, локальные ресурсы полностью расписаны, и прежде, чем задание будет выполнено, планировщик Platform LSF получает задание и выполняет сценарий предварительного выполнения (pre-execution script). Этот сценарий сначала проверяет гарантии того, что требующаяся база данных была перемещена в удаленный узел сети, пытаясь выполнить подключение к базе данных. Если база данных была уже передана, то выполнение задания может быть продолжено. Иначе сценарий предварительного выполнения инициирует перемещение базы данных, и переносит ее в интерактивном режиме в локальный экземпляр. Последовательность действий, которые предпринимаются Platform LSF и сценарием предварительного выполнения проиллюстрирована на рисунке 4.

Это достигается за счет использования процедуры MAINTAIN_TABLESPACES, предлагаемой в составе пакета DBMS_STREAMS_ADM. Эта процедура использует для того, чтобы выполнить перемещение и установку базы данных в удаленном узле сети, мобильные табличные пространства, Data Pump, пакет DBMS_STREAMS_TABLESPACE_ADM и пакет DBMS_FILE_TRANSFER. После завершения перемещения применяются любые сделанные тем временем изменения и автоматически синхронизируются любые дальнейшие изменения, для чего используется Oracle Streams. Сценарий предварительного выполнения может быть реализован на любом языке, приводящем к созданию исполнимой программы, так что для того, чтобы осуществить взаимодействие с базой данных Oracle можно использовать любое множество языков, (например, ProC, Java, perl, основной сценарий выполнения sqlplus и т.д.). Сценарий предварительного выполнения может быть сконфигурирован так, чтобы он выполнялся от имени определенного пользователя. Поэтому, если узел использует аутентификацию пользователей для базы данных средствами ОС, для того, чтобы производить требующееся перемещение, необходимо использовать для выполнения сценария предварительного выполнения надлежащего пользователя.

Рисунок 4: Управляемое рабочей нагрузкой управление данными
Надписи на рисунке
      Кластер LSF 1.
      Кластер LSF 2.
1 - Пересланное задание
2 - Запустить предварительное выполнение
      Главная база данных о молекулах (MOL)
3 - Подключиться к MOL и выполнить MAINTAIN_TABLESPACES
4 - Пересылк метаданных и табличных пространств MOL
5 - Завершение предварительного выполнения
6 - Запуск задания
     Поддерживаемая с помощью Streams версия MOL
     Операторы DML обновлений Streams
     Табличные пространства для MOL
7 - Задание использует копию
     Табличные пространства для MOL

Реализация Oracle Streams для Oracle Database 10g делает этот процесс намного более простым, чем в предыдущих версиях базы данных. Во-первых, механизм переносимых табличных пространств позволяет автоматически преобразовывать форматы файла в различных архитектурах, так что узлу, экспортирующему данные и задания, более не приходится волноваться о том, чтобы в удаленных узлах (которые вполне могут оказаться вне их административного контроля), экземпляры базы данных выполнялись на том же самом типе аппаратных средств. Во вторых, процедуры, определенные в пакете DBMS_STREAMS_ADM, значительно упрощают процесс перемещения, так как все детали, типа установки базы данных в режим “только для чтения”, выполнения экспорта и передачи файлов обрабатываются процедурой стандартизированным способом. Наконец, Data Pump обеспечивает намного более эффективный способ экспорта и импорта метаданных базы данных, сокращая время ожидания процесса передачи.

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

Инфраструктура планировщика Platform LSF встроена в модули планировщика, каждому из которых нужно реализовать две подпрограммы: match и order. Подпрограмма match отвечает за составление списка определений заданий и нахождение списка хостов, удовлетворяющих требованиям задания к ресурсам. Если имеется 4 задания и 2 хоста, задание номер 1 могло бы соответствовать хосту B, задание номер 2 могло бы соответствовать хостам A и B, задание номер 3 могло бы соответствовать хосту A, а заданию номер 4 мог бы не соответствовать ни один из хостов.

Подпрограмма order отвечает за перечисление списка заданий в том порядке, в котором они должны быть диспетчеризованы. При условии, что имеет место приведенное выше соответствие хостов и заданий, этот список мог бы иметь вид: задание 1, задание 3 и задание 2 (помните, что заданию 4 не нашлось соответствия). При таком упорядочивании задание 2 не будет диспетчеризовано, потому что задания 1 и задание 3 имеют более высокое старшинство, и хосты для них будут выделены прежде, чем будет рассмотрено задание 2.

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

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

Рисунок 5: Планирование с учетом работы с базами данных
Надписи на рисунке
1 - Опрос (poll) установок данных при помощи Сервиса Управления Данными
      Узел 1 – MOL, MOL2
      Узел 2 – (нет)
      Узел 3 – MOL     
2 - Обновление данных в кэшах
3 - bsub - extsched MOL
4 - Локальный узел перегружен:
      Встроенный модуль планировщика, готового к работе с базами данных, принимает
      решение переслать задание в узел 3, так как в нем имеется база данных MOL     
5 - Задание пересылается в узел 3

Виртуализация сервисов

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

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

Чтобы эффективно использовать эти ресурсы, требуется механизм управления политиками, который будет контролировать использование обращающихся к ним баз данных и приложений, и обеспечит повторную подготовку системы к работе на базе текущей загрузки системы и имеющихся бизнес-политик и соглашений об уровне обслуживания (SLA - Service Level Agreements).

Чтобы продемонстрировать этот тип функциональных возможностей, исследователи из Platform Computing создали демонстрационную систему, которая моделирует бизнес-приложения, использующие технологии сетевых вычислений Platform Computing, чтобы автоматически подготовить к работе Oracle RAC и приложения, базируясь на бизнес-политиках.

Цели и функциональные возможности демонстрационной системы

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

К главным демонстрируемым функциональным возможностям относятся:

• Динамическкое предоставление рабочей нагрузки на Oracle RAC
• Принудительное выполнение SLA на основе политик
• Совместное использование ресурсов несколькими базами данных и приложениями в кластерах Oracle RAC и узлах приложений

Система и среда

• Аппаратные средства: 4 узла Linux Enterprise Server, установленные, как узлы базы данных с использованием Oracle RAC, и 4 других Linux-узла, установленные, как узлы приложений.
• Две базы данных – dbFinanceиdbHR – которые совместно используют эти 4 узла Oracle RAC
• Два образца приложений Java:appDBAccess(90 % обращений к базе данных и 10 % вычислений) и appCompute(10 % обращений к базе данных и 90 % вычислений). Вначале мы просто непосредственно используем JRE, чтобы можно было выполнять приложения. Впоследствии мы могли бы добавить Oracle AS или некоторые другие серверы приложений, динамически инициировать сервисы базы данных, прикладные сервисы и приложения.

Динамическая инициализация на уровне базы данных

Первоначально мы имеем первый узел Oracle RAC, на котором выполняется dbFinance и второй и третий узлы Oracle RAC, где выполняется dbHR. Затем мы запускаем много клиентов appDBAccess, чтобы разделить нагрузку от dbFinance, и имеем несколько клиентов appDBAccess, чтобы разделить нагрузку от dbHR, но с малым воздействием на dbFinance.

Если мы не применим наше решение, мы увидим, что время реакции dbFinance становится очень большим, в то время как dbHR – почти простаивает, а 4-ый узел Oracle RAC простаивает полностью.

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

Следует определить две политики:

• "Если нагрузка по доступу для данного экземпляра базы данных слишком высока И (AND) имеется узел, сконфигурированный для Oracle RAC, в котором не эксплуатируется экземпляр базы данных, ТОГДА (THEN) запустите в этом узле новый экземпляр базы данных”.
• "Если загрузка по доступу для экземпляра базы данных является слишком низкой, И (AND) имеется более одного узла, в котором выполняется экземпляр базы данных, ТОГДА (THEN) остановите экземпляр базы данных в одном из узлов, в которых выполняется экземпляр базы данных”.

В результате применения этих политик должно получиться, что:

• Число узлов, используемых для dbHR, автоматически уменьшится, а число узлов, используемых для dbFinance, увеличится.
• Время реакции dbFinance сократится до нормального.

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

Первоначально мы имеем ситуацию, когда на 1-м узле Oracle RAC выполняется dbFinance, а на 2-ом узле Oracle RAC выполняется dbHR. Приложения являются смесью appDBAccess и appCompute, с равным числом клиентов, обращающихся к dbFinance и dbHR. Для того чтобы определить, может ли в данном узле выполняться клиент, или нет, менеджер рабочей нагрузки будет использовать системную нагрузку.

Если мы не применим наше решение, мы увидим, что некоторые приложения appCompute не могут быть диспетчированы для выполнения из-за чрезмерной загрузки системы в вычислительных узлах, в то время как 3-ий и 4-ый узлы Oracle RAC полностью простаивают.

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

Ниже будут определены три политики:

• "Если рабочая нагрузка узла с приложениями высока, ТОГДА (THEN) не диспетчируйте приложения в этот узел приложений, ИНАЧЕ (ELSE) диспетчируйте приложения в этот узел”.
• "Если имеются ожидающие приложения, И (AND) рабочая нагрузка во всех узлах приложений высока, И есть узел Oracle RAC, в котором не выполняется экземпляр базы данных, ТОГДА (THEN) диспетчируйте приложение в узел RAC Oracle”.
• "Если есть потребность запустить новый экземпляр базы данных (подобно первому сценарию), И есть приложение, выполняющееся в узле Oracle RAC, И (AND) нет другого простаивающего узла Oracle RAC, ТОГДА (THEN) выгрузите выполняющееся приложение, И запустите новый экземпляр базы данных в узле Oracle RAC”.

В результате применения этих политик должно получиться, что:

• Некоторые приложения, ожидающие диспетчирования, вследствие загруженности вычислительных узлов, будут автоматически диспетчированы на третий и четвертый узлы Oracle RAC.
• Когда нагрузка доступа для приложения dbH разделяется, приложения, выполняющиеся в узле Oracle RAC, будут выгружены, и будет запущен новый экземпляр dbHR в освободившемся узле Oracle RAC.

Архитектура демонстрационной системы

Архитектура программных систем, которые обычно используются для реализации демонстрационной версии инициализации, изображена на рисунке 6. Компоненты диаграммы базируются на системе управления событиями SiteAssure компании Platform Computing и ее же продукте Workload Management Solutions. К числу компонент относятся:

• SGM – Service Grid Manager является центральным менеджером, используемым для управления всеми сервисами и приложениями в системе, включая принудительное выполнение политики SLA, динамическую инициализацию и управление ресурсами/средствами контроля/состоянием
• SAM – Service Agent Manager является главным агентом, используемым для управления сенсорными и моторными агентами нижнего уровня. В каждом управляемом узле имеется один SAM.
• Агент – Агентом называется исполнимая программа, используемая для взаимодействия с конкретным типом или группой сервисов и экземпляров приложений.

Рисунок 6: Демонстрационная архитектура инициализации RAC
Основные надписи на рисунке:
Управление на основе событий
Управление на базе рабочей нагрузки

Результаты

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

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

Имеющиеся политики:

• Выяснить состояние системы: каким является текущее состояние узлов-кандидатов (то есть узлов, в которых не выполняются никакие экземпляры).
• База данных сильно загружена – является кандидатом на запуск нового экземпляра базы данных.
• База данных слабо загружена – узел является подходящим для выключения выполняющегося в нем экземпляра базы данных.

На рисунке 7 изображено обнаружение неактивных узлов RAC.

Рисунок 7: Обнаружение

Info	2003-06-04 21:18:19 GMT	CONDITION	masterResRACa…	No_DB_Running asserted
Info	2003-06-04 21:18:18 GMT	CONDITION	masterResRACa…	No_DB_Running asserted

На рисунке 8 показана регистрация событий, когда обнаружена высокая нагрузка на dbHR. В этом случае находится узел-кандидат, этот узел удаляется из списка свободных узлов, в нем запускается экземпляр базы данных dbHR и узел добавляется в список узлов, в которых выполняется dbHR.

Рисунок 8: Обнаружена высокая нагрузка

Info	2003-06-04 21:23:21 GMT	ACTION	masterResStack…	pushStack $name=”Stack_HR_DB_Hosts” $value=”pe02” in action
Good	2003-06-04 21:23:20 GMT	ACTION	masterResRACa…	startDbInstance $db=”secdb” $host=”pe02” in action
Info	2003-06-04 21:23:19 GMT	ACTION	masterResStack…	popStack $name=”Stack_Free_Hosts” in action
Info	2003-06-04 21:23:19 GMT	ACTION	RE	React_High_Load dbHR--0:Get_HR_Candidate_Name executed
Good	2003-06-04 21:23:19 GMT	CONDITION	masterResStack…	Have_Free_Hosts_For_HR asserted
Warning	2003-06-04 21:23:19 GMT	CONDITION	masterResRACa…	High_Load_dbHR asserted

На рисунке 9 показаны события, когда продолжается высокая нагрузка, что заставляет систему добавить другой (еще один) хост кандидатом в узлы, в которых эксплуатируется экземпляр dbHR.

Рисунок 9: Продолжающаяся высокая нагрузка

Info	2003-06-04 21:28:20 GMT	ACTION	masterResStack…	pushStack $name=”Stack_HR_DB_Hosts” $value=”pe03” in action
Good	2003-06-04 21:28:19: GMT	ACTION	masterResRACa…	startDbInstance $db=”secdb” $host=”pe03” in action
Info	2003-06-04 21:28:18 GMT	ACTION	masterResStack…	popStack $name=”Stack_Free_Hosts” in action
Info	2003-06-04 21:28:18 GMT	ACTION	RE	React_High_Load dbHR--0:Get_HR_Candidate_Name executed
Good	2003-06-04 21:28:18 GMT	CONDITION	masterResStack…	Have_Free_Hosts_For_HR asserted
Warning	2003-06-04 21:28:18 GMT	CONDITION	masterResRACa…	High_Load_dbHR asserted

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

Рисунок 10: Низкая нагрузка

Info	2003-06-04 21:38:21 GMT	ACTION	masterResStack…	pushStack $name=”Stack_Free_Hosts” $value=”pe03” in action
Good	2003-06-04 21:38:20: GMT	ACTION	masterResRACa…	stopDbInstance $db=”secdb” $host=”pe03” in action
Info	2003-06-04 21:38:19 GMT	ACTION	masterResStack…	popStack $name=”Stack_HR_DB_Hosts” in action
Info	2003-06-04 21:38:19 GMT	ACTION	RE	React_Low_Load dbHR--0:Get_HR_Host_To_Remove executed
Good	2003-06-04 21:38:19 GMT	CONDITION	masterResStack…	Allocated_Spare_For_HR asserted
Warning	2003-06-04 21:38:18 GMT	CONDITION	masterResRACa…	Low_Load_dbHR asserted

Резюме

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

Технологии компании Platform Computing для управления рабочей нагрузкой и организации работы системы, а также новые характеристики, реализованные в Oracle Database 10g, сегодня могут быть объединены для реализации этих целей. Были исследованы три примера применения сетевых технологий:

• Автоматизация пакетных процессов, демонстрирующая координированное планирование как вычислительных ресурсов, так и ресурсов баз данных путем интеграции Platform JobScheduler сOracle Database 9i, и продолжение этой технологии в Oracle Database 10g.
• Вычисление пропускной способности многоузловых конфигураций, когда организации могут усилить использование вычислительных ресурсов, раскиданных по всей организации. Такие характеристики Oracle Database 10g как переносимые табличные пространства, Data Pump, DBMS_FILE_TRANSFER и DBMS_STREAMS_TABLESPACES_ADM являются основными для того, чтобы позволить прозрачную передачу данных между географически распределенными узлами полностью согласованным способом.
• Виртуализация сервисов, которая описывает систему-прототип, использующую для управления автоматической инициализацией экземпляров баз данных Oracle RAC высокоуровневые бизнес-политики в форме SLA, чтобы соответствовать потребностям рабочей нагрузки организации.

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