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

23.04.2012

16

Настройка Ораклового двух-нодового кластера базы данных 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.
  • Добрый день!
    Не замечали падения производительности при переносе БД со standalone на RAC?
    Спасибо за хороший гайд )

  • Замечательная инструкция!!! Надо будет обязательно попробовать. И написать похожую про инсталляцию Oracle Enterprise Manager B-)

    При регистрации получаю вот такое сообщение:
    Доступен WordPress 3.3.2! Пожалуйста, сообщите администратору сайта.
    Сим сообщаю.

    • Под Oracle Enterprise Manager я имел в виду версию 12с.

      • KSDaemon

        Да, давно собираюсь поставить/посмореть, но все руки не доходят… Ничего, найдем врем 🙂

  • VVD

    Что-то явно не то в разделе «Настройка dns» в примере конфига bind.
    Имена хостов отличаются от используемых в дальнейшем по тексту.
    Но это не главное — догадаться можно и так.
    У меня другой вопрос — каким именно хостам и каким их интерфейсам присвоены эти все IP? Далее по тексту разъясняется только о n1, n2, n1-priv, n2-priv. А вот чему присваивать IP n1-vip, n2-vip, и rac-scan я так и не понял…

    Есть 1 сервер для Oracle DB с 1 IP, через некоторое время предполагается поставить второй сервер. Но настроить кластер хотелось бы уже сейчас, чтобы потом просто добавить ноду в готовый кластер. В связи с этим непонятно куда прописывать столько IP.

    • KSDaemon

      Про имена хостов — да, там просто приведены примеры уже насторенных dns двух систем.
      А про интерфейсы — видимо вы просто не внимательно читали вводную часть, да и совсем не изучили таблицу, которую я привел в самом начале раздела про dns. Иначе бы вы увидели, что все адреса n1,n1-vip,scan,n2,n2-vip находятся в одной подсети, а n1-priv/n2-priv — в другой. И в самом начале я сказал, что на каждом сервере должно быть минимум по 2 интерфейса — один для интерконнекта, другой для публичной/рабочей сети. Из этих данных легко сделать вывод, что все публичные адреса, scan, vip — вешаются на один публичный интерфейс.

      • VVD

        Прочитал, но написано действительно запутанно и совсем не очевидно, что речь идёт об одних и тех же интерфейсах (в случае n1, n1-vip и scan). В примере 3 IP на scan, при этом серверов всего 2 — какие IP на каких серверах должны быть?
        В оракловой табличке вообще какие-то свои термины — что за тип такой «virtual»? Это алиас на lo0 + включенный arp proxy? Или алиас на интерфейсе public с маской 255.255.255.255? Табличка больше запутывает, чем разъясняет.
        > Иначе бы вы увидели, что все адреса n1,n1-vip,scan,n2,n2-vip находятся в одной подсети
        Видать ещё не сталкивались с IP из одной подсети на разных интерфейсах (с разными масками). Я к тому, что это обычное дело, а значит совсем не очевидно что и где должно быть.
        > Из этих данных легко сделать вывод, что все публичные адреса, scan, vip — вешаются на один публичный интерфейс.
        Ну-ну. Т.е. нужен ещё скил телепата, чтобы понять, что имел в виду автор статьи и сами оракловцы? Ну или солидное терпение — перебирать варианты. 🙁

        Интерфейсов есть и больше, чем 2, но IP пока 1, подключен «проводок» только к одной сетевухе, а остальные не используются.
        Отдельные IP для scan не предполагались — без этого совсем никак?
        Когда появится второй сервак, тогда он соединится с первым отдельным каналом со своими внутренними IP — это и будут интерфейсы private. Сейчас же есть только один сервер и воткнут в него только один «проводок», и выделен только 1 IP. Дополнительные IP надо заказывать, а эта процедура не быстрая. Уже начал придумывать заведомо несуществующие в компании и в мире подсети, чтобы набрать необходимое для установки количество IP… Как-то это всё криво… Всё у Oracle не по людски…

        • KSDaemon

          Ну у Оракла действительно все не так как у всех, но, знаете, если понять и осознать, то не так уж там все не правильно или не логично. Можно свыкнуться.
          А про сети: если на интерфейсах разные маски — это означает разные подсети. Однако что-то я сомневаюсь, что вы сможете дать адреса сеток, чтобы публичные и vip-адреса были в разных подсетях (для айпишников в той таблице). Ну да ладно. Не будем спорить.
          По поводу scan-адресов: их нужно минимум три. И в случае двух нод, очевидно 2 scan-адреса будут висеть на одной ноде. Но этот процесс вообще вами не контролируем, это как crsd решит.
          Для экспериментов, вы можете попробовать обойтись прописыванием всех адресов в /etc/hosts, но в любом случае scan-адреса должны быть в той же подсети, что и публичные адреса нод. Без этого оно просто не поставится.

          • VVD

            > А про сети: если на интерфейсах разные маски — это означает разные подсети.
            eth0: a.b.c.d/24, eth1: a.b.c.e/25 — IP a.b.c.e входит в подсеть a.b.c.0/24, куда также входит и IP a.b.c.d — чем не 2 IP из одной подсети на разных интерфейсах? Ну да ладно — с этим уже разобрались, хоть и в комментариях, а не в статье.

            Методом тыка определил, что НЕ надо поднимать IP для SCAN нигде вообще. По статье это непонятно — думал, что надо их делать алиасами.
            Остаётся непонятно надо ли поднимать самостоятельно IP для VIP алисами на основном интерфейсе или это сделает Oracle самостоятельно?

            Так же могу сказать, что поднятие кластера на одной ноде стопорится на «SSH Connectitivity» — видимо инсталлятор клинит при попытке связаться по ssh попарно между всеми нодами, когда в списке она всего одна…

  • KSDaemon

    2VVD: Да, ни SCAN-адреса, ни VIP-адреса — самим прописывать не надо, это делает кластерное ПО Оракл само. Про ssh-доступность — нет, вы не правы, видимо у вас не правильно указаны пароли/логины. У меня даже с одной нодой все проходило успешно.
    П.С. про адреса поправлю статью.

    • VVD

      Нода одна. Логин grid, пароль grid — ошибиться тяжело, тем более раз 10 подряд. :-]
      К тому же кнопочка Setup отрабатывает, а Test — нет.
      Сейчас попробую ещё раз.

      • VVD

        О ужас!
        Методом научного тыка было определено, что hostname сервера должен совпадать с хостом, который указывается на скриншоте http://blog.ksdaemon.ru/wp-content/uploads/2012/04/Ora-Grid-Infrastructure6.png — «n1»! Что за бред? DNS в обе стороны резолвит как надо: n1=>IP1, IP1=>n1, но этого для Oracle не достаточно.
        Не очень хочется выставлять hostname сервака в что-то типа «node1″…
        Или забить на красивые имена и выставить реальные srv—-, которые им назначили согласно регламенту именования серверов компании…
        Что говорит об этом «best practice» Oracle?

        Так же для прохождения проверки пришлось сначала удалить содержимое ~grid/.ssh/*, а потом залогиниться по ssh с grid@n1 на grid@n1 и на grid@n1.rac. Потом нажать Setup, и только после этого Test стал отрабатывать. И Next тоже прошёл! Где здесь логика? Интсталлятор сам не мог «yes» вбить на вопрос о подтверждении ключа, или что там у него не получалось?

        • VVD

          Скриншот Step 14 установки Grid Infrastructure.
          Ругается на то, что:
          1. пользователь grid не находится в группе grid (такой группы вообще нет!);
          2. группа у /dev/oracleasm/disks/* dba, а должна быть grid.

          Как исправить понятно, но не понятно как именно должно быть.

  • Большое спасибо. Отличный пост!
    Знаю, что RAC можно создать и на платформе MS, хотя у многих, возможно, это вызовет усмешку, ибо считается, что кластер Oracle на Linux-е работает намного лучше.
    И все же такая потребность есть… и поэтому хучу спросить:
    — есть ли какие то принципиальные отличия в процессе развертывания? Может быть есть какие-то особенности;
    — Чем, на ваш взгляд, кластер на винде хуже (или лучше), чем на Linux (возможно, доводилось сравнивать)?

    • KSDaemon

      Нуу… Принципиальных различий с точки зрения оракла — нет. Тут скорее различия в подготовке дисковых систем, на которых будет подниматься ASM и прочих моментах.
      Я, просто, честно не люблю М$. Как-то у меня на линуксе все просто, стабильно и понятно. Да и если что — я всегда зайду в консоль и все поправлю.

  • Pingback: Oracle Data Guard между RAC и standalone. Часть первая: Oracle Linux, ASM, GRID, RAC | Системная архитектура и все-все-все()