Oracle Enterprise Grid

• Сеть устройств хранения данных (Storage Grid);
• Cеть серверов баз данных (Database Grid);
• Cеть серверов приложений (Application Server Grid);
• Система управления (Grid Control)

Storage Grid

Storage Grid строится на основе модуля ASM (Automatic Storage Manager). ASM выполняет функции кластерной файловой системы и менеджера томов. Этот модуль объединяет отдельные диски в дисковые группы, которые управляются специальным экземпляром Oracle. ASM-экземпляр Oracle сервера занимает около 100MB оперативной памяти.

ASM-экземпляр обслуживает запросы баз данных Oracle на открытие, создание и удаление файлов. Один ASM экземпляр может обслуживать несколько баз данных. Любой отдельный ASM-файл может храниться только в одной дисковой группе, однако дисковая группа может содержать файлы от разных баз данных, а одна база данных может иметь свои файлы в разных дисковых группах.

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

ASM разбивает файлы на экстенты и распределяет каждый файл сразу по всем дискам в дисковой группе. Размер экстента может быть 1Mb или 128Kb в зависимости от типа файла. При добавлении диска к дисковой группе ASM в фоновом режиме автоматически переносит часть экстентов с других дисков на новый диск пропорционально его размеру. Это обеспечивает равномерное распределение нагрузки ввода/вывода по всем дискам дисковой группы, т.е. работа по настройке ввода/вывода, требовавшая ранее больших усилий от администратора базы данных, теперь выполняется автоматически. Если администратор хочет отключить диск от системы, он выполняет соответствующую команду и ASM перемещает все экстенты с этого диска на другие диски группы, после чего диск может быть отключен. Добавлять и удалять диски из дисковой группы можно, не останавливая зависимые от неё базы данных Oracle.

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

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

Для защиты данных от сбоев блоков на диске файлы могут зеркалироваться внутри дисковой группы. Возможно двойное и тройное зеркалирование. В отличие от менеджера томов в ASM зеркалируются не диски, а экстенты файлов. Экстент и его копии размещаются на разных физических дисках внутри дисковой группы. Зеркальные копии экстентов одного диска равномерно распределены по другим дискам. В случае выхода из строя диска его нагрузка будет перераспределена по всей дисковой группе. У разных файлов дисковой группы может быть разный режим зеркалирования. Дисковая группа может быть разбита на подгруппы по принадлежности дисков к общему ресурсу, например, контроллеру. В этом случае ASM гарантирует, что экстент и его зеркальная копия будут в разных дисковых подгруппах, обеспечивая тем самым защиту данных от сбоя этого общего ресурса (контроллера, дискового массива и т.д.).

Database Grid

Database Grid является развитием кластерной архитектуры Oracle. Oracle Real Application Clusters (RAC) хорошо зарекомендовал себя во многих проектах. Если раньше для установки кластера требовалось установить для стандартной операционной системы дополнительное специализированное ПО третьих фирм, то в настоящее время специалистами Oracle разработано ПО кластера (Clasterware), которое поставляется с Oracle Database 10G для любых платформ.

Для создания Database Grid необходимо обеспечить возможность автоматического динамического подключения и отключения дополнительных вычислительных ресурсов сервера баз данных. Это делается на основе понятия "сервис". Каждое приложение можно рассматривать как сервис, работающий на нескольких узлах Grid. Администратор Database Grid определяет для каждого сервиса узлы Grid, на которых этот сервис запускается сразу при старте сервиса (предпочтительные узлы) и узлы, которые этот сервис будет использовать дополнительно при определенных условиях (так называемые доступные узлы). На остальных узлах Grid этот сервис запускаться не может.

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

При дальнейшем увеличении нагрузки будут запускаться новые экземпляры Oracle на доступных узлах. При снижении нагрузки узлы будут освобождаться и их смогут использовать другие сервисы (один и тот же узел может быть описан как доступный для нескольких сервисов).

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

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

