Oracle rac что это

Обновлено: 09.01.2025

В базе данных вычислений , Oracle Real Application Clusters ( RAC ) - вариант для базы данных Oracle программного обеспечения , разрабатываемого корпорация Oracle и введен в 2001 году с Oracle9i - предоставляет программное обеспечение для кластеризации и высокой доступности в базе данных Oracle сред. Oracle Corporation включает RAC в Enterprise Edition при условии, что узлы кластеризованы с использованием Oracle Clusterware .

СОДЕРЖАНИЕ

Функциональность

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

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

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

Основная цель Oracle RAC - реализовать кластеризованную базу данных для обеспечения производительности, масштабируемости, устойчивости и высокой доступности данных на уровне экземпляра.

Выполнение

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

Cache Fusion

До Oracle 9 в базах данных Oracle с сетевой кластеризацией в качестве среды передачи данных использовалось устройство хранения (это означает, что один узел записывал блок данных на диск, а другой узел считывал эти данные с того же диска), что имело присущий недостаток тусклого исполнения. В Oracle 9i эта проблема решена: RAC использует выделенное сетевое соединение для внутренней связи кластера.

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

Служба именования Oracle Grid (GNS) обрабатывает разрешение имен в реестре кластера.

Диагностика

Анализатор файлов трассировки (TFA) помогает в сборе диагностических данных RAC.

Версии

Oracle Real Application Clusters 12c Release 1 Enterprise Edition.
Oracle Real Application Clusters One Node (RAC One Node) применяет RAC к одноузловым установкам с Oracle Database 11g Release 2 Enterprise Edition.

Эволюция

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

Oracle Real Application Clusters (RAC), представленный в Oracle 9i в 2001 году, заменяет опцию базы данных Oracle Parallel Server (OPS). В то время как Oracle9i требовалось внешнее кластерное ПО (известное как кластерное ПО поставщика, такое как TruCluster Veritas Cluster Server или Sun Cluster ) для большинства разновидностей Unix (за исключением Linux и Windows, где Oracle предоставляла бесплатное кластерное ПО под названием Cluster Ready Services или CRS ), начиная с Oracle 10g, Продукт Oracle clusterware был доступен для всех операционных систем. С выпуском Oracle Database 10g Release 2 (10.2) Cluster Ready Services был переименован в Oracle Clusterware. При использовании Oracle 10g или выше Oracle Clusterware - единственное программное обеспечение кластера, которое вам нужно для большинства платформ, на которых работает Oracle RAC (за исключением кластера Tru, в этом случае вам потребуется кластерное программное обеспечение поставщика). Вы по-прежнему можете использовать кластерное ПО других поставщиков, если оно сертифицировано для Oracle RAC.

В RAC транзакция записи должна владеть соответствующей областью базы данных: обычно это включает в себя запрос через межкластерное соединение (локальную IP-сеть) на передачу права владения блоком данных от другого узла тому, кто желает сделать написать. Это занимает относительно много времени (от нескольких до десятков миллисекунд ) по сравнению с одним узлом базы данных, использующим операции в памяти. Для многих типов приложений время, затрачиваемое на координацию блочного доступа между системами, невелико по сравнению со многими операциями в системе, и RAC можно масштабировать сравнимо с одной системой. Более того, базы данных с большим количеством транзакций чтения (например, приложения для хранилищ данных) очень хорошо работают в RAC, поскольку нет необходимости в передаче прав собственности. (Oracle 11g внес много улучшений в этой области и работает намного лучше, чем более ранние версии для рабочих нагрузок только для чтения.)

Накладные расходы на управление ресурсами (или передачу владения) минимальны для менее чем трех узлов, поскольку запрос любого ресурса в кластере может быть получен максимум за три прыжка (владелец-мастер-запросчик). Это делает Oracle RAC масштабируемым по горизонтали с множеством узлов. Поставщики приложений (например, SAP ) используют Oracle RAC для демонстрации масштабируемости своего приложения. Большинство крупнейших тестов OLTP проводится на Oracle RAC. Oracle RAC 11g поддерживает до 100 узлов.

Для некоторых приложений RAC может потребовать тщательного разделения приложений для повышения производительности . Приложение, которое линейно масштабируется на машине SMP, может линейно масштабироваться в RAC. Однако, если приложение не может линейно масштабироваться на SMP, оно не будет масштабироваться при переносе на RAC. Короче говоря, масштабируемость приложения зависит от того, насколько хорошо приложение масштабируется в одном экземпляре .

Конкурентный контекст

