Кластерные технологии Oracle

Written on 12 Декабря 2008. Posted in Oracle

Экономичная масштабируемость - известно, что стоимость SMP-систем от компьютеров одного класса к классу более мощных вычислительных машин. Объединение стандартных недорогих 2-х или 4-х процессорных компьютеров в кластерную систему способно дать ощутимый экономический эффект. Аппаратная часть такой кластерной конфигурации может оказаться в несколько раз дешевле эквивалентной по мощности большой SMPсистемы. Здесь же стоит учесть немалые ежегодные отчисления на контракты поддержки, которые, как правило, требуются для минимизации простое в больших SMP-систем.
Возможность преодоления ограничений одиночных машин - даже самые большие вычислительные машины имеют ограничения на количество процессоров, число карт ввода/вывода, объем памяти и т.д. Кластеры позволяют преодолеть физические ограничения одиночных компьютеров, используя эти компьютеры в качестве "кирпичиков" для построения системы требуемой вычислительной мощности.
Бесперебойная работа - в информационной системе работают множество компонент, самыми важными из которых являются аппаратная часть, операционная система, системное и прикладное программное обеспечение. Сбой любой такой компоненты в отдельно взятой SMP-системе может привести к остановке обслуживания. Узлы кластера взаимозаменяемы, что позволяет перебрасывать решение задач выполнявшихся на узлах вышедших из строя на узлы продолжающие работать.

Система управления базами данных (СУБД) Oracle с помощью опции Real Application Clusters (RAC) может производить обработку единой базы данных одновременно с множества серверов объединенных в кластер. Механизм Oracle RAC поддерживает приложения с любым типом нагрузки, начиная от оперативной обработки транзакций до хранилищ и аналитических систем. В качестве приложений могут быть как "коробочные" продукты, так и самостоятельно разработанные приложения.

RAC обеспечивает для приложений высочайшие уровни доступности и масштабируемости:

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

Технология Oracle RAC позволяет системам, построенным на основе недорогой аппаратной платформы, предоставлять высочайшее качество сервиса, сравнимое и даже превосходящее уровни доступности и масштабируемости самых дорогих SMP-систем и мэйнфреймов. Существенно сокращая расходы на обслуживание, и обеспечивая новые гибкие методы администрирования, программное обеспечение Oracle может быть использовано для создания среды Grid-вычислений предприятия.

Application Clusters

Технология Oracle Real Application Clusters как опция СУБД Oracle была впервые представлена в Oracle 9i. На сегодняшний день Oracle RAC является проверенным решением, которое используется тысячами заказчиков по всему миру во всех отраслях экономики и для любых типов приложений.

Опция RAC расширяет возможности СУБД Oracle, обеспечивая работу ее на кластере. Это позволяет заказчику, используя недорогие стандартные сервера, сократить стоимость владения системой. А возможность динамического добавления и удаления серверов в кластер обеспечивает масштабируемую вычислительную среду для приложений. При использовании Oracle RAC отдельный сервер больше не является компонентой, выход из строя которой, приводит к выходу из строя всей системы. Oracle Real Application Clusters - ключевой компонент Архитектуры Максимальной Доступности (Maximum Availability Architecture) компании Oracle, стратегии по созданию наивысшей доступности приложений.

Архитектура Real Applications Clusters

В "обычной" некластерной конфигурации к базе данных эксклюзивно имеет доступ один экземпляр программного обеспечения СУБД Oracle.

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

Аппаратная архитектура

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

В качестве таких дисковых устройств могут быть использованы дисковые устройства, подключаемые через сеть (NAS), специализированные сети устройств хранения (SAN) или SCSI-диски. На выбор типа устройства хранения часто влияет размер кластера, используемая платформа сервера и поддержка производителя аппаратного обеспечения. Устройство хранения должно обеспечить достаточную производительность операций ввода-вывода приложений и быть хорошо масштабируемым при добавлении в кластер дополнительных узлов.

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

В большинстве случаев для обеспечения межсоединения в кластере вполне достаточно использование Gigabit Ethernet.

Дублирование сетевых интерфейсов увеличивает надежность кластерной конфигурации. Кластерное программное обеспечение Oracle Clusterware поддерживает до 100 узлов в кластере. Узлы кластера могут быть неидентичными, но должны иметь одинаковую аппаратную архитектуру, операционную систему и версию Oracle Cluserware.

Oracle Clusterware

