|
Обзор основных возможностей Oracle Real Application
Cluster
Real Application Cluster (RAC) работает поверх
аппаратного кластера. Аппаратный кластер -
группа независимых серверов, объединенных
в единое целое.
Основные компоненты кластера - собственно
сервера (nodes), межкластерное соединение (cluster
interconnect) и общая дисковая подсистема (shared
storage subsystem). Отдельные сервера разделяют
дисковую подсистему и ресурсы, которыми они
управляют, но они не разделяют основную собственную
физическую память между другими сервера.
Кластерная БД объединяет память
отдельных серверов, чтобы обеспечить
единую распределеную кеш-память всей БД.
Каждый сервер кластера может иметь
несколько процессоров. Обычно,
используются сервера с симметричной
многопроцессорной архитектурой (SMP). Каждый
сервер поддерживает собственный
инстанс БД, работая со своей собственной
физической памятью под управлением своей
операционной системы.
Основные достоинства кластерных
систем
Масштабируемость - Возможность
преодолевать ограничения аппаратных
средств. Как только система достигает
порога своих ресурсов, добавление еще
одного процессорного узла позволяет плавно
нарастить мощность комплекса.
Вычислительные мощности могут быть
добавлены "на лету" для обеспечения
быстрых откликов системы для приложений с
интенсивным использованием процессоров и
сложных аналитических приложений. Вам не
нужно покупать аппаратуру взамен не справляющейся,
а нужно наращивать мощь своей системы.
Высокая доступность - RAC обеспечивает
окружение, устойчивое к сбоям.
Пользовательские соединения с узлом, на
котором произошел сбой, могут быть
прозрачно перенесены на доступный узел.
RAC сохраняет все возможности Oracle Fast
Start Fault Recovery (быстрое восстановление после
сбоя), свойственные обычной версии, такие
как Fast Start Checkpointing и Fast Start Rollback, и расширяет
доступность за счет использования на
кластерных архитектурах.
Warm Failover - пользователи прозрачно
переводятся на соседний узел кластера.
На этом узле уже запущен экземпляр Real Application
Cluster и открыта база данных. Это значительно
экономит время, так как соседний узел уже
готов к работе и вполне возможно, что в его
буферах данных уже находятся данные
последних запросов узла, с которого
переключаются пользователи.
Hot Failover - пользователи автоматически
переключаются в случае сбоя на соседний
узел, где уже заранее установлены
соединения. Это значительно экономит время,
необходимое для перевода сессии, и
уменьшает сложность для пользователя. Все
эти операции происходят абсолютно
прозрачно для пользователя.
Устойчивость к сбоям - RAC
обеспечивает полностью устойчивую к сбоям
параллельную архитектуру баз данных, что
достигается за счет способности
восстановления при крахе (N-1) узла в N-узловом
кластере. Это означает, что пока работает
хотя бы один узел, Real Application Cluster может
динамически переконфигурировать свои
ресурсы и поддерживать непрерывное
выполнение пользовательских транзакций.
Прозрачный перевод сессий в случае сбоя
- оба вышеприведенных сценария выигрывают
от применения механизма Transparent Application Failover
при выполнениии запросов, так как в этом
случае сохраняются контекст сессии и уже
откомпилированные запросы, но в случае Hot
Failover процесс переключения происходит
значительно быстрее за счет
предустановленных соединений
пользователей с базой данных. Все
особенности обычной версии Oracle, такие как
реорганизация и дефрагментация данных "на
лету", значительно уменьшающие влияние
на производительность системы операций с
данными при рутинном администрировании,
поддерживаются и в Real Application Cluster.
Распределение нагрузки - интернет и
корпоративные приложения налагают
значительные требования для поддержки
большого числа присоединенных
пользователей. Схема, применяемая в Oracle9i
для балансировки соединений новых
пользователей, упрощает
способы управления большим числом
пользователей, не ухудшая время реакции
системы. Согласно этой схеме
пользовательское соединение
перебрасывается на узел с наименее
занятыми процессорами. Таким образом
гарантируется равномерная
загрузка всех процессоров на всех узлах
кластера и сбалансированное использование
оперативной памяти этих узлов, что
в свою очередь, приводит к уменьшению
времени отклика.
Параллельное выполнение запросов -
наивысшая производительность сервера баз
данных Oracle достигается за счет совместного
применения опции Real Application Clusters и опции,
встроенной в Enterprise Edition - Oracle Parallel Query и
обеспечивающей распараллеливание операций
обработки запросов. Real Application Cluster и Oracle Parallel
Query работают совместно и результатом этого
является значительное повышение
быстродействия во время выполнения сложных
запросов в аналитических системах и
системах хранилищ данных. Эта архитектура
выполнения запросов не имеет каких-либо
ограничений (кроме ограничений
платформы) для масштабирования аналитических
приложений, так как добавление процессора
сразу отражается на эффективности системы
в целом.
Оптимизация вычеслений - в Real Application
Clusters встроен оптимизатор параллельных
вычислений, использующий информацию о
загрузке всех процессоров на всех узлах
кластера. При использовании параллелизма,
присущего таблицам с разделами, и метода
"разделяй и властвуй" при обработке
больших запросов в аналитических системах,
запросы разделяются на меньшие подзапросы
и выполняются на всех доступных в кластере
процессорах одновременно над всеми
разделами таблицы.
Конвеерный параллелизм - обычно
используется для одновременного
выполнения операций дискретного типа,
таких как сканирование, соединения и
сортировки. Так же как и в предыдущем случае,
процессоры разных узлов загружаются
работой по необходимым сортировкам,
соединениям и слияниям, требуемым
характеристиками запросов. Архитектура
запроса позволяет простаивающему
процессору "запросить" часть заботы у
"занятого" процессора для его
разгрузки. Эта особенность, свойственная
архитектуре Oracle Parallel Query, наиболее полно
раскрывается в кластерной среде.
Простота управления - Real
Application Cluster расширяет управляемость
единичного экземпляра на кластерные
системы, предоставляя возможность связать
несколько операций управления в один пакет
и автоматически реплицировать их на все
узлы, входящие в кластер. Можно также
осуществлять мониторинг кластерной системы
так, как если бы это был единственный
компьютер с одним экземпляром Oracle Server.
Сравнение с прочими
технологиями
Компания Microsoft предложила свою
архитектуру кластеризации БД. Однако,
для ее внедрения требуется существенно
переделать существующие приложение.
Техническое сравнение двух предлагаемых
архитектур описано в статье Database
Architecture:Federated vs. Clustered
Поддерживаемые платформы
На апрель 2003 года RAC сертифицирован для
следующих платформ:
- Linux (Red Hat 2.1 Advanced Server)
- Unix (HP-UX, SPARC Solaris, HP True64, IBM AIX RS/6000)
- Microsoft Windows
- Open VMS Alpha
- S/390
Примеры внедрения
На конференции Open World были представлены
следующие доклады:
- Лидирующая в мире компания по
управлению финансовыми бумагами Merrill Lynch
Europe PLC (http://www.ml.com) и ее директор Mark Clark представляли
использование RAC в своей компании;
- Adam Dodson, (Shell International) представлял
использование RAC в своей компании;
- Статья Erik Peterson,
сотрудника консалтинговой службы Oracle об
опыте внедрения RAC в более чем 100
компаниях.
Ссылки:
|