Разделяемой ничего и разделяемой всё архитектуры каждый имеет преимущества по сравнению с другой. Поставщики СУБД и отраслевые аналитики регулярно обсуждают этот вопрос; например, Microsoft рекламирует сравнение своего SQL Server 2005 с Oracle 10g RAC.

Корпорация Oracle предложила РСУБД с архитектурой Shared Nothing с появлением IBM SP и SP2 с выпуском 7.x MPP, в которых виртуальные общие диски (VSD) использовались для создания реализации Shared Everything на архитектуре Shared Nothing.

Общий-все

Архитектуры с общим доступом совместно используют данные на диске и данные в памяти между узлами кластера. Это контрастирует с архитектурами «без совместного использования», в которых их не используется.

Некоторые коммерчески доступные базы данных предлагают архитектуру «общего доступа ко всему». IBM DB2 для z / OS ( операционная система для мэйнфреймов IBM ) предоставляет возможность высокопроизводительного совместного использования данных с середины 1990-х годов, когда IBM выпустила аппаратную и программную инфраструктуру для кластеризации мэйнфреймов. В конце 2009 года IBM анонсировала DB2 pureScale, схему кластеризации совместно используемых дисков для DB2 9.8 на AIX, которая имитирует реализацию параллельного sysplex, лежащую в основе совместного использования данных DB2 на мэйнфрейме.

В феврале 2008 года Sybase выпустила свой Adaptive Server Enterprise , Cluster Edition. Он напоминает Oracle RAC своим дизайном, предусматривающим совместное использование всего.

Хотя технически не является общим для всего, Sybase также предоставляет реляционную базу данных на основе столбцов, ориентированную на аналитические приложения и приложения хранилища данных, под названием Sybase IQ, которые можно настроить для работы в режиме общего диска.

Собственные облачные базы данных, такие как Amazon Aurora и POLARDB из Alibaba Cloud , реализованы с архитектурой «все совместно» поверх облачной распределенной файловой системы.

Ничего общего

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

К конкурирующим продуктам, предлагающим архитектуры без совместного использования ресурсов, относятся:

Высоконагруженные сайты, доступность «5 nines». На заднем фоне (backend) куча обрабатываемой информации в базе данных. А что, если железо забарахлит, если вылетит какая-то давно не проявлявшаяся ошибка в ОС, упадет сетевой интерфейс? Что будет с доступностью информации? Из чистого любопытства я решил рассмотреть, какие решения вышеперечисленным проблемам предлагает Oracle. Последние версии, в отличие от Oracle 9i, называются Oracle 10g (или 11g), где g – означает «grid», распределенные вычисления. В основе распределенных вычислений «как ни крути» лежат кластера, и дополнительные технологии репликации данных (DataGuard, Streams). В этой статье в общих чертах описано, как устроен кластер на базе Oracle 10g. Называется он Real Application Cluster (RAC).

Статья не претендует на полноту и всеобъемлемость, также в ней исключены настройки (дабы не увеличивать в объеме). Смысл – просто дать представление о технологии RAC.

Статью хотелось написать как можно доступнее, чтобы прочесть ее было интересно даже человеку, мало знакомому с СУБД Oracle. Поэтому рискну начать описание с аспектов наиболее часто встречаемой конфигурации БД – single-instance, когда на одном физическом сервере располагается одна база данных (RDBMS) Oracle. Это не имеет непосредственного отношения к кластеру, но основные требования и принципы работы будут одинаковы.

Введение. Single-instance.

область хранения данных, т.е. физические файлы на диске (datastorage) (сама БД)
экземпляр БД (получающая и обрабатывающая эти данные в оперативной памяти) (СУБД)

Во всех современных реляционных БД данные хранятся в таблицах. Таблицы, индексы и другие объекты в Oracle хранятся в логических контейнерах – табличных пространствах (tablespace). Физически же tablespace располагаются в одном или нескольких файлах на диске. Хранятся они следующим образом:
Каждый объект БД (таблицы, индексы, сегменты отката и.т.п.) хранится в отдельном сегменте – области диска, которая может занимать пространство в одном или нескольких файлах. Сегменты в свою очередь, состоят из одного или нескольких экстентов. Экстент – это непрерывный фрагмента пространства в файле. Экстенты состоят из блоков. Блок – наименьшая единица выделения пространства в Oracle, по умолчанию равная 8K. В блоках хранятся строки данных, индексов или промежуточные результаты блокировок. Именно блоками сервер Oracle обычно выполняет чтение и запись на диск. Блоки имеют адрес, так называемый DBA (Database Block Address).

