каков алгоритм разруливания ситуации split brain в Oracle RAC, сценарии такие:
1) порвались все interconnects
2) погиб vote disk
3) 1+2
4) один из двух узлов Oracle RAC намертво завис, а через какое-то время отвис
вообщем если в 8 нодовом кластере 3 ноды отвалятся и получится что сервера останутся в рахных группах 3 в одной и 2 в другой то та группа с 3 нодам даст сигнал той группе из двух нод отключится
Алгоритмы там простые как японский самурай - все узлы кроме нулевого сделают себе харакири.
Вообще оракловые решения отличаются склонностью к самоубийствам (даже простой ASM на одном узле в 10.2.0.4), а уж кластерные (что RAC что OCFSv2) особенно.
Кстати, ИНТЕРКОННЕКТ там один - насколько я помню, ни в одном кластере оракла не было возможности описывать несколько.
В случае 4 - узел пришибется процессом oprocd если тот оживет (что не факт). До версии 10.2.0.3 - модулем hangcheck_timer.
Ну что там зависит? Если нет внешнего фенсинга и есть ровно ОДИН интерконнект и абсолютно дубовый алгоритм принятия решения (что в OCFSv2 что в СRS)? При любом чихе вся конструкция говорит _АЙ-ЯЙ-ЯЙ, я не знаю что делать, а потому лучше я сделаю себе харакири_ и перевызывает систему без единого, подчеркну без единого, слова в логах! (oprocd этим особо славится).
При этом реализация оного oprocd во первых толком не документирована (там какие то гистограммы и прочая лапша наворочены), а во вторых просто як сибирский валенок
- запускаем процесс
- вешаем в нем приоритет RT
- засыпляем, по просыплянию проверяем насколько он отстал
- если отстал больше чем на маржин то убиваем систему мгновенно и безболезненно (причем так чтобы она вообще ничего не успела сделать)
Авторы свято верили в то, что RT процесс самый приоритетный (что НЕ ПРАВДА АБОСЛЮТНО), в то что не бывает задержек вызванных скажем виртуализацией (в итоге OPROCD приходится выключать в VMware нафиг), а также в то, что харакири нужно делать ВСЕГДА (даже когда система не имеет в данный момент никаких ресурсов взятых у кластера). В итоге сразу же была выдана рекомендация ставить там один загадочный параметр в 13 - вычитая из 13 3 получаем 10 секунд марджина вместо 500 миллисекунд по умолчанию.
Ну и все прочее в ораклиных кластерах в том же духа - святая вера в правду бумажки без попытки подумать сначала что получится. В итоге получается нечто, падающее при проблемах оборудования направо и налево (и к тому же не фига не отрабатывающее частичные проблемы). И толку от оного oprocd немного, потому что по жизни процессы ядра ПРИОРИТЕТНЕЕ чем процесс oprocd и скажем если зациклится драйвер а потом отциклится - то сначала система отработает задержавшиеся обмены скажем в iSCSI или в FC HBA (тем самым успешно развалив диски) а потом уже проснувшийся oprocd вонзит в нее карающий меч...
Если сравнивать с нормальными кластерами, то ораклиные - просто детский лепет начинающих индусов.
1) порвались все interconnects
2) погиб vote disk
3) 1+2
4) один из двух узлов Oracle RAC намертво завис, а через какое-то время отвис
вообщем если в 8 нодовом кластере 3 ноды отвалятся и получится что сервера останутся в рахных группах 3 в одной и 2 в другой то та группа с 3 нодам даст сигнал той группе из двух нод отключится
Алгоритмы там простые как японский самурай - все узлы кроме нулевого сделают себе харакири.
Вообще оракловые решения отличаются склонностью к самоубийствам (даже простой ASM на одном узле в 10.2.0.4), а уж кластерные (что RAC что OCFSv2) особенно.
Кстати, ИНТЕРКОННЕКТ там один - насколько я помню, ни в одном кластере оракла не было возможности описывать несколько.
В случае 4 - узел пришибется процессом oprocd если тот оживет (что не факт). До версии 10.2.0.3 - модулем hangcheck_timer.
Ну что там зависит? Если нет внешнего фенсинга и есть ровно ОДИН интерконнект и абсолютно дубовый алгоритм принятия решения (что в OCFSv2 что в СRS)? При любом чихе вся конструкция говорит _АЙ-ЯЙ-ЯЙ, я не знаю что делать, а потому лучше я сделаю себе харакири_ и перевызывает систему без единого, подчеркну без единого, слова в логах! (oprocd этим особо славится).
При этом реализация оного oprocd во первых толком не документирована (там какие то гистограммы и прочая лапша наворочены), а во вторых просто як сибирский валенок
- запускаем процесс
- вешаем в нем приоритет RT
- засыпляем, по просыплянию проверяем насколько он отстал
- если отстал больше чем на маржин то убиваем систему мгновенно и безболезненно (причем так чтобы она вообще ничего не успела сделать)
Авторы свято верили в то, что RT процесс самый приоритетный (что НЕ ПРАВДА АБОСЛЮТНО), в то что не бывает задержек вызванных скажем виртуализацией (в итоге OPROCD приходится выключать в VMware нафиг), а также в то, что харакири нужно делать ВСЕГДА (даже когда система не имеет в данный момент никаких ресурсов взятых у кластера). В итоге сразу же была выдана рекомендация ставить там один загадочный параметр в 13 - вычитая из 13 3 получаем 10 секунд марджина вместо 500 миллисекунд по умолчанию.
Ну и все прочее в ораклиных кластерах в том же духа - святая вера в правду бумажки без попытки подумать сначала что получится. В итоге получается нечто, падающее при проблемах оборудования направо и налево (и к тому же не фига не отрабатывающее частичные проблемы). И толку от оного oprocd немного, потому что по жизни процессы ядра ПРИОРИТЕТНЕЕ чем процесс oprocd и скажем если зациклится драйвер а потом отциклится - то сначала система отработает задержавшиеся обмены скажем в iSCSI или в FC HBA (тем самым успешно развалив диски) а потом уже проснувшийся oprocd вонзит в нее карающий меч...
Если сравнивать с нормальными кластерами, то ораклиные - просто детский лепет начинающих индусов.
Комментариев нет:
Отправить комментарий