Начиная с СУБД Oracle версии 10g в комплект дистрибутива включено специально разработанное и интегрированное с СУБД программное обеспечение для объединения компьютеров в кластер - Oracle Clusterware. Теперь для того, что бы иметь кластерную базу данных RAC, больше нет необходимости приобретать кластерное программное обеспечение от других производителей. Установка Oracle Clusterware достаточно просто производится с помощью хорошо знакомой каждому администратору базы данных, универсальной программой инсталляции Oracle (Oracle Universal Installer). Тот факт, что у кластерного программного обеспечения и СУБД единый разработчик, упрощает настройку и техническую поддержку.

ПО Oracle Clusterware необходимо для работы Oracle RAC. Кластерное программное обеспечение является полнофункциональным и полностью самостоятельным продуктом - для своей работы Oracle Clusterware не требует кластерного программного обеспечения других производителей, но при необходимости может быть в него интегрировано для совместной работы.

Oracle Clusterware производит мониторинг и управление кластерными базами данных и другими программными компонентами, обеспечивающими их функционал. При старте узла кластера Oracle Clusterware автоматически производит старт всех экземпляров СУБД Oracle, прослушивающих процессов (listeners) и служб. В случае сбоя любой компоненты, Oracle Clusterware автоматически производит ее перезапуск, так, что обслуживание может быть восстановлено раньше, чем администратор заметит, что был сбой. ПО Oracle Clusterware использует совместные дисковые устройства для хранения файла Oracle Cluster Registry (OCR), в котором описана конфигурация всех компонент кластера, и Voting File - файла используемого для голосования на случай физического разделения кластера на части в результате аппаратного сбоя. Кроме этого Voting File наряду с кластерным межсоединением используется для прослушивания узлами "пульсов" входящих в кластер других узлов. В Oracle Clusterware начиная c 10g Release 2 поддерживается программный интерфейс (API) для обеспечения высокой готовности процессов не только СУБД Oracle, но и других приложений. Когда администратор регистрирует такой процесс в Oracle Clusterware, он определяет правила старта, остановки и мониторинга процесса. Также должны быть определены правила перемещения процесса на другой узел кластера в случае сбоя того узла, на котором он выполнялся.

Файловые системы и управление дисковым пространством

Oracle RAC строится на основе архитектуры с разделяемыми дисками, поэтому механизмы управления дисковым пространством и файловой системой в ОС на всех узлах должны поддерживать работу в кластере. Для работы с дисками рекомендуется использовать встроенную в СУБД систему автоматического управления дисковыми ресурсами для базы данных Oracle - Automatic Storage Management (ASM). ASM обеспечивает высокопроизводительные операции дискового ввода-вывода и простоту в управлении файловой системой и дисками. ASM автоматически производит оптимальное распределение данных между всеми дисковыми ресурсами для достижения наилучшей производительности, что исключает необходимость ручной настройки дискового ввода/вывода.

В качестве альтернативы Oracle поддерживает использование неформатированных дисковых разделов (сырых устройств) и некоторых кластерных файловых систем, например, таких как Oracle Cluster File System, доступная в операционных системах Windows и Linux.

Виртуальный IP адрес (VIP)

В Oracle RAC 11g для каждого сервера в кластере требуется виртуальный IP-адрес. Виртуальный IP-адрес - это IP-адрес, который не привязан "жестко" к какому либо интерфейсу публичной сети кластера, но входит в адресное пространство той же подсети, что и статичные адреса этих интерфейсов. Этот адрес используется приложениями для подключения к кластерной базе данных. Если в узле происходит сбой, то его виртуальный IP-адрес перебрасывается на другой работающий в кластере сервер.

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

Сервисы (Services)

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

7 Рабочая нагрузка создаваемая сессиями одного Сервиса, распределяется и балансируется между узлами, которые назначены для обслуживания этого Сервиса. Интеграция с диспетчером ресурсов Database Resource Manager позволяет производить распределение ресурсов между сессиями различных Сервисов внутри каждого узла.

Производительность и качество выполнения каждого "Сервиса" отслеживается в автоматизированном репозитарии данных о рабочих нагрузках Automatic Workload Repository, входящем в состав СУБД начиная с Oracle Database 10g. Контроль за качеством выполнения "Cервиса" может осуществляться установкой пороговых показателей производительности, в случае нарушений которых производится автоматическое оповещение или выполнение заданных процедур. По каждому Сервису собирается детальная статистика его выполнения. Сервисы интегрируются с механизмом Oracle Streams Advanced Queuing и системой выполнения фоновых пакетных задач.