При любом обращении DML (Data Manipulation Language) к базе данных, Oracle подгружает соответствующие блоки с диска в оперативную память, а именно в буферный кэш. Хотя возможно, что они уже там присутствуют, и тогда к диску обращаться не нужно. Если запрос изменял данные (update, insert, delete), то изменения блоков происходят непосредственно в буферном кэше, и они помечаются как dirty (грязные). Но блоки не сразу сбрасываются на диск. Ведь диск – самое узкое место любой базы данных, поэтому Oracle старается как можно меньше к нему обращаться. Грязные блоки будут сброшены на диск автоматически фоновым процессом DBWn при прохождении контрольной точки (checkpoint) или при переключении журнала.

Что будет, если Oracle упадет где-то на середине длинной транзакции (если бы она вносила изменения)?
Какие же данные прочтет первая транзакция, когда в кэше у нее «под носом» другая транзакция изменила блок?

журнал повтора (redo log)
сегмент отмены (undo)

Когда в базу данных поступает запрос на изменение, то Oracle применяет его в буферном кэше, параллельно внося информацию, достаточную для повторения этого действия, в буфер повторного изменения (redo log buffer), находящийся в оперативной памяти. Как только транзакция завершается, происходит ее подтверждение (commit), и сервер сбрасывает содержимое redo buffer log на диск в redo log в режиме append-write и фиксирует транзакцию. Такой подход гораздо менее затратен, чем запись на диск непосредственно измененного блока. При сбое сервера кэш и все изменения в нем потеряются, но файлы redo log останутся. При включении Oracle начнет с того, что заглянет в них и повторно выполнит изменения таблиц (транзакции), которые не были отражены в datafiles. Это называется «накатить» изменения из redo, roll-forward. Online redo log сбрасывается на диск (LGWR) при подтверждении транзакции, при прохождении checkpoint или каждые 3 секунды (default).

С undo немного посложнее. С каждой таблицей в соседнем сегменте хранится ассоциированный с ней сегмент отмены. При запросе DML вместе с блоками таблицы обязательно подгружаются данные из сегмента отката и хранятся также в буферном кэше. Когда данные в таблице изменяются в кэше, в кэше так же происходит изменение данных undo, туда вносятся «противодействия». То есть, если в таблицу был внесен insert, то в сегмент отката вносится delete, delete – insert, update – вносится предыдущее значение строки. Блоки (и соответствующие данные undo) помечаются как грязные и переходят в redo log buffer. Да-да, в redo журнал записываются не только инструкции, какие изменения стоит внести (redo), но и какие у них противодействия (undo). Так как LGWR сбрасывает redo log buffer каждые 3 секунды, то при неудачном выполнении длительной транзакции (на пару минут), когда после минуты сервер упал, в redo будут записи не завершенные commit. Oracle, как проснется, накатит их (roll-forward), и по восстановленным (из redo log) в памяти сегментам отката данных отменит (roll-back) все незафиксированные транзакции. Справедливость восстановлена.

Кратко стоит упомянуть еще одно неоспоримое преимущество undo сегмента. По второму сценарию (из схемы) когда select дойдет до чтения блока (DBA) 500, он вдруг обнаружит что этот блок в кэше уже был изменен (пометка грязный), и поэтому обратится к сегменту отката, для того чтобы получить соответствующее предыдущее состояние блока. Если такого предыдущего состояния (flashback) в кэше не присутствовало, он прочитает его с диска, и продолжит выполнение select. Таким образом, даже при длительном «select count(money) from bookkeeping» дебет с кредитом сойдется. Согласованно по чтению (CR).

Отвлеклись. Пора искать подступы к кластерной конфигурации. =)

Уровень доступа к данным. ASM.

Хранилищем (datastorage) в больших БД почти всегда выступает SAN (Storage Area Network), который предоставляет прозрачный интерфейс серверам к дисковым массивам.
Сторонние производители (Hitachi, HP, Sun, Veritas) предлагают комплексные решения по организации таких SAN на базе ряда протоколов (самым распространенным является Fibre Channel), с дополнительными функциональными возможностями: зеркалирование, распределение нагрузки, подключение дисков на лету, распределение пространства между разделами и.т.п.
Позиция корпорации Oracle в вопросе построения базы данных любого масштаба сводится к тому, что Вам нужно только соответствующее ПО от Oracle (с соответствующими лицензиями), а выбранное оборудование – по возможности (если средства останутся после покупки Oracle :). Таким образом, для построения высоконагруженной БД можно обойтись без дорогостоящих SPARC серверов и фаршированных SAN, используя сервера на бесплатном Linux и дешевые RAID-массивы.

