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) должно быть дублировано и необходимые драйвера установлены в ОС.
Note 294430.1 “CSS Timeout Computation in RAC 10g
Читать дальше...
Сообщения
