Перейти к содержимому

23.04.2012

17

Настройка Ораклового двух-нодового кластера базы данных Oracle RAC 11gR2.

В этой статье, или серии статей, я расскажу, как поднять оракловый кластер 11gR2 из двух нод, и затем поднять на этом кластере базу данных и настроить отказоустойчивый сервис. В качестве основной ОС будем использовать Linux CentOS 5 x86_64.
Вся процедура состоит из нескольких последовательных этапов:

  1. Настройка окружения: настройка dns-сервера, выделение ip-адресов.
  2. Подготовка железа: серверы, массивы/хранилища. /* Опустим этот этап, ибо он будет специфичен в каждом случае */
  3. Подготовка операционной системы: установка необходимых пакетов, создание необходимых юзверей и структуры каталогов.
  4. Подготовка и конфигурирование ASM.
  5. Установка Oracle Grid Infrastructure 11gR2.
  6. Установка сервера базы данных Oracle RDBMS Server 11gR2.
  7. Создание cluster-based сервиса базы данных с TAF (Transparent-Application-Failover) и FAN (Fast Application Notification).
  8. Радость по поводу успешной настройки 🙂

Совсем немного теории.

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

Оракловый кластер (впрочем как и любой другой) состоит из нескольких нод/узлов. Каждый узел — это отдельный сервер. На каждом сервере должно быть не менее двух сетевых интерфейсов: один публичный и один интерфейс для интерконнекта. Так же необходимо хранилище данных, которое доступно всем нодам, и выделенное пространство является разделяемым (shared) между всеми нодами кластера. В качестве хранилища можно использовать разные варианты: nfs; общие диски, если вы настраиваете кластер на виртуальных машинах; iSCSI; ну и наверное самый очевидный для продакшн вариант — реальное хранилище, каким либо способом подключенное ко всем нодам, например оптикой.

С точки зрения софта, кластер функционирует следующим образом:
Все ноды в кластере с точки зрения ОС должны быть одинаковыми, то есть, например, если вы используете linux, значит на всех нодах должна стоять ось одной и то же битности, не допускается одновременное использование 32-х и 64-х битных узлов, и, конечно, крайне желательно одной и той же версии (странно, если кто-то делает по-другому). Далее, для корректного функционирования кластера, необходима конфигурация dns-сервера. Смысл конфигурации в том, что начиная с версии 11gR2, оракловый кластер использует механизм SCAN (Single Client Access Name). Смысле этой фичи в том, что все клиенты один раз настраиваются на обращение к одному hostname, который средствами dns сервера может резолвиться в несколько ip-адресов, на каждом из которых висит публичный LISTENER. Это так называемые виртуальные адреса кластера. Все listener’ы на публичных адресах перенаправляют запросы на локальные listener’ы, запущенные на частных адресах конкретных нод. Оракловое ПО clusterware, установленное на всех нодах кластера, умеет общаться между собой, используя для этого interconnect и public сеть и поэтому всегда есть актуальная информация о том, какие ноды сейчас доступы, и в случае падения например одной ноды, виртуальных listener, который физически был запущен на упавшей ноде автоматически поднимается на доступном узле, и соответственно все запросы уже перекидываются на честные listener’ы на доступных нодах. Так же можно настроить TAF (Transparent Application Failover), чтобы открытое соединение к базе данных автоматически средствами сервера перекидывалось на доступную ноду, даже без потери данных.

Такс, вернемся к узлам. На каждой ноде устанавливается Oracle Clusterware, начиная с 11-й версии это отдельный софт, и его желательно ставить из-под отдельного пользователя. Для функционирования Clusterware необходим так называемый voting disk, который должен быть доступен одновременно всем нодам. Лучше всего использовать ASM, и инициализировать ASM диски на расшаренном хранилище. Тогда и все данные БД можно будет так же расположить на ASM. Далее, на каждый узел ставится Oracle RDBMS Server.

Небольшое дополнение: я говорю, что весь софт ставится на каждую ноду, и многие могут подумать, что это означает ручную установку всего ПО на каждой ноде. Нет, это не так. Вы просто заводите на каждом сервере/ноде одинаковых пользователей, даете всем одинаковые пароли или публикуете публичные ключи, и запускаете установку софта только на одной ноде, а оракл уже сам поставит все и на другие ноды в кластере тоже.

Пожалуй, хватит теории, перейдем к практике!

Настройка dns.

Не буду расписывать как настроить сам dns-сервер. По этому поводу в инете полно материалов, а может быть даже в вашей мегакомпании есть отдельные сетевики/админы, которые вам все сделают 🙂 Поговорим про настройку dns в контексте кластера. Вот скрин того, что написано в документации оракл.

