1. Главная страница » Компьютеры » Oracle real application cluster

Oracle real application cluster

Автор: | 16.12.2019

Oracle Real Application Clusters (RAC) — программное обеспечение для кластеризации и повышения доступности для Oracle Database. Oracle поставляет RAC как дополнение к Oracle Database, бесплатное для стандартной редакции СУБД (англ. Standard Edition ) и платное для редакции уровня предприятия (англ. Enterprise Edition ). Впервые разработано в 2001 году для Oracle Database версии 9i.

Содержание

Функциональность [ править | править код ]

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

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

Развитие [ править | править код ]

До создания RAC, СУБД Oracle требовала сторонних продуктов (таких как Sun или Veritas Cluster) для поддержки кластеризации. Для операционных сред, не имевших собственных средств кластеризации (Linux, Windows) было разработано бесплатное дополнение Cluster Ready Service, которое с версии 10g было переименовано в Oracle Clusterware. После создания RAC, пользователям больше не нужно использовать сторонние средства кластеризации. Однако пользователь может выбирать между Oracle RAC и сторонней программой.

Компания «1001 СОФТ» является официальным партнером компании Oracle в Санкт-Петербурге. В нашей компании Вы можете купить лицензионные продукты Oracle. Чтобы совершить покупку, Вам надо позвонить по телефону в Санкт-Петербурге /СПб/ (812) 670-02-06 или отправить запрос на адрес zakaz@1001-soft.ru, наши специалисты ответят на Ваши вопросы и подберут оптимальный вариант поставки.

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

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

Real Application Cluster

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

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

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

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

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

При использовании вместе с СУБД Oracle сформированные с помощью Grid-технологии пулы стандартных недорогих компьютеров и модульных систем хранения данных делают это решение еще более гибким. Процесс наращивания ресурсов становится значительно более простым и быстрым, поскольку при необходимости расширения к кластеру можно добавлять новые узлы вместо того чтобы заменять существующие более мощными. Технология Cache Fusion, реализованная в Real Application Clusters, и поддержка InfiniBand, предусмотренная в СУБД Oracle, позволяют практически линейно наращивать пропускную способность системы без каких-либо изменений в приложениях.

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

Другое ключевое преимущество кластерной архитектуры на основе Oracle RAC – присущая ей устойчивость к отказам за счет наличия множества узлов. Поскольку физические узлы работают независимо друг от друга, отказ одного или нескольких узлов не оказывает влияния на работу остальных узлов кластера. Аварийное переключение сервиса может быть произведено на любой узел Grid. В самой крайней ситуации система на базе Real Application Clusters способна поддерживать работу базы данных даже при отказе всех узлов за исключением одного.

Читайте также:  Miboxer c4 vc4 обзор

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

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

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

Единый стек кластерного ПО

Oracle Database Enterprise Edition и Опция Real Application Clusters составляют полный комплект ПО управления и функционирования кластера. Кластерное программное обеспечение Oracle (Clusterware) предоставляет все необходимые возможности, требуемые для работы кластера, включая учет узлов, службы сообщений и блокировки.

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

  • Сравнение возможностей редакций Oracle Database
  • Сравнение Oracle 11g и Microsoft SQL 2008
  • Сравнение Oracle и PostgreSQL

На сайте представлен неполный перечень программных продуктов Oracle, которые Вы можете купить в нашей компании. Если Вам нужен продукт не представленный на сайте, обратитесь к нам по тел. (812) 670-02-06. Возможна поставка продуктов Oracle во все регионы России.

Высоконагруженные сайты, доступность «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.

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

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

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

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

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

  • журнал повтора (redo log)
  • сегмент отмены (undo)
Читайте также:  Msmpeng exe грузит память

Когда в базу данных поступает запрос на изменение, то 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.

ASM работает поверх RAW device, его преимуществами являются:

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

Disk group — объединение нескольких дисков. При записи файлов на диски данные записываются экстентами размерами по 1 МБ, распределяя их по всем дискам в группе. Это делается для того, чтобы обеспечить высокую доступность, ведь части одной таблицы (из tablespace) разбросаны по разным физическим дискам.

Способности ASM:

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

Предположим, что несколько дисков подключены к определенному контроллеру- и, таким образом, представляют собой, SPF – single point of failure (При выходе из строя контроллера теряем весь дисковый массив). У ASM есть технология определения Failure Groups внутри Disk Group. При этом механизме зеркалирование будет раскидывать копии экстентов по дискам, находящимся в различных failure groups, чтобы избежать SPF (Single Point of Failure), например, при смерти SAN или RAID контроллера.

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

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

Clusterware. CRS.

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

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

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

CRS состоит из 3-х основных компонент:

  • CSSD – Cluster Synchronization Service Daemon
  • CRSD – Cluster Ready Services Daemon
  • EVMD – Event Monitor Daemon
x Назначение (вкратце) С какими правами работает При смерти процесса, перезагружается:
CSSD Механизм синхронизации для взаимодействия узлов в кластерной среде. user процесс
CRSD Основной «движок» для поддержки доступности ресурсов root хост
EVMD Процесс оповещения о событиях, происходящих в кластере user процесс

Настройки кластера хранятся в OCR (Oracle Cluster Registry). OCR – это специальный файл профилей узлов базы данных, хранящий их текущую конфигурацию: доступность узлов, распределение сервисов (несколько БД могут поддерживаться различными группами узлов в кластере), сетевые настройки и.т.п. Физически OCR хранится в общем datastorage. При работе кластера каждый узел хранит в памяти OCR, и только один узел (master) производит непосредственное обновление OCR на диске.

Как уже стало ясно из таблички, самым главным процессом, «самым могущественным демоном», является 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.

В обязанности сервиса CSSD (Cluster Synchronization Service Daemon) входит координация взаимодействия узлов кластера, синхронизация узлов и ресурсов между ними, определение их доступности через следующие функции:

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

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

Информатором в кластере выступает 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 для задержек.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *