Материал из Xgu.ru

Ниже будет рассмотрен Oracle Сoldfailover для Oracle Database Standard 11.1 + Oracle Clusterware 11.1.

Описание решения Coldfailover для Oracle Database 11.2 и Oracle Grid 11.2 приведено в документе Oracle Coldfailover 11.2

Содержание 1 Введение 2 «Холодная» миграция СУБД 3 Реализация отказоустойчивой СУБД Oracle 4 Требования к установке 5 Подготовка операционной системы 5.1 Устанавливаем Oracle Linux 5 на сервер 5.2 Настройка сети 5.3 Пользователи и группы 6 Создание каталогов для установки 7 Установка ПО 7.1 Установка пакетов с репозитария. 7.2 Настройка VMware Tools 7.3 Установка cvuqdisk 7.4 Установка пакетов для работы с ASM 8 Настройка кластерных дисков 8.1 Подключение дисков от СХД 8.2 Задание правил udev для кластерных дисков без использования multipath 8.3 Настройка multipath 8.4 Задание правил udev для кластерных дисков c multipath 8.5 Настройка oracleasm 9 Настройка службы синхронизации времени 10 Настройка SSH для входа по ключам 11 Настройка лимита ресурсов и переменных оболочки 11.1 Лимиты ресурсов 11.2 Переменные окружения 11.3 Утилита rlwrap 12 Настройка параметров ядра 13 Настройка shared memory и hugepages 13.1 Shared memory 13.2 Hugepages 14 Установка Clusterware 15 Создание отказоустойчивой БД Oracle 15.1 Установка СУБД Oracle 15.2 Создание ресурсов, обслуживающих СУБД 15.2.1 Настройка прослушивателя 15.2.2 Настройка экземпляра ASM и создание дисковых групп 15.2.3 Конфигурация БД 15.2.4 Задание контроля за работой СУБД 15.2.4.1 Создание начального ресурса 15.2.4.2 Создание ресурса виртуального сетевого адреса 15.2.4.3 Создание ресурса прослушивателя 15.2.4.4 Создание ресурса, контролирующего состояние базы данных 15.2.4.5 Создание головного ресурса 16 Обновление СУБД и Clusterware 16.1 Обновление Oracle Clusterware 16.2 Обновление Oracle Database 17 Приложение 17.1 Описание утилит Oracle Clusterware 17.2 Утилиты для работы с кластером 17.3 Смена сетевых адресов и интерфейсов 17.3.1 Смена адреса виртуального интерфейса 17.3.2 Смена интерфейсов 17.4 Добавление/удаление узлов из кластера 17.4.1 Расширение Clusterware 17.4.2 Расширение СУБД 17.4.3 Удаление узла из кластера 17.5 Работа с ASM (asmcmd, sqlplus, rman) 17.5.1 Работа с дисковыми группами 17.5.2 Утилита ASMCMD 17.5.3 Копирование табличного пространства на ASM с помощью RMAN 17.5.4 Перенос БД на дисковую группу ASM 17.6 Перенос кластера на другую систему хранения 17.6.1 Перенос реестра кластера 17.6.2 Перенос voting disk 17.6.3 Добавление/удаление дисков ASM 17.6.4 Удаление устройств multipath и составляющих дисков из операционной системы 18 Примечания

[править] Введение

В данной статье будет рассмотрен метод, позволяющий восстановить обслуживание запросов к СУБД Oracle, в случае возникновения неисправности на сервере, на котором запущена СУБД. Существуют несколько вариантов программного повышения отказоустойчивости работы СУБД Oracle. Основные из них это: параллельные кластеры приложений (Oracle Real Application Clusters), параллельный кластер с одним активным узлом (Oracle RAC One Node) и «холодная» миграция СУБД (Oracle Сoldfailover).

Ниже будет рассмотрен Oracle Сoldfailover (Oracle Database Standard 11.1 + Oracle Clusterware 11.1), так как самый мало затратный по финансам. Этот способ подходит для небольших организаций, с числом одновременных сессий к базе менее 1000. Описываемый метод будет работать на версиях 11.1 DB и Clusterware.

Описание решения Coldfailover для Oracle Database 11.2 и Oracle Grid 11.2 приведено в документе Oracle Coldfailover 11.2

Следует заметить, что начиная с версии 11.2 появилось официальное решение – Oracle RAC One Node, но оно работает только в Enterprise редакции. Особенность данной технологии заключается в том, что при её использовании, возможно осуществлять «живую миграцию» подключений к СУБД с одного узла на другой. При миграции подключений с первого узла – Oracle RAC One Node запускает второй экземпляр СУБД на резервном узле и на короткий период времени работает в режиме двух активных узлов. Когда соединения завершат транзакции на сервере узла 1, они перемещаются на узел 2. В тот момент, когда все соединения мигрируют, экземпляр СУБД на узле 1 завершает работу и миграция считается выполненной.

Основой данной статьи стал документ, поставляемый вместе Oracle Clusterware 11.1. По-умолчанию он называется coldfailover.pdf и располагается в $CRS_HOME/crs/demo/ (у меня был путь – /u01/app/crs/crs/demo).

Так же использовались материалы:

• Oracle Clusterware Installation Guide 11g Release 1 (11.1) for Linux (англ.)
• Oracle Database Installation Guide 11g Release 1 (11.1) for Linux (англ.)
• Oracle Database Storage Administrator's Guide 11g Release 1 (11.1) (англ.)
• Oracle Clusterware Administration and Deployment Guide 11g Release 1 (англ.)
• Oracle Database Backup and Recovery User's Guide 11g Release 1 (11.1) (англ.)
• Конфигурация и администрирование DM Multipath (рус.)

[править] «Холодная» миграция СУБД

При использовании «холодной» миграции СУБД (Oracle Coldfailover) СУБД работает только на одном из узлов. Резервный узел находиться в ожидании. В отличие от технологии Oracle RAC One Node, при миграции экземпляра с одного узла на другой, необходимо сначала остановить процессы СУБД на первом узле и после последовательно запустить их на втором узле, так как в данном случае параллельный запуск экземпляров СУБД на разных узлах невозможен. Таким образом, при выполнении миграции – всё существующие соединения разрываются и могут быть восстановлены только после запуска экземпляра на другом узле.

Решение Coldfailover использует скрипты perl для подключения к СУБД и определения состояния базы. Оно может восстановить работу базы данных на другом узле, если процессы СУБД завершились или если физический сервер отключился. Если же процессы СУБД запущены, но возникли проблемы с подключением к базе (например, превышено число максимальных процессов), то такое решение не определит сбой.

Время восстановление работы пользователей, в случае отказа в работе одного из узлов кластера, аналогично времени восстановления при использовании Oracle RAC One Node. Оно зависит от производительности сервера и от объёма данных, которые необходимо восстанавливать после сбоя и в среднем составляет от 5 до 10 минут.

Данному решению необходима только лицензию для работы СУБД на одном сервере и лицензия на Real Application Clusters option. При этом не требуется особых возможностей редакции СУБД и достаточно для работы Oracle Database Standard Edition. Кроме того при использовании Standard Edition опция Real Application Clusters включена в поставку и не требует отдельного лицензирования.

[править] Реализация отказоустойчивой СУБД Oracle

На несколько узлов устанавливается программное обеспечение Oracle Clusterware, которое отслеживает состояние узлов и компонентов экземпляров СУБД. К качестве примера рассмотрим два экземпляра СУБД – alpha и beta. Базы данных, обслуживаемые экземплярами, располагаются на системе хранения данных (СХД) на диске с кластерной файловой системой Oracle ASM, что позволяет обращаться к базам данных с нескольких серверов. Будет рассмотрено подключение к СХД как по iSCSI так и по Fibre Channel. На той же системе хранения располагаются диск с реестром кластера и диск голосования. Реестр кластера (OCR), служит для хранения информации о составе кластера, об именах узлов и параметрах связи (сетевые порты и адреса) между службами узлов. Диск голосования (voting disk) служит для точного определения работоспособности узлов.

Узел считается работающим исправно, если он обменивается сетевыми пакетами о функционировании (heartbeat), а так же производит запись в определенные интервалы на диск голосования. Если одно из условий не выполняется, узел считается неисправным и Oracle Clusterware отправляет команду на перезагрузку данного узла. Сервера подключены к системе хранения посредством оптических линий связи. Межкластерная сетевая связь организована через отдельную подсеть и не связана с сетью пользователей.

Для подключения к СУБД через сетевое соединение, необходимо, чтобы на сервере был сетевой интерфейс, и запущенные службы Oracle Net (прослушиватель). Для повышения отказоустойчивости для каждого экземпляра созданы отдельные виртуальные интерфейсы и прослушиватели. Для каждого вышеописанного элемента в Oracle Clusterware задаётся описание, называемое ресурс: для прослушивателя это rg.listener, для виртуального сетевого интерфейса – rg.vip, для ресурса, отвечающего за запуск СУБД – rg.db. Связанный набор ресурсов образует группу ресурсов. Данные о ресурсах хранятся в реестре кластера.

При запуске или миграции экземпляра ресурсы, необходимые для подключение клиентов к базе данных, должны запускаться в определённом порядке. Порядок определяется зависимостями при регистрации ресурсов, поэтому в дополнение к ресурсам, выполняющим обслуживание подключений клиентов к базе, необходимы два дополнительных ресурса. Это начальный (rg) и головной ресурсы (rg.head). Данные ресурсы необходимы для соблюдения порядка запуска группы. Если при регистрации указать, что головной ресурс зависит от всех остальных, а начальный ни от чего, но остальные зависят от него, то это позволит просто останавливать и запускать группу. Например, для того, чтобы запустить группу ресурсов, достаточно дать команду на запуск головного ресурса, а для останова группы – команду стоп начальному ресурсу. Промежуточные ресурсы запустятся или остановятся автоматически. При нормальной работе обе группы ресурсов (СУБД alpha и beta) запущены на одном сервере.

Пользовательские приложения, при подключении обращаются через виртуальные сетевые интерфейсы к прослушивателям, которые перенаправляют подключение к СУБД. Oracle Clusterware отслеживает состояние как отдельных ресурсов, так и узлов кластера в целом. В случае сбоя какого–либо ресурса – он перезапускается. Если количество запусков превысит заданное при регистрации ресурса значение, то будет предпринята попытка переместить всю группы на резервный узел. Группы автоматически запустятся на резервном узле и в случае, если произойдет сбой на основном узле. В связи с тем, что виртуальные сетевые адреса так же перемещаются на резервный узел, на клиентской стороне не требует каких–либо изменений настроек подключения, несмотря на то, что СУБД уже будут запущены на другом сервере. Пользовательские приложения при повторном подключении соединятся с резервным сервером, где прослушиватель перенаправит их к СУБД. Так как база данных расположена на общей системе хранения, то пользователи могут продолжить работу с теми же документами, как если бы они продолжали работать на основном сервере.

[править] Требования к установке

Два сервера (желательно x86-64) с ОЗУ более 3 Гб. Не обязательно одинаковое железо (но необходимо одинаковые версии ОС и пакетов). Основной сервер может быть физическим, а резервный виртуальным.

Место на локальных дисках серверов желательно более 20 Гб.

На системе хранения (iSCSI или Fibre Channel): два диска размером более 300 МБ каждый и диск под файлы баз данных – зависит от размера базы данных, но не менее 5Гб.

Для сетевых карт желательно использовать bonding. Оптимально использовать 6 сетевых карт – две карты в bonding для сессий пользователей, две карты в bonding для межкластерной связи и две карты в bonding для подключения системы хранения (при использовании iSCSI). Если карт меньше, то придётся использовать vlan-ы.

Названия общедоступных и внутренних сетевых интерфейсов (eth0, bond0, vlan20 и т. п.) на обоих узлах должны совпадать!

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

В данном примере будет вестись описание установки Oracle Coldfailover на Oracle Linux 5 x86-64.

[править] Устанавливаем Oracle Linux 5 на сервер

Подключаем открытый репозитарий Oracle latest, обновляем пакеты до последних версий.

# cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-el5.repo
# yum update

Из этого же репозитория возможно установить Unbreakable Enterprise Kernel Release 2. При установке ОТКЛЮЧИТЬ SELinux! Если пропустили, то после установки в файле /etc/sysconfig/selinux установить SELINUX=disabled или SELINUX=permissive.

[править] Настройка сети

Для работы Clusterware потребуется три ip-адреса на каждый узел. Нужно заранее выбрать имена узлов и прописать их в DNS или файле hosts на каждом узле. Кроме самого имени хоста нужно прописать имена с суффиксами -vip (Virtual IP) и -priv (private interconnect). Имена должны соответствовать RFC 952, подчеркивания не допускаются.

Например так:

[root@node1 ~]# cat /etc/hosts

172.16.72.11    node1.domain.ru node1	# физические адреса узлов
172.16.72.12    node2.domain.ru node2	# (общедоступны)
172.16.72.30    node1-vip.domain.ru  node1-vip	# виртуальные адрес 
172.16.72.31    node2-vip.domain.ru  node2-vip	# (общедоступны)
10.8.72.1	node1-priv.domain.ru  node1-priv	# адреса для межкластерной связи
10.8.72.2	node2-priv.domain.ru  node2-priv	# (частные, доступны только кластеру)

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

Желательно настроить объединение сетевых карт сервера и подключить их в разные коммутаторы. Если сетевая связь между узлами кластера будет прервана (при замене коммутатора или отключении питания), то Clusterware посчитает, что возникли неисправности на узлах и перезагрузит их. Использование объединения карт позволит работать кластеру более надёжно.

Ниже рассмотрен пример настройки двух сетевых интерфейсов в Oracle Linux с использованием объединения карт. Общедоступная и служебная кластерная сеть будет разделены с помощью vlan-ов. Карты eth0 и eth1 сервера подключены к разным коммутаторам. Порты коммутаторов переведены в транк, можно дополнительно ограничить доступ к требуемым vlan-ам. Пример настройки порта коммутатора (на Cisco):

interface GigabitEthernet0/10
description OracleLinux nic
switchport mode trunk
spanning-tree portfast trunk

Интерфейсы сервера eth0 и eth1 настроены как часть интерфейса bond0.

# vim /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

# vim /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Интерфейс bond0 используется для межкластерной связи и использует нативный vlan (vlan 1). Параметры объединения : интервал проверки 100 мс, режим объединения balance-tlb — балансировка исходящего трафика.

# vim /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
IPADDR=10.8.72.1
NETMASK=255.255.255.0
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
BONDING_OPTS="miimon=100 mode=balance-tlb"

На интерфейсе bond0 настроен vlan 20, который используется для подключения клиентов.

# vim /etc/sysconfig/network-scripts/ifcfg-bond0.20
DEVICE=bond0.20
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
VLAN=yes
IPADDR=172.16.72.11
NETMASK=255.255.0.0

Если для подключения к СХД используется iSCSI, то необходимо создать vlan и для неё.

[править] Пользователи и группы

На каждом из узлов пользователи от которых будут запускаться процессы СУБД и кластера должны иметь одинаковые имена, идентификаторы, принадлежность к группам путь к домашнему каталогу. Документация рекомендует использовать разделение ролей – процессы СУБД запускать от одного пользователя (oracle), а процессы кластера – от другого (crs). При изучении RAC 11.2 (Oracle DB 11.2 и Oracle Grid/clusterware 11.2) у меня успешно получилось использовать разделения ролей, а вот на 11.1 возникли сложности, поэтому там все процессы запускались от одного пользователя oracle. Итак необходимо создать следующие группы в ОС:

• oinstall – её участники будут иметь доступ к Oracle Inventory (oraInventory). У всех пользователей, от которых будут запускаться процессы СУБД и кластера это должна быть основная группа.
• dba – участники этой группы предоставляются административные права на управление СУБД. В БД это соответствует группе OSDBA, и привилегии SYSDBA. Данные пользователи способны подключаться к СУБД, используя локальную аутентификацию в операционной системе.
• asmadmin – участники этой группы разрешено администрирование Oracle ASM: монтирование и размонтирование дисковых групп, добавление- удаление дисков. Группа OSASM, привилегия SYSASM.