На каждую ноду надо по 3 адреса: собственный публичный адрес ноды, виртуальный адрес ноды, приватный адрес ноды для интерконнекта + минимум 3 адреса SCAN для кластера. Если хочется, можно приватные адреса нод прописать в /etc/hosts на каждом узле. Но имейте в виду, что если вы потом добавите еще ноды, то эту операцию придется снова повторить на каждой ноде. Так что лучше ве прописать в dns, тогда при необходимости все правки надо будет вносить всего лишь в одном месте. Вот примеры конфига named и djbdns.

Идем дальше.

Подготовка операционной системы.

Первым делом надо установить необходимые пакеты, прописать/изменить необходимые параметры ядра и все такое прочее. С недавних пор у Оракл есть замечательный пакет oracle-validated, который упрощает всю эту процедуру и берет часть работы на себя. Крайне рекомендую им воспользоваться. Этот пакет доступен на oss.oracle.com/el5/oracle-validated/. Я скачал этот пакет и сразу положил его в свой локальный yum-репозиторий, чтобы он всегда был под рукой, да и при установке через yum автоматически удовлетворятся все зависимости. Итак, ставим oracle-validated на каждой ноде. Он доставит необходимые пакеты, добавит необходимые опции ядра в /etc/sysctl.conf, и даже добавит пользователя oracle, который нам в дальнейшем пригодится.

Однако этого нам мало. Из-под пользователя oracle будет работать база данных. По рекомендациям Оракла, кластерное ПО лучше запускать из-под отдельного пользователя, обычно это grid. Создадим его на каждой ноде.