Каждый Сервис может выполняться на одном или нескольких экземплярах СУБД Oracle, а каждый экземпляр может поддерживать несколько Сервисов. Количество и состав экземпляров, которые обслуживает тот или иной Сервис определяются администратором базы данных независимо от самого приложения. При возникновении сбоя выполнение Сервисов автоматически восстанавливается на работающих экземплярах.

Быстрое оповещение приложений - Fast Application Notification (FAN)

Использование приложением механизма быстрого оповещения приложения Fast Application Notification (FAN) позволяет ускорить реакцию приложения на сбои внутри кластера и улучшить качество распределения рабочей нагрузки между доступными вычислительными ресурсами. FAN обеспечивает интеграцию между базой данных RAC и приложением. Благодаря этому механизму приложение обладает информацией о конфигурации кластера в любой момент времени, поэтому приложения могут подключаться только к тем экземплярам, которые в текущий момент отвечают на запросы приложений. Инфраструктура высокой доступности Oracle RAC немедленно посылает событие FAN при изменении состояния кластера.

Клиентское приложение получает возможность быстрой реакции на события, происходящие в кластере. В качестве реакции на стороне сервера настраиваются вызовы внешних программ, которые можно, например, использовать для протоколирования проблем или уведомления администраторов о сбое. Клиенты Oracle JDBC, ODP.NET и OCI интегрированы с FAN. Другие приложения могут использовать возможности FAN при помощи программируемого интерфейса приложений и прямой подписки на события FAN.

Высокая доступность

СУБД Oracle известна своей надежностью. Real Application Clusters обеспечивает для СУБД Oracle еще большую доступность - RAC исключает ситуацию, когда выход из строя сервера или его программного обеспечения приводит к выходу из строя всей системы в целом. При сбое на узле или экземпляре СУБД база данных остается открытой, и приложения продолжают иметь доступ к данным через другие работающие узлы и экземпляры. Программное обеспечение Oraclе Clusterware производит мониторинг кластерных баз данных RAC и других компонентов кластера, быстро выявляет проблемы и само производит их разрешение. Кластерная СУБД Oracle автоматически определяет сбой любого экземпляра, после чего сразу же начинает процедуру его восстановления. Так, что сбой может быть устранен, до того как кто-либо заметит, что он имел место. Механизм быстрого оповещения приложений Fast Application Notification позволяет приложениям получать немедленное уведомление о неисправностях компонентов кластера и скрывать сбои от пользователя передачей операций другому, работающему узлу кластера.

Обеспечение высокой доступности для приложений

СУБД Oracle поддерживает множество механизмов, облегчающих быстрое восстановление работы после всех видов сбоев. Кроме этого такие механизмы, как Fast Application Notification, Fast Connection Failover и Transparent Application Failover, позволяют приложениям маскировать сбои компонентов кластера от пользователей. Прозрачное переключение приложения Transparent Application Failover - механизм, который в случае сбоя экземпляра, обеспечивает автоматическое пересоздание соединения с другим экземпляром СУБД Oracle в кластере. Само переключение на другой экземпляр производится на уровне клиентского сетевого стека программного обеспечения Oracle и прозрачно для приложения. При этом в случае, если в момент сбоя на экземпляре выполнялась транзакция, эта транзакция должна быть повторно выполнена инициировавшем ее приложением после переключения к другому экземпляру.

Для более тесной интеграции приложения с кластерной СУБД, приложение может подписаться на события FAN, что позволит мгновенно реагировать на любые изменения (в том числе планируемые) в конфигурации кластера, а не только на сбой, который уже произошел. Автоматическая поддержка обработки событий FAN уже реализована для пулов соединений JDBC, ODP.NET, OCI - это механизм называется Fast Connection Failover (FCF). Приложения, использующие такие пулы соединений, получают возможность реакции на события FAN без дополнительных усилий со стороны разработчиков.

Беспрерывность при выполнении сервисного обслуживания

Real Application Clusters обеспечивает непрерывное обслуживание, как при сбоях, так и при выполнении запланированных сервисных работ. Большинство сервисных операций с базами данных может быть выполнено без остановки в обслуживании и прозрачно для пользователя. Другая часть работ по обслуживанию могут выполняться на узлах кластера поочередно, что приводит к значительной минимизации простоев.