Так же возможно создать следующие группы:

• oper – участники данной группы имеют ограниченный набор привилегий для работы с БД. Группа OSOPER, привилегия SYSOPER. На рисунке OSOPER вместо группы oper сопоставлена группа oinstall.
• asmdba – участникам данной группы разрешено читать и записывать файлы на ASM диск.
• asmoper – пользователи данной группы имеют ограниченный набор привилегий для работы с ASM – запуск и останов экземпляра ASM. Группа OSOPER for ASM.

Пример. Создаём группы на каждом узле кластера с заданными идентификаторами, чтобы на разных узлах пользователи были одинаковыми:

# groupadd -g 1100 oinstall
# groupadd -g 1110 dba
# groupadd -g 1120 oper
# groupadd -g 1130 asmadmin

Создаём пользователя:

# useradd -u 1100 -g oinstall -G dba,oper,asmadmin -m oracle

Устанавливаем пароль:

# passwd oracle

В итоге пользователь операционной системы oracle при работе с СУБД будет иметь следующие права: доступ к описанию установленного ПО Oracle, административные права на управление СУБД, управление дисковыми группами и экземпляром ASM.

Если у вас используется разделение пользователей для запуска Clusterware и СУБД, то владельца процессов Clusterware необходимо добавить в группу dba на обоих узлах. Иначе Clusterware не сможет управлять СУБД.

[править] Создание каталогов для установки

Документация рекомендует выбирать пути для установки ПО от Oracle в соответствии с Optimal Flexible Architecture (OFA). Согласно данными рекомендациям путь для установки продукта выбирается следующим образом /u[01-09]/app/<имя пользователя>. Таким образом СУБД будем установить в /u01/app/oracle, а clusterware в /u01/app/crs, а Oracle Inventory в таком случае будет находиться в /u01/app/oraInvenory. При использовании одного пользователя для запуска СУБД и Clusterware достаточно предварительно создать каталог /u01/app у выставить для него права на запись для пользователя oracle и группы oinstall. Каталоги /u01/app/oracle и /u01/app/crs создаст инсталлятор. В конце установки корректные права выставит скрипт root.sh.

# mkdir -p /u01/app
# chown -R oracle:oinstall /u01/app

[править] Установка ПО

Распаковываем скаченные архивы с Clusterware и СУБД во временный каталог:

$ unzip linux.x64_11gR1_clusterware.zip
$ unzip linux.x64_11gR1_database.zip

[править] Установка пакетов с репозитария.

Для установки и работы СУБД на Oracle Linux 5 потребуются пакеты, которые можно просто установить командой:

yum install \
binutils compat-libstdc++-33.x86_64 compat-libstdc++-33.i386 elfutils-libelf elfutils-libelf-devel gcc gcc-c++ glibc \
glibc.i386 glibc-common glibc-devel glibc-devel.i386 glibc-headers ksh libaio libaio.i386 libaio-devel libaio-devel.i386 \
libgcc libgcc.i386 libstdc++ libstdc++.i386 libstdc++-devel make sysstat unixODBC unixODBC.i386 unixODBC-devel unixODBC-devel.i386 \
libcap1 libcap1-32bit

[править] Настройка VMware Tools

При установке Oracle Linux 5 в Vmware для tools потребуется еще пакет kernel-uek-devel. При использовании UEK2 потребуется изменение конфигуратора vmware tools – необходимо указать, что модули ehci-hcd, ohci-hcd, uhci-hcd встроены в ядро и нужно пропустить их при сборке initrd. Для этого в файле /usr/bin/vmware-config-tools.pl нужно найти строки