На уровне доступа к данным и дискам Oracle предлагает свое решение – ASM (Automatic Storage Management). Это отдельно устанавливаемый на каждый узел кластера мини-экземпляр Oracle (INSTANCE_TYPE = ASM), предоставляющий сервисы работы с дисками.

Oracle старается избегать обращений к диску, т.к. это является, пожалуй, основным bottleneck любой БД. Oracle выполняет функции кэширования данных, но ведь и файловые системы так же буферизуют запись на диск. А зачем дважды буферизировать данные? Причем, если Oracle подтвердил транзакцию и получил уведомления том, что изменения в файлы внесены, желательно, чтобы они уже находились там, а не в кэше, на случай «падения» БД. Поэтому рекомендуется использовать RAW devices (диски без файловой системы), что делает ASM.

отсутствие необходимости в отдельном ПО для управления разделами дисков
нет необходимости в файловой системе

Зеркалирование данных:
как правило, 2-х или 3-х ступенчатое, т.е. данные одновременно записываются на 2 или 3 диска. Для зеркалирования диску указываются не более 8 дисков-партнеров, на которые будут распределяться копии данных.
Автоматическая балансировка нагрузки на диски (обеспечение высокой доступности):
если данные tablespace разместить на 10 дисках и, в некоторый момент времени, чтение данных из определенных дисков будет «зашкаливать», ASM сам обратится к таким же экстентам, но находящимся на зеркалированных дисках.
Автоматическая ребалансировка:
При удалении диска, ASM на лету продублирует экстенты, которые он содержал, на другие оставшиеся в группе диски. При добавлении в группу диска, переместит экстенты в группе так, что на каждом диске окажется приблизительно равное число экстентов.

Таким образом, кластер теперь может хранить и читать данные с общего файлового хранилища.

Пора на уровень повыше.

Clusterware. CRS.

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

CRS (Cluster-Ready Services) – набор сервисов, обеспечивающий совместную работу узлов, отказоустойчивость, высокую доступность системы, восстановление системы после сбоя. CRS выглядит как «мини-экземпляр» БД (ПО) устанавливаемый на каждый узел кластера. Устанавливать CRS – в обязательном порядке для построения Oracle RAC. Кроме того, CRS можно интегрировать с решениями clusterware от сторонних производителей, таких как HP или Sun.

Опять немного «терминологии»…

CSSD – Cluster Synchronization Service Daemon
CRSD – Cluster Ready Services Daemon
EVMD – Event Monitor Daemon

Как уже стало ясно из таблички, самым главным процессом, «самым могущественным демоном», является CRSD (Cluster Ready Services Daemon). В его обязанности входит: запуск, остановка узла, генерация failure logs, реконфигурация кластера в случае падения узла, он также отвечает за восстановление после сбоев и поддержку файла профилей OCR. Если демон падает, то узел целиком перезагружается. CRS управляет ресурсами OCR: Global Service Daemon (GSD), ONS Daemon, Virtual Internet Protocol (VIP), listeners, databases, instances, and services.

Node Membership (NM).Каждую секунду проверяет heartbeat между узлами. NM также показывает остальным узлам, что он имеет доступ к так называемому voting disk (если их несколько, то хотя бы к большинству), делая регулярно туда записи. Если узел не отвечает на heartbeat или не оставляет запись на voting disk в течение нескольких секунд (10 для Linux, 12 для Solaris), то master узел исключает его из кластера.
Group Membership (GM). Функция отвечает за своевременное оповещение при добавлении / удалении / выпадении узла из кластера, для последующей реконфигурации кластера.

Информатором в кластере выступает EVMD (Event Manager Daemon), который оповещает узлы о событиях: о том, что узел запущен, потерял связь, восстанавливается. Он выступает связующим звеном между CRSD и CSSD. Оповещения также направляются в ONS (Oracle Notification Services), универсальный шлюз Oracle, через который оповещения можно рассылать, например, в виде SMS или e-mail.

Стартует кластер примерно по следующей схеме: CSSD читает из общего хранилища OCR, откуда считывает кластерную конфигурацию, чтобы опознать, где расположен voting disk, читает voting disk, чтобы узнать сколько узлов (поднялось) в кластере и их имена, устанавливает соединения с соседними узлами по протоколу IPC. Обмениваясь heartbeat, проверяет, все ли соседние узлы поднялись, и выясняет, кто в текущей конфигурации определился как master. Ведущим (master) узлом становится первый запустившийся узел. После старта, все запущенные узлы регистрируются у master, и впоследствии будут предоставлять ему информацию о своих ресурсах.

