Fencing - это механизм исключения "поврежденного" узла из кластера. Fencing
необходим потому, что нельзя отличить сбой узла от повреждения интерконнекта/SAN.
Fencing, таким образом гарантирует, что узел не может выполнить I/O и повредить
данные.
Если узел не обновляет информацию в voting disk или не отвечает по
interconnect в течении timeout, возникает потенциально ситуация (split brain),
когда узлы кластера начнут несогласованно модифицировать данные. Более точно,
узлы каждую секунду пишут в voting файл и также каждую секунду читают kill
block.
Начиная с 10gR2 существуют 3 параметра (Note:284752.1):
reboottime
disktimeout
misscount
Управлять этими параметрами можно с помощью $CRS_HOME/bin/crsctl get/set css
Однако необходимо помнить, что "Customers should not modify
CSS settings unless guided by either Oracle support or Oracle development to do
so"
Для осуществления голосования каждый узел должен иметь доступ как минимум к
N/2+1 Voting disk, где N - число voting disks. Например если сконфигурировано 5
voting disks, в любой момент времени должно быть доступно не менее 3-х.
Для предотвращения данной ситуации, существует алгоритм, выделяющий подкластера,
и подкластер с меньшим количеством узлов должен покинуть кластер. Для
двуузлового кластера, выживает узел с меньшим номером.
Для выполнения fencing Oracle использует алгоритм STONITH (shoot the other node
in the head -
http://en.wikipedia.org/wiki/STONITH). Oracle Clusterware реализует данный
алгоритм посылая узлу команду "самоубийства" (commit suicide), и узел выполняет
перезагрузку. В нижеследующей таблице описан алгоритм вызова STONITH.
| Network Ping |
Disk Ping |
Reboot |
| Completes within misscount seconds |
Completes within Misscount seconds |
N
|
| Completes within Misscount seconds |
Takes more than misscount seconds but less than Disktimeout seconds |
N
|
| Completes within Misscount seconds |
Takes more than Disktimeout seconds |
Y
|
| Takes more than Misscount Seconds |
Completes within Misscount seconds |
Y
|
Надо отметить, что некоторые другие вендоры (я точно знаю про Veritas)
используют для fencing инструкции scsi persistent reservation (набор команд
SCSI3). В это случае узлы "голосуют" через этот набор команд, кто из них должен
"умереть". У этого подхода есть и достоинства и недостатки. Недостаток - диски
должы поддерживать scsi3, достоинство - такой fencing драйвер работает в kernel
mode, таким образом гарантируя, что I/O команды не пройдут.
Fencing драйвер Oracle напротив работает в user mode, но целостность данных
дополнительно гарантируется внутренними механизмами RAC.
И я надеюсь, что после вышесказанного, понятно, что для предотвращения reboot
узлов все оборудование (сетевые карты, SAN адаптеры, SAN switch) должно быть
дублировано и необходимые драйвера установлены в ОС.Автор: http://dsvolk.blogspot.com/
Последние комментарии