Oracle tech Day Minsk (cluster reconfiguration)

Во время Oracle Tech Day в Минске я выступал с презентацией "Архитектура максимальной доступности" и показывал мультфильм, демонстрирующий балансировку нагрузки и поведение кластера во время неожиданной перегрузки одного из узлов (прочитать про все мультфильмы).

Во время демонстрации фильма, кто-то из зала, воспользовавшись темнотой :), задал коварный вопрос - "а почему падает в 0 кол-во транзакций ? " и я пытался объяснить этот факт не вдаваясь в архитектуру, что оказалось очень не просто. Сейчас я восполню этот пробел, насколько я смогу. Во первых детально различные сбои в кластере и необходимые настройки, чтобы уменьшить продолжительность сбоев собраны в замечательной whitepaper (внимание, она про 10g у меня в мультфильмах 11g)
Для удобства я привожу картинку оттуда: действительно на какое-то время транзакции в системе останавливаются. Но, это время ~ 2 сек.

Так что же происходит, когда один из узлов вдруг пропадает ?
(дальше мои предположения, возможно они не абсолютно точные)


1) Clusterware обнаруживает, что узел перестает голосовать в voting диске и (скорее всего) хочет выбросить этот узел из кластера, но сети тоже нет. Скорее это происходит быстро, несколько секунд.

2) Далее блокируется глобальная база блокировок (IDLM)
Начиная с этого момента кол-во транзакций падает. потому что продолжаются только транзакции, которым нужны данные на локальном узле.

3)Далее необходимо выполнить переконфигурацию ASM. Опрации ввода-вывода замедляются.

4)Далее идет переконфигурация экземпляров для переделки "прав собственности" владельцев объектов в глобальном кеше.

Я думаю на этапе 3-4 транзакции в кластере прекращаются полностью.

5) Далее выполняется оставшиеся узлы кластера выполняют instance recovery

6) Число транзакций в системе нарастает, но если транзакциии встречается блок, который необходимо восстановить - он восстанавливается, только потом транзакция продолжается.

7) Все блоки восстановлены - достигнут максимальный уровень производительности.

Для увлекающихся могу порекомендовать еще вот эту ссылку:
Oracle RAC: Cluster reconfiguration steps
К сожалению сама книга в бумажном варианте мне сейчас недоступна, как только я ее получу возможно что-то и изменю в тексте выше.


Давайте обсудим результат: ~2 сек простоя системы. Как видно из рисунка слева - это четыре 9 ! Давайте решим что у нас 4 узла, что каждый из них раз в год перегрузиться неожиданно - все равно укладываемся.

Попробуйте найти у вендоров оборудование, которое сертифицировано по такому же классу (9999) - есть, на надо еще поискать и посмотреть на его стоимость.

Итак: Я надеюсь, все понимают, что мы рассмотрели самый тяжелый случай - перегрузку узла. Что в случае планового обслуживания у Вас не будет простоя сервиса, если Вы все сделаете аккуратно.

Итого, при соответсвующем оборудовании мы может строить на Oracle RAC системы с уровнем доступности четыре 9999. Сравните это с HA решением (cold failover) - там с трудом можно попасть в две 9.