Oracle RAC 11gR2 на RHEL 6: разворачиваем двухузловой кластер для продакшн-БД

Oracle RAC на Linux - это то, что в документации выглядит как полтора шага, а на практике разворачивается в несколько дней плотной работы с логами, кольцевыми зависимостями и вопросами «почему это снова не завелось». На прошлой неделе мы закрыли очередной такой проект: двухузловой кластер для производственной базы клиента, работающего в сфере дистрибуции. Пишем пока помним.

Зачем RAC и зачем Linux

Клиент исторически сидел на Oracle SE на одном сервере под Windows Server 2008 R2. База росла, нагрузка в пиковые часы (утреннее открытие складов, конец дня) давала заметные просадки, и главное - любое плановое обслуживание означало простой. Переговоры о переходе на что-то кластерное шли около полугода.

Oracle RAC - очевидный выбор, когда уже вложились в Oracle и не готовы к миграции. Linux как платформа под RAC - это отдельный разговор с лицензионщиками Oracle, но в итоге RHEL 6 дешевле Windows в пересчёте на два узла, а совместимость с Oracle Clusterware у него хорошая.

Взяли два физических сервера (не виртуалки - для продакшн RAC мы пока предпочитаем металл), общее дисковое хранилище через FC, и поехали.

Для поддержки таких задач у нас есть практика BI и DWH - Oracle в варианте RAC там встречается регулярно.

Чеклист до установки - то, что нельзя пропустить

Половина проблем при установке RAC происходит не от самого Oracle, а от того, что окружение не было подготовлено правильно. Наш рабочий список до запуска runInstaller:

Сеть - три отдельных сегмента. Публичная сеть (клиентские подключения), приватная interconnect (только между узлами, желательно выделенный свитч), и SCAN VIP для подключений через Single Client Access Name. Смешивать interconnect с публичной сетью - это потенциальные проблемы с производительностью кластерного кеша. У нас была отдельная пара гигабитных карт под interconnect с прямым кабелем между узлами.

Имена хостов и /etc/hosts. Oracle Clusterware очень чувствителен к DNS и резолвингу. Мы прописали все VIP-адреса и SCAN в /etc/hosts, убедились что прямое и обратное разрешение работает на обоих узлах без задержек. Проблема с DNS в момент старта Clusterware - это неочевидный сбой, который долго ищется.

Параметры ядра и лимиты. В /etc/sysctl.conf и /etc/security/limits.conf нужны конкретные значения под Oracle - они задокументированы, но их много. Мы держим готовый конфиг, адаптируем под каждый проект.

Синхронизация времени. NTP, одинаковый на обоих узлах, с маленьким drift. Clusterware при расхождении часов между узлами может принять неверное решение при голосовании.

ASM диски. Перед установкой Grid Infrastructure разметили диски под ASM через udev - правила, которые дают одинаковые имена устройств на обоих узлах. Это важно: Oracle ASM ожидает видеть одни и те же пути на всех узлах кластера.

Порядок установки: Grid перед Database

Это не очевидно из названий, но Oracle Grid Infrastructure (в которую входит Clusterware и ASM) устанавливается первой, отдельным инсталлятором, от отдельного пользователя grid. Только потом - Oracle Database Software от пользователя oracle.

Путать порядок или ставить от одного пользователя - верный способ получить странные ошибки на этапе rootcrs.pl.

После установки Grid проверяем статус кластера:

crsctl status res -t

Все ресурсы (ora.cssd, ora.crsd, ora.diskmon, ASM-инстанция) должны быть ONLINE на обоих узлах. Если что-то не стартовало - смотрим в $GRID_HOME/log/<hostname>/agent/ohasd/, там обычно есть внятное сообщение.

ASM: дисковые группы и избыточность

Создали три группы:

• DATA - для файлов данных, Normal Redundancy (два failure group под два контроллера СХД)
• FRA - Fast Recovery Area для архивных логов и бэкапов, Normal Redundancy
• REDO - отдельная группа для online redo logs, High Redundancy

High Redundancy для REDO - это три копии на трёх failure groups, что для двухузлового кластера потребовало немного поизвращаться с разметкой. В итоге использовали одну failure group на первый LUN от первого контроллера, вторую - от второго, третью - отдельный небольшой LUN под redo. Избыточно? Возможно. Но redo потерять нельзя.

Проверка failover

После создания базы и первой нагрузки (тестовая копия данных клиента, около 80 ГБ) проверили автоматический failover.

Схема простая: на первом узле во время активных сессий принудительно остановили CRS:

crsctl stop crs

Смотрели с клиентской машины через JDBC-соединение на SCAN. Соединения, которые были в момент остановки, получили ошибку и потребовали переподключения - это ожидаемо, TAF (Transparent Application Failover) в нашей конфигурации не был включён. Новые подключения через SCAN пошли на второй узел в течение примерно 15-20 секунд.

Второй тест - эмуляция потери interconnect: отключили оба кабеля на первом узле. Здесь кластер должен принять решение, кто выживает. При правильной конфигурации voting disk (у нас - три диска, два на основном LUN, один на отдельном) первый узел должен был сделать reboot. Так и произошло. Node eviction - не баг, а фича: лучше управляемая перезагрузка узла, чем split-brain.

Что осталось сделать

Мониторинг через Oracle Enterprise Manager Grid Control у клиента пока не развёрнут - это отдельный проект. Базовую проверку состояния RAC сделали через Zabbix: скрипт опрашивает crsctl и сообщает о смене статуса ресурсов.

Также не закрыт вопрос с резервным копированием: RMAN через ASM работает, политика retention настроена, но тест восстановления на изолированный стенд - в плане на следующую неделю. Без теста восстановления нет бэкапа - это правило мы не обсуждаем.

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