Кластерные системы традиционно рассматриваются в качестве альтернативы большим компьютерам, созданным на основе архитектуры симметричной мультипроцессорной обработки (SMP). Объединение вычислительных мощностей множества независимых компьютеров в единую систему для решения одной задачи позволяет вычислительным кластерам получить следующие преимущества над большими ЭВМ:
• Экономичная масштабируемость - известно, что стоимость 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-рекомендаций.