Уровнем выше CRS на узлах установлены экземпляры базы данных.
Друг с другом узлы общаются по private сети – Cluster Interconnect, по протоколу IPC (Interprocess Communication). К ней предъявляются требования: высокая ширина пропускной способности и малые задержки. Она может строиться на основе высокоскоростных версий Ethernet, решений сторонних поставщиков (HP, Veritas, Sun), или же набирающего популярность InfiniBand. Последний кроме высокой пропускной способности пишет и читает непосредственно из буфера приложения, без необходимости в осуществлении вызовов уровня ядра. Поверх IP Oracle рекомендует использовать UDP для Linux, и TCP для среды Windows. Также при передаче пакетов по interconnect Oracle рекомендует укладываться в рамки 6-15 ms для задержек.

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

Понимание Oracle RAC

Согласно приведенной выше схеме

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

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

Категория решений Oracle RAC предлагает тщательно настроенный пакет элементов, чтобы обеспечить выполнение всех этих требований. Коллекция Oracle RAC обычно состоит из следующих компонентов, которые могут называться «Категория альтернатив Oracle RAC».

Преимущества Oracle RAC

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

Требуемые навыки Oracle RAC

Виртуализация:

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

Диспетчер автоматического хранения (ASM):

Почему мы должны использовать Oracle RAC?

Oracle RAC на самом деле является общим кластером, имеющим один этап сбоя и узкое место: подсистема хранения. Эта подсистема общего доступа на самом деле гарантирует, что рабочие нагрузки OLTP будут очень устойчивыми, независимо от наличия множества узлов Oracle RAC.
Поэтому в случае увеличения количества узлов RAC производительность ввода-вывода не будет линейно повышаться из-за одноэлементной подсистемы хранения. В частности, повышение, например, увеличение количества узлов RAC, может быть процессором и памятью.
Преимущества RAC - Cache Fusion (быстрая выделенная объединительная панель, которую узлы используют для соединения друг с другом), которая позволяет пользователям кластера обмениваться данными, которые могут кэшироваться внутри SGA. Это означает, что вся SGA со всем кластером (и, следовательно, количество данных, которые могут быть кэшированы) на самом деле почти равна сумме отдельных узлов SGA.
В целом: RAC масштабирует состояние (из-за масштабирования между процессором и памятью), однако не может масштабировать создаваемые (из-за одноэлементной подсистемы хранения).
Пока вы не используете Exadata . в этом случае подсистема хранения может масштабироваться (каждая ячейка хранения имеет свой собственный процессор, ОЗУ, флэш-память и жесткие диски).

Кто является подходящей аудиторией для изучения технологий Oracle RAC?

Oracle обычно похож на SQL Server и каждую дополнительную систему реляционных баз данных. Архитектурные концепции его базы данных идентичны, и затем он работает с SQL (язык структурированных запросов), а также с собственными расширениями Oracle PL / SQL. Это легко понять - если вы много работаете с Linux и SQL.

Администраторы Linux
Инженеры DevOps
Администраторы базы данных Oracle
ИТ-специалисты

Как эта технология поможет вам в карьерном росте?

Квалифицированные администраторы баз данных Oracle (DBA) обычно пользуются спросом на рынке. Точно так же, поскольку база данных компании постоянно растет, у нас есть большие требования к людям, которые могут управлять, поддерживать, а также разрабатывать базы данных с тех пор, как были организованы / спроектированы, устранены проблемы и установлены руководящие принципы для повышения эффективности.

Одной из наиболее важных квалификаций является значительный опыт администрирования баз данных, а также опыт работы с системами Oracle. Oracle также предоставляет три уровня квалификации для администраторов баз данных, в состав которых обычно входят Oracle Certified Associate, Oracle Certified Professional (OCP) и Oracle Certified Master (OCM), которые также могут повысить эффективность работы.

Вывод

Идентификация сервисов для получения предоставленной конфигурации требует рассмотрения:

Поддержка, чтобы получить эту базу данных Oracle
Матрицы совместимости технологий Oracle RAC (RTCM)
Документы Oracle, касающиеся дополнительных требований
Альтернативные кластерные решения и другие кластерные файловые блоки по мере необходимости

Поддержка получения Oracle RAC может быть «многоуровневой», в некоторой степени не отразится на оборудовании

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

Виды кластеров

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