В случае если обновление программного обеспечения Oracle сопровождается внесением изменений в словарь базы данных, Oracle предлагает использовать логическую резервную базу данных Oracle Data Guard. Такой подход позволяет минимизировать остановку в обслуживании только на время переключения ролей между основной и резервной базами данных. Эта процедура обновления включает в себя обновление логической резервной базы данных до следующего выпуска, запуск ее в смешанном режиме для проверки работоспособности обновления, изменение роли посредством переключения на обновленную базу данных, а затем обновление старой основной базы данных. При проведении тестирования в смешанном режиме возможна отмена установки обновления и восстановление старого программного обеспечения без потери данных. Для обеспечения защиты данных при этих процедурах можно использовать дополнительную резервную базы данных. Благодаря возможности поочередных обновлений с минимальными задержками Data Guard уменьшает время обслуживания для большинства административных задач, тем самым обеспечивая непрерывную работу системы 24x7 (7 дней в неделю по 24 часа).

Масштабируемость

Oracle Real Application Clusters обладает уникальной технологией масштабирования приложений. Типичный подход без использования кластеров заключается в замене сервера, которому уже не хватает мощности, новым сервером большего размера. Использование технологии RAC является альтернативой наращиванию вычислительной мощности одиночных серверов. Для того, что бы сохранить инвестиции, вложенные в уже имеющееся аппаратное обеспечение, можно просто добавить новый сервер к кластеру (или создать кластер). Приложения, обычно работающие на больших SMP-системах, могут быть переведены на кластеры, состоящие из небольших серверов.

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

Балансировка рабочей нагрузки

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

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

Балансировка соединений

Сетевой стек программного обеспечения Oracle SQL*NET, который обеспечивает взаимодействие между клиентом и сервером баз данных, обладает функцией балансировки нагрузки на уровне соединений. Балансировка нагрузки на уровне соединений осуществляется как на стороне клиента, так и на стороне сервера. Для балансировки нагрузки на стороне клиента необходимо в описании подключения к сервису перечислить все узлы кластера. SQL*NET случайно выбирает один из серверов. Если выбранный сервер недоступен, то производится попытка подключения к следующему серверу. Балансировка нагрузки на стороне сервера производится прослушивающим процессом (LISTENER). Каждый прослушивающий процесс получает информацию от всех экземпляров кластера об обслуживаемых Сервисах и о качестве их выполнения. В зависимости от целей, определенной для конкретного Сервиса, прослушивающий процесс выбирает экземпляр, наиболее точно подходящий для данной задачи, и производит с ним соединение.

Рассылка рекомендаций по балансировке нагрузки

Нагрузка сервера базы данных может изменяться с течением временем, также как может изменяться и конфигурация кластера, поэтому важно создавать соединения с базами данных и производить распределение работы внутри пулов соединений на основе самой оперативной информации. Real Application Clusters начиная с Oracle 10g Relese 2 поддерживает механизм расчета баланса нагрузки - Load Balancing Advisory. RAC постоянно производит мониторинг качества выполнения Сервиса для каждого экземпляра. Эта информация протоколируется в автоматическом архиве рабочей нагрузки (Automatic Workload Repository). На основе запротоколированной информации производится анализ, результаты которого затем передаются приложениям при помощи событий FAN. В событиях FAN содержится текущее качество выполнения Сервисов и рекомендательная информация о том, какой процент заданий должен направляться на каждый экземпляр.

Интегрированные клиенты Oracle используют эти события для распределения нагрузки запросов от приложений. Без использования FAN большинство пулов соединений производят выбор соединения для выполнения запроса последовательно или случайным образом. При помощи событий FAN и рекомендациям по балансировке нагрузки пул соединений может выбирать соединение, обеспечивающее на данный момент наилучшее обслуживание. Пулы соединений Oracle JDBC, ODP.NET и OCI производят балансировку нагрузки с использованием FAN-рекомендаций.

Динамически масштабируемое параллельное выполнение

Другим способом распределения нагрузки в базе данных Oracle является использование функции параллельного выполнения запросов. Параллельное выполнение (параллельный запрос или параллельный DML) распределяет работу по выполнению команды SQL между несколькими процессами. В среде Oracle Real Application Clusters эти процессы могут быть принадлежать разным экземплярам СУБД. Оптимизатор по стоимости СУБД поддерживает функцию параллельного исполнения как фундаментальный компонент при создании планов выполнения SQL-команд. В среде Real Application Clusters принятие решений о распараллеливании задачи зависит от возможностей внутриузлового и межузлового параллелизма. Например, если для конкретного запроса необходимо шесть процессов для его выполнения и шесть процессоров локального узла (узла, к которому подключен пользователь) свободны, то запрос будет обрабатываться только при помощи локальных ресурсов. Это демонстрирует эффективность внутриузлового параллелизма, при котором исключается распределение запроса между множеством узлов. Однако если в локальном узле доступны только два процессора, то для обработки запроса будут использоваться два процессора локального и четыре процессора другого узла. Таким образом, для ускорения операции с запросами используются как межузловой так и внутриузловой параллелизмы.

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