.........
   if ($style eq 'redhat') {
     my $image_file = '/boot/initrd-' . $kernRel . ".img";
     $syscmd = join(' ', $binary, '-f', $content, $image_file, $kernRel);
     db_add_answer('RESTORE_RAMDISK_CMD', join(' ', $binary, '-f',
                                           '/boot/initrd-KREL.img', 'KREL'));
.........

в VMwareTools-8.6.0-425873 этот блок располагается со строки номер 7430. Далее добавить параметры сборки initrd: --builtin=ehci-hcd --builtin=ohci-hcd --builtin=uhci-hcd чтобы скрипт выглядел так:

.........
if ($style eq 'redhat') {
my $image_file = '/boot/initrd-' . $kernRel . ".img";
$syscmd = join(' ', $binary, '-f --builtin=ehci-hcd --builtin=ohci-hcd --builtin=uhci-hcd', $content, $image_file, $kernRel);
.........

[править] Установка cvuqdisk

Так же потребуется пакет, который необходим для обнаружения общих (кластерных дисков) – cvuqdisk. Он находится в архиве с Clusterware в каталоге clusterware/rpm/cvuqdisk-1.0.1-1.rpm. Чтобы его установить, предварительно нужно экспортировать переменную окружения CVUQDISK_GRP и присвоить ей значение имени группы Oracle Inventory:

# CVUQDISK_GRP=oinstall; export CVUQDISK_GRP 
# rpm -i clusterware/rpm/cvuqdisk-1.0.1-1.rpm

[править] Установка пакетов для работы с ASM

Для работы с файловой системой ASM потребуется установить пакеты:

1. oracleasm-support – The Oracle Automatic Storage Management support programs – программы для создания, настройки и удаления файловой системы ASM на разделах (есть в открытом репозитарии)
2. Модули ядра файловой системы включены в ядро UEK2. Если используется ядро 2.6.18, то необходимо установить модули ядра oracleasm-2.6.18.
3. oracleasmlib – The Oracle Automatic Storage Management library userspace code. Упрощает работу с дисками ASM: позволяет обращаться из СУБД к дискам по меткам ORCL:<метка>, а так же позволяет избежать задание правил udev для установки прав на разделы диска ASM. Возможно настроить работу и без данной библиотеки. Скачать пакет можно с сайта Oracle http://www.oracle.com/technetwork/server-storage/linux/downloads/rhel5-084877.html

[править] Настройка кластерных дисков

Для работы Clusterware требуется как минимум два кластерных диска, размером не менее 300 МБ — для OCR (oracle cluster register) и Voting disk. Для каждого диска можно указать варианты избыточности: внешняя и нормальная. При выборе внешней избыточности считается, что администратор сам позаботился о резервировании кластерных дисков (RAID, DRBD и т. п.). При выборе нормальной избыточности для voting disk потребуется три кластерных диска, для OCR – два диска. В документации упоминается высокий уровень избыточности (5 voting disk и 4 OCR), но в стандартном установщике Clusterware я не нашел как его выбрать. Возможно есть способ его использовать при установке с помощью файла ответов. У нас система хранения построена с резервированием данных, поэтому я выбрал внешний тип избыточности.

Для диска с OCR необходимо в правилах UDEV прописать права: владелец root, группа oinstall, права 640.

Для voting disk: владелец oracle, группа oinstall, права 640.

[править] Подключение дисков от СХД

При подключении по Fibre Channel, как правило, используются средства настройки производителя СХД.

Например для использования multipath подключения к EMC Clariion необходимо установить пакеты с сайта производителя EMCPower.LINUX.5.6 (модули ядра) и HostAgent-Linux-64-x86 (агент). Но модули ядра от EMC, как правило, не совместимы с последними версиями ядер Oracle Linux и тем более с UEK2. Поэтому, считаю, лучше использовать родные для Linux средства multipath.

Если же используется СХД с подключением дисков по iSCSI, то здесь гораздо больше свободы настройки.

Рассмотрим простой пример: СХД сделана на обычном сервере с GNU Linux, LUNы раздаёт служба tgtd (в Oracle Linux 6 – это пакет scsi-target-utils).

Настраиваем сеть, желательно для трафика к СХД использовать отдельный vlan или физическую отдельную сеть с отдельными коммутаторами. В примере, будет использоваться подсеть 192.168.202.0/24.

На сервер, выступающий в роли СХД, устанавливаем tgtd, настраиваем target-ы в /etc/tgt/targets.conf.

# vim /etc/tgt/targets.conf
<target iqn.2012-06.ru.server:cluster>
   backing-store /dev/vg_iscsi/ocr
   backing-store /dev/vg_iscsi/votdisk
   backing-store /dev/vg_iscsi/asmdisk
</target>

Здесь по iSCSI будут раздаваться разделы LVM:

• /dev/vg_iscsi/ocr - реестр кластера
• /dev/vg_iscsi/votdisk - диск голосования
• /dev/vg_iscsi/asmdisk - диск ASM

Сами же разделы LVM построены из дисков, объединённых в RAID массив. На мини-СХД запускаем службы: chkconfig tgtd on, service tgtd start.

На узлах кластера запускаем службу iscsid (в Oracle Linux – пакет iscsi-initiator-utils): chkconfig iscsid on, service iscsid start.

После на каждом узле производим обнаружение целей (ip СХД — 192.168.202.1):

# iscsiadm -m discovery -t st -p 192.168.202.1
192.168.202.1:3260,1 iqn.2012-06.ru.server:cluster

Далее убеждаемся, что для целей включен автоматическое подключение при запуске службы iscsi на узлах кластера:

# iscsiadm -m node -T iqn.2012-06.ru.server:cluster | grep node.startup
node.startup = automatic

Если включено manual, то выполняем команду:

# iscsiadm -m node -T iqn.2012-06.ru.server:cluster -o update -n node.startup -v automatic

Или правим базу iscsi вручную — переходим в каталог /var/lib/iscsi/nodes. И далее до конца ищем файл default.

Например, у меня это будет путь /var/lib/iscsi/nodes/iqn.2012-06.ru.server:cluster/192.168.202.1,3260,1/default.

Открываем его в текстовом редакторе, и меняем node.startup = manual на node.startup = automatic.

Если изменили что-то лишнее, перейдите в /var/lib/iscsi/nodes/ и удалите нижележащие каталоги и выполните обнаружение целей заново.

В конце стартуем службу iscsi :

# chkconfig iscsi on
# service iscsi start 

Подключение к цели должно произойти автоматически.

Можно проверить диски командой lsscsi:

[root@node1 ~]# lsscsi
[0:0:0:0]    disk    VMware   Virtual disk     1.0   -
[0:0:1:0]    disk    VMware   Virtual disk     1.0   -
[2:0:0:0]    cd/dvd  NECVMWar VMware IDE CDR10 1.00  -
[7:0:0:0]    storage IET      Controller       0001  -
[7:0:0:1]    disk    LocalDat VIRTUAL-DISK     0001  -
[7:0:0:2]    disk    LocalDat VIRTUAL-DISK     0001  -
[7:0:0:3]    disk    LocalDat VIRTUAL-DISK     0001  -

здесь последние три диска подключены по iSCSI.

[править] Задание правил udev для кластерных дисков без использования multipath

Для работы Clusterware необходимо выставить права доступа на диски, используемые для реестра кластера и диска голосования. Для OCR права должны быть: владелец - root, группа - oinstall, права - 640. Для voting disk: владелец - oracle, группа - oinstall, права - 640.

Так как, по-умолчанию ОС выставляет владельцем дисков пользователя root, то для дальнейшей установки кластера необходимо добавить правила в udev.

Рассмотрим для начала случай настройки правил для кластерных дисков без использования multipath. Например, при установки одного из узлов в виртуальную машину избыточности связи с системой хранения может обеспечивать хост виртуализации. Или же возможен вариант, когда связь с системой хранения не дублируется, но это не рекомендуется.

Если диск OCR в системе виден как sdb, а voting disk как sdc, то можно создать правило /etc/udev/rules.d/98-oracleasm.rules:

#OCR disk
KERNEL=="sdb*" NAME="%k", OWNER="root", GROUP="oinstall", MODE="640"
KERNEL=="sdb", SYMLINK+="oracle/ocr"
#Voting disk
KERNEL=="sdc*" NAME="%k", OWNER="oracle", GROUP="oinstall", MODE="640"
KERNEL=="sdc", SYMLINK+="oracle/vdsk"

Данное правило выставит требуемые права доступа и создаст символические ссылки /dev/oracle/ocr и /dev/oracle/vdsk. Далее при установке Clusterware мы укажем использовать эти ссылки на диски. Использование символических ссылок необходимо, если на разных узлах кластерные диски имеют разные названия. Например, если основной узел – это физический сервер и диски к нему подключены через Fiber channel к системе хранения EMC, то они будут иметь название /dev/emcpowera, /dev/emcpowerb1 и т. п. И если второй узел виртуальный, то у него диски будут называться стандартно — sdb, sdc …. В данном случае Clusterware не установиться, так как ей необходимо, чтобы названия указанных ей для работы дисков как и сетевых карт совпадали на всех узлах. Символические ссылки позволяют указать Clusterware обращаться по одинаковым имена дисков /dev/oracle/ocr и /dev/oracle/vdsk.

Проверить работают ли правила, можно командой udevtest: udevtest /block/sdb. Путь к устройству отсчитывается относительно каталога /sys. Например, если нужно проверить правила для раздела /dev/sdd1, то нужно выполнить команду udevtest /block/sdd/sdd1. Применить правила можно, выполнив команду start_udev или перезагрузив сервер.

Надёжнее в правилах udev использовать идентификаторы scsi, а не имена дисков. Сначала узнаем scsiid указав путь к диску относительно каталога /sys. Например для диска /dev/sdb информация об scsiid расположена в каталоге /sys/block/sdb/ поэтому программе scsi_id указываем опции -g ( Treat the device as white listed) и -s (Generate an id for the sysfs-device) и путь к sysfs-device:

# scsi_id -g -s /block/sdb
36006016001911e00f0cc5637d4e4e011

Далее узнаём id для voting disk, например, это будет 36006016001911e005e6e5d5dd4e4e011. При подключении дисков по iSCSI идентификатор может быть вида «1IET 00010002» в таком случае в правилах нужно вызывать scsi_id с ключом -u (заменяет пробелы на подчёркивания). Пример udev-правила:

$ vim /etc/udev/rules.d/98-oracleasm.rules
#OCR disk
# задание атрибутов по SCSI_ID
KERNEL=="sd*", BUS=="scsi", PROGRAM="/sbin/scsi_id -u -g -s %p", RESULT=="36006016001911e00f0cc5637d4e4e011",
OWNER="root", GROUP="oinstall", MODE="640", SYMLINK+="oracle/ocr"
#Voting disk
# задание атрибутов по SCSI_ID
KERNEL=="sd*", BUS=="scsi", PROGRAM="/sbin/scsi_id -u -g -s %p", RESULT=="36006016001911e005e6e5d5dd4e4e011", 
OWNER="oracle", GROUP="oinstall", MODE="640", SYMLINK+="oracle/vdsk"

[править] Настройка multipath

Рассмотрим пример использования родной для GNU Linux возможности multipath при подключении по Fiber Channel к СХД EMC Clariion. Если LUN c СХД подключены двумя линиями, то на сервере каждый LUN будет виден как два диска. Допустим идентификаторы LUNов, полученные scsi_id, следующие:

• 36006016001911e00f0cc5637d4e4e011 (OCR)
• 36006016001911e005e6e5d5dd4e4e011 (Voting Disk)
• 360060160d0901e00caf214a20d18dd11 (диск ASM 1)
• 360060160d0901e000a108c031418dd11 (диск ASM 2)

Для того, чтобы объединить их в одно устройство настраиваем /etc/multipath.conf:

defaults {
       user_friendly_names no
}

blacklist {
	devnode "^sda"
}

device {
	vendor "DGC"
	product ".*"
	product_blacklist "LUNZ"
	path_grouping_policy group_by_prio
	getuid_callout "/lib/udev/scsi_id --whitelisted --device=/dev/%n"
	path_checker emc_clariion
	features "1 queue_if_no_path"
	hardware_handler "1 emc"
	prio emc
	failback immediate
	rr_weight uniform
	no_path_retry 60
	rr_min_io 1000
}

multipaths {

	multipath {
		wwid			36006016001911e00f0cc5637d4e4e011 
		alias			ocr
	}

	multipath {
		wwid			36006016001911e005e6e5d5dd4e4e011
		alias			vdsk
	}

	multipath {
		wwid			360060160d0901e00caf214a20d18dd11
		alias			asmdisk1
	}

	multipath {
		wwid			360060160d0901e000a108c031418dd11
		alias			asmdisk2
	}
}

Здесь сначала задаём не проверять локальные диски (sda), далее идут специфичные настройки для EMC Clariion и в конце задание имён для многопутевых устройств по идентификатору устройства scsi_id (диск с OCR, Voting disk и два диска для хранения файлов БД). Использование пользовательских имён пригодится в написании правил udev.

Более подробно о multipath можно почитать в документе Red Hat Enterprise Linux 5 DM Multipath (рус.)

Загружаем модуль dm-multipath:

[root@node1]# modprobe dm-multipath

Пробуем запустить проверку:

[root@node1]# multipath -v2.	

Если прошло успешно, то включаем службу miltipath и загрузку модуля при старте системы:

1. Создаём файл /etc/sysconfig/modules/multipath.modules, он должен иметь атрибут исполняемый (chmod +x multipath.modules)

2. В нём прописываем shell-скрипт для загрузки модуля:

#!/bin/sh
/sbin/modprobe dm-multipath

3. Включаем службу: chkconfig multipathd on

[править] Задание правил udev для кластерных дисков c multipath

При использовании multipath, права на диски OCR и Voting Disk необходимо задавать в файле /etc/udev/rules.d/40-multipath.rules. Для этого нужно в нём найти строчки:

.........
PROGRAM=="/sbin/dmsetup info -c --noheadings -o name -j %M -m %m", RESULT=="?*",NAME="%k", SYMLINK="mpath/%c",
RUN+="/bin/bash -c '/sbin/mpath_wait /dev/mapper/%c; /sbin/kpartx -a -p p /dev/mapper/%c'"
OPTIONS="last_rule"
.........

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

.........
PROGRAM=="/sbin/dmsetup info -c --noheadings -o name -j %M -m %m", RESULT=="?*",NAME="%k", SYMLINK="mpath/%c",
RUN+="/bin/bash -c '/sbin/mpath_wait /dev/mapper/%c; /sbin/kpartx -a -p p /dev/mapper/%c'"
RESULT=="ocr", OWNER="root", GROUP="oinstall", MODE="640", SYMLINK+="oracle/%c"
RESULT=="vdsk", OWNER="oracle", GROUP="oinstall", MODE="640", SYMLINK+="oracle/%c"
OPTIONS="last_rule"
.........

В итоге получиться следующее: при появлении диска срабатывает правило udev 40-multipath.rules, в нём указано выполнить программу dmsetup, которая в качестве параметров принимает младшее и старшее число устройства и в качестве результата выдаёт имя устройства. Если имена совпадут со значениями ocr или vdsk, то к ним будет применено добавленное нами правило на изменение прав доступа и создания символических ссылок.

В настройках multipath.conf имена устройств можно задать любыми главное, чтобы они совпадали с тем, что указано в правилах udev.

В выводе udevtest /block/dm-1 это выделено жирным:

main: looking at device '/block/dm-1' from subsystem 'block'
run_program: '/sbin/mpath_wait 252 1'
run_program: '/sbin/mpath_wait' returned with status 0
run_program: '/sbin/dmsetup info -c --noheadings -j 252 -m 1'
run_program: '/sbin/dmsetup' (stdout) 'vdsk:252:1:L--w:2:1:0:mpath-36006016001911e005e6e5d5dd4e4e011'
run_program: '/sbin/dmsetup' returned with status 0
run_program: '/sbin/dmsetup info -c --noheadings -o name -j 252 -m 1'
run_program: '/sbin/dmsetup' (stdout) 'vdsk'
run_program: '/sbin/dmsetup' returned with status 0
udev_rules_get_name: reset symlink list
udev_rules_get_name: add symlink 'mpath/vdsk'
udev_rules_get_name: rule applied, 'dm-1' becomes 'dm-1'
udev_rules_get_name: add symlink 'oracle/vdsk'
udev_device_event: device '/block/dm-1' already in database, validate currently present symlinks
udev_node_add: creating device node '/dev/dm-1', major = '252', minor = '1', mode = '0640', uid = '1100', gid = '1100'
udev_node_add: creating symlink '/dev/mpath/vdsk' to '../dm-1'
udev_node_add: creating symlink '/dev/oracle/vdsk' to '../dm-1'
main: run: 'socket:/org/kernel/dm/multipath_event'
main: run: '/bin/bash -c '/sbin/mpath_wait /dev/mapper/vdsk; /sbin/kpartx -a -p p /dev/mapper/vdsk

[править] Настройка oracleasm

Для того, чтобы СУБД могла работать на любом из узлов кластера, необходимо, чтобы файлы БД располагались на кластерной ФС. Документация рекомендует для этих целей использовать ASM (Automatic Storage Management).

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

# fdisk /dev/mapper/asmdisk1
Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-3211263, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-3211263, default 3211263):
Using default value 3211263
Partition 1 of type Linux and of size 1.5 GiB is set

Command (m for help): w
The partition table has been altered! 

Если есть второй диск, то аналогично создаем раздел на нём. После на другом узле перечитываем таблицы разделов дисков командой partprobe. Если не поможет, то можно попробовать перезапустить Udev – start_udev, если и это не помогло, то перезагрузите второй узел.

Далее на обоих узлах настраиваем службу, которая будет искать диски ASM при загрузке:

# oracleasm configure -i

автозапуск — да, владелец — oracle, группа — oinstall.

Настройки службы хранятся в файле /etc/sysconfig/oracleasm. Если используется multipath, то его необходимо отредактировать, указав сканировать только многопутевые устройства: ORACLEASM_SCANORDER="dm", ORACLEASM_SCANEXCLUDE="sd". В противном случае ORACLEASM_SCANORDER, ORACLEASM_SCANEXCLUDE можно оставить пустыми.

Пример:

# ORACLEASM_ENABELED: 'true' means to load the driver on boot.
ORACLEASM_ENABLED=true
# ORACLEASM_UID: Default user owning the /dev/oracleasm mount point.
ORACLEASM_UID=oracle
# ORACLEASM_GID: Default group owning the /dev/oracleasm mount point.
ORACLEASM_GID=oinstall
# ORACLEASM_SCANBOOT: 'true' means scan for ASM disks on boot.
ORACLEASM_SCANBOOT=true
# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE="sd"

После настройки службы можно приступать к созданию дисков ASM. На одном из узлов запускаем команду:

# oracleasm createdisk <МЕТКА> <путь>, где <МЕТКА> должна начинаться с заглавной буквы.
# oracleasm createdisk ASMDATA /dem/mapper/asmdisk1p1

На другом узле кластера нужно просканировать диски и вывести их список:

# oracleasm scandisks
Reloading disk partitions: done
Cleaning any stale ASM disks...
Scanning system for ASM disks...
# oracleasm listdisks
ASMDATA

Если используется asmlib то задавать права доступа к дискам ASM в правилах udev не требуется.

Если же oracleasmlib не используется, то правила udev необходимо задать и для них. Для разделов диска ASM необходимо установить владельца oracle, группу — dba, права 660.

#ASM disk без multipath
KERNEL=="sd[b-z]1", PROGRAM=="/sbin/blkid -s LABEL -o value /dev/%k",
RESULT=="ASMDATA", OWNER="oracle", GROUP="dba" MODE="0660"

В данном примере права выставятся для раздела диска с меткой ASMDATA (метка задаётся при создании диска oracleasm createdisk ...). Здесь следует предусмотреть, чтобы метки для разных дисков отличались.

Если хотите выставить права для всех дисков с ФС ASM, то можно использовать правило:

KERNEL=="sd[b-z]1", PROGRAM=="/sbin/blkid -s TYPE -o value /dev/%k",
RESULT=="oracleasm", OWNER="oracle", GROUP="dba", MODE="0660"

Если диск ASM подключен как multipath и oracleasmlib не используется, то задавать правила доступа нужно в /etc/udev/rules.d/40-multipath.rules после метки kpartx_check (так как ASM находится на разделе диска).

Между строк

PROGRAM=="/sbin/dmsetup info -c --noheadings -o name -j %M -m %m", RESULT=="?*", NAME="%k", SYMLINK="mpath/%c"
OPTIONS="last_rule"

необходимо добавить правило

RESULT=="<имя multipath диска c ASM>", OWNER="oracle", GROUP="dba", MODE="660"

где <имя multipath диска c ASM> - короткое имя (или шаблон имён) для ASM диска, указанное в /etc/multipath.conf.

В итоге весть файл /etc/udev/rules.d/40-multipath.rules у меня приобрел следующий вид:

# multipath wants the devmaps presented as meaninglful device names
# so name them after their devmap name
SUBSYSTEM!="block", GOTO="end_mpath"
RUN+="socket:/org/kernel/dm/multipath_event"
# KERNEL!="dm-[0-9]*", ACTION=="add", PROGRAM=="/bin/bash -c '/sbin/lsmod | /bin/grep ^dm_multipath'", RUN+="/sbin/multipath \
-v0 %M:%m"
KERNEL!="dm-[0-9]*", GOTO="end_mpath"
PROGRAM!="/sbin/mpath_wait %M %m", GOTO="end_mpath"
PROGRAM!="/sbin/dmsetup info -c --noheadings -j %M -m %m", GOTO="end_mpath"
RESULT!="*:*:*:*:*:*:*:mpath-*", GOTO="kpartx_check"
PROGRAM=="/sbin/dmsetup info -c --noheadings -o name -j %M -m %m", RESULT=="?*",NAME="%k", SYMLINK="mpath/%c", RUN+="/bin/bash \
-c '/sbin/mpath_wait /dev/mapper/%c; /sbin/kpartx -a -p p /dev/mapper/%c'"
RESULT=="ocr", OWNER="root", GROUP="oinstall", MODE="640", SYMLINK+="oracle/%c"
RESULT=="vdsk", OWNER="oracle", GROUP="oinstall", MODE="640", SYMLINK+="oracle/%c"
OPTIONS="last_rule"
LABEL="kpartx_check"
RESULT!="*:*:*:*:*:*:*:part*-mpath-*", GOTO="end_mpath"
PROGRAM=="/sbin/dmsetup info -c --noheadings -o name -j %M -m %m", RESULT=="?*", NAME="%k", SYMLINK="mpath/%c"
RESULT=="asmdisk*", OWNER="oracle", GROUP="dba", MODE="660"
OPTIONS="last_rule"
LABEL="end_mpath"

Так как, у меня имена multipath дисков отличаются только цифрой в конце, то я в правилах указал маску asmdisk*. Если у вас имена разные, то пишите отдельную строку правил для каждого диска.

Ещё раз повторюсь, что правила для дисков (OCR, Voting disk) задаются до метки kpartx_check, а правила для разделов (ASM) — после метки.

После необходимо службе oracleasm указать путь поиска дисков только среди multipath устройств.

В файле /etc/sysconfig/oracleasm необходимо указать:

...
ORACLEASM_SCANORDER="dm"
ORACLEASM_SCANEXCLUDE="sd"

А так же экземпляру ASM в файле инициализации (см. далее «Настройка экземпляра ASM и создание дисковых групп» ) указать параметр:

 asm_diskstring=/dev/dm-*'

[править] Настройка службы синхронизации времени

Важно, чтобы время на узлах кластера совпадало как можно точнее, поэтому желательно настроить синхронизацию времени по NTP.

[править] Настройка SSH для входа по ключам

Для работы Clustreware необходимо, что пользователь, от кого запускаются процессы мог заходить на другой узел по SSH. Для этих целей необходимо настроить вход по ключам SSH. Как правило, SSHD уже настроен для этого и остаётся только создать ключи. Если не уверены, то проверьте, что в /etc/ssh/sshd_config параметр PubkeyAuthentication имеет значение «yes». Если sshd не включена на запуск при загрузке сервера, то включаем её: chkconfig sshd on. Заходим в консоль на первый узел под пользователем, кто будет запускать Clisterware (у меня это oracle) и генерируем ключи.

$ ssh-keygen -t dsa

Можно установить пароли на ключи и загружать их в ssh-agent вручную, но тогда после перезагрузки сервера, Clusterware не будет работать, пока вы не добавите ключи в агент, поэтому я не стал задавать пароль на ключи, чтобы кластер работал полностью автоматически. Копируем публичный ключ в файл authorized_keys:

cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys.

Копируем authorized_keys на другой узел:

scp ~/.ssh/authorized_keys node2:~/.ssh/

Генерируем ключи на втором узле для пользователя oracle:

$ ssh-keygen -t dsa

Копируем публичный ключ в файл authorized_keys: cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys. Теперь файл authorized_keys на втором узле содержит публичные ключи пользователей с обоих узлов. Копируем его на первый узел:

scp ~/.ssh/authorized_keys node1:~/.ssh/

Проверяем вход по SSH. Нужно с каждого узла зайти как на другой узел, так и на собственный. Подключаться необходимо как по короткому доменному имени, так и по полному, как на общедоступный сетевой интерфейс, так и на служебный.

В итоге для нашего случая, получается, что

• с узла node1 нужно зайти на node1, node2, node1.domain.ru, node2.domain.ru, node1-priv, node2-priv, node1-priv.domain.ru, node2-priv.domain.r
• с узла node2 на node1,node2, node1.domain.ru, node2.domain.ru, node1-priv, node2-priv, node1-priv.domain.ru, node2-priv.domain.ru.

[oracle@node1] $ ssh node1
The authenticity of host 'node1 (172.16.72.11)' can't be established.
DSA key fingerprint is d9:f6:3b:c5:1b:bd:04:44:10:3c:a4:36:d7:74:39:bc.
Are you sure you want to continue connecting (yes/no)? Yes

и так далее ...

[править] Настройка лимита ресурсов и переменных оболочки

[править] Лимиты ресурсов

Для корректной работы СУБД и Clusterware необходимо увеличить значения лимитов для процессов. Для этого сначала в файл /etc/pam.d/login необходимо добавить строку: session required pam_limits.so, затем в файле /etc/security/limits.conf здать лимиты для количества процессов пользователя (nproc) и для количества открытых файлов (nofile):

oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536

Если планируется использовать большие страницы памяти Hugepages (см. далее), то необходимо, так же указать максимальный размер блокируемой памяти в кБ, он должен быть больше максимального размера областей SGA и PGA экземпляра СУБД. Например, если в СУБД SGA будет иметь размер 3 Гб, то memlock должен быть более 3 145 728 кБ.

oracle soft memlock 3145728
oracle hard memlock 4194304

Следует заметить, если процессу Oracle потребуется для расчётов более 1 Гб PGA, то такая конфигурация вызовет ошибку ORA-04030 СУБД, тогда придётся увеличить memlock. Однако такие ограничения позволят избежать случаев, когда неправильно написанная программа начнет потреблять всё больше памяти PGA, что приведет к тому, что оперативная память на сервере закончится и ОС начнёт вымещать страницы памяти СУБД в swap.

[править] Переменные окружения

После установки максимальных значений лимитов необходимо их назначить пользователю. Можно в файле "/etc/profile" добавить блок:

if [ $USER = "oracle" ] ; then
	if [ $SHELL = "/bin/ksh" ]; then
		ulimit -p 16384
		ulimit -n 65536
	else
	ulimit -u 16384 -n 65536
	fi
umask 022
fi 

или же если используется bash, то в файле /home/oracle/.bashrc добавить строку:

ulimit -u 16384 -n 65536 

При установке Clusterware инсталятор выполняет команды SSH и копирует файлы на другие узлы. В течении установки, скрытые файлы (.bashrc или .cshrc) могут вызвать ошибки выполнения makefile если они содержат команды stty. Чтобы избежать ошибок необходимо подавить все выводы на STDERR, прописав в .bashrc:

if [ -t 0 ]; then
        stty intr ^C
fi

Основные используемые СУБД переменные:

ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/11.1.0/db_1; export ORACLE_HOME
CRS_HOME=/u01/app/crs/11.1; export CRS_HOME
PATH=$ORACLE_HOME/bin:$CRS_HOME/bin:$PATH; export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH

[править] Утилита rlwrap

Весьма полезна утилита rlwrap (http://utopia.knoware.nl/~hlub/uck/rlwrap). С её помощью можно редактировать команды, вводимые в sqlplus, rman, asmcmd. Так же она позволяет использовать историю введённых команд (стрелки курсора), осуществлять поиск по истории команд (Ctrl-R <команда>) и многие другие возможности, которые предоставляет GNU readline.

Утилиты распространяется в архиве с исходными текстами. Для компиляции дополнительно потребуется пакет readline-devel.

Сборка стандартная: # ./configure && make && make install

Использование: $ rlwrap [-опции] <команда> <аргументы>.

Удобно разместить алиасы в .bashrc:

RLWR=/usr/local/bin/rlwrap
alias sqlplus="${RLWR} -c sqlplus"
alias rman="${RLWR} -c rman"
alias lsnrctl="${RLWR} -c lsnrctl"
alias asmcmd="${RLWR} -c asmcmd"

После применения алиасов, можно удобно пользоваться sqlplus и rman.

[править] Настройка параметров ядра

Так же потребуется изменение параметров ядра Linux. В документации по установке указаны все параметры, здесь же приведены только те, которые пришлось изменять. Файл /etc/sysctl.conf:

kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 262144
fs.file-max = 6553600
fs.aio-max-nr = 1048576
vm.hugetlb_shm_group=1100

Параметру vm.hugetlb_shm_group должно быть присвоено значение id групы oinstall.

Если будут производится расчёты, которые потребуют более 4 Гб памяти PGA для одной сессии, то необходимо увеличить максимальное количество используемых страниц памяти процессом vm.max_map_count со стандартного значение 65530 на большее значение. Более подробно это указано на сайте поддержки в документе FAQ: ORA-4030 [ID 399497.1] в разделе «4G Memory limitation in memory mapped systems using realfree allocator».

[править] Настройка shared memory и hugepages

[править] Shared memory

Для работы СУБД необходимо, чтобы размер используемой СУБД памяти Memory Size (SGA + PGA), который устанавливается параметром MEMORY_TARGET или MEMORY_MAX_TARGET не превышал размера shared memory filesystem (/dev/shm) в ОС. Если у вас для СУБД требуется больше памяти, чем свободно в /dev/shm, то необходимо увеличить размер Shared memory. Текущий размер можно узнать командой df /dev/shm.

[oracle@node1 ~]$ df /dev/shm
Filesystem            Size  Used Avail Use% Mounted on
tmpfs                1005M  168M  838M  17% /dev/shm

Для изменения размера shm необходимо от root выполнить команду:

# mount -t tmpfs shmfs -o size=4g /dev/shm

или прописать в /etc/fstab:

shmfs /dev/shm tmpfs size=4g 0 0

, где size=4g собственно и указывает новый размер shared memory. Если у вас не планируется использовать автоматическое управление памятью (MEMORY_TARGET=0), то размер необходимо подбирать по величине области SGA.

[править] Hugepages

При настройке в ОС больших страниц памяти (Hugepages) СУБД Oracle может использовать их для размещения SGA области. Большие страницы не вытесняются в swap – если какая-либо программа начнёт отъедать память, то SGA гарантированно останется в ОЗУ (аналогично при включении параметра СУБД lock_sga=true). При использовании больших страниц памяти общее быстродействие СУБД увеличиться, так как процессору потребуется выполнять меньшее число трансляций виртуальных адресов памяти в физические. Кеш CPU о недавних обращениях к виртуальный адресам (Translation Lookaside Buffers (TLB) ) будет реже устаревать и в нём будет храниться большее информации об адресном пространстве.

Размещение SGA в больших страницах памяти происходит только если отключено автоматическое управление памятью AMM (memory_target=0). При использовании больших страниц памяти shared memory для СУБД настраивать не нужно. Важно только, чтобы размер /dev/shm был больше 300 МБ, так как при использовании ASM создаётся экземпляр СУБД который обслуживает запись в файлы БД. Как правило он использует менее 300 МБ shared memory.

Настраивать hugepages до установки СУБД нужно, только если вы при установке СУБД выберите тип управления памяти, отличный от Automatic Memory Management (AMM)^[1].

Количество больших страниц памяти задаётся параметром ядра vm.nr_hugepages. Можно динамически изменять количество hugepages, но лучше резервировать их при загрузке ОС. Для этого в загрузчике необходимо добавить в параметры загрузки ядра: hugepages=<nnn>.

Пример для Grub:

title Oracle Linux Server (2.6.39-100.7.1.el5uek)
   root (hd0,1)
   kernel /boot/vmlinuz-2.6.39-100.7.1.el5uek ro root=LABEL=/ hugepages=9500
   initrd /boot/initrd-2.6.39-100.7.1.el5uek.img

Информацию об использовании hugepages можно узнать из /proc/meminfo:

[ oracle@node1 ~]$ grep Huge /proc/meminfo
HugePages_Total:    9500
HugePages_Free:     1238
HugePages_Rsvd:      956
HugePages_Surp:        0
Hugepagesize:       2048 kB

В моём случае видно, что размер одной страницы памяти равен 2 Мб (стандартная страница 4 кБ), всего выделено 9500 страниц (19000 Мб), из них используется 9218 страниц (9500 всего – 1238 свободных + 956 зарезервированных). На сервере запущены два экземпляра СУБД, у одного sga_max_size=8G, у второго sga_max_size=10G. Для того чтобы узнать требуемое количество hugepages для СУБД, необходимо сложить размеры SGA всех экземпляров, разделить на размер страницы и добавить некоторое количество про запас. Так у нас получается следующее: суммарный размер SGA двух экземпляров 18 Гб, размер страницы 2048 кБ, в итоге по расчётам нужно 9216 страниц. Запас у меня составил 284 страницы. Как видно из вывода /proc/meminfo используется 9218, поэтому запас можно уменьшить.

Итак, кратко о том как использовать hugepages в Oracle:

1. В СУБД отключить AMM , установив memory_target=0, посмотреть размер sga (show parameter sga_max_size)
2. Остановить СУБД.
3. Рассчитать требуемое количество страниц памяти.
4. Зарезервировать полученное значение: # sysctl vm.nr_hugepages=<nnn>
5. Запустить СУБД и проверить в /proc/meminfo, что hugepages используются.
6. Если всё успешно, то прописать в параметрах загрузчика рассчитанное значение hugepages.

Если использовать hugepages не получилось, удостоверьтесь, что в СУБД отключено автоматическое управление памятью AMM, а так же, что в настройке лимитов /etc/security/limits.conf пользователю, от которого запускается СУБД разрешено блокировать память такого размера (oracle hard memlock <....>). Попробуйте сделать больший запас свободных страниц hugepages.

Помните, что память, занятая hugepages, может использоваться только приложениями в которых есть поддержка больших страниц памяти. Не резервируйте слишком много памяти под большие страницы. Помните, что PGA может значительно расти, и параметр pga_agregate_target не ограничивает жестко максимальный размер используемой PGA. PGA использует стандартные блоки памяти, поэтому если под hugepages занять слишком много памяти, то для PGA её может не хватить. Hugepages может использоваться только для размещения SGA. Помните и про другие процессы на сервере.

[править] Установка Clusterware

После настройки узлов можно переходить к установке Clusterware. Распаковываем скаченный архив с Clusterware во временный каталог:

$ unzip linux.x64_11gR1_clusterware.zip
$ ls ./clusterware
cluvfy  doc  install  response  rpm  runcluvfy.sh  runInstaller  stage  upgrade  welcome.html

Желательно, предварительно запустить проверки утилитой Cluster Verification Utility (cluvfy): первая проверит доступ к разделяемым дискам, вторая проверит корректность параметров и пакетов.

До установки данная утилита вызывается через скрипт runcluvfy.sh, располагающийся в корне распакованного архива.

Тест на общий доступ к дискам запускается командой:

./runcluvfy.sh comp ssa -n  <список узлов> -s <список дисков>

[oracle@node1 ~]$ ./runcluvfy.sh comp ssa -n node1,node2 -s /dev/oracle/ocr,/dev/oracle/vdsk
Verifying shared storage accessibility
Checking shared storage accessibility...
"/dev/oracle/ocr" is shared.
"/dev/oracle/vdsk" is shared.
Shared storage check was successful on nodes "node1,node2".
Verification of shared storage accessibility was successful.

Тест проверки настроек:

./runcluvfy.sh stage -pre crsinst -n <список узлов> -verbose 
[oracle@node1 ~]$ ./runcluvfy.sh stage -pre crsinst -n node1,node2 -verbose | less
 Performing pre-checks for cluster services setup 
Checking node reachability...
Check: Node reachability from node "node1"
 Destination Node                      Reachable?              
 ------------------------------------  ------------------------
 node2                                yes                     
 node1                                yes                     
Result: Node reachability check passed from node "node1".
............

Возможно, тест выдаст ошибку, что пакет glibc-2.5-12 отсутствует, но если посмотреть ниже, то окажется, что вместо него установлена более новая версия.

Check: Package existence for "glibc-2.5-12" 
 Node Name                       Status                          Comment         
 ------------------------------  ------------------------------  ----------------
 node1                          missing                         failed          
 node2                          missing                         failed          
Result: Package existence check failed for "glibc-2.5-12".
Check: Package existence for "glibc-2.5-12" 
 Node Name                       Status                          Comment         
 ------------------------------  ------------------------------  ----------------
 node1                          glibc-2.5-81.el5_8.2            passed          
 node2                          glibc-2.5-81.el5_8.2            passed          
Result: Package existence check passed for "glibc-2.5-12".

Основные ошибки могут возникнуть из-за того, что на узлах не указаны маршруты по-умолчанию (или они разные), а так же при настройке входа по SSH не все комбинации были перебраны. В таком случае, скрипт будет пытаться подключиться по какому-то адресу, и зависнет, так там ему выдают предложение принять публичный ключ.

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

Самый простой способ использовать графический установщик. Чаще всего на сервере не запущен X window, поэтому можно подключиться к нему по SSH с X11 forwarding (или использовать Putty и Xming при подключении с MS Windows) и производить установку удалённо. Логонимся под пользователем oracle, переходим в каталог с распакованным clusterware и запускаем ./runInstaller.

Если у пользователя нет прав на запись в каталог с clusterware, то нужно перейти в каталог, где права на запись есть и запускать, используя полный путь:

$ cd ~
$ /media/cdrom/clusterware/runInstaller

Далее выполняем шаги установщика:

1. Установочный путь (OraCrs11g_home): /u01/app/crs

2. Запуститься утилита проверки кластера (см. выше). Если выдаст ошибки на каких-то параметрах, в которых вы уверенны, то поставьте галочку «User Verified»

3. Название кластера (можно указать любое), и список узлов. Пока в кластере указан один узел. Добавляем второй. Нужно указать имена узла:

Public Node Name: node2.domain.ru (должен пинговаться)
Private Node Name: node2-priv.domain.ru (должен пинговаться)
Virtual Host Name: node2-vip.domain.ru (пинговаться  не должен). 

Все имена должны разрешаться в ip адреса (dns или /etc/hosts) со всех узлов.

4. Выбор сетевых интерфейсов. Укажите сетевой интерфейс, который будет использоваться для общедоступной сети и для межкластерной.

5. Выбор пути к кластерному диску для хранения реестра кластера: /dev/oracle/ocr, external redundancy

6. Выбор пути к диску голосования: /dev/oracle/vdsk, external redundancy

7. Установка ПО на узлы кластера.

8. Запуск скриптов завершения установки от root:

Выполните последовательно на каждом узле /u01/app/oraInventory/orainstRoot.sh. Скрипт выставит корректные права доступа на каталоги с Clusterware.

После выполните последовательно на каждом узле /u01/app/crs/root.sh. Этот скрипт произведёт начальное форматирование дисков с OCR и Voting Disk. Так же настроит запуск служб Clusterware при загрузке ОС и сконфигуриет приложения кластера. Скрипт может выполняться очень долго около 10 минут. Если после 10 минут скрипт на первом узле, так и не завершился, то запустите его на втором узле. Хоть в документации это делать настоятельно не рекомендуют, это единственный, найденный мной, способ ускорить его работу.

[править] Создание отказоустойчивой БД Oracle

Для того, чтобы развернуть БД, работу которой будет контролировать службы кластера, необходимо сначала установить ПО СУБД, затем создать БД на кластерной ФС и перенести управление ею под контроль Clusterware.

[править] Установка СУБД Oracle

Сначала распакуем архив во временный каталог:

$ unzip linux.x64_11gR1_database.zip

Запускаем графический установщик: ./runInstaller.

1. Выбираем тип установки Enterprise или Standard.
2. Задаём пути: Oracle Base: /u01/app/oracle, тогда Oracle home (OraDb11g_home1) примет значение: /u01/app/oracle/product/11.1.0/db_1
3. Запуститься проверка параметров ОС аналогичная, что и при установке Clusterware.
4. Далее выбор конфигурации: создать БД, настроить ASM, только установить ПО. Здесь нужно выбрать «Install Software Only», остальные шаги по настройке БД сделаем вручную.
5. Задание соответствия групп ОС и БД: OSDBA, OSOPER, OSASM. Подробнее см. «Пользователи и группы»
6. Вывод итоговой сводки и установка на узлы.
7. Запуск скриптов /u01/app/oracle/product/11.1.0/db_1/root.sh на обоих узлах.

После завершения установки ПО, желательно у пользователя oracle задать в .bashrc переменные ORACLE_BASE, ORACLE_HOME. Так же можно задать переменную CRS_HOME. Включить путь $ORACLE_HOME/bin и $CRS_HOME/bin в переменную $PATH, а путь $ORACLE_HOME/lib в переменную LD_LIBRARY_PATH.

ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/11.1.0/db_1; export ORACLE_HOME
CRS_HOME=/u01/app/crs/11.1; export CRS_HOME
PATH=$ORACLE_HOME/bin:$CRS_HOME/bin:$PATH; export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH

[править] Создание ресурсов, обслуживающих СУБД

Если установка БД будет производиться на ASM, то предварительно нужно настроить прослушиватель и создать дисковые группы ASM.

[править] Настройка прослушивателя

Для настройки прослушивателя можно запустить команду netca ($ORACLE_HOME/bin/netca). Далее выбрать всё узлы и нажать сконфигурировать прослушиватель.

Мастер создаст файл $ORACLE_HOME/network/admin/listener.ora на каждом узле.

На первом узле он будет примерно такого вида:

LISTENER_NODE1 =
 (DESCRIPTION_LIST =
   (DESCRIPTION =
     (ADDRESS = (PROTOCOL = TCP)(HOST = node1-vip)(PORT = 1521)(IP = FIRST))
     (ADDRESS = (PROTOCOL = TCP)(HOST = 172.16.72.11)(PORT = 1521)(IP = FIRST))
   )
 )

на втором узле:

LISTENER_NODE2 =
 (DESCRIPTION_LIST =
   (DESCRIPTION =
     (ADDRESS = (PROTOCOL = TCP)(HOST = node2-vip)(PORT = 1521)(IP = FIRST))
     (ADDRESS = (PROTOCOL = TCP)(HOST = 172.16.72.12)(PORT = 1521)(IP = FIRST))
   )
 )

В данных прослушивателях будут регистрироваться экземпляры ASM.

[править] Настройка экземпляра ASM и создание дисковых групп

Для создании экземпляра ASM нужно запустить команду dbca ($ORACLE_HOME/bin/dbca). Выбрать тип СУБД «Real Application Cluster database». Экземпляр ASM, по сути та же СУБД, только с урезанными возможностями. Напомню, что согласно документу Licensing, при использовании Standard Edition опция Real Application Clusters включена в поставку и не требует отдельного лицензирования.

Далее выбрать «Configure Automatic Storage Management», выбрать все узлы, придумать пароль администратора экземпляра ASM. Пароль храниться локально на сервере в каталоге $ORACLE_HOME/dbs в файле orapw+ASM1 (для первого узла). На втором и последующих узлах, цифра после +ASM будет увеличиваться.

Думаю, если забудете пароль, то можно воспользоваться утилитой orapwd для создания нового. Пароль таким образом, не менял, но думаю, что тогда придётся генерировать новый пароль на всех узлах.

Файл инициализации располагается в каталоге $ORACLE_BASE/admin/+ASM/pfile/init.ora. Но так же на этот файл есть символическая ссылка в каталоге $ORACLE_HOME/dbs, которая имеет вид init+ASM1.ora. Параметров в нём не много. Основной – это имя монтируемой дисковой группы asm_diskgroups.

Дисковая группа ASM, это аналог RAID-массива. СУБД может хранить на ней свои файлы. В группу можно добавлять диски при нехватке места. Тогда ASM сделает автоматическую балансировку данных по дискам. Так же можно удалять диски. Если на остающихся хватит места, то ASM переместит данные с удаляемого диска на остающиеся, иначе не даст удалить диск. Более подробно по работе с ASM будет написано ниже.

Сначала нам нужно создать дисковую группу. После вызова мастера dbca и ввода пароль администратора ASM вы должны попасть на шаг создания дисковой группы.

Нажимайте «Create new». Нужно ввести название дисковой группы без пробелов.

Это название будет указано в настройках БД для создания файлов. То есть если название дисковой группы будет DG_DATA, имя базы Alpha, то БД разместит файл табличного пространства SYSTEM по пути: +DG_DATA/ALPHA/DATAFILE/SYSTEM.380.773605479, где цифры могут быть другими. Файлы другого типа будут размещаться в других каталогах (CONTROLFILE, DATAFILE, ONLINELOG, TEMPFILE).

Если у вас система хранения, где располагаются ASM диски построена по избыточному принципы (используются raid), то выбирайте тип избыточности External. В противном случае нужно добавлять в группу несколько дисков, чтобы обеспечить целостность данных в случае повреждения одного из дисков.

В поле «Select Member Disks» должны быть диски, которые вы размечали программой oracleasm (см. Настройка oracleasm). Если тех дисков нет – попробуйте переключить флажок с «Show candidates» в «Show all».

Если используется библиотека oracleasmlib, то диски должны быть показаны в формате ORCL:<метка>, например ORCL:ASMDISK1.

Если диске не отображаются, возможно, у вас не установлена oracleasmlib. Тогда нажмите «Cancel». Откройте файл инициализации ASM (init+ASM1.ora) и добавьте параметр asm_diskstring=<список дисков>, где <список дисков> – разделённый запятыми шаблон для поиска дисков ASM. Можно использовать маски * и ?

Подробнее данный параметр описан в Oracle Database Storage Administrator's Guide (англ.) и в Oracle Database Reference (англ.).

Например:

asm_diskstring='/dev/oracle/*','/dev/dm*'

После того, как создали дисковую группу, нажмите «Mount all» – это команда смонтирует дисковые группы на всех узлах. Если на другом узле группа не смонтировалась, проверяйте настройку кластерных дисков и oracleasm.

[править] Конфигурация БД

Теперь нужно создать БД. Самый простой способ — использовать графический мастер dbca. Если на сервере не запущен X window, то можно подключиться к нему по SSH с X11 forwarding (или использовать Putty и Xming при подключении с MS Windows) и производить установку удалённо. Или можно подготовить файл ответов и запустить создание БД с консоли.

Подключаемся к любому узлу и запускаем dbca. Отвечаем на вопросы мастера.

1. Выбираем тип БД — Oracle single instance database. Установка файлов СУБД на кластер, необходима для работы ASM в кластерном режиме. Сама же БД должна работать только на одном узле. Иначе вам будет необходима лицензия для каждого узла + лицензия на RAC.
2. Тип операции — Create DB.
3. Шаблон — Custom Database
4. Задаём global database name, SID базы данных.
5. Если нужен Enterprise manager, то оставляем «Configure Enterprise Manager»
6. Задаём пароли пользователей SYS и SYSTEM (если указано создание Enterprise Manager, то и для DBSNMP и др.)
7. Если настроена ASM, то в качестве хранилища, где будут размещаться файлы указываем Automatic Storage Managment (ASM). Иначе указываем File system и выбираем другую кластерную ФС. Далее будет опиcываться использование ASM.
8. Выбираем дисковую группу ASM в которой будут храниться файлы БД.
9. Выбираем использовать или нет Oracle managed files (имена и пути файлов будут автоматически создаваться СУБД на основе их типа, параметр db_create_file_dest)
10. Настраиваем Flash recovery area и архивацию.
11. Выбираем необходимые компоненты БД.
12. Выбираем тип управления памятью, размеры областей SGA, PGA. Если планируется использовать hugepages (см. выше), то нужно выбрать Custom и Automatic Shared Memory Managment или Manual Shared Memory Menagment. Определение размера SGA и hugepages описано выше в разделе «Настройка shared memory и hugepages».
13. На этом же окне выбираем кодировку, размер блока, максимальное количество процессов, подключенных к БД.
14. Выбираем использовать или нет умолчальные настройки безопасности 11 версии (срок действия пароля 180 дней и т. д.)
15. Разрешаем или нет запуск автоматических задач.
16. Настраиваем табличные пространства и остальные файлы БД.
17. Запускаем процесс создания БД. Желательно сгенерировать скрипты создания — они могут пригодиться при повтороном создании БД.

[править] Задание контроля за работой СУБД

После того как БД создана, необходимо перевести её под контроль Clusterware. Для этого необходимо создать профили группы ресурсов, работу которых Clusterware будет отслеживать и перезапускать при необходимости. Описание команд приведено в Oracle Clusterware Administration and Deployment Guide 11g Release 1 (англ.).

Для работы профилей необходимо скопировать скрипты act_db .pl, act_listener.pl и act_resgroup.pl из каталога $CRS_HOME/crs/demo/coldfailover (/u01/app/crs/crs/demo/coldfailover) в каталог $CRS_HOME/crs/public (/u01/app/crs/crs/public) и выставить права на выполнение данным скриптам. Скопировать скрипты нужно на каждом узле.

$ cp /u01/app/crs/crs/demo/coldfailover/*.pl /u01/app/crs/crs/public/
$ chmod +x /u01/app/crs/crs/public/*.pl

После можно приступать к созданию и регистрации профилей (команды crs_profile и crs_register находяться в каталоге $CRS_HOME/bin).

По-умолчанию, после перезагрузки сервера у ресурсов восстанавливается состояние до сбоя. Если вам нужно, чтобы ресурсы всегда запускались, не смотря на их прошлое состояние, то при создании профилей у команды crs_profile укажите в опциях (после -o) параметр as=always. Пример:

crs_profile -create rg1 -t application -a $CRS_HOME/crs/public/act_resgroup.pl -o ci=600,as=always

Параметр as=<запуск> может принимать следующие значения:

• always—всегда запускать ресурсы при восстановлении узла
• restore—восстанавливать предыдущее состояние ресурсов. Если ресурс был выключен (STATE=OFFLINE, TARGET=OFFLINE) когда узел выключался, то он останется выключенным и при восстановлении узле. Ресурс запуститься, только до сбоя он был в статусе ONLINE.
• never—Oracle Clusterware не будет восстанавливать состояние ресурса после восстановления узла.

[править] Создание начального ресурса

Создаём основной начальный профиль, от которого будут зависеть остальные ресурсы. Его будет удобно использовать если нужно необходимо остановить работу всех остальных ресурсов.

$ crs_profile -create rg1 -t application -a $CRS_HOME/crs/public/act_resgroup.pl -o ci=600

Профиль создаётся в каталоге $CRS_HOME/crs/public с расширением cap. Далее регистрируем профиль в реестре кластера OCR, который находится на общем кластерном диске.

$ crs_register rg1

Этот профиль ничего не запускает, он нужен для зависимости.

[править] Создание ресурса виртуального сетевого адреса

Создаём профиль виртуального сетевого интерфейса, который может перемещаться между узлами.

$ crs_profile -create rg1.vip -t application -r rg1 -a $CRS_HOME/crs/bin/usrvip \
 -o oi=<имя сет. интерфейса>,ov=<вирт. ip>,on=<сетевая маска>

пример:

$ crs_profile -create rg1.vip -t application -r rg1 -a $CRS_HOME/crs/bin/usrvip -o oi=bond0.10,ov=172.16.72.20,on=255.255.0.0

Регистрируем профиль в OCR.

$ crs_register rg1.vip

От root задаём права на создание сетевых интерфейсов пользователю oracle:

# /u01/app/crs/bin/crs_setperm rg1.vip -o root
# /u01/app/crs/bin/crs_setperm rg1.vip -u user:oracle:r-x

Пробуем запустить ресурс:

$ crs_start rg1.vip
Attempting to start `rg1` on member `node1`
Start of `rg1` on member `node1` succeeded.
Attempting to start `rg1.vip` on member `node1`
Start of `rg1.vip` on member `node1` succeeded.

Посмотрите статистику ресурсов командой crs_stat -t ресурсы rg1 и rg1.vip должны быть ONLINE.

$ crs_stat -t 
Name           Type           Target    State     Host
------------------------------------------------------------
ora....SM1.asm application    ONLINE    ONLINE    node1
ora....1T.lsnr application    ONLINE    ONLINE    node1
ora.node1.gsd  application    ONLINE    ONLINE    node1
ora.node1.ons  application    ONLINE    ONLINE    node1
ora.node1.vip  application    ONLINE    ONLINE    node1
ora....SM2.asm application    ONLINE    ONLINE    node2
ora....2T.lsnr application    ONLINE    ONLINE    node2
ora.node2.gsd  application    ONLINE    ONLINE    node2
ora.node2.ons  application    ONLINE    ONLINE    node2
ora.node2.vip  application    ONLINE    ONLINE    node2
rg1            application    ONLINE    ONLINE    node1
rg1.vip        application    ONLINE    ONLINE    node1

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

[oracle@node1 ~]$ /sbin/ip addr
...
3: bond0.10@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
  link/ether 84:2b:2b:6e:0b:b5 brd ff:ff:ff:ff:ff:ff
   inet 172.16.72.11/16 brd 172.16.255.255 scope global bond0.10
   inet 172.16.72.30/16 brd 172.16.255.255 scope global secondary bond0.10:1
   inet 172.16.72.20/16 brd 172.16.255.255 scope global secondary bond0.10:2
...

Попробуйте переместить ресурс на другой узел – сетевой адрес переместится на него:

[oracle@node1 ~]$ crs_relocate -f rg1.vip
Attempting to stop `rg1.vip` on member `node1`
Stop of `rg1.vip` on member `node1` succeeded.
Attempting to stop `rg1` on member `node1`
Stop of `rg1` on member `node1` succeeded.
Attempting to start `rg1` on member `node2`
Start of `rg1` on member `node2` succeeded.
Attempting to start `rg1.vip` on member `node2`
Start of `rg1.vip` on member `node2` succeeded. 

Если не получилось, то проверьте, что на другом узле скрипты Clusterwware скопированы в каталог $CRS_HOME/crs/public и для них выставлены права на выполнения. Сетевой адрес виртуального интерфейса должен быть на втором узле:

[oracle@node2 ~]$ /sbin/ip addr
...
3: bond0.10@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
  link/ether 84:2b:2b:6e:0b:b5 brd ff:ff:ff:ff:ff:ff
   inet 172.16.72.12/16 brd 172.16.255.255 scope global bond0.10
   inet 172.16.72.31/16 brd 172.16.255.255 scope global secondary bond0.10:1
   inet 172.16.72.20/16 brd 172.16.255.255 scope global secondary bond0.10:2
...

Для дальнейшей настройки необходимо будет использовать доменное сетевое имя этого интерфейса. Так же, на этот адрес будут обращаться клиенты для подключения к СУБД, поэтому необходимо прописать его в DNS.

В примере ниже, для виртуального интерфейса будет использоваться доменное имя - alpha.domain.ru (172.16.72.20).

[править] Создание ресурса прослушивателя

После создания виртуального сетевого интерфейса, необходимо создать на нём прослушиватель (listener). В файле $ORACLE_HOME/network/admin/listener.ora на каждом узле добавим конфигурацию для нового прослушивателя:

LISTENER_RG1 =
 (DESCRIPTION_LIST =
   (DESCRIPTION =
     (ADDRESS = (PROTOCOL = TCP)(HOST = alpha.domain.ru)(PORT = 1521)(IP = FIRST))
   )
 )

здесь alpha.domain.ru=172.16.72.20 — ip виртуального интерфейса, что был задан при регистрации ресурса rg1.vip.

В общем, файл listener.ora должен выглядеть примерно так:

LISTENER_NODE1 =
 (DESCRIPTION_LIST =
   (DESCRIPTION =
     (ADDRESS = (PROTOCOL = TCP)(HOST = node1-vip)(PORT = 1521)(IP = FIRST))
     (ADDRESS = (PROTOCOL = TCP)(HOST = 172.16.72.11)(PORT = 1521)(IP = FIRST))
   )
 )
LISTENER_RG1 =
 (DESCRIPTION_LIST =
   (DESCRIPTION =
     (ADDRESS = (PROTOCOL = TCP)(HOST = alpha.domain.ru)(PORT = 1521)(IP = FIRST))
   )
 )

Здесь LISTENER_NODE1 будет использоваться локально экземпляром ASM, а LISTENER_RG1 — базой данных. Аналогично на втором узле.

Создаём ресурс прослушивателя.

$ crs_profile -create rg1.listener \
  -t application \
  -r rg1.vip \
  -a $CRS_HOME\crs\public\act_listener.pl \
  -o ci=20,ra=5,osrv=LISTENER_RG1,ol=$ORACLE_HOME

Здесь ci интервал проверки, ra – количество попыток перезапуска прослушивателя до миграции на другой узел.

Регистрируем ресурс:

$ crs_register  rg1.listener

Пробуем запустить ресурс:

crs_start  rg1.listener

Пробуем мигрировать на другой узел:

crs_relocate  rg1.listener

Проверьте статус прослушивателей: lsnrctl status — выведет статус LISTENER_NODE1, в нем должен быть зарегистрирован экземпляр +ASM, если вы его создали ранее

...
Listening Endpoints Summary...
 (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=172.16.72.30)(PORT=1521)))
 (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=172.16.72.11)(PORT=1521)))
Services Summary...
Service "+ASM" has 1 instance(s).
 Instance "+ASM1", status READY, has 1 handler(s) for this service...
Service "+ASM_XPT" has 1 instance(s).
 Instance "+ASM1", status READY, has 1 handler(s) for this service...
...

lsnrctl status LISTENER_RG1 – выведет статус виртуального прослушивателя. Пока база не настроена на него, у него не будет служб.

...
Listening Endpoints Summary...
 (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=172.16.72.20)(PORT=1521)))
The listener supports no services
...

Следует заметить, что при такой конфигурации прослушивателя не удастся использовать Enterprise manager, так как он будет пытаться использовать LISTENER_NODE1, а на нём СУБД регистрироваться не будет.

Если не удалось запустить прослушиватель через Clusterware, проверьте listener.ora – адреса после HOST должны быть разные. Попробуйте запустить прослушиватель вручную lsnrctl start LISTENER_RG1. Если вручную запускается, а через Clusterware нет, то нужно посмотреть вывод сообщений при запуске скриптов Clusterware.

Для этого экспортируем переменные, необходимы для прямого запуска скрипта:

$ export _USR_ORA_LANG=$ORACLE_HOME
$ export _USR_ORA_SRV=LISTENER_RG1

и запускам скрипт:

$ $CRS_HOME/crs/public/act_listener.pl start

Выводимые сообщения должны помочь в решении проблемы.

После остановите прослушиватель:

$CRS_HOME/crs/public/act_listener.pl stop

[править] Создание ресурса, контролирующего состояние базы данных

Теперь необходимо создать ресурс, который будет проверять состояние СУБД.

Предварительно нужно настроить СУБД, чтобы она регистрировалась на виртуальном сетевом интерфейсе. Для этого необходимо установить параметр LOCAL_LISTENER. Данный параметр определяет сетевое имя TNS, которое преобразуется в адрес локального прослушивателя. Имя должно быть прописано в файле TNSNAMES.ORA.

По-умолчанию, данный параметр имеет значение (ADDRESS = (PROTOCOL=TCP)(HOST=<hostname>)(PORT=1521)), где <hostname> – сетевое имя сервера.

В файле $ORACLE_HOME/network/admin/tnsnames.ora добавляем запись, указывающую на виртуальный сетевой интерфейс:

LISTENERS_RG1 =
 (ADDRESS_LIST =
   (ADDRESS = (PROTOCOL = TCP)(HOST = alpha.domain.ru)(PORT = 1521))
 )

Весь файл должен выглядеть примерно так:

LISTENERS_RG1 =
 (ADDRESS_LIST =
   (ADDRESS = (PROTOCOL = TCP)(HOST = alpha.domain.ru)(PORT = 1521))
 )
ALPHA =
 (DESCRIPTION =
   (ADDRESS = (PROTOCOL = TCP)(HOST = alpha.domain.ru)(PORT = 1521))
   (CONNECT_DATA =
     (SERVER = DEDICATED)
     (SERVICE_NAME = alpha.domain.ru)
   )
 )

Здесь ALPHA – tns имя созданной базы данных. Такое же описание имени ALPHA должно быть и у клиентов.

Далее подключаемся к СУБД и изменяем параметр LOCAL_LISTENER:

$ export ORACLE_SID=alpha
$ sqlplus / as sysdba
sql> alter system set LOCAL_LISTENER=LISTENERS_RG1 SCOPE=BOTH;

Обратите внимание, что в LOCAL_LISTENER указывается не имя прослушивателя из listener.ora (у него имя LISTENER_RG1), а имя TNS, ссылающееся на адрес, где находится прослушиватель.

Можно было указать сразу сетевой адрес:

sql> alter system set LOCAL_LISTENER='(ADDRESS = (PROTOCOL=TCP)(HOST=alpha.domain.ru)(PORT=1521))' SCOPE=BOTH; 

Перезапускаем базу данных и проверяем, что она зарегистрировалась в прослушивателе, работающим на виртуальном сетевом интерфейсе.

[oracle@node1~]$ lsnrctl status LISTENER_RG1
...
Listening Endpoints Summary...
 (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=alpha.domain.ru)(PORT=1521)))
Services Summary...
Service "alpha.domain.ru" has 1 instance(s).
 Instance "alpha", status READY, has 1 handler(s) for this service...
Service "alpha_XPT.domain.ru" has 1 instance(s).
 Instance "alpha", status READY, has 1 handler(s) for this service...
The command completed successfully

Если БД зарегистрировалась успешно, то останавливаем СУБД и копируем файлы, необходимые для работы СУБД на другой узел (файл параметров, пароль SYS, описание tns-имен):

[oracle@node1~]$ scp $ORACLE_HOME/dbs/spfile<SID>.ora node2:$ORACLE_HOME/dbs
[oracle@node1~]$ scp $ORACLE_HOME/dbs/orapw<SID>.ora node2:$ORACLE_HOME/dbs
[oracle@node1~]$ scp $ORACLE_HOME/network/admin/tnsnames.ora node2:$ORACLE_HOME/network/admin

Скорей всего, при установке БД на ASM у вас в каталоге $ORACLE_HOME/dbs не будет файла параметров SPFILE, а будет PFILE init<SID>.ora, в котором будет указан одни параметр — путь к spfile:

SPFILE='+DG_ASM/alpha/spfilealpha.ora'

Если у вас узлы одинаковые конфигурации, то копируете pfile:

[oracle@node1~]$ scp $ORACLE_HOME/dbs/init<SID>.ora node2:$ORACLE_HOME/dbs

В данном случае, при запуске БД с разных узлов будет использовать один и тот же spfile c ASM хранилища.

Если же, узлы разные (физический и виртуальный), то лучше для каждого узла создать свой spfile и настроить в них индивидуальные настройки распределения памяти.

Для этого на первом узле:

• Запускаем БД

• Заходим в $ORACLE_HOME/dbs копируем файл параметров init<SID>.ora для резерва

• Подключаемся к СУБД и создаём pfile из spfile

sql> create pfile from spfile;

Предыдущий файл параметров будет перезаписан.

• Останавливаем БД

• Если в полученном pfile-ле есть указание, где размещается spfile, то удаляем эту строку, чтобы СУБД искала spfile в стандартном $ORACLE_HOME/dbs

• Запускаем БД с pfile-ом

sql> startup pfile='$ORACLE_HOME/dbs/init<SID>.ora';

• Создаём spfile

sql> create spfile from pfile;

• Копируем pfile на другой узел
• Останавливаем БД

На втором узле создаём каталог для файлов аудита. Путь можно узнать, посмотрев параметр СУБД audit_file_dest.

[oracle@node2~]$ mkdir -p /u01/app/oracle/admin/alplha/adump

В файл /etc/oratab на втором узел добавляем запись о созданной БД:

[oracle@node2~]$ vim /etc/oratab
+ASM2:/u01/app/oracle/product/11.1.0/db_1:N
alpha:/u01/app/oracle/product/11.1.0/db_1:N

Пробуем вручную запустить БД на втором узле:

[oracle@node2~]$ export ORACLE_SID=alpha
[oracle@node2~]$ sqlplus / as sysdba
sql> startup

Если СУБД запустилась успешно, то останавливаем её

sql> shutdown transactional

и пробуем запустить через Clusterware.

Создаём ресурс СУБД:

$ crs_profile -create rg1.db_<SID БД> -t application \
-r rg1 \
-a $CRS_HOME/crs/public/act_db.pl \
-o ci=20,ra=5,osrv=<SID БД>,ol=$ORACLE_HOME,oflags=<0 или 1>, rt=600

здесь oflags должно быть равно 1, если для хранения файлов БД используется ASM, иначе oflags=0.

Пример SID=alpha, БД на ASM:

[oracle@node1 ]$ crs_profile -create rg1.db_alpha -t application \
-r rg1 \
-a $CRS_HOME/crs/public/act_db.pl \
-o ci=20,ra=5,osrv=alpha,ol=$ORACLE_HOME,oflags=1,rt=600

Регистрируем ресурс:

[oracle@node1 ]$ crs_register rg1.db_alpha

Пробуем запустить БД через Clusterware:

[oracle@node1 ]$ crs_start rg1.db_alpha

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

$ export _USR_ORA_LANG=$ORACLE_HOME
$ export _USR_ORA_SRV=alpha
$ export _USR_ORA_FLAGS=1

Переменная _USR_ORA_FLAGS=1 аналогична параметру oflags, описанному выше при создании профиля.

Запускаем скрипт:

$CRS_HOME/crs/public/act_db.pl start

Теперь на консоли будет более подробное описание запуска СУБД.

Основные проблемы могут быть связаны отсутствием необходимых каталогов (аудит, логи), необходимостью подстройки параметров памяти под новый узел (если конфигурация разная), а так же проблемой доступа к файлам БД на кластерной ФС.

После того, как удалось запустить БД, остановите её:

$CRS_HOME/crs/public/act_db.pl stop

Теперь необходимо проверить миграцию БД на другой узел:

[oracle@node1 ] $ crs_start rg1.db_alpha
[oracle@node1 ] $ crs_relocate rg1.db_alpha

Если не удалось, то останавливаем группу ресурсов и запускаем ресурсы (кроме СУБД) на другом узле:

[oracle@node1 ] $ crs_stop -f rg1
[oracle@node1 ] $ crs_start rg1.listener -c node2

Далее на втором узле нужно попробовать запустить ресурс напрямую через скрипт act_db.pl, как описано выше.

[править] Создание головного ресурса

В завершение документация предлагает создать head-ресурс, который будет зависеть от всех ресурсов. Таким образом, будет достаточно дать команду на его запуск, чтобы запустить все зависимые ресурсы.

[oracle@node1 ] $ crs_profile -create -t application \
-a $CRS_HOME/crs/public/act_resgroup.pl \
-r "rg1.listener rg1.db_alpha" \ 
-o ci=600
[oracle@node1 ] crs_register rg1.head

Таким образом, для запуска всех ресурсов (виртуальный сетевой интерфейс, прослушиватель, СУБД) достаточно дать команду:

[oracle@node1 ] $ crs_start rg1.head

Для останова всех ресурсов:

[oracle@node1 ] $ crs_stop -f rg1

Ключ -f необходим, для предварительного останова зависящих ресурсов. Иначе Clusterware выдаст ошибку.

Для перемещения ресурсов на другой узел можно указать любой ресурс — переместиться все группа:

[oracle@node1 ] $ crs_relocate -f rg1

Аналогично под защиту Clusterware можно перевести другие экземпляры СУБД. Ниже приведён пример статистики ресурсов кластера из двух узлов, который защищает две СУБД. Для каждой СУБД создан отдельный виртуальный сетевой интерфейс, отдельные прослушиватели. В нормальном режиме обе СУБД работают на одном узле.

$ crs_stat -t 
Name           Type           Target    State     Host
------------------------------------------------------------
ora....SM1.asm application    ONLINE    ONLINE    node1
ora....E1.lsnr application    ONLINE    ONLINE    node1
ora.node1.gsd  application    ONLINE    ONLINE    node1
ora.node1.ons  application    ONLINE    ONLINE    node1
ora.node1.vip  application    ONLINE    ONLINE    node1
ora....SM2.asm application    ONLINE    ONLINE    node2
ora....E2.lsnr application    ONLINE    ONLINE    node2
ora.node2.gsd  application    ONLINE    ONLINE    node2
ora.node2.ons  application    ONLINE    ONLINE    node2
ora.node2.vip  application    ONLINE    ONLINE    node2
rg1            application    ONLINE    ONLINE    node1
rg1.db_alpha   application    ONLINE    ONLINE    node1
rg1.head       application    ONLINE    ONLINE    node1
rg1.listener   application    ONLINE    ONLINE    node1
rg1.vip        application    ONLINE    ONLINE    node1
rg2            application    ONLINE    ONLINE    node1
rg2.db_beta    application    ONLINE    ONLINE    node1
rg2.head       application    ONLINE    ONLINE    node1
rg2.listener   application    ONLINE    ONLINE    node1
rg2.vip        application    ONLINE    ONLINE    node1

[править] Обновление СУБД и Clusterware

[править] Обновление Oracle Clusterware

Отключите ресурсы, Enterprise Manager, службы, экземпляры ASM

$ crs_stop -f rg1
$ srvctl stop asm -n node1
$ srvctl stop asm -n node2
$ srvctl stop nodeapps -n node1
$ srvctl stop nodeapps -n node2

На каждом узле от root запустить скрипт снятия блокировки файлов preupdate.sh, в качестве параметра crsuser указать пользователя, от которого запускаются процессы Clusterware.

# export CRS_HOME=/u01/app/crs
# $CRS_HOME/install/preupdate.sh -crshome $CRS_HOME -crsuser oracle

На одном из узлов запустите установщик патча (./Disk1/runInstaller). В окне выбора ORACLE_HOME выберите путь к Clusterware (CRS_HOME), далее выберите узлы кластера для обновления и запустите обновление файлов.

По окончанию обновления файлов, на каждом узле от root последовательно запустите скрипт

# $CRS_HOME/install/root111.sh

[править] Обновление Oracle Database

Убедитесь, что на каждом узле отключены Enterprise Manager, службы, экземпляры ASM

$ emctl stop dbconsole 
$ srvctl stop asm -n node1
$ srvctl stop asm -n node2
$ srvctl stop nodeapps -n node1
$ srvctl stop nodeapps -n node2

Отключите от root Clusterware на обоих узлах

# $CRS_HOME/bin/crsctl stop crs

На одном из узлов запустите установщик патча (./Disk1/runInstaller). В окне выбора ORACLE_HOME выберите путь к СУБД (/u01/app/oracle). Далее выберите узлы кластера для обновления СУБД и запустите обновление файлов.

По окончанию обновления запустите скрипт root.sh на каждом из узлов, он заменить файлы в /usr/local/bin.

Запустите Clusterware от root на каждом узле:

# $CRS_HOME/bin/crsctl start crs -wait

Как правило запуск идёт долго. Ускорить его можно, если дать команду на запуск на обоих узлах.

Подождите пока запустятся службы, экземпляры ASM. Статус можно узнать командой crs_stat -t.

Использовать стандартный мастер не получиться, так он посчитает, что производиться обновление базы типа RAC. Поэтому нужно обновлять схемы вручную.

Запустите группу ресурсов до прослушивателя.

$ crs_start rg1.listener

С помощью SQL*Plus подключитесь к БД и запустите её с опцией UPGRADE:

$ export ORACLE_SID=<SID БД>
$ sqlplus / as sydba
sql> STARTUP UPGRADE

Запустите скрипт сбора информации об обновлении:

sql> SPOOL upgrade_info.log
sql> @?/rdbms/admin/utlu111i.sql
… 
sql> SPOOL OFF

Выполните обновление структур таблиц:

sql> SPOOL PATCH.LOG-<SID БД>
sql> @?/rdbms/admin/catupgrd.sql
sql> SPOOL OFF

При возникновении ошибок, запустите catupgrd.sql снова.

После завершения работы скрипты остановите БД и запустите её через Clusterware

sql> shutdown transactional
$ crs_start rg1.head

Подключитесь к БД как sys и запустите перекомпиляцию всех ошибочных пакетов:

sql> @?/rdbms/admin/utlrp.sql

Узнать статус компонентов после обновления можно запросом:

sql> select comp_name, version, status from sys.dba_registry

Количество ошибочных пакетов:

sql> select count(*) from obj$ where status in (4,5,6);

Количество перекомпилированных пакетов:

sql> select count(*) from utl_recomp_compiled;

Установка патчей PSU или CPU в случае Coldfailover осуществляется стандартно по инструкции.

[править] Приложение

[править] Описание утилит Oracle Clusterware

Команда crs_stat -t -v - статистика ресурсов кластера.

Name           Type           R/RA   F/FT   Target    State     Host
rg1            application    0/1    0/0    ONLINE    ONLINE    node1
rg1.db_alpha   application    0/5    0/0    ONLINE    ONLINE    node1
rg1.head       application    0/1    0/0    ONLINE    ONLINE    node1
rg1.listener   application    0/5    0/0    ONLINE    ONLINE    node1
rg1.vip        application    0/1    0/0    ONLINE    ONLINE    node1
rg2            application    0/1    0/0    ONLINE    ONLINE    node1
rg2.db_beta    application    0/5    0/0    ONLINE    ONLINE    node1
rg2.head       application    0/1    0/0    ONLINE    ONLINE    node1
rg2.listener   application    0/5    0/0    ONLINE    ONLINE    node1
rg2.vip        application    0/1    0/0    ONLINE    ONLINE    node1

• Name — название ресурса/группы ресурсов
• Type — тип ресурса
• R/RA — RESTART – количество восстановлений ресурса (перезапусков), RESTART ATTEMPTS – общее количество допустимых перезапусков ресурса до перемещения его на другой узел
• F/FT — FAILURE — количество сбоев запуска, FAILURE_THRESHOLD допустимое количество сбоев запуска
• Target — требуемое состояние ресурса (определяется ранее отданной командой crs_start для ONLINE или crs_stop для OFFLINE)
• State — текущее состояние ресурса (определяется произошедшими сбоями в работе)
• Host — название узла, на котором запущен ресурс.

При сбое в работе одного из ресурсов, Oracle Clusterware предпринимает попытку его перезапуска. Количество перезапусков отражает параметр RESTART в столбце R/RA. В случае если количество перезапусков ресурса превысило значение, заданное в соответствующем параметре RESTART ATTEMPTS, производится перемещение группы ресурсов на резервный узел.

• rg1 — группа ресурсов базы alpha, rg2 — группа ресурсов базы beta.
• rg1.db_alpha — ресурс, запускающий базу данных alpha
• rg2.db_beta — ресурс, запускающий базу данных beta
• rg1.head, rg2.head — головной ресурс, не запускает приложения и не обслуживает запросы, необходим для указания зависимостей для запуска остальных ресурсов
• rg1.listener, rg2.listener — ресурс, запускающий процесс прослушивателя (listener), который обслуживает подключения к базе на виртуальном сетевом интерфейсе
• rg1.vip, rg2.vip – ресурс, запускающий виртуальный сетевой интерфейс для обслуживание запросов на подключение к базе.

Команда crs_start — запуск ресурса, а так же всех зависящих от него ресурсов. Пример: crs_start rg1.head — запустит последовательно ресурсы rg1, rg1.vip, rg1.listener, rg1.db_alpha, rg1.head. Команда crs_stop — останов ресурса. Без дополнительных ключей данная команда может остановить только ресурсы, от которых не зависят другие ресурсы. Для последовательной остановки зависимых ресурсов необходимо указать ключ –f.

Пример:

crs_stop –f rg1 — последовательно остановит ресурсы rg1.head, rg1.listener, rg1.db_alpha, rg1.vip, rg1

В случае, если запущены зависимые ресурсы команда останова crs_stop rg1 выдаст ошибку CRS-1016: Resources depending on 'rg1' are running.

Команда crs_relocate — перемещение ресурсов кластера между узлами. Данная команда, предназначена для перемещения группы ресурсов с одного узла на другой. Ключ –f указывает принудительное перемещение указанного ресурса и всех зависимых от него ресурсов. Без указания данного ключа переместить можно только ресурсы, у которых нет зависимостей.

Ключ –с <имя_узла> — указывает, что необходимо переместить ресурсы на указанный узел <имя_узла>. Без указания данного ключа, производится перемещение на резервный узел, который указывается при регистрации ресурсов. Данная команда сначала останавливает все ресурсы группы, а после запускает на другом узле. Во время перемещения ресурсов база данных на запросы отвечать не будет.

Пример перемещения группы ресурсов.

[oracle@node1 node1]$ crs_relocate -f rg1
Attempting to stop `rg1.head` on member `node1`
Stop of `rg1.head` on member `node1` succeeded
Attempting to stop `rg1.listener` on member `node1`
Attempting to stop `rg1.db_alpha` on member `node1`
Stop of `rg1.db_alpha` on member `node1` succeeded.
Stop of `rg1.listener` on member `node1` succeeded.
Attempting to stop `rg1.vip` on member `node1`
Stop of `rg1.vip` on member `node1` succeeded.
Attempting to stop `rg1` on member `node1`
Stop of `rg1` on member `node1` succeeded.
Attempting to start `rg1` on member `node2`
Start of `rg1` on member `node2` succeeded.
Attempting to start `rg1.vip` on member `node2`
Start of `rg1.vip` on member `node2` succeeded.
Attempting to start `rg1.listener` on member `node2`
Start of `rg1.listener` on member `node2` succeeded.
Attempting to start `rg1.db_alpha` on member `node2`
Start of `rg1.db_alpha` on member `node2` succeeded.
Attempting to start `rg1.head` on member `node2`
Start of `rg1.head` on member `node2` succeeded.

Пример перемещения группы ресурсов с основного узла node1.domain.ru, на резервный узел node2.domain.ru.

[oracle@node1 node1]$ crs_relocate -f rg1 -с node2
Attempting to stop `rg1.head` on member `node2`
......
Start of `rg1.head` on member `node2` succeeded.

Если Oracle Clusterware не сможет остановить приложение или ресурс из-за внутренней ошибки самого приложения, то его состояние отметится как UNKNOWN (см. crs_stat). Невозможно использовать crs_relocate при данном состояние ресурса. Для того, чтобы вручную переместить сбойный ресурс необходимо перевести его из состояния UNKNOWN в состояние ONLINE командой crs_start <имя_ресурса>, а после повторно попытаться переместить его на резервный узел командой crs_relocate -f <имя_ресурса>. Если Oracle Clusterware повторно не сможет переместить ресурс необходимо проверить активность приложения ресурса.

[править] Утилиты для работы с кластером

Выше приведены команды с помощью которых можно управлять созданными ресурсами.

Ниже приводятся дополнительные утилиты, которые могут пригодиться в работе с кластером:

• srvctl – Server control, управление ресурсами кластера (приложение Clusterware, прослушиватель, экземпляры ASM). С помощью только это утилиты можно управлять ресурсами, начинающимися с ora в выводе crs_stat
• crsctl – Cluster Ready Services Control, запуск/останов, включение/выключение Clusterware
• oifcfg – Oracle Interface Configuration Tool, настройка сетевых интерфейсов
• olsnodes – список узлов кластера и их номера
• ocrconfig, ocrcheck, ocrdump – утилиты работы с OCR
• cluvfy – Cluster Verification Utility, проверка доступности кластерных дисков и требований к кластеру
• evmwatch -A – просмотр событий EVM
• emctl, emca – управление Enterprise manager

[править] Смена сетевых адресов и интерфейсов

Возможно после установки и настройки кластера потребуется изменить сетевые адреса или названия сетевых интерфейсов. Желательно в настройках прослушивателя listener.ora и в файле TNS имён tnsnames.ora использовать доменные имена, указанные в /etc/hosts, а не числовые ip адреса. Это в дальнейшем позволит экономить время при необходимости смены адресов.

Это можно сделать следующим образом.

Для изменения адреса сетевых интерфейсов созданных нами ресурсов нужно:

1. Остановить ресурсы
2. Отменить регистрацию в OCR (от root, так он назначен владельцем сетевого интерфейса)
3. Создать новый профиль rg1.vip (потребуется ключ -f, чтобы переписать профиль)
4. Зарегистрировать ресурсы заново

$ crs_stop -f rg1.vip
$ crs_unregister rg1.head
$ crs_unregister rg1.db_alpha
$ crs_unregister rg1.listener
# /u01/app/crs/bin/crs_unregister rg1.vip
$ crs_profile -create rg1.vip -t application -r rg1 -a $CRS_HOME/bin/usrvip -o oi=<сет. инт>,ov=<новый ip>,on=255.255.0.0 -f
# /u01/app/crs/bin/crs_setperm rg1.vip -o root
# /u01/app/crs/bin/crs_setperm rg1.vip -u user:oracle:r-x
$ crs_register rg1.listener
$ crs_register rg1.db_alpha
$ crs_register rg1.head

Можно так же не создавать профиль rg1.vip заново, а отредактировать существующий $CRS_HOME/crs/public/rg1.vip.cap текстовым редактором и зарегистрировать его заново.

[править] Смена адреса виртуального интерфейса

Для изменения виртуальных сетевых адресов служб Clusterware нужно выполнить следующее:

• Определить текущую конфигурацию

$ srvctl config nodeapps -n node1 -a
$ srvctl config nodeapps -n node2 -a

• Остановить ресурсы, экземпляры ASM, службы Clusterware

$ crs_stop rg1 -f
$ srvctl stop asm -n node1
$ srvctl stop asm -n node2
$ srvctl stop nodeapps -n node1
$ srvctl stop nodeapps -n node2

• Проверить /sbin/ip addr, чтобы виртуального адреса не было.
• Внести новый адрес в /etc/hosts для node{1,2}-vip на обоих узлах. Если в listener.ora, tnsnames.ora были указаны сетевые адреса, а не доменные имена, то заменить их на новые.
• Изменить адрес:

# /u01/app/crs/bin/srvctl modify nodeapps -n node{1,2} -A <новый IP>/<сетевая маска>/<интерфейс>
# /u01/app/crs/bin/srvctl modify nodeapps -n node1 -A 172.16.10.1/255.255.0.0/eth2
# /u01/app/crs/bin/srvctl modify nodeapps -n node2 -A 172.16.10.2/255.255.0.0/eth2

• Проверить конфигурацию

$ srvctl config nodeapps -n node1 -a
$ srvctl config nodeapps -n node2 -a

• Запустить ресурсы:

$ srvctl start nodeapps -n node1
$ srvctl start nodeapps -n node2
$ srvctl start asm -n node1
$ srvctl start asm -n node2
$ crs_start rg1.head

[править] Смена интерфейсов

• Определить текущую конфигурацию

$ oifcfg getif
eth2  172.16.0.0  global  public
eth1  10.8.72.0  global  cluster_interconnect

• Остановить СУБД, экземпляры ASM, службы Clusterware
• Удалить старый интерфейс:

$ oifcfg delif  -global eth2

• Внести изменения в /etc/host, listener.ora, tnsnames.ora
• Добавить новый интерфейс (адрес для нового интерфейса должен быть настроен в ОС)

$ oifcfg setif -global eth3/172.16.0.0/255.255.0.0:public

• Проверить конфигурацию

$ oifcfg getif
$ oifcfg listif

• Перерегистрировать rg.vip, если необходимо
• Запустить службы и ресурсы

[править] Добавление/удаление узлов из кластера

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

[править] Расширение Clusterware

• Во-первых, проверьте, что на новом узле настроен вход по ключам SSH как описано выше, а так же что шлюз по-умолчанию совпадает с тем, что прописаны на других узлах. Проверьте, что правила iptables разрешают любые соединения на интерфейсе, выбранном как cluster interconnect.
• Сделайте резервную копию OCR утилитами ocrdump или dd
• На существующем узле кластера запустите команду

$ $CRS_HOME/oui/bin/addNode.sh

После завершения работы мастера, выполните скрипты (root.sh и rootaddnode.sh).

• На вновь добавленном узле перезапустите nodeapps (через srvctl), иначе может не запуститься службы ONS.
• Запустите RACGONS

$ $CRS_HOME/bin/racgons add_config <имя нового узла>:<порт>

где <порт> как правило 6251.

Порт можно узнать если снять дамп OCR командой ocrdump и посмотреть секцию [DATABASE.ONS_HOSTS.<имя узла>.PORT]

• Выполните проверку кластера:

$ cluvfy comp clumgr -n all -verbose
$ cluvfy comp clu -verbose
$ cluvfy stage -post crsinst -n all -verbose

[править] Расширение СУБД

• На существующем узле кластера запустите

$ $ORACLE_HOME/oui/bin/addNode.sh

• На существующем узле запустите dbca, выберите Real Application Cluster, далее Configure ASM. Мастер расширит ASM на новый узел.
• На добавленном узле отредактируйте listener.ora и tnsnames.ora, чтобы в них было описание БД с других узлов.
• Создайте службу прослушивателя для нового узла:

$ srvctl add listener -n <имя нового узла> -o $ORACLE_HOME
$ srvctl start listener -n <имя нового узла>

• На новом узле добавьте в /etc/oratab информацию о БД с других узлов.
• На новом узле создайте каталог аудита для БД

Если Clusterware расширилось корректно, а СУБД не может расширить кластер, то скопируйте olsnodes из $CRS_HOME в $ORACLE_HOME.

[править] Удаление узла из кластера

• Сделайте резервную копию OCR (ocrdump)
• Удалите ASM и прослушиватель с освобождаемого узла

$ srvctl stop asm -n <имя удаляемого узла>
$ srvctl remove asm -n <имя удаляемого узла>
$ srvctl stop listener -n <имя удаляемого узла>
$ srvctl remove listener -n <имя удаляемого узла>

• На узле, который останется в кластере запустите:

$ racgons remove_config <имя удаляемого узла>:<порт> 

где <порт> можно узнать просмотрев секцию дампа ocrdump [DATABASE.ONS_HOSTS.<имя удаляемого узла>.PORT]

• На удаляемом узле запустите от root:

# /u01/app/crs/install/rootdelete.sh

• На узле, который останется в кластере запустите от root:

# /u01/app/crs/install/rootdeletenode.sh <имя удаляемого узла>,<номер удаляемого узла>

где <номер удаляемого узла> - можно узнать командой olsnodes -n

• На удаляемом узле перейдите в $CRS_HOME/oui/bin и запустите

$ ./runInstaller -updateNodeList ORACLE_HOME=$CRS_HOME "CLUSTER_NODES={<имя удаляемого узла>}" CRS=TRUE -local

• На удаляемом узле удалите Clusterware:

$ $CRS_HOME/oui/bin/runInstaller -deinstall "REMOVE_HOMES={$CRS_HOME}"

• На узле, который останется в кластере обновите список узлов кластера:

$ $CRS_HOME/oui/bin/runInstaller -updateNodeList ORACLE_HOME=$CRS_HOME "CLUSTER_NODES={<список оставшихся узлов>}" CRS=TRUE

где <список оставшихся узлов> – перечисленные через запятую имена узлов кластера (из olsnodes), например node1,node3.

• На узле, который останется в кластере обновите список узлов СУБД:

$ $ORACLE_HOME/oui/bin/runInstaller -updateNodeList ORACLE_HOME=$ORACLE_HOME "CLUSTER_NODES={<список оставшихся узлов>}"

• На удаляемом узле удалите каталоги с $CRS_HOME (/u01/app/crs) и $ORACLE_HOME (/u01/app/oracle).
• Отключите службу Clusterware

# ckhconfig init.crs off

• Удалите скрипты запуска Clusterware из /etc/initd: init.cssd, init.crs, init.crsd, init.evmd
• В конце файла /etc/inittab удалите строки

h1:35:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1 </dev/null
h2:35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1 </dev/null
h3:35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1 </dev/null

или восстановите оригинал /etc/inittab.no_crs.

[править] Работа с ASM (asmcmd, sqlplus, rman)

Для работы ASM размер Shared memory (/dev/shm) должен быть более 256 МБ.

Файл инициализации располагается в каталоге $ORACLE_BASE/admin/+ASM/pfile/init.ora. Но так же, на этот файл есть символическая ссылка в каталоге $ORACLE_HOME/dbs, которая имеет вид init+ASM<N>.ora, где N - номер узла кластера.

Параметры инициализации:

• asm_diskgroups – имена дисковых групп, монтируемых при сатрте
• asm_diskstring – шаблон для поиска дисков asm
• asm_power_limit – интенсивность при ребалансировки данных от 0 до 11
• diagnostic_dest – диагностический каталог

ASM использует Oracle Clusterware (CSS демон) для работы с СУБД.

Подключиться к экземпляру ASM можно через SQL*Plus с привилегией sysasm:

$ export ORACLE_SID=+ASM1
$ sqlplus / as sysasm

Запуск: STARTUP [FORCE , MOUNT|OPEN, NOMOUNT, RESTRICT]

Останов: SHUTDOWN [NORMAL, IMMEDIATE, ABORT]

[править] Работа с дисковыми группами

Информацию о подключенных группах и используемых дисках можно узнать из запроса:

set linesize 120
col NAME form a10
col LABEL form a10
col PATH form a15
col FAILGROUP form a10
select GROUP_NUMBER,DISK_NUMBER,MODE_STATUS,STATE,LABEL,PATH,NAME,FAILGROUP,HEADER_STATUS from v$asm_disk;

GROUP_NUMBER DISK_NUMBER MODE_ST STATE    LABEL      PATH            NAME       FAILGROUP  HEADER_STATU
------------ ----------- ------- -------- ---------- --------------- ---------- ---------- ------------
           1           0 ONLINE  NORMAL   ORADATA    ORCL:ORADATA    ORADATA    ORADATA    MEMBER 

Используемое место в группе:

select GROUP_NUMBER,NAME,SECTOR_SIZE,STATE,TOTAL_MB,FREE_MB from V$ASM_DISKGROUP;

Создание дисковой группы

Если вы хотите использовать дублирование данных средствами ASM, то при создании группы указываете уровень избыточности NORMAL (двойное дублирование) или HIGH (тройное дублирование). Если же у вас используется система хранения с дублированием (raid), то указывайте тип избыточности EXTERNAL.

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

Когда ASM распределяет данные при нормальной избыточности, создаются основная и вторичная копия. Для хранения вторичной копии, ASM выбирает диск, который принадлежит другой группе сбоя (failgroup), отличной от той, где находиться основная копия. Failgroup используются для размещения копий данных. Одновременный сбой всех дисков в одной группе сбоя не приводит к потере данных.

Дисковую группу можно создать в sqlplus следующим образом:

create diskgroup DGNAME1 normal redundancy
       failgroup controller1 disk 'ORCL:asmdisk1' name DISK1,
                                  'ORCL:asmdisk2' name DISK2
       failgroup controller2 disk 'ORCL:asmdisk3' name DISK3,
                                  'ORCL:asmdisk4' name DISK4

Данная команда создаст дисковую группу DGNAME1 из четырёх дисков, имеющих метки ASM как asmdisk1, asmdisk2 ...

В примере используется библиотека oracleadmlib, поэтому пути указаны как 'ORCL:asmdisk...'. Если библиотека не используется, то необходимо указывать путь вида /dev/dm-7, /dev/sdf1 и т.п.

Два диска образуют группу сбоя. Аналог RAID10.

Создание дисковой группы с внешней избыточностью:

create diskgroup DGDATA external redundancy disk 'ORCL:ASMDISK1' name DISK1;

Здесь используется путь к дискам, через интерфейс библиотеки oracleasmlib (ORCL:<метка>). Если вы не используете данную библиотеку, то указывайте стандартный путь (/dev/sdb1, /dev/mapper/datadisk2 и т.п.).

Добавление диска в существующую группу:

alter diskgroup DGDATA add disk
'ORCL:ASMDISK5' name DISK5,
'ORCL:ASMDISK7' name DISK7;

Удаление диска из группы:

alter diskgroup DGDATA drop disk DISK5;

Монтирование дисковых групп:

alter diskgroup DGDATA mount [force]; 
alter diskgroup all dismount;

Проверка данных :

Смотрите так же параметр интенсивности балансировки данных asm_power_limit (англ.)

alter diskgroup DGNAME1 check all;

Уничтожение группы:

drop diskgroup DGNAME1 [including contents | force]

[править] Утилита ASMCMD

С помощью утилиты asmcmd можно просмотреть содержимое дисковых групп, свободное место и многое другое.

$ export ORACLE_SID=+ASM1
$ asmcmd -p

Скопировать файл на дисковую группу у вас с помощью данный утилиты не получится. Для копирования файлов данных нужно воспользоваться RMAN.

[править] Копирование табличного пространства на ASM с помощью RMAN

Скопировать табличное пространство со стандартной ФС на ASM можно следующим образом:

$ export ORACLE_SID=<SID БД>
$ rman target /
rman> sql "alter tablespace TEST1 offline"
rman> backup as copy tablespace TEST1 format '+DG_ASM';
rman> switch tablespace TEST1 to copy;
rman> sql "alter tablespace TEST1 online";

[править] Перенос БД на дисковую группу ASM

Подробно перенос описан в документе Performing ASM Data Migration (англ.). Примеры команд можно посмотреть в нём.

Если кратко перенос осуществляется следующим образом:

• С помощью RMAN сделайте копию БД на дисковую группу ASM (BACKUP AS COPY DATABASE), так же резервную копию spfile.
• Если планируется перенести spfile на ASM, то восстановите его с помощью RMAN или через команду CREATE SPFILE.
• Измените значение параметров DB_CREATE_FILE_DEST, DB_RECOVERY_FILE_DEST, CONTROL_FILES, чтобы они указывали на новую дисковую группу.
• Восстановите управляющие файлы с помощью RMAN на новое место.
• Переключите в БД файлы с данными на те, что были созданы как копии в RMAN (SWITCH DATABASE TO COPY;)
• Так как RMAN не делает копий временного табличного пространства, пересоздайте его вручную. Добавьте в TEMP файл, расположив его на новом месте, и удалите старый.
• Добавьте в группы Redo log файлы, расположив их на новой дисковой группе ASM, а после удалите старые.

[править] Перенос кластера на другую систему хранения

Основные команды по переносу реестра кластера и диска голосования описаны в документе - Oracle® Clusterware Administration and Deployment Guide (англ.)

Само переназначение не требует остановки кластера, однако для удаления дисков из операционной системы, возможно потребуется остановить службы CRS.

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

[править] Перенос реестра кластера

Перенос OCR не требует остановки служб кластера.

Путь, где будет осуществлять поиск реестра кластера можно отредактировать в файле /etc/oracle/ocr.loc на каждом узле. Но нужно чтобы реестр был сформирован и записан на диск. Поэтому лучше использовать специальные команды для переноса.

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

Запрашиваем информацию о текущем местоположении реестра кластера:

[root@node1 ~]# /u01/app/crs/bin/ocrcheck
Status of Oracle Cluster Registry is as follows :
        Version                  :          2
        Total space (kbytes)     :     306968
        Used space (kbytes)      :       3840
        Available space (kbytes) :     303128
        ID                       : 1053649581
        Device/File Name         : /dev/oracle/ocr
                                   Device/File integrity check succeeded
                                   Device/File not configured
        Cluster registry integrity check succeeded
        Logical corruption check succeeded

Добавляем новый диск под реестр кластера как зеркало существующего:

[root@node1 ~]# /u01/app/crs/bin/ocrconfig -replace ocrmirror /dev/oracle/ocr2

Удаляем старый диск:

[root@node1 ~]# /u01/app/crs/bin/ocrconfig -replace ocr

Проверяем текущую конфигурацию - теперь используется новый диск:

[root@node1 ~]# /u01/app/crs/bin/ocrcheck
Status of Oracle Cluster Registry is as follows :
        Version                  :          2
        Total space (kbytes)     :     306968
        Used space (kbytes)      :       3840
        Available space (kbytes) :     303128
        ID                       : 1053649581
        Device/File Name         : /dev/oracle/ocr2
                                   Device/File integrity check succeeded
                                   Device/File not configured
        Cluster registry integrity check succeeded
        Logical corruption check succeeded

[править] Перенос voting disk

Перенос voting disk не требует остановки служб кластера.

Запрашиваем информацию о текущей конфигурации:

[root@node1 ~]# /u01/app/crs/bin/crsctl query css votedisk
 0.     0    /dev/oracle/vdsk
Located 1 voting disk(s).

Добавляем новый диск:

[root@node1 ~]# /u01/app/crs/bin/crsctl add css votedisk /dev/oracle/vdsk2
Now formatting voting disk: /dev/oracle/vdsk2.
Successful addition of voting disk /dev/oracle/vdsk2.

Удаляем старый диск:

[root@node1 ~]# /u01/app/crs/bin/crsctl delete css votedisk /dev/oracle/vdsk
Successful deletion of voting disk /dev/oracle/vdsk

[править] Добавление/удаление дисков ASM

При размещении файлов СУБД Oracle на дисковой группе ASM, можно перенести все данные не останавливая работу СУБД.

Для это необходимо:

• добавить новый диск(-и) достаточного объёма в существующую дисковую группу
• дождаться когда ASM завершит балансировку данных между дисками
• удалить старый диск из ASM группы
• дождаться когда ASM перенесёт оставшиеся данные на новый диск

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

Создаём таблицу разделов на новом диске (возможно потом потребуется запустить partprobe или start_udev, чтобы перечитать таблицу разделов на диске)

[root@node2 ~]# fdisk /dev/mapper/asmdata1

Записываем метку ASM и пересканируем диски

[root@node2 ~]# oracleasm createdisk ASMDATA1 /dev/mpath/asmdata1p1
[root@node2 ~]# oracleasm scandisks

Диск /dev/mpath/asmdata1p1 у меня - это символическая ссылка на /dev/dm-7, а /dev/mpath/asmdata2p1 на /dev/dm-6.

От пользователя oracle, просмотрим видимые экземпляром ASM диски, обратившись к таблице v$asm_disk

[root@node2 ~]# su - oracle
[oracle@node2 ~]$ export ORACLE_SID=+ASM2
[oracle@node2 ~]$ sqlplus / as sysasm

SQL>set linesize 120
col NAME form a10
col LABEL form a10
col PATH form a15
col FAILGROUP form a10
select GROUP_NUMBER,DISK_NUMBER,MODE_STATUS,STATE,LABEL,PATH,NAME,FAILGROUP,HEADER_STATUS from v$asm_disk;
GROUP_NUMBER DISK_NUMBER MODE_ST STATE    LABEL      PATH            NAME       FAILGROUP    HEADER_STATU
------------ ----------- ------- -------- ---------- --------------- ---------- ----------   ------------
          0           0 ONLINE  NORMAL              /dev/dm-5                               FOREIGN
          0           1 ONLINE  NORMAL              /dev/dm-7                               PROVISIONED
          0           2 ONLINE  NORMAL              /dev/dm-4                               FOREIGN
          1           1 ONLINE  NORMAL              /dev/dm-6       DG_ASM_0001 DG_ASM_0001 MEMBER

SQL> select GROUP_NUMBER,NAME,SECTOR_SIZE,STATE,TOTAL_MB,FREE_MB from V$ASM_DISKGROUP;
GROUP_NUMBER NAME       SECTOR_SIZE STATE         TOTAL_MB    FREE_MB
------------ ---------- ----------- ----------- ---------- ----------
           1 DG_ASM             512 MOUNTED           2039        988

Добавим новый диск в дисковую группу.

SQL> alter diskgroup DG_ASM add disk '/dev/dm-7';
Diskgroup altered.

Подождём когда завершиться перенос части данных на новый диск (балансировка). Процесс можно посмотреть в таблице V$ASM_OPERATION.

SQL> col OPERATION form a10
SQL> select OPERATION,STATE,POWER,ACTUAL,SOFAR,EST_WORK,EST_RATE,EST_MINUTES from V$ASM_OPERATION;
OPERATION  STAT      POWER     ACTUAL      SOFAR   EST_WORK   EST_RATE EST_MINUTES
---------- ---- ---------- ---------- ---------- ---------- ---------- -----------
REBAL      RUN           1          1        163        501        571           0

Теперь дисковая группа состоит из двух дисков:

GROUP_NUMBER DISK_NUMBER MODE_ST STATE    LABEL      PATH            NAME         FAILGROUP    HEADER_STATU
------------ ----------- ------- -------- ---------- --------------- ------------ ------------ ------------
          0           0 ONLINE  NORMAL              /dev/dm-5                                 FOREIGN
          0           2 ONLINE  NORMAL              /dev/dm-4                                 FOREIGN
          1           1 ONLINE  NORMAL              /dev/dm-6       DG_ASM_0001  DG_ASM_0001  MEMBER
          1           0 ONLINE  NORMAL              /dev/dm-7       DG_ASM_0000  DG_ASM_0000  MEMBER
GROUP_NUMBER NAME         SECTOR_SIZE STATE         TOTAL_MB    FREE_MB
------------ ------------ ----------- ----------- ---------- ----------
          1 DG_ASM               512 MOUNTED           3890       2837

Удаляем старый диск и ждём завершения балансировки (узнать можно по таблице V$ASM_OPERATION):

SQL> alter diskgroup DG_ASM drop disk 'DG_ASM_0001';
Diskgroup altered.

Теперь в группе только один новый диск dm-7.

GROUP_NUMBER DISK_NUMBER MODE_ST STATE    LABEL      PATH            NAME         FAILGROUP    HEADER_STATU
------------ ----------- ------- -------- ---------- --------------- ------------ ------------ ------------
          0           0 ONLINE  NORMAL              /dev/dm-5                                 FOREIGN
          0           1 ONLINE  NORMAL              /dev/dm-6                                 FORMER
          0           2 ONLINE  NORMAL              /dev/dm-4                                 FOREIGN
          1           0 ONLINE  NORMAL              /dev/dm-7       DG_ASM_0000  DG_ASM_0000  MEMBER

GROUP_NUMBER NAME         SECTOR_SIZE STATE         TOTAL_MB    FREE_MB
------------ ------------ ----------- ----------- ---------- ----------
          1 DG_ASM               512 MOUNTED           1851        800

Удаляем метку со старого диска (в примере /dev/mpath/asmdata2p1 это ссылка на dm-6, см. ls -l /dev/mpath/)

[root@node2 ~]# oracleasm deletedisk /dev/mpath/asmdata2p1
Clearing disk header: done
Dropping disk: done

Удаляем multipath устройство и составляющие диски из операционный системы.

[править] Удаление устройств multipath и составляющих дисков из операционной системы

Если у вас есть возможность выключить сервер, то можно просто выключить его и удалить подключенные с СХД диски (по iSCSI или Fibre Channel). Если такой возможности нет, то можно удалить диски без отключения сервера.

В ходе тестов у меня несколько раз было, что если отключить диски сразу, то Oracle Linux не корректно обрабатывает пропажу дисков и после долго выполняет перезагрузку или выключение. Несколько раз, после такого отсоединения, приходилось принудительно перезагружать тестовый сервер. Чтобы избежать возможных проблем, лучше корректно выполнить удаления дисков из операционной системы.

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

[root@node1 ~]# /u01/app/crs/bin/crsctl stop crs -wait

Рассмотрим пример удаления voting disk. Удаление OCR и дисков ASM производиться аналогично, меняется только имя multipath устройства и составных дисков.

Переходим в интерактивный режим работы со службой multipath и удаляем многопутевое устройство:

[root@node1 ~]# multipathd -k
multipathd> show topology
.........
vdsk (1IET_00010004) dm-1 LocalDat,VIRTUAL-DISK
size=300M features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=1 status=active
| `- 4:0:0:4 sdj 8:144 active ready running
`-+- policy='round-robin 0' prio=1 status=enabled
  `- 3:0:0:4 sdi 8:128 active ready running
..............
multipathd> del multipath vdsk
ok

В выводе show topology были приведены имена устройств (sdj и sdi), из которых multipath устройство было собрано, удаляем их из ОС.

[root@node1 ~]# echo 1 > /sys/block/sdj/device/delete
[root@node1 ~]# echo 1 > /sys/block/sdi/device/delete

В журнале /var/log/messages должны появятся записи, подобные приведённым:

multipathd: vdsk: remove map (operator)
multipathd: vdsk: devmap removed
multipathd: vdsk: stop event checker thread (1081293120)
multipathd: vdsk: event checker exit
multipathd: dm-1: remove map (uevent)
multipathd: dm-1: devmap not registered, can't remove
multipathd: sdj: remove path (uevent)
kernel: sd 4:0:0:4: [sdj] Synchronizing SCSI cache
multipathd: sdi: remove path (uevent)
kernel: sd 3:0:0:4: [sdi] Synchronizing SCSI cache

Теперь в СХД можно отключить диски от сервера.

[править] Примечания

1. ↑ Automatic Memory Management (AMM) in Oracle Database 11g Release 1 - http://www.oracle-base.com/articles/11g/automatic-memory-management-11gr1.php

Инфраструктура Oracle ®
Операционные системы	Oracle Linux  • Solaris  • OpenSolaris
Виртуализация	Oracle VM  • Xen  • VirtualBox
Файловые системы	ZFS  • OCFS2  • Lustre
Системы управления базами данных	Oracle  • MySQL  • InnoDB  • Berkeley DB
Кластеризация	Oracle Coldfailover / Oracle Coldfailover 11.2
Серверы приложений	Oracle IRM Server • WebLogic  • JBoss (принадлежит Red Hat)