Application Server Grid

С архитектурной точки зрения, Application Server Grid представляет собой кластер компьютеров, на которых распространена инфраструктура Oracle Application Server 10G и выполняются те или иные его компоненты: Oracle HTTP Server, J2EE Server, WebCache и др. Вычислительные мощности кластера рассматриваются как единый пул ресурсов, динамически выделяемых для функционирования того или иного компонента Oracle AS 10G в соответствии с политиками и стратегиями предоставления ресурсов, а также с учетов состояния всей прикладной программной системы и ее компонентов.

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

Концепция Grid потребовала инноваций в Oracle AS 10G с учетом двух факторов.

1). Ключевым элементом Oracle Grid, и фактической основой ее реализации как раз и является Oracle AS 10G. Сбор информации, ее обработка, обмен, регистрация событий в системе, механизмы управления построены на основе Oracle AS 10G. Oracle AS API был расширен и является теперь неотъемлемым элементом для всех базовых компонентов архитектуры Grid. Унификация удаленного доступа к компонентам архитектуры Grid и возможность сбора, обработки и анализа информации о состоянии компонент распределенной системы в сочетании с управлением их состоянием является краеугольным камнем концепции Oracle Enterprise Grid.

2). Использование Oracle AS 10G в архитектуре Grid потребовало большого количества метрик и статистических показателей (параметров) работы приложений и самого сервера приложений. Таким образом, стало абсолютно необходимым их отслеживание при помощи специальных агентов (spy agents), исполняемых на сервере приложений и встроенных в ядро Oracle AS.

В Grid-архитектуре на Oracle Application Server 10G возложены новые сложные задачи (перечислены в таблице).

Задачи, решаемые Oracle AS 10G в Oracle Enterprise Grid
Управление виртуализированными ресурсами	Resource Management и Resource Planning
Управление нагрузкой на основе политик	Policy-based Workload Management
Планирование исполнения приложений	Application Workload Scheduling
Обеспечение автоматизации функционирования приложений и целевые стратегии	Automated Provisioning
Клонирование программного обеспечения из известных источников	Software Cloning
Обеспечение обслуживания пользователей	User Provisioning
Масштабируемость системы и ее компонентов по требованию или условиям	Scalability On-Demand
Миграция пользовательских сессий между системными компонентами	Session Migration
Быстрое восстановление функционирования приложений	Fast-Start Fault Recovery
Мониторинг производительности приложений	Oracle Grid Performance Monitoring
Установление правил и приоритетов предоставления обслуживания	Service Level Agreements
Регистрации сигналов и сигнальных системных сообщений от приложений, системы и ее компонентов	Customized Alerts

Grid-архитектура предъявляет высокие требования к обеспечению детального анализа (мониторинга) функционирования прикладной программной системы и ее компонентов на следующих уровнях:

a) Состояние системы и ее компонентов - отслеживается по сообщениям системы и ее компонентов, сигналам, через обработку статистики и метрической информации, состояние аппаратной платформы, состояние операционной системы

b) Состояние конкретных приложений, работающих в Grid-архитектуре (получение информации об этом состоянии производится унифицированным способом для всех приложений).

c) Взаимное влияние распределенных приложений друг на друга, проведение анализа этого влияния и корректировка состояния системы, ее компонентов и приложений.

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

Сказанное выше прежде всего касается распределенных J2EE-приложений, использующих стандартные архитектурные элементы J2EE, конструктивы (framework) и Java-паттерны; управление ими реализуется в архитектуре Grid через систему взаимосвязанных управляющих работ и предопределенных уведомлений и сигналов.

