В этой статье, или серии статей, я расскажу, как поднять оракловый кластер 11gR2 из двух нод, и затем поднять на этом кластере базу данных и настроить отказоустойчивый сервис. В качестве основной ОС будем использовать Linux CentOS 5 x86_64.
Вся процедура состоит из нескольких последовательных этапов:
- Настройка окружения: настройка dns-сервера, выделение ip-адресов.
- Подготовка железа: серверы, массивы/хранилища. /* Опустим этот этап, ибо он будет специфичен в каждом случае */
- Подготовка операционной системы: установка необходимых пакетов, создание необходимых юзверей и структуры каталогов.
- Подготовка и конфигурирование ASM.
- Установка Oracle Grid Infrastructure 11gR2.
- Установка сервера базы данных Oracle RDBMS Server 11gR2.
- Создание cluster-based сервиса базы данных с TAF (Transparent-Application-Failover) и FAN (Fast Application Notification).
- Радость по поводу успешной настройки 🙂
Совсем немного теории.
Можно много и долго говорить о том, как строится оракловый кластер, на какие технологии и компоненты он опирается, но я не буду этого делать. Про это написано не одна тысяча страниц оракловой документации. Так что кому интересно поглубже вникнуть — предлагаю почитать на досуге 🙂 А я попробую рассказать это в двух словах.
Оракловый кластер (впрочем как и любой другой) состоит из нескольких нод/узлов. Каждый узел — это отдельный сервер. На каждом сервере должно быть не менее двух сетевых интерфейсов: один публичный и один интерфейс для интерконнекта. Так же необходимо хранилище данных, которое доступно всем нодам, и выделенное пространство является разделяемым (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.
# Кусок зоны для named vmracnode1 IN A 192.168.24.64 vmracnode2 IN A 192.168.24.65 vmracnode1-vip IN A 192.168.24.34 vmracnode2-vip IN A 192.168.24.45 vmrac-scan IN A 192.168.24.69 vmrac-scan IN A 192.168.24.70 vmrac-scan IN A 192.168.24.71 vmracnode1-priv IN A 10.0.0.2 vmracnode2-priv IN A 10.0.0.3 # Кусок зоны для djbdns =n1.rac:192.168.204.11:86400 =n2.rac:192.168.204.12:86400 =n1-vip.rac:192.168.204.13:86400 =n2-vip.rac:192.168.204.14:86400 =rac-scan.rac:192.168.204.15:86400 +rac-scan.rac:192.168.204.16:86400 +rac-scan.rac:192.168.204.17:86400 =n1-priv.rac:10.0.0.1:86400 =n2-priv.rac:10.0.0.2:86400
Идем дальше.
Подготовка операционной системы.
Первым делом надо установить необходимые пакеты, прописать/изменить необходимые параметры ядра и все такое прочее. С недавних пор у Оракл есть замечательный пакет oracle-validated, который упрощает всю эту процедуру и берет часть работы на себя. Крайне рекомендую им воспользоваться. Этот пакет доступен на oss.oracle.com/el5/oracle-validated/. Я скачал этот пакет и сразу положил его в свой локальный yum-репозиторий, чтобы он всегда был под рукой, да и при установке через yum автоматически удовлетворятся все зависимости. Итак, ставим oracle-validated на каждой ноде. Он доставит необходимые пакеты, добавит необходимые опции ядра в /etc/sysctl.conf, и даже добавит пользователя oracle, который нам в дальнейшем пригодится.
[13:47] cmd#:140 root@racnode1: ~# yum install --nogpgcheck oracle-validated Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package oracle-validated.x86_64 0:1.0.0-24.el5 set to be updated falcon-repo/filelists | 3.5 MB 00:00 --> Processing Dependency: /usr/lib64/libodbccr.so for package: oracle-validated --> Processing Dependency: libXp.so.6 for package: oracle-validated --> Processing Dependency: /usr/lib/libXtst.so.6 for package: oracle-validated --> Processing Dependency: sysstat for package: oracle-validated --> Processing Dependency: xorg-x11-utils for package: oracle-validated --> Processing Dependency: /usr/lib/libaio.so for package: oracle-validated --> Processing Dependency: compat-gcc-34-c++ for package: oracle-validated --> Processing Dependency: libstdc++.so.5 for package: oracle-validated --> Processing Dependency: libaio-devel for package: oracle-validated --> Processing Dependency: /usr/lib/libodbccr.so for package: oracle-validated --> Processing Dependency: compat-gcc-34 for package: oracle-validated --> Processing Dependency: unixODBC-devel for package: oracle-validated --> Processing Dependency: /usr/lib64/libaio.so for package: oracle-validated --> Processing Dependency: libdb-4.2.so()(64bit) for package: oracle-validated --> Processing Dependency: libstdc++.so.5()(64bit) for package: oracle-validated --> Running transaction check ---> Package compat-db.x86_64 0:4.2.52-5.1 set to be updated ---> Package compat-gcc-34.x86_64 0:3.4.6-4 set to be updated ---> Package compat-gcc-34-c++.x86_64 0:3.4.6-4 set to be updated ---> Package compat-libstdc++-33.i386 0:3.2.3-61 set to be updated ---> Package compat-libstdc++-33.x86_64 0:3.2.3-61 set to be updated ---> Package libXp.i386 0:1.0.0-8.1.el5 set to be updated ---> Package libXtst.i386 0:1.0.1-3.1 set to be updated ---> Package libaio-devel.i386 0:0.3.106-5 set to be updated ---> Package libaio-devel.x86_64 0:0.3.106-5 set to be updated ---> Package sysstat.x86_64 0:7.0.2-3.el5 set to be updated ---> Package unixODBC-devel.i386 0:2.2.11-7.1 set to be updated ---> Package unixODBC-devel.x86_64 0:2.2.11-7.1 set to be updated ---> Package xorg-x11-utils.x86_64 0:7.1-2.fc6 set to be updated --> Processing Dependency: libXv.so.1()(64bit) for package: xorg-x11-utils --> Processing Dependency: libdmx.so.1()(64bit) for package: xorg-x11-utils --> Processing Dependency: libXxf86dga.so.1()(64bit) for package: xorg-x11-utils --> Running transaction check ---> Package libXv.x86_64 0:1.0.1-4.1 set to be updated ---> Package libXxf86dga.x86_64 0:1.0.1-3.1 set to be updated ---> Package libdmx.x86_64 0:1.0.2-3.1 set to be updated --> Finished Dependency Resolution Dependencies Resolved =========================================================================================================================== Package Arch Version Repository Size =========================================================================================================================== Installing: oracle-validated x86_64 1.0.0-24.el5 falcon-repo 22 k Installing for dependencies: compat-db x86_64 4.2.52-5.1 falcon-repo 1.6 M compat-gcc-34 x86_64 3.4.6-4 falcon-repo 4.4 M compat-gcc-34-c++ x86_64 3.4.6-4 falcon-repo 13 M compat-libstdc++-33 i386 3.2.3-61 falcon-repo 232 k compat-libstdc++-33 x86_64 3.2.3-61 falcon-repo 227 k libXp i386 1.0.0-8.1.el5 falcon-repo 23 k libXtst i386 1.0.1-3.1 falcon-repo 15 k libXv x86_64 1.0.1-4.1 falcon-repo 14 k libXxf86dga x86_64 1.0.1-3.1 falcon-repo 16 k libaio-devel i386 0.3.106-5 falcon-repo 12 k libaio-devel x86_64 0.3.106-5 falcon-repo 11 k libdmx x86_64 1.0.2-3.1 falcon-repo 13 k sysstat x86_64 7.0.2-3.el5 falcon-repo 173 k unixODBC-devel i386 2.2.11-7.1 falcon-repo 739 k unixODBC-devel x86_64 2.2.11-7.1 falcon-repo 796 k xorg-x11-utils x86_64 7.1-2.fc6 falcon-repo 123 k Transaction Summary ============================================================================================================================ Install 17 Package(s) Upgrade 0 Package(s) Total download size: 21 M Is this ok [y/N]: y Downloading Packages: (1/17): libaio-devel-0.3.106-5.x86_64.rpm | 11 kB 00:00 (2/17): libaio-devel-0.3.106-5.i386.rpm | 12 kB 00:00 (3/17): libdmx-1.0.2-3.1.x86_64.rpm | 13 kB 00:00 (4/17): libXv-1.0.1-4.1.x86_64.rpm | 14 kB 00:00 (5/17): libXtst-1.0.1-3.1.i386.rpm | 15 kB 00:00 (6/17): libXxf86dga-1.0.1-3.1.x86_64.rpm | 16 kB 00:00 (7/17): oracle-validated-1.0.0-24.el5.x86_64.rpm | 22 kB 00:00 (8/17): libXp-1.0.0-8.1.el5.i386.rpm | 23 kB 00:00 (9/17): xorg-x11-utils-7.1-2.fc6.x86_64.rpm | 123 kB 00:00 (10/17): sysstat-7.0.2-3.el5.x86_64.rpm | 173 kB 00:00 (11/17): compat-libstdc++-33-3.2.3-61.x86_64.rpm | 227 kB 00:00 (12/17): compat-libstdc++-33-3.2.3-61.i386.rpm | 232 kB 00:00 (13/17): unixODBC-devel-2.2.11-7.1.i386.rpm | 739 kB 00:00 (14/17): unixODBC-devel-2.2.11-7.1.x86_64.rpm | 796 kB 00:00 (15/17): compat-db-4.2.52-5.1.x86_64.rpm | 1.6 MB 00:00 (16/17): compat-gcc-34-3.4.6-4.x86_64.rpm | 4.4 MB 00:00 (17/17): compat-gcc-34-c++-3.4.6-4.x86_64.rpm | 13 MB 00:00 ----------------------------------------------------------------------------------------------------------------------------- Total 14 MB/s | 21 MB 00:01 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing : compat-gcc-34 1/17 Installing : libXxf86dga 2/17 Installing : compat-libstdc++-33 3/17 Installing : sysstat 4/17 Installing : libXv 5/17 Installing : libdmx 6/17 Installing : xorg-x11-utils 7/17 Installing : compat-db 8/17 Installing : libaio-devel 9/17 Installing : libaio-devel 10/17 Installing : unixODBC-devel 11/17 Installing : unixODBC-devel 12/17 Installing : libXtst 13/17 Installing : libXp 14/17 Installing : compat-libstdc++-33 15/17 Installing : compat-gcc-34-c++ 16/17 Installing : oracle-validated 17/17 Installed: oracle-validated.x86_64 0:1.0.0-24.el5 Dependency Installed: compat-db.x86_64 0:4.2.52-5.1 compat-gcc-34.x86_64 0:3.4.6-4 compat-gcc-34-c++.x86_64 0:3.4.6-4 compat-libstdc++-33.i386 0:3.2.3-61 compat-libstdc++-33.x86_64 0:3.2.3-61 libXp.i386 0:1.0.0-8.1.el5 libXtst.i386 0:1.0.1-3.1 libXv.x86_64 0:1.0.1-4.1 libXxf86dga.x86_64 0:1.0.1-3.1 libaio-devel.i386 0:0.3.106-5 libaio-devel.x86_64 0:0.3.106-5 libdmx.x86_64 0:1.0.2-3.1 sysstat.x86_64 0:7.0.2-3.el5 unixODBC-devel.i386 0:2.2.11-7.1 unixODBC-devel.x86_64 0:2.2.11-7.1 xorg-x11-utils.x86_64 0:7.1-2.fc6 Complete!
Однако этого нам мало. Из-под пользователя oracle будет работать база данных. По рекомендациям Оракла, кластерное ПО лучше запускать из-под отдельного пользователя, обычно это grid. Создадим его на каждой ноде.
root@n1: ~# /usr/sbin/useradd -u 1100 -g oinstall -G dba grid root@n1: ~# passwd grid Changing password for user grid. New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully. # Повторим тоже самое на всех нодах. # Проверка root@n1: ~# id grid uid=1100(grid) gid=54321(oinstall) groups=54321(oinstall),54322(dba) root@n2: ~# id grid uid=1100(grid) gid=54321(oinstall) groups=54321(oinstall),54322(dba)
Далее необходимо создать структуру каталогов, в которой будет размещаться софт оракла. Следуя схеме OFA (ну или частично следуя 🙂 сделаем /u01/app/grid /u01/app/oracle и так далее. Опять же, делаем это на всех узлах кластера.
root@n1: ~# mkdir -p /u01/app/grid root@n1: ~# mkdir -p /u01/app/oracle root@n1: ~# chown grid:oinstall /u01/app/grid root@n1: ~# chown oracle:oinstall /u01/app/oracle root@n1: ~# mkdir -p /u01/app/11.2.0/grid root@n1: ~# chown grid:oinstall /u01/app/11.2.0/grid root@n1: ~# mkdir /u01/app/oraInventory root@n1: ~# chown grid:oinstall /u01/app/oraInventory root@n1: ~# chmod -R 775 /u01/
Подготовка и конфигурирование ASM.
Если у вас уже настроен сервер, к нему подключено хранилище, и луны/диски/разделы уже видны в системе, можно приступать к конфигурированию ASM. Для этих целей нам понадобятся несколько пакетов от оракла:
oracleasm-2.6.18-274.el5-2.0.5-1.el5.x86_64.rpm oracleasmlib-2.0.4-1.el5.x86_64.rpm oracleasm-support-2.1.7-1.el5.x86_64.rpm
Гланое, чтобы версия драйвера ASM совпадала с версией ядра вашей операционной системы. Ну и архитектура конечно тоже. В моем случае ядро было 2.6.18-274 и драйвер я скачал соответственный. Узнать версию ядра можно командой uname -a. Скачать все эти пакеты можно с сайта Оракла тут.
root@n1: ~# uname -a Linux n1.rac 2.6.18-274.el5 #1 SMP Fri Jul 22 04:43:29 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
Итак, ставим пакеты на каждой ноде.
root@n2: /home/kostik# rpm -ivh oracleasm* warning: oracleasm-2.6.18-274.el5-2.0.5-1.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] 1:oracleasm-support ########################################### [ 33%] 2:oracleasm-2.6.18-274.el########################################### [ 67%] 3:oracleasmlib ########################################### [100%]
После этого можно приступать к конфигурации ASM. Первым делом надо сконфигурировать сам драйвер. Это делается один раз. Запускаем конфигурирование и указываем некоторые данные: пользователя, из-под которого будет работать драйвер и кому будет принадлежать интерфейс, группу, запускать ли драйвер при старте системы. Если вы придерживались этой статьи, и завели двух пользователей, одного для кластера, другого для базы данных, то здесь надо указать пользователя кластера.
root@n2: /home/kostik# /usr/sbin/oracleasm configure -i
Configuring the Oracle ASM library driver.
This will configure the on-boot properties of the Oracle ASM library
driver. The following questions will determine whether the driver is
loaded on boot and what permissions it will have. The current values
will be shown in brackets ('[]'). Hitting without typing an
answer will keep that current value. Ctrl-C will abort.
Default user to own the driver interface []: grid
Default group to own the driver interface []: dba
Start Oracle ASM library driver on boot (y/n) [n]: y
Scan for Oracle ASM disks on boot (y/n) [y]: y
Writing Oracle ASM library driver configuration: done
# Инициализируем драйвер
root@n2: /home/kostik# oracleasm init
Creating /dev/oracleasm mount point: /dev/oracleasm
Loading module "oracleasm": oracleasm
Mounting ASMlib driver filesystem: /dev/oracleasm
После этого можно создать диски ASM из устройств с расшаренного хранилища. В моем случае в качестве хранилища выступает массив EMC, подключенный двумя оптическими шнурками с настроенным failover. Поэтому в моей системе эти диски видны как /dev/emcpower*. Для начала размечаем диски с помощью fdisk или любой другой утилиты, какая вам больше нравится. После этого инициализируем эти диски как ASM. Делаем это на одной ноде.
[18:18] cmd#:520 root@n1: /home/kostik# oracleasm createdisk DISK1 /dev/emcpowerb1 Writing disk header: done Instantiating disk: done [18:18] cmd#:522 root@n1: /home/kostik# oracleasm createdisk DISK2 /dev/emcpowerc1 Writing disk header: done Instantiating disk: done [18:19] cmd#:523 root@n1: /home/kostik# oracleasm createdisk DISK3 /dev/emcpowerd1 Writing disk header: done Instantiating disk: done [18:19] cmd#:524 root@n1: /home/kostik# oracleasm createdisk DISK4 /dev/emcpowere1 Writing disk header: done Instantiating disk: done [18:19] cmd#:526 root@n1: /home/kostik# oracleasm listdisks DISK1 DISK2 DISK3 DISK4
Поскольку диски расшарены на всех нодах кластера, убеждаемся, что мы видим их на второй ноде.
root@n2: /home/kostik# oracleasm listdisks # Дисков не видно - не беда, просканиурем диски. root@n2: /home/kostik# oracleasm scandisks Reloading disk partitions: done Cleaning any stale ASM disks... Scanning system for ASM disks... Instantiating disk "DISK1" Instantiating disk "DISK2" Instantiating disk "DISK3" Instantiating disk "DISK4" # Ура! Чудо! Диски нашлись
После этого можно приступать к установке 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. В свежей версии проверяются различные таймауты на запросы к днс-серверу, так что потребовалось дополнительно настроить таймауты и количество попыток. Делается это так:
root@n2: /home/kostik# vim /etc/resolv.conf search rac nameserver 192.168.24.27 options attempts:1 options timeout:1
После этого краткий обзор нашей установки. Можно сохранить его в файл ответов и в дальнейшем проводить silent-установку без вопросов и графики. Жмем «Готово» и начинается уставновка.
Ближе к концу установки появится окно с предложением выполнить пару скриптов от имени root на каждой ноде. Делаем это и жмем «окей». Здесь стоит подчеркнуть, что НЕ НАДО запускать эти скрипты одновременно на всех нодах. Это может привести к ошибкам. Скрипт orainstRoot.sh отработает быстро, а вот root.sh — выполняется достаточно долго, потому что он производит конфигурирование ноды кластера. Поэтому мой совет, подождите, пока этот скрипт полностью отработает на одной ноде и только потом запускайте его на следующей.
[12:05] cmd#:220
root@n2: /home/kostik# /u01/app/oraInventory/orainstRoot.sh
Changing permissions of /u01/app/oraInventory.
Adding read,write permissions for group.
Removing read,write,execute permissions for world.
Changing groupname of /u01/app/oraInventory to oinstall.
The execution of the script is complete.
[12:33] cmd#:221
root@n2: /home/kostik# /u01/app/11.2.0/grid/root.sh
Running Oracle 11g root.sh script...
The following environment variables are set as:
ORACLE_OWNER= grid
ORACLE_HOME= /u01/app/11.2.0/grid
Enter the full pathname of the local bin directory: [/usr/local/bin]:
Copying dbhome to /usr/local/bin ...
Copying oraenv to /usr/local/bin ...
Copying coraenv to /usr/local/bin ...
Creating /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.
2011-12-27 12:34:04: Parsing the host name
2011-12-27 12:34:04: Checking for super user privileges
2011-12-27 12:34:04: User has super user privileges
Using configuration parameter file: /u01/app/11.2.0/grid/crs/install/crsconfig_params
Creating trace directory
LOCAL ADD MODE
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
root wallet
root wallet cert
root cert export
peer wallet
profile reader wallet
pa wallet
peer wallet keys
pa wallet keys
peer cert request
pa cert request
peer cert
pa cert
peer root cert TP
profile reader root cert TP
pa root cert TP
peer pa cert TP
pa peer cert TP
profile reader pa cert TP
profile reader peer cert TP
peer user cert
pa user cert
Adding daemon to inittab
CRS-4123: Oracle High Availability Services has been started.
ohasd is starting
ADVM/ACFS is not supported on centos-release-5-7.el5.centos
CRS-2672: Попытка запустить 'ora.gipcd' на 'n2'
CRS-2672: Попытка запустить 'ora.mdnsd' на 'n2'
CRS-2676: Запуск 'ora.gipcd' на 'n2' выполнен успешно.
CRS-2676: Запуск 'ora.mdnsd' на 'n2' выполнен успешно.
CRS-2672: Попытка запустить 'ora.gpnpd' на 'n2'
CRS-2676: Запуск 'ora.gpnpd' на 'n2' выполнен успешно.
CRS-2672: Попытка запустить 'ora.cssdmonitor' на 'n2'
CRS-2676: Запуск 'ora.cssdmonitor' на 'n2' выполнен успешно.
CRS-2672: Попытка запустить 'ora.cssd' на 'n2'
CRS-2672: Попытка запустить 'ora.diskmon' на 'n2'
CRS-2676: Запуск 'ora.diskmon' на 'n2' выполнен успешно.
CRS-2676: Запуск 'ora.cssd' на 'n2' выполнен успешно.
CRS-2672: Попытка запустить 'ora.ctssd' на 'n2'
CRS-2676: Запуск 'ora.ctssd' на 'n2' выполнен успешно.
ASM created and started successfully.
DiskGroup DATA created successfully.
clscfg: -install mode specified
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
CRS-2672: Попытка запустить 'ora.crsd' на 'n2'
CRS-2676: Запуск 'ora.crsd' на 'n2' выполнен успешно.
CRS-4256: Updating the profile
Successful addition of voting disk 9fba8d3955824f5ebf18b8c8c8d2ffbe.
Successfully replaced voting disk group with +DATA.
CRS-4256: Updating the profile
CRS-4266: Voting file(s) successfully replaced
## STATE File Universal Id File Name Disk group
-- ----- ----------------- --------- ---------
1. ONLINE 9fba8d3955824f5ebf18b8c8c8d2ffbe (ORCL:DISK1) [DATA]
Located 1 voting disk(s).
CRS-2673: Попытка остановить 'ora.crsd' на 'n2'
CRS-2677: Останов 'ora.crsd' на 'n2' выполнен успешно.
CRS-2673: Попытка остановить 'ora.asm' на 'n2'
CRS-2677: Останов 'ora.asm' на 'n2' выполнен успешно.
CRS-2673: Попытка остановить 'ora.ctssd' на 'n2'
CRS-2677: Останов 'ora.ctssd' на 'n2' выполнен успешно.
CRS-2673: Попытка остановить 'ora.cssdmonitor' на 'n2'
CRS-2677: Останов 'ora.cssdmonitor' на 'n2' выполнен успешно.
CRS-2673: Попытка остановить 'ora.cssd' на 'n2'
CRS-2677: Останов 'ora.cssd' на 'n2' выполнен успешно.
CRS-2673: Попытка остановить 'ora.gpnpd' на 'n2'
CRS-2677: Останов 'ora.gpnpd' на 'n2' выполнен успешно.
CRS-2673: Попытка остановить 'ora.gipcd' на 'n2'
CRS-2677: Останов 'ora.gipcd' на 'n2' выполнен успешно.
CRS-2673: Попытка остановить 'ora.mdnsd' на 'n2'
CRS-2677: Останов 'ora.mdnsd' на 'n2' выполнен успешно.
CRS-2672: Попытка запустить 'ora.mdnsd' на 'n2'
CRS-2676: Запуск 'ora.mdnsd' на 'n2' выполнен успешно.
CRS-2672: Попытка запустить 'ora.gipcd' на 'n2'
CRS-2676: Запуск 'ora.gipcd' на 'n2' выполнен успешно.
CRS-2672: Попытка запустить 'ora.gpnpd' на 'n2'
CRS-2676: Запуск 'ora.gpnpd' на 'n2' выполнен успешно.
CRS-2672: Попытка запустить 'ora.cssdmonitor' на 'n2'
CRS-2676: Запуск 'ora.cssdmonitor' на 'n2' выполнен успешно.
CRS-2672: Попытка запустить 'ora.cssd' на 'n2'
CRS-2672: Попытка запустить 'ora.diskmon' на 'n2'
CRS-2676: Запуск 'ora.diskmon' на 'n2' выполнен успешно.
CRS-2676: Запуск 'ora.cssd' на 'n2' выполнен успешно.
CRS-2672: Попытка запустить 'ora.ctssd' на 'n2'
CRS-2676: Запуск 'ora.ctssd' на 'n2' выполнен успешно.
CRS-2672: Попытка запустить 'ora.asm' на 'n2'
CRS-2676: Запуск 'ora.asm' на 'n2' выполнен успешно.
CRS-2672: Попытка запустить 'ora.crsd' на 'n2'
CRS-2676: Запуск 'ora.crsd' на 'n2' выполнен успешно.
CRS-2672: Попытка запустить 'ora.evmd' на 'n2'
CRS-2676: Запуск 'ora.evmd' на 'n2' выполнен успешно.
CRS-2672: Попытка запустить 'ora.asm' на 'n2'
CRS-2676: Запуск 'ora.asm' на 'n2' выполнен успешно.
CRS-2672: Попытка запустить 'ora.DATA.dg' на 'n2'
CRS-2676: Запуск 'ora.DATA.dg' на 'n2' выполнен успешно.
n2 2011/12/27 12:38:15 /u01/app/11.2.0/grid/cdata/n2/backup_20111227_123815.olr
Preparing packages for installation...
cvuqdisk-1.0.7-1
Configure Oracle Grid Infrastructure for a Cluster ... succeeded
Updating inventory properties for clusterware
Starting Oracle Universal Installer...
Checking swap space: must be greater than 500 MB. Actual 15999 MB Passed
The inventory pointer is located at /etc/oraInst.loc
The inventory is located at /u01/app/oraInventory
'UpdateNodeList' was successful.
Ну что ж, на этом установка Oracle Grid Infrastructure for Cluster успешно (я надеюсь) завершается.
Чтобы проверить, что все прошло успешно, и наш новенький кластер функционирует как положено, можно воспользоваться утилитой crsctl. Запускаем ее вот такую штуку из-под рута на каждой ноде и убеждаемся, что все онлайн.
root@n2: /home/kostik# /u01/app/11.2.0/grid/bin/crsctl check crs CRS-4638: Oracle High Availability Services is online CRS-4537: Cluster Ready Services is online CRS-4529: Cluster Synchronization Services is online CRS-4533: Event Manager is online
Проверить работоспособность ASM, сети, SCAN, listener’ов и прочих компонентов, можно так.
root@n1: ~# crsctl status resource -w "TYPE co ’ora’" -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
ONLINE ONLINE n1
ONLINE ONLINE n2
ora.FRA.dg
ONLINE ONLINE n1
ONLINE ONLINE n2
ora.LISTENER.lsnr
ONLINE ONLINE n1
ONLINE ONLINE n2
ora.asm
ONLINE ONLINE n1 Started
ONLINE ONLINE n2 Started
ora.gsd
OFFLINE OFFLINE n1
OFFLINE OFFLINE n2
ora.net1.network
ONLINE ONLINE n1
ONLINE ONLINE n2
ora.ons
ONLINE ONLINE n1
ONLINE ONLINE n2
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
1 ONLINE ONLINE n2
ora.LISTENER_SCAN2.lsnr
1 ONLINE ONLINE n1
ora.LISTENER_SCAN3.lsnr
1 ONLINE ONLINE n1
ora.cvu
1 ONLINE ONLINE n1
ora.n1.vip
1 ONLINE ONLINE n1
ora.n2.vip
1 ONLINE ONLINE n2
ora.oc4j
1 ONLINE ONLINE n1
ora.scan1.vip
1 ONLINE ONLINE n2
ora.scan2.vip
1 ONLINE ONLINE n1
ora.scan3.vip
1 ONLINE ONLINE n1
Все прекрасно, все онлайн 🙂 Можно идти дальше. А дальше по плану — установка сервера базы данных. Однако здесь стоит сказать вот что: если вы планируете ставить БД версии 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. Я показал какие параметры есть у этой команды и что они значат.
[18:30] cmd#:469 oracle@n1: ~> which srvctl /u01/app/oracle/product/11.2.0/dbhome_1/bin/srvctl [18:31] cmd#:470 oracle@n1: ~> srvctl Usage: srvctl< object > [ ] commands: enable|disable|start|stop|relocate|status|add|remove|modify|getenv|setenv|unsetenv|config|convert|upgrade objects: database|instance|service|nodeapps|vip|network|asm|diskgroup|listener|srvpool|server|scan|scan_listener|oc4j|home|filesystem|gns|cvu For detailed help on each command and object and its options use: srvctl -h or srvctl < object > -h [18:31] cmd#:471 oracle@n1: ~> srvctl add service -h Adds a service configuration to the Oracle Clusterware. Usage: srvctl add service -d -s {-r " " [-a " "] [-P {BASIC | NONE | PRECONNECT}] | -g [-c {UNIFORM | SINGLETON}] } [-k ] [-l [PRIMARY][,PHYSICAL_STANDBY][,LOGICAL_STANDBY][,SNAPSHOT_STANDBY]] [-y {AUTOMATIC | MANUAL}] [-q {TRUE|FALSE}] [-x {TRUE|FALSE}] [-j {SHORT|LONG}] [-B {NONE|SERVICE_TIME|THROUGHPUT}] [-e {NONE|SESSION|SELECT}] [-m {NONE|BASIC}] [-z ] [-w ] [-t ] [-f] -d Unique name for the database -s Service name -r " " Comma separated list of preferred instances -a " " Comma separated list of available instances -g Server pool name -c {UNIFORM | SINGLETON} Service runs on every active server in the server pool hosting this service (UNIFORM) or just one server (SINGLETON) -k network number (default number is 1) -P {NONE | BASIC | PRECONNECT} TAF policy specification -l Role of the service (primary, physical_standby, logical_standby, snapshot_standby) -y Management policy for the service (AUTOMATIC or MANUAL) -e Failover type (NONE, SESSION, or SELECT) -m Failover method (NONE or BASIC) -w Failover delay -z Failover retries -t Edition (or "" for empty edition value) -j Connection Load Balancing Goal (SHORT or LONG). Default is LONG. -B Runtime Load Balancing Goal (SERVICE_TIME, THROUGHPUT, or NONE) -x Distributed Transaction Processing (TRUE or FALSE) -q AQ HA notifications (TRUE or FALSE) Usage: srvctl add service -d -s -u {-r " " | -a " "} [-f] -d Unique name for the database -s Service name -u Add a new instance to service configuration -r Name of new preferred instance -a Name of new available instance -f Force the add operation even though a listener is not configured for a network -h Print usage # Создаем сервис, указываем его название, список нод, на которых он будет крутиться, политику TAF, роль этого сервиса, режим и параметры отказоустойчивости. [18:31] cmd#:472 oracle@n1: ~> srvctl add service -d orcl -s gisrac.rac -r orcl1,orcl2 -P BASIC -l PRIMARY -y AUTOMATIC -e SELECT -m BASIC -w 1 -z 180 -j LONG -B SERVICE_TIME -q TRUE
Теперь можем запустить его и проверить что этот сервис запущен и работает.
[18:38] cmd#:473 oracle@n1: ~> srvctl start service -d orcl [18:38] cmd#:474 oracle@n1: ~> srvctl status service -d orcl Service gisrac.rac is running on instance(s) orcl2,orcl1
Теперь, если мы выполним команду проверки статуса всех компонентов кластера, там появятся еще 2 компонента: просто база данных, и наш только что созданных сервис.
[18:41] cmd#:1444
root@n1: ~# crsctl status resource -w "TYPE co ’ora’" -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
ONLINE ONLINE n1
ONLINE ONLINE n2
ora.FRA.dg
ONLINE ONLINE n1
ONLINE ONLINE n2
ora.LISTENER.lsnr
ONLINE ONLINE n1
ONLINE ONLINE n2
ora.asm
ONLINE ONLINE n1 Started
ONLINE ONLINE n2 Started
ora.gsd
OFFLINE OFFLINE n1
OFFLINE OFFLINE n2
ora.net1.network
ONLINE ONLINE n1
ONLINE ONLINE n2
ora.ons
ONLINE ONLINE n1
ONLINE ONLINE n2
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
1 ONLINE ONLINE n2
ora.LISTENER_SCAN2.lsnr
1 ONLINE ONLINE n1
ora.LISTENER_SCAN3.lsnr
1 ONLINE ONLINE n1
ora.cvu
1 ONLINE ONLINE n1
ora.n1.vip
1 ONLINE ONLINE n1
ora.n2.vip
1 ONLINE ONLINE n2
ora.oc4j
1 ONLINE ONLINE n1
ora.orcl.db
1 ONLINE ONLINE n1 Open
2 ONLINE ONLINE n2 Open
ora.orcl.gisrac.rac.svc
1 ONLINE ONLINE n2
2 ONLINE ONLINE n1
ora.scan1.vip
1 ONLINE ONLINE n2
ora.scan2.vip
1 ONLINE ONLINE n1
ora.scan3.vip
1 ONLINE ONLINE n1
Теперь, если зайти в 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.