Кластеры высокой готовности или отказоустойчивые кластеры (high-availability clusters или failover clusters) используют избыточные узлы для обеспечения работы в случае отказа одного из узлов.
Кластеры балансировки нагрузки (load-balancing clusters) служат для распределения запросов от клиентов по нескольким серверам, образующим кластер.
Вычислительные кластеры (compute clusters), как следует из названия, используются в вычислительных целях, когда задачу можно разделить на несколько подзадач, каждая из которых может выполняться на отдельном узле. Отдельно выделяют высокопроизводительные кластеры (HPC — high performance computing clusters), которые составляют около 82% систем в рейтинге суперкомпьютеров Top500.

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

Такую систему можно рассматривать как обобщение понятия «кластер». ластеры могут быть сконфигурированы в режиме работы active/active, в этом случае все узлы обрабатывают запросы пользователей и ни один из них не простаивает в режиме ожидания, как это происходит в варианте active/passive.

Oracle RAC и Network Load Balancing являются примерами active/ active кластера. Failover Cluster в Windows Server служит примером active/passive кластера. Для организации active/active кластера требуются более изощренные механизмы, которые позволяют нескольким узлам обращаться к одному ресурсу и синхронизовать изменения между всеми узлами. Для организации кластера требуется, чтобы узлы были объединены в сеть, для чего наиболее часто используется либо традиционный Ethernet, либо InfiniBand.

Программные решения могут быть довольно чувствительны к задержкам — так, например, для Oracle RAC задержки не должны превышать 15 мс. В качестве технологий хранения могут выступать Fibre Channel, iSCSI или NFS файловые сервера. Однако оставим аппаратные технологии за рамками статьи и перейдем к рассмотрению решений на уровне операционной системы (на примере Windows Server 2008 R2) и технологиям, которые позволяют организовать кластер для конкретной базы данных (OracleDatabase 11g), но на любой поддерживаемой ОС.

Windows Clustering

У Microsoft существуют решения для реализации каждого из трех типов кластеров. В состав Windows Server 2008 R2 входят две технологии: Network Load Balancing (NLB) Cluster и Failover Cluster. Существует отдельная редакция Windows Server 2008 HPC Edition для организации высокопроизводительных вычислительных сред. Эта редакция лицензируется только для запуска HPC-приложений, то есть на таком сервере нельзя запускать базы данных, web- или почтовые сервера.

NLB-кластер используется для фильтрации и распределения TCP/IPтрафика между узлами. Такой тип кластера предназначен для работы с сетевыми приложениями — например, IIS, VPN или межсетевым экраном.

Могут возникать сложности с приложениями, которые полага ются на сессионные данные, при перенаправлении клиента на другой узел, на котором этих данных нет. В NLB-кластер можно включать до тридцати двух узлов на x64-редакциях, и до шестнадцати — на x86.

Failoverclustering — это кластеризации с переходом по отказу, хотя довольно часто термин переводят как «отказоустойчивые кластеры».

Узлы кластера объединены программно и физически с помощью LAN- или WAN-сети, для multi-site кластера в Windows Server 2008 убрано требование к общей задержке 500 мс, и добавлена возможность гибко настраивать heartbeat. В случае сбоя или планового отключения сервера кластеризованные ресурсы переносятся на другой узел. В Enterprise edition в кластер можно объединять до шестнадцати узлов, при этом пятнадцать из них будут простаивать до тех пор, пока не произойдет сбой. Приложения без поддержки кластеров (cluster-unaware) не взаимодействуют со службами кластера и могут быть переключены на другой узел только в случае аппаратного сбоя.

Приложения с поддержкой кластеров (cluster-aware), разработанные с использованием ClusterAPI, могут быть защищены от программных и аппаратных сбоев.

Развертывание failover-кластера

Процедуру установки кластера можно разделить на четыре этапа. На первом этапе необходимо сконфигурировать аппаратную часть, которая должна соответствовать The Microsoft Support Policy for Windows Server 2008 Failover Clusters. Все узлы кластера должны состоять из одинаковых или сходных компонентов. Все узлы кластера должны иметь доступ к хранилищу, созданному с использованием FibreChannel, iSCSI или Serial Attached SCSI. От хранилищ, работающих с Windows Server 2008, требуется поддержка persistent reservations.

На втором этапе на каждый узел требуется добавить компонент Failover Clustering — например, через Server Manager. Эту задачу можно выполнять с использованием учетной записи, обладающей административными правами на каждом узле. Серверы должны принадлежать к одному домену. Желательно, чтобы все узлы кластера были с одинаковой ролью, причем лучше использовать роль member server, так как роль domain controller чревата возможными проблемами с DNS и Exchange.

Третий не обязательный, но желательный этап заключается в проверке конфигурации. Проверка запускается через оснастку Failover Cluster Management. Если для проверки конфигурации указан только один узел, то часть проверок будет пропущена.