Более сложны в настройке классы программных систем, не являющиеся в полной мере объектно-ориентированными (например, распределенные Web-приложения, исполняемые и на Oracle HTTP Server, и на Oracle Containers for J2EE); взаимное влияние их компонентов на работу системы в целом требует более детального рассмотрения. Особый интерес представляют распределенные J2EE-приложения с высокой степенью симметрии и балансировки при их использовании на кластерах серверов приложений, например, приложения без состояния типа Oracle AS Portal; Web-приложения, созданые на базе Struts Framework и им подобные; приложения, написанные с использованием Oracle ADF, а также полностью кластеризуемые J2EE-приложения, как например, J2EE-приложения на осноае Oracle AS TopLink.

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

Grid Control

Для управления, конфигурирования, диагностики множества разнородных узлов, составляющих сеть распределенной обработки данных, Oracle предоставляет инструментарий Grid Control, который позволяет управлять всеми компонентами сети распределенной обработки данных - серверами баз данных, серверами приложений, серверами кэширования, серверами J2EE, устройствами хранения, сетевыми компонентами, распространением данных.

Grid Control включает в себя:

• Oracle Management Service (OMS) - J2EE-приложение, работающее под управлением Oracle AS 10G. OMS использует Oracle базу данных в качестве репозитария, в котором хранит информацию о конфигурации Grid.
• Oracle Management Agents (OMA) - специальные процессы, которые должны быть запущены на каждом узле Grid. OMA контролирует все сервисы узла и исполняет удалённые команды, поступающие от OMS.

Администратор работает с Grid Control, используя консоль, доступную из любого Web-навигатора. Администратор может также иметь доступ к Grid Control с карманного персонального компьютера, используя модуль EM2Go. Взаимодействие между OMS, OMA и консолью администратора осуществляется по протоколу HTTP. Для обеспечения безопасности связи между различными компонентами Grid Control может быть включён протокол SSL.

Для того, чтобы обеспечить управление новым узлом сети посредством Grid Control, достаточно установить на этот узел OMA, возможна его автономная установка через HTTP. При установке OMA автоматически регистрирует новый узел в OMS. Если сеть распределенной обработки данных состоит из большого количества объектов, то стартует несколько OMS, которые будут работать с общим репозиторием; между ними организуется балансировка нагрузки.

Поскольку индивидуально управлять каждым компонентом в большой Grid сложно, их можно объединить в группы. Например, группа серверов баз данных отдела или группа компонентов, на которых работает приложение (она может включать серверы БД, серверы приложений, серверы кэширования). Для группы можно установить суммарные характеристики (например, работоспособность всех компонент, наличие проблем или сообщений об ошибках в группе). Администратор будет отслеживать не состояние отдельных объектов, а состояние групп объектов и проводить операции с группами. При желании, можно спуститься и до уровня отдельного компонента группы (например, узла сервера базы данных). Если какой-то из компонентов Grid становится недоступным или производительность компонента неудовлетворительная, то в консоли Grid Control появляется соответствующее сообщение и дополнительно по e-mail посылается уведомление администраторам, зарегистрировавшимся для получения таких сообщений. Автоматическое наблюдение за компонентами Grid может быть отключено на период проведения регламентных работ.

Система заданий Grid Control позволяет администратору автоматизировать его повседневные задачи, такие как резервирование баз данных, сбор статистики и т.д. Администратор может запускать через систему заданий как поставляемые с Grid Control, так и свои собственные скрипты операционной системы или SQL-скрипты, которые будут выполняться либо один раз, либо периодически, через заданные интервалы времени. Скрипты могут быть выполнены не только на одном объекте Grid, но и на группе объектов.

С помощью Grid Control администратор может клонировать программное обеспечение Oracle и базы данных на другие узлы, причём в новом клоне ПО Oracle настройки, зависящие от параметров узла (IP адрес, имя машины и т.д.), будут автоматически заменены на новые.

Grid Control также предоставляет администратору средства автоматически проверять появление новых критических патчей на сайте технической поддержки Oracle Metalink http://metalink.oracle.com и устанавливать их на соответствующие узлы Grid.