Oracle Coldfailover
Материал из 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
[править] Введение
В данной статье будет рассмотрен метод, позволяющий восстановить обслуживание запросов к СУБД 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 потребуется установить пакеты:
- oracleasm-support – The Oracle Automatic Storage Management support programs – программы для создания, настройки и удаления файловой системы ASM на разделах (есть в открытом репозитарии)
- Модули ядра файловой системы включены в ядро UEK2. Если используется ядро 2.6.18, то необходимо установить модули ядра oracleasm-2.6.18.
- 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».
[править]
[править]
Для работы СУБД необходимо, чтобы размер используемой СУБД памяти 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:
- В СУБД отключить AMM , установив memory_target=0, посмотреть размер sga (show parameter sga_max_size)
- Остановить СУБД.
- Рассчитать требуемое количество страниц памяти.
- Зарезервировать полученное значение: # sysctl vm.nr_hugepages=<nnn>
- Запустить СУБД и проверить в /proc/meminfo, что hugepages используются.
- Если всё успешно, то прописать в параметрах загрузчика рассчитанное значение 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.
- Выбираем тип установки Enterprise или Standard.
- Задаём пути: Oracle Base: /u01/app/oracle, тогда Oracle home (OraDb11g_home1) примет значение: /u01/app/oracle/product/11.1.0/db_1
- Запуститься проверка параметров ОС аналогичная, что и при установке Clusterware.
- Далее выбор конфигурации: создать БД, настроить ASM, только установить ПО. Здесь нужно выбрать «Install Software Only», остальные шаги по настройке БД сделаем вручную.
- Задание соответствия групп ОС и БД: OSDBA, OSOPER, OSASM. Подробнее см. «Пользователи и группы»
- Вывод итоговой сводки и установка на узлы.
- Запуск скриптов /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. Отвечаем на вопросы мастера.
- Выбираем тип БД — Oracle single instance database. Установка файлов СУБД на кластер, необходима для работы ASM в кластерном режиме. Сама же БД должна работать только на одном узле. Иначе вам будет необходима лицензия для каждого узла + лицензия на RAC.
- Тип операции — Create DB.
- Шаблон — Custom Database
- Задаём global database name, SID базы данных.
- Если нужен Enterprise manager, то оставляем «Configure Enterprise Manager»
- Задаём пароли пользователей SYS и SYSTEM (если указано создание Enterprise Manager, то и для DBSNMP и др.)
- Если настроена ASM, то в качестве хранилища, где будут размещаться файлы указываем Automatic Storage Managment (ASM). Иначе указываем File system и выбираем другую кластерную ФС. Далее будет опиcываться использование ASM.
- Выбираем дисковую группу ASM в которой будут храниться файлы БД.
- Выбираем использовать или нет Oracle managed files (имена и пути файлов будут автоматически создаваться СУБД на основе их типа, параметр db_create_file_dest)
- Настраиваем Flash recovery area и архивацию.
- Выбираем необходимые компоненты БД.
- Выбираем тип управления памятью, размеры областей SGA, PGA. Если планируется использовать hugepages (см. выше), то нужно выбрать Custom и Automatic Shared Memory Managment или Manual Shared Memory Menagment. Определение размера SGA и hugepages описано выше в разделе «Настройка shared memory и hugepages».
- На этом же окне выбираем кодировку, размер блока, максимальное количество процессов, подключенных к БД.
- Выбираем использовать или нет умолчальные настройки безопасности 11 версии (срок действия пароля 180 дней и т. д.)
- Разрешаем или нет запуск автоматических задач.
- Настраиваем табличные пространства и остальные файлы БД.
- Запускаем процесс создания БД. Желательно сгенерировать скрипты создания — они могут пригодиться при повтороном создании БД.
[править] Задание контроля за работой СУБД
После того как БД создана, необходимо перевести её под контроль 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 адреса. Это в дальнейшем позволит экономить время при необходимости смены адресов.
Это можно сделать следующим образом.
Для изменения адреса сетевых интерфейсов созданных нами ресурсов нужно:
- Остановить ресурсы
- Отменить регистрацию в OCR (от root, так он назначен владельцем сетевого интерфейса)
- Создать новый профиль rg1.vip (потребуется ключ -f, чтобы переписать профиль)
- Зарегистрировать ресурсы заново
$ 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
Теперь в СХД можно отключить диски от сервера.
[править] Примечания
- ↑ 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) |