Далее необходимо создать структуру каталогов, в которой будет размещаться софт оракла. Следуя схеме OFA (ну или частично следуя 🙂 сделаем /u01/app/grid /u01/app/oracle и так далее. Опять же, делаем это на всех узлах кластера.

Подготовка и конфигурирование ASM.

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

Гланое, чтобы версия драйвера ASM совпадала с версией ядра вашей операционной системы. Ну и архитектура конечно тоже. В моем случае ядро было 2.6.18-274 и драйвер я скачал соответственный. Узнать версию ядра можно командой uname -a. Скачать все эти пакеты можно с сайта Оракла тут.

Итак, ставим пакеты на каждой ноде.

После этого можно приступать к конфигурации ASM. Первым делом надо сконфигурировать сам драйвер. Это делается один раз. Запускаем конфигурирование и указываем некоторые данные: пользователя, из-под которого будет работать драйвер и кому будет принадлежать интерфейс, группу, запускать ли драйвер при старте системы. Если вы придерживались этой статьи, и завели двух пользователей, одного для кластера, другого для базы данных, то здесь надо указать пользователя кластера.

После этого можно создать диски ASM из устройств с расшаренного хранилища. В моем случае в качестве хранилища выступает массив EMC, подключенный двумя оптическими шнурками с настроенным failover. Поэтому в моей системе эти диски видны как /dev/emcpower*. Для начала размечаем диски с помощью fdisk или любой другой утилиты, какая вам больше нравится. После этого инициализируем эти диски как ASM. Делаем это на одной ноде.

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

После этого можно приступать к установке clusterware.

Установка Oracle Grid Infrastructure.

Проделав все вышеперечисленные процедуры и операции мы подошли к тому, что можно начинать ставить софт Оракл. Первым делом надо поставить Oracle Grid Infrastructure, в составе этого пакета идут необходимые кластерные компоненты Oracle Clusterware. К этому моменту у нас должен быть настроен dns, инициализированы ASM диски, созданы необходимые пользователи и структура каталогов, куда все будем ставить.

Вот, кстати, наглядная схемка компонентов Ораклового кластера и последовательность старта 🙂 Кому интересно копнуть глубже, в конце будет список документов, которые можно почитать по теме.

Запускаем инсталлер от имени пользователя, которого мы специально завели для кластера — grid и погнали!
Выбираем установку кластера.

Продвинутый режим.

Выбираем нужные языки

Далее указываем название нашего кластера и важно указываем scan-адрес, который мы прописали в dns.

Далее настраиваем наши ноды. По умолчанию, инсталлер конечно же добавляет одну ноду, ту, на которой он был запущен. Добавляем сюда нашу вторую ноду, указываем пароль пользователя, чтобы проверить доступность ноды по ssh. Так же здесь указываем виртуальные адреса нод, которые мы так же прописали в dns.

Если после нажатия «Next/Следующий» у вас появляется ошибка, что введенный виртуальный адрес не верен ( у меня появилась такая ошибка в одной из инсталляций), то исправить ее можно путем явного прописывания всех виртуальных адресов в /etc/hosts каждой ноды. По крайней мере так советуют сделать в MOS 264847.1.

Далее надо указать типы сетевых интерфейсов на узлах кластера. Напомню, что на каждом сервере у нас должно быть минимум 2 сетевых интерфейса, и они должны быть настроены однообразно. То есть если на одной ноде первый интерфейс eth0 — публичный, а eth1 — приватный, для интерконнекта, то на других нодах eth0 не может быть приватным, а так же должен быть настроен как публичный интерфейс.

Далее настраиваем хранилище. В нашем случае — это ASM. Выбираем те самые диски, которые мы инициализировали с помощью oracleasm. Важный момент — на забыть выбрать правильный режим избыточности. В моем случае раздела на массиве сделаны на RAID-группах, поэтому я выбираю внешнюю избыточность. В этом случае Оракл ASM не будет дублировать данные между дисками. Далее указываем пароль/пароли для администрирования ASM.

Пропустим настройку IPMI. Хотя если у вас настроена консоль управления — можете здесь указать ее параметры и oracle clusterware будет про нее знать и использовать для управления серверами.

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

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

После этого инсталлер проведет ряд проверок, и выдаст окошко с информацией о том, какие тесты не прошли. В моем случае были обнаружены проблемы со свапом, но ее можно смело игнорировать, потому как оракл хотел 16 гиг, а у меня было 15.6 — в общем это вообще не проблема. Не было установлено несколько пакетов — пришлось их доставить. Ну и еще одна проблема с количеством открытых дескрипторов файлов — её мог устранить сам инсталлер.

Здесь стоит еще сказать, что у Grid Infrastructure 11.2.0.1 и 11.2.0.3 несколько разные требования и проверки. В случае установки 11.2.0.1 у меня возникли только ошибки, описанные выше. При установке версии 11.2.0.3 установщик так же ругнулся на неверные настройки в /etc/resolv.conf. В свежей версии проверяются различные таймауты на запросы к днс-серверу, так что потребовалось дополнительно настроить таймауты и количество попыток. Делается это так:

После этого краткий обзор нашей установки. Можно сохранить его в файл ответов и в дальнейшем проводить silent-установку без вопросов и графики. Жмем «Готово» и начинается уставновка.

Ближе к концу установки появится окно с предложением выполнить пару скриптов от имени root на каждой ноде. Делаем это и жмем «окей». Здесь стоит подчеркнуть, что НЕ НАДО запускать эти скрипты одновременно на всех нодах. Это может привести к ошибкам. Скрипт orainstRoot.sh отработает быстро, а вот root.sh — выполняется достаточно долго, потому что он производит конфигурирование ноды кластера. Поэтому мой совет, подождите, пока этот скрипт полностью отработает на одной ноде и только потом запускайте его на следующей.

Ну что ж, на этом установка Oracle Grid Infrastructure for Cluster успешно (я надеюсь) завершается.

Чтобы проверить, что все прошло успешно, и наш новенький кластер функционирует как положено, можно воспользоваться утилитой crsctl. Запускаем ее вот такую штуку из-под рута на каждой ноде и убеждаемся, что все онлайн.

Проверить работоспособность ASM, сети, SCAN, listener’ов и прочих компонентов, можно так.

Все прекрасно, все онлайн 🙂 Можно идти дальше. А дальше по плану — установка сервера базы данных. Однако здесь стоит сказать вот что: если вы планируете ставить БД версии 11.2.0.1, то можете переходить к установке БД; если же вы планируете ставить версию по-новее (на момент написания статьи это 11.2.0.4), то прежде чем приступать к установке БД, надо обновить clusterware. Да и вообще, если это продакшн-инсталляция, и у вас есть доступ к апдейтам, это крайне желательно сделать.

Установка Oracle Database Server 11gR2.

Сервер базы данных мы будем ставить из-под отдельного пользователя, исторически так сложилось, что обычно это oracle. Собственно, он был создан автоматически при установке пакета oracle-validated. Логинимся под пользователем oracle и запускаем runInstaller. Если у вас есть доступ на support.oracle.com к скачиванию свежих релизов — имеет смысл скачать последнюю версию, иначе придется ставить 11.2.0.1, доступную для всех.

Создаем новую базу данных.

Указываем, что мы хотим создать кластерную базу данных. Выбираем наши ноды, указываем пароль пользователя oracle и проверяем доступность нод по ssh.

Выбираем расширенный режим установки.

Выбираем нужные нам языки и затем редакцию базы данных.

Далее указываем место установки софта. Указываем здесь те папки, которые мы подготовили в начале.

Выбираем тип базы данных.

Указываем имя БД и ее SID.

Далее, выделяем память, и, самое главное, указываем кодировку нашей БД. Лучше всего использовать UTF8, это избавит вас в дальнейшем от многих проблем, уж поверьте 🙂

Дальше выбираем, как мы будем управлять нашей БД: если у вас есть настроенный EM Grid Control — на этом шаге можно сразу подключить БД в Grid, а если нет — использовать DB Control.

Указываем где мы будем хранить данные. Выбираем конечно же ASM, иначе зачем мы его настраивали 🙂 Указываем пароль ASMSNMP пользователя.

Сразу настраиваем ежедневные бэкапы в ASM. Затем указываем дисковую группу ASM, где будут лежать данные, у меня это DATA.

Указываем пароли системных пользователей баз данных, а затем системные группы пользователей с привилегиями sysdba и sysoper.

Далее инсталлер проводит несколько тестов. Если что-то не так, вы снова увидите список проваленных проверок и их надо будет поправить. В этот раз у меня провалилась только проверка на свап. Но вы помните что было в прошлый раз (при установке Grid Infrastructure), так что эту ошибку мы проигнорируем.

Крткий обзор нашей установки и погнали.

Как всегда, в процессе установки надо будет выполнить скрипт из-под рута. Делаем это на всех нодах.

Ну вот и все! Установка прошла успешно.

Создание cluster-based сервиса базы данных с TAF и FAN.

Теперь мы подошли к самому интересному. У нас настроен кластер, поднят сервер БД, осталось настроить сервис базы данных, чтобы он мог использовать наш кластер по максимум, например TAF, а для .NET и Java приложений еще и FAN. То есть уже можно обращаться к кластерной БД, но никакие плюшки типа перекидывания соединения при падении ноды нам не доступны. Исправим это. В EM версии 11.2.0.1 почему-то ссылка на управление кластерными сервисами появляется только после того, как хотя бы один такой сервис уже есть. В случае EM версии 11.2.0.4 такая ссылка есть сразу. Но в любом случае такой сервис можно сделать из консоли. Чтобы создать новый сервис, воспользуемся утилитой srvctl. Поскольку мы делаем сервис базы данных, то запускать ее следует из-под пользователя, под которым работает сервер БД, то есть oracle в нашем случае. У srvctl можно вывести помощь по любой команде или связке команда+объект. Для создания сервиса нам нужна команда srvctl add service. Я показал какие параметры есть у этой команды и что они значат.

Теперь можем запустить его и проверить что этот сервис запущен и работает.

Теперь, если мы выполним команду проверки статуса всех компонентов кластера, там появятся еще 2 компонента: просто база данных, и наш только что созданных сервис.

Теперь, если зайти в em dbconsole в раздел Availability, можно увидеть ссылку: Cluster Managed Database Services. Вот два скриншота из версий 11.2.0.1 и 11.2.0.4

Нажав на нее, указываем пользователей и пароли для доступа к сервису и попадаем в список кластерных сервисов.

Выбираем Manage и жмем «Go». Попадаем в более подробное описание нашего сервиса.

Если нажать Service Properties Edit — мы увидим те самые настройки отказоустойчивости, которые мы указывали при создании нашего сервиса.

Ну вот мы и подошли к самому главному и заключительному пункту нашей статьи.

Радость по поводу успешной настройки.

Ура!!! 🙂 🙂 🙂

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

  • An Oracle White Paper. Application Failover with Oracle Database 11g.
  • An Oracle White Paper. Automatic Workload Management with Oracle Real Application Clusters 11g Release 2.
  • White Paper. Deploying Oracle Database 11g Release 2 on EMC Unified Storage.
  • Oracle® Clusterware. Administration and Deployment Guide 11g Release 2 (11.2) E10717-03.
  • Oracle® Database. High Availability Overview 11g Release 2 (11.2) E10804-01.
  • Oracle® Database. Net Services Administrator’s Guide 11g Release 2 (11.2) E10836-07.
  • Oracle® Real Application Clusters. Administration and Deployment Guide 11g Release 2 (11.2) E16795-11.
  • Oracle® Database. 2 Day + Real Application Clusters Guide 11g Release 2 (11.2) E17264-11.
  • Oracle® Grid Infrastructure. Installation Guide 11g Release 2 (11.2) for Linux E22489-04.
  • Oracle® Real Application Clusters. Installation Guide 11g Release 2 (11.2) for Linux and UNIX E24660-02.
  • Oracle Maximum Availability Architecture White Paper. Client Failover Best Practices for Highly Available Oracle Databases: Oracle Database 11g Release 2.
  • Rac11gR2OnLinux.
  • SINGLE CLIENT ACCESS NAME (SCAN). scan-129069.
  • An Oracle White Paper. Oracle Real Application Clusters (RAC) 11g Release 2.