Автор: Дмитрий Волков, Oracle СНГ
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. 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) должно быть дублировано и необходимые драйвера установлены в ОС. |