Технология RAC в территориально-разнесенном кластере

Территориально-разнесенный кластер - это архитектура, в которой узлы кластера находятся в разных Центрах Обработки Данных (ЦОД). Благодаря технологии Oracle RAC все узлы кластера, независимо в каком ЦОД они располагаются, включены в активную работу, как и в случае локального кластера. С этой точки зрения технология Oracle RAC является уникальной. Плюс к этому Oracle RAC в территориально-разнесенном кластере обеспечивает необычайно быстрое восстановление, в случае сбоя на какой-либо площадке. В связи с тем, что эта архитектура вызывает очень большой интерес и имеет успешные реализации, важно понять, где ее применение приносит наибольшую пользу с учётом расстояний, задержки в передаче сигнала и обеспечиваемую ей степень защиты.

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

Технология RAC для Extended Distance Clusters обеспечивает более высокую доступность, чем локальный RAC, но она может удовлетворять не всем требованиям мер по восстановлению работы в чрезвычайных ситуациях. Разнесение частей кластера на удаленные площадки является хорошей защитой от многих катастрофоподобных обстоятельств (локальное отключение электропитания, пожар, затопление помещения сервера, теракт), но не от всех. Такие стихийные бедствия, как землетрясения, ураганы или потопы, могут охватывать очень большую территорию. Компания должна произвести анализ и определить, могут ли оба центра обработки данных пострадать от одного и того же стихийного бедствия. Для всеобъемлющей защиты от различных угроз, включая защиту от повреждений данных и от региональных стихийных бедствий, специалисты компании Oracle рекомендуют использовать Oracle Data Guard совместно с технологией RAC, как описано в руководствах Oracle по архитектуре высокой доступности. Кроме этого Data Guard дает дополнительные преимущества, например поддержку поочередных обновлений версий Oracle.

Настроить территориально-разнесенный кластер сложнее, чем локальный. Особое внимание следует уделить месторасположению узлов, "кворуму" дисков и размещению устройств хранения с данными. При правильном применении эта архитектура может обеспечить более высокую доступность, чем база данных с локальным RAC. Для создания территориально-разнесенных кластеров можно использовать комбинацию программного обеспечения Oracle Clusterware, Oracle Real Application Clusters и Automatic Storage Management.

Создание и управление кластерной средой Oracle

Программное обеспечение Oracle Real Application Clusters создает из кластерной конфигурации единый образ не только для клиентских приложений, но и для администратора, что упрощает настройку и управление. Кластерная база данных RAC может быть установлена и сконфигурирована с любого узла входящего в кластер. Работу с кластерной конфигурацией поддерживают все средства и программы для управления базой данных, включая универсальную программу инсталляции ПО Oracle (OUI), Oracle Enterprise Manager, программу-ассистента конфигурирования базы данных (DBCA), программу-ассистента по модернизации версии базы данных (DBUA), программу-ассистента по конфигурированию сети (NETCA) и утилиты командной строки, такие как srvctl.

Утилита проверки кластера

В СУБД Oracle 10g Release 2 появилось новое средство проверки конфигурации кластера. Средство проверки кластера помогает устранять ошибки проведением ревизии до установки программного обеспечения, после его установки и при любых изменений конфигурации. Оно также может использоваться для текущей проверки кластера. Это утилита может быть вызвана из интерфейса командной строки или через API при помощи других программ, например универсальной программы установки Oracle Universal Installer (OUI).

Oracle Enterprise Manager

Программный пакет Enterprise Manager традиционно предлагаются как средство управления инфраструктурой программного обеспечения Oracle. В версии Enterprise Manager 10g пакет значительно переработан, так, например доступ к графическому интерфейсу управления теперь осуществляется через веб-браузер. Enterprise Manager для управления СУБД Oracle предлагается в двух редакциях:

Database Control - средство управления одной базой данных Oracle, автоматически настраивается при помощи DBCA во время создания базы данных.
Grid Control - средство управления информационной инфраструктурой предприятия, включая базы данных Oracle, устанавливается с отдельного компакт диска, включенного в поставку СУБД Oracle.

Оба средства поддерживают работу с кластерами и обладают централизованной консолью для управления кластерной СУБД.

Страница управления кластерной базой данных "Cluster Database" позволяет:

Следить за общим состоянием системы, например, за количеством и текущим состоянием всех экземпляров кластерной СУБД.
Видеть предупреждения, полученные со всех экземпляров, а также углубляться в систему для детального изучения источника каждого предупреждения.
Устанавливать пороги отслеживаемых показателей для генерации предупреждений на уровне кластерной базы данных.
Выполнять мониторинг показателей производительности со всех экземпляров: агрегированных или отображенных друг с другом так, чтобы их можно было легко сравнить между собой. В случае необходимости можно произвести детализацию по отдельным компонентам.
Контролировать статистику когерентности кэша кластера (например, global buffer gets и др.)
Производить операции уровня всей кластерной базы данных: создание резервных копий и восстановление базы данных, запуск и остановка экземпляров и т. д.
Управлять Сервисами, выполняя такие операции, как создание, изменение, запуск/остановка, включение/выключение или перемещение Сервисов, и производить мониторинг их производительности.

На странице "Cluster" пакета Grid Control можно просматривать состояние аппаратного обеспечения кластера и операционной системы в целом - это особенно полезно, когда кластер обеспечивает работу множество баз данных. Страница даёт обзор общего состояния компонент кластера с возможностью перехода к отдельным экземплярам СУБД.

Grid Control 10g Release 2 может произвести автоматическое преобразование отдельного экземпляра базы данных Oracle в кластерную базу данных под управлением RAC. Кроме этого при помощи Enterprise Manager можно осуществить начальное создание кластера, включая инсталляцию программного обеспечения и конфигурацию Oracle Clusterware. Содержимое домашнего каталога программного обеспечения Oracle (Oracle Home), используемого для инсталляции, может храниться либо в Enterprise Manager как "Золотой образ" или на любом известном сервере. "Золотой образ" может быть создан из образцовой копии установленного программного обеспечения Oracle Clusterware или Real Application Clusters 10g Release 2. При клонировании программного обеспечения выполняются без исключения все действия по установке и конфигурации RAC и Oracle Clusterware, в том числе запуск "root.sh" под правами привилегированных пользователей и необходимые шаги до и после инсталляции. Эта справедливо и при добавлении нового узла к уже существующему кластеру. Для ОС Linux программное обеспечение от Oracle может установить "образ системы" на "голое железо". В такой "образ" может входить операционная система, агент Oracle Enterprise Manager, Oracle Clusterware и СУБД Oracle с Real Application Clusters. Каждый "образ" можно связать с профилем аппаратного обеспечения. Все компоненты "образа" хранятся как "Золотые образы" в Enterprise Manager. "Мастер по установке" позволяет производить выбор аппаратного обеспечения и устанавливать полный стек программного обеспечения на новый сервер. Новый узел добавляется к кластеру автоматически.

Попеременное обновление программного обеспечения

Oracle позволяет производить попеременное обновления (patch) программного обеспечение в RAC. Обновление производится по очереди на каждом узле, при этом в нерабочем состоянии находится только один узел, а остальные продолжают работать. Подобный сценарий допустим со специально помеченными для этого обновлениями. Эта возможность присутствует в RAC начиная с Oracle 10g.

Для Oracle Clusterware ВСЕ обновления могут быть применены попеременно.

Поддержка попеременного перехода между версиями

Oracle Clusterware поддерживает попеременный переход на узлах между версиями. Такую же возможность предоставляет Automatic Storage Management, начиная с версии Oracle 11g. Всё это обеспечивает беспрерывное функционирование бизнеса в режиме 24x7.

Real Application Clusters позволяет производить попеременный переход между версиями с перерывами в работе близкими к нулевым при помощью логической резервной базы данных (SQL Apply) Data Guard. В случае реализации данного сценария, сначала логическая резервная переводится на новую версию. В этот момент времени базы данных Data Guard работают под управлением различных версий СУБД Oracle. После того как на новом программном обеспечении произведены все необходимые тесты для подтверждения работоспособности системы, осуществляется переключение ролей между основной и резервной базами данных. Следующими шагами являются перевод на новую версию основной базы данных, а затем обратное переключение ролей. В случае отказа от продолжения перехода, во время работы в смешанном режиме возможен откат изменений без потери данных. Для дополнительной защиты при выполнении данной процедуры может использоваться другая резервная база данных.

Oracle Clusterware: Защита других приложений

Кроме поддержки работы кластерных баз данных RAC программное обеспечение Oracle Clusterware для любых других приложений позволяет создать среду так называемого "Failover" кластера. В таком кластере защищаемая задача работает только на одном узле и в случае его сбоя мигрирует на другой "живой" узел кластера. Эта возможность реализована в Oracle Clusterware начиная с версии 10g Release 2.

Включение приложения в среду высокой доступности Oracle Clusterware состоит из трёх этапов:

Создание внешней программы для старта, мониторинга и остановкиприложения, принимающей от Clusterware один из возможных аргументов - "start", "stop" или "check".
Создание профиля приложения. В профиле кроме имени приложения и управляющей программы определяются узлы, на которых приложение может работать, и политика их выбора, зависимости приложения от других ресурсов кластера, в том числе VIP, временные параметры мониторинга, повторного старта и другие.
Регистрация профиля приложения. Кроме этого, для большей интеграции приложений в Oracle Clusterware есть программный интерфейс 'C'(API). С помощью этого интерфейса защищаемая программа во время работы может манипулировать содержимым Oracle Cluster Registry (OCR), и изменять поведение Oracle Clusterware по управлению приложением.

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

Oracle Clusterware является бесплатным программным обеспечением и лицензировано для использования на кластере при условии:

• защищаемое программное обеспечение произведено компанией Oracle;

• защищаемое программное обеспечение использует базу данных Oracle;

• защищаемое программное обеспечение работает на Oracle Unbreakable Linux;

• по крайне мере на одном из узлов кластера лицензирована для использования СУБД Oracle редакций Enterprise или Standard.

Кластером считается группа компьютеров с выполняемым на них Oracle Clusterware и одним набором файлов OCR и Voting File.

Описание примера: В кластер с помощью Oracle Clusterware объединены четыре компьютера с одним набором файлов OCR и Voting File, расположенных на общих дисковых устройствах. На кластере под управлением Clusterware работают четыре приложения: приложение A на узле 1, приложение B на узле 2, приложение С на узле 3, некластерная СУБД Oracle работает на узле 4. Для всех четырех приложений любой другой узел может быть сконфигурирован в качестве резервного. Узлы 1 и 2 используются для работы кластерной СУБД Oracle.

Automatic Storage Management

Механизм Automatic Storage Management (ASM) изначально представленный в СУБД Oracle 10g объединяет в себе кластерную файловую систему и возможности менеджера томов. ASM входит в стандартный функционал СУБД Oracle и не требует дополнительного лицензирования. ASM сокращает стоимость владения системами хранения для файлов СУБД Oracle, автоматизируя множество дисковых операций.

Механизм ASM производит балансировку распределения данных между дисковыми устройствами для оптимизации производительности и защищает данные при поддержке их избыточности.

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

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

Механизм ASM производит оптимизацию распределения данных между дисковыми устройствами одной дисковой группы, используя технологию схожую с идеей чередования данных (striping), но по собственному алгоритму. Для этого ASM разбивает данные на экстенты размером в 1 мегабайт или 128 килобайт в зависимости от типа файла.

Кластерные технологии СУБД Oracle

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

ASM поддерживает три режима избыточности данных:

External - избыточность не поддерживается. Рекомендуется использовать при применении RAID массивов осуществляющих избыточность данных на аппаратном уровне;
Normal - 2-х кратная избыточность. Поддерживаются две копии одного экстента.
High - 3-х кратная избыточность. Поддерживаются три копии одного экстента.

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

Основными нововведениями ASM версии Oracle 11g являются:

Быстрая ресинхронизация при кратковременном сбое - позволяет отслеживать изменение экстентов в случае кратковременной недоступности части дисковой подсистемы, содержащей дублированные данные. В этом случае после устранения проблем нет необходимости производить полное восстановление данных на вновь включенных в конфигурацию дисковых устройствах, - восстанавливаются только те экстенты, дубликаты которых были изменены за время недоступности дисков.
Улучшенная поддержка очень больших баз данных - размер экстента файла базы данных отныне будет варьироваться в зависимости от его размеров. Размеры экстентов могут варьироваться от 1 единицы размещения (Allocation Unit) до 8 и 64 единиц. Кроме этого при создании дисковых групп разрешено устанавливать единицу размещения отличную от значения по умолчанию в 1МБ. Возможные значения могут быть 1/2/4/8/16/32/64МБ. И то, и другое новшество позволяют: увеличить максимальные размеры управляемого дискового пространства (до 140PB без избыточности, 42PB c 2-х кратной избыточностью, 15PB с 3-х кратной), сэкономить ресурсы памяти и увеличить производительность.
Предпочтительная группа сбоя при чтении - эта возможность позволяет указать для каждого узла предпочтительную группу дисков для чтения, что очень важно при построении катастрофоустойчивых решений, когда дисковые массивы и узлы располагаются на значительном расстоянии друг от друга, что характерно для территориально разнесенных кластеров.
Попеременное обновление программного обеспечения ASM - позволяет производить обновление по очереди на каждом из узлов кластера. Во время выполнения процедуры обновления на узлах допускаются различные версии программного обеспечения.

Консолидация дисковых устройств хранения

Automatic Storage Manager с помощью Oracle Clusterware позволяет произвести консолидацию дисковых ресурсов в группы, так что они могут использоваться совместно всем базами данных, работающими на одном кластере. Для пользования совместным дисковым пулом база данных не должна быть кластерной, в этом случае опадает необходимость приобретения лицензий Real Application Clusters.

Описание примера: Для всех баз данных работающих на кластере, объединенном

Oracle Clusterware, используется единый пул дисковых устройств. Файлы кластерной базы данных с экземплярами на узлах 1 и 2, кластерной базы данных с экземплярами на узлах 3 и 4 и не кластерной базы данных с экземпляром на узле 4 размещаются в общих дисковых группах под управлением кластерной конфигурации ASM.

Real Application Testing - новая опция СУБД Oracle 11g

Принципиальным отличием опции Real Application Testing от известных средств эмуляции нагрузки является то, что вместо трудоемкого создания синтетического теста, производится ее захват на промышленной системе. Захваченная в виде SQL команд нагрузка воспроизводится на тестовом стенде с последующим автоматическим анализом исполнения.

Таким образом, опция Real Application Testing для многих заказчиков и разработчиков делает реальным недостижимое полнофункциональное тестирование с реальным объемом нагрузки, а значит существенно снижает риски миграции на новую платформу.

Пример возможного сценария работы с опцией Real Application Testing:

Полное резервное копирование производственной БД - это обеспечит аккуратное воспроизведение нагрузки на тестовой системе и снизит количество логических ошибок;
Захват и сохранение в двоичные файлы активности клиентов базы данных при минимальном воздействии на систему. Возможные фильтры: по отдельным сессиям, по именам пользователей, модулей, программ или сервисов;
Восстановление на тестовой системе копии производственной БД. Желательна установка системного времени на время начала захвата активности;
Трансформация захваченных файлов в проигрываемый формат, для возможного многократного воспроизведения;
Установка режима воспроизведения: синхронный или асинхронный. Синхронный режим гарантирует последовательность действий, точно в том порядке, в котором они были произведены. Асинхронный режим порядок действий не сохраняет (подходит для стресс-тестов).
Запуск воспроизведения нагрузки на тестовой базе данных.
Получение отчетов.

Дополнительные настройки при воспроизведении тестов для асинхронного режима:

время между sql вызовами:
0% - выполнять как можно быстрее;
<100% выполнять быстрее, чем в реальной ситуации;
100% выполнять точно как в реальной ситуации;
> 100% выполнять медленнее, чем в реальной ситуации
последовательность входа сессий:
0% - все сессии соединяются в БД немедленно;
100% все сессии соединяются точно так, как в реальной ситуации;
порядок операций commit:
сохранять порядок операции;
не сохранять порядок операций.

Кроме этого можно указать, число сессий, которые должны воспроизводить нагрузку.

Автоматически формируемая отчетность включает:

Число строк, которые вернул каждый sql вызов в промышленных и тестовых системах, и отклонение между ними;
Отчетность по ошибкам для каждого вызова для новых ошибок, которые произошли на тестовой системе, а так же по ошибкам, которые изменились на тестовой системе;
Отчеты Automatic Workload Repository (AWR)

Все операции по захвату, воспроизведению нагрузки осуществляются из графического интерфейса Enterprise Manager (EM)

В версии СУБД Oracle 10.2.0.4 планируется появление возможности захвата нагрузки на СУБД Oracle 10g для ее воспроизведения ее на СУБД Oracle 11g, что позволит значительно упростить переход с одной версии на другую.

Опция Real Application Testing может работать как с кластерной так не-кластерной базой данных. Но особую пользу она может принести именно при миграции приложений в среду Oracle RAC.

Заключение

Технология Oracle Real Application Clusters предназначена для обеспечения гибкой экономичной масштабируемости и высокой доступности. Защищая от сбоев программной и аппаратной части, Oracle RAC обеспечивает непрерывный доступ к данным.

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

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

Даже без использования RAC построение кластерной конфигурации на основе Oracle Clusterware может принести выгоды. Oracle Clusterware позволяет обеспечить высокую доступность для приложений разработанных другими производителями, а совместное его использование с Automatic Storage Management даёт возможность построить единый кластеризованный пул дисковых устройств предприятия.

форум oracle