На четвертом этапе создается кластер. Для этого из Failover Cluster Management запускается мастер Create Cluster, в котором указываются серверы, включаемые в кластер, имя кластера и дополнительные настройки IP-адреса. Если серверы подключены к сетям, которые не будут использоваться для общения в рамках кластера (например, подключение только для обмена данными с хранилищем), то в свойствах этой сети в Failover Cluster Management необходимо установить параметр «Do not allow the cluster to use this network».

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

Для этого необходимо запустить High Availability Wizard, который можно найти в Services and Applications оснастки Failover Cluster Management.

Cluster Shared Volumes

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

Еще одна проблема, возникающая из-за того, что LUN является минимальной единицей обхода отказа, заключается в том, что при сбое одного приложения, находящегося на LUN, приходится переключать все приложения, которые хранятся на этом LUN, на другой сервер. Во всех приложениях (включая Hyper-V до второго релиза Server 2008) это удавалось обходить за счет многочисленных LUN, на каждом из которых хранились данные только одного приложения. В Server 2008 R2 появилось решение для этих проблем, но предназначенное для работы только с Hyper-V и CSV (Cluster Shared Volumes).

CSV позволяет размещать на общем хранилище виртуальные машины, запускаемые на разных узлах кластера — тем самым разбивается зависимость между ресурсами приложения (в данном случае виртуальными машинами) и дисковыми ресурсами. В качестве файловой системы CSV использует обычную NTFS. Для включения CSV необходимо в Failover Cluster Manage выполнить команду Enable Cluster Shared Volumes. Отключить поддержку CSV можно только через консоль:

Для использования этой команды должен быть загружен Failover Clusters, модуль PowerShell. Использование CSV совместно с live migration позволяет перемещать виртуальные машины между физическими серверами в считанные миллисекунды, без обрыва сетевых соединений и совершенно прозрачно для пользователей. Стоит отметить, что копировать любые данные (например, готовые виртуальные машины) на общие диски, использующие CSV, следует через узел-координатор.

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

Oracle RAC

Oracle Real Application Clusters (RAC) — это дополнительная опция Oracle Database, которая впервые появилась в Oracle Database 9i под названием OPS (Oracle Parallel Server). Опция предоставляет возможность нескольким экземплярам совместно обращаться к одной базе данных. Базой данных в Oracle Database называет ся совокупность файлов данных, журнальных файлов, файлов параметров и некоторых других типов файлов. Для того, чтобы пользовательские процессы могли получить доступ к этим данным, должен быть запущен экземпляр. Экземпляр (instance) в свою очередь состоит из структур памяти (SGA) и фоновых процессов. В отсутствии RAC получить доступ к базе данных может строго один экземпляр.

Опция RAC не поставляется с Enterprise Edition и приобретается отдельно. Стоит отметить, что при этом RAC идет в составе Standard Edition, но данная редакция обладает большим количеством ограничений по сравнению с Enterprise Edition, что ставит под сомнение целесообразность ее использования.

Oracle Grid Infrastructure

Для работы Oracle RAC требуется Oracle Clusterware (или стороннее ПО) для объединения серверов в кластер. Для более гибкого управления ресурсами узлы такого кластера могут быть организованы в пулы (с версии 11g R2 поддерживается два варианта управления — на основании политик для пулов или, в случае их отсутствия, администратором).

Во втором релизе 11g Oracle Clusterware был объединен с ASM под общим названием Oracle Grid Infrastructure, хотя оба компонента и продолжают устанавливаться по различным путям.

Automatic Storage Management (ASM) — менеджер томов и файловая система, которые могут работать как в кластере, так и с singleinstance базой данных. ASM разбивает файлы на ASM Allocation Unit.

Размер Allocation Unit определяется параметром AU_SIZE, который задается на уровне дисковой группы и составляет 1, 2, 4, 8, 16, 32 или 64 MB. Далее Allocation Units распределяются по ASM-дискам для балансировки нагрузки или зеркалирования. Избыточность может быть реализована, как средствами ASM, так и аппаратно.

ASM-диски могут быть объединены в Failure Group (то есть группу дисков, которые могут выйти из строя одновременно — например, диски, подсоединенные к одному контролеру), при этом зеркалирование осуществляется на диски, принадлежащие разным Failure Group. При добавлении или удалении дисков ASM автоматически осуществляет разбалансировку, скорость которой задается администратором.

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

Oracle рекомендует использовать ASM в качестве решения для управления хранением данных вместо традиционных менеджеров томов, файловых систем или RAW-устройств.

Развертывание Oracle RAC

Рассмотрим этапы установки различных компонентов, необходимых для функционирования Oracle RAC в режиме active/active кластера с двумя узлами. В качестве дистрибутива будем рассматривать последнюю на момент написания статьи версию Oracle Database 11g Release 2. В качестве операционной системы возьмем Oracle Enterprise Linux 5. Oracle Enterprise Linux — операционная система, базирующаяся на RedHat Enterprise Linux. Ее основные отличия — цена лицензии, техническая поддержка от Oracle и дополнительные пакеты, которые могут использоваться приложениями Oracle.

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

На узлах должен быть настроен доступ к внешним общим дискам, на которых будут храниться файлы базы данных и файлы Oracle Clusterware. К последним относятся votingdisk (файл, определяющий участников кластера) и Oracle Cluster Registry (содержит конфигурационную информацию — например, какие экземпляры и сервисы запущены на конкретном узле). Рекомендуется создавать нечетное количество votingdisk. Для создания и настройки ASMдисков желательно использовать ASMLib, которую надо установить на всех узлах:

Кроме интерфейса для взаимодействия с хранилищем на узлах желательно настроить три сети — Interconnect, External и Backup.
Необходимо настроить IP-адресацию (вручную или с использованием Oracl e GNS) и DNS для разрешения всех имен (или только GNS).

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

В конце нужно выполнить с правами root скрипты orainstRoot.sh и root.sh. Первым на всех узлах выполняется скрипт orainstRoot.sh, причем запуск на следующем узле осуществляется только после завершения работы скрипта на предыдущем. После выполнения orainstRoot.sh последовательно на каждом узле выполняется root.sh. Проверить успешность установки можно с помощью команды:

/u01/grid/bin/crsctl check cluster –all

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

Кроме active/active-кластера в версии 11g R2 существуют две возможности для создания active/passive-кластера. Одна из них — Oracle RACOneNode. Другой вариант не требует лицензии для RAC и реализуется средствами Oracle Clusterware. В этом случае вначале создается общее хранилище; затем устанавливается Grid Infrastructure, с использованием ASM_CRS и SCAN; а после этого на узлы устанавливается база данных в варианте Standalone. Далее создаются ресурсы и скрипты, которые позволяют запускать экземпляр на другом узле в случае недоступности первого.

Заключение

Oracle RAC совместно с Oracle Grid Infrastructure позволяют реализовать разнообразные сценарии построения кластеров. Гибкость настройки и широта возможностей компенсируются ценой такого решения.

Решения же Microsoft ограничены не только возможностями самой кластеризации, но и продуктами, которые могут работать в такой среде. Хотя стоит отметить, что набор таких продуктов все равно шире, чем одна база данных.

По Вашему запросу ничего не найдено.

Рекомендуем сделать следующее:

Проверьте правильность написания ключевых слов.
Используйте синонимы введенных Вами ключевых слов, например “приложение” вместо “программное обеспечение”.
Попробуйте воспользоваться одним из популярных поисковых запросов ниже.
Начните новый поиск.

Oracle RAC One Node

RAC One Node provides higher availability by eliminating the database server as a single point of failure.

Video: Oracle RAC One Node Demo

Report: Oracle RAC One Node (PDF)

Video: Autonomous Database Keynote Highlights

Architecture

Similar to Oracle Real Application Clusters (RAC), Oracle RAC One Node uses a shared disk system to provide best in class high availability for Oracle Databases. Unlike Oracle RAC, which runs multiple instances concurrently, Oracle RAC One Node provides an Oracle Database failover solution for that facilitates the clustered infrastructure. It requires no application changes, can support any Oracle Database workloads, and is easily upgraded to a full multi-instance Oracle Real Application Clusters configuration.

High Availability

Eliminates the single database server as a single point of failure, and takes further advantage of clustering to apply rolling patches and database service relocation without incurring downtime.

Database as a Service

Provides all the software components required to easily deploy Oracle Database instances on a pool of servers and take full advantage of the performance, scalability and availability that clustering enables.

Database Consolidation and Virtualization

Multiple single database instances can be configured on a physical Oracle RAC One Node server. In addition, with full support for Oracle VM, multiple database instances and be configured in a virtualized environment.

Oracle RAC Family of Solutions

The Oracle RAC Family of Solutions refers to the collection of products and features that licensed Oracle RAC or Oracle RAC One Node customers can use free of additional charge. Each solution either enhances or complements the core Oracle RAC offering by ensuring better high availability and scalability or by automating and simplifying day-to-day operation. Learn more about these valuable enhancements by following the links under the Related section below.

Читайте также: