null

Преодоление защиты от "амнезии" в Sun Cluster 3.x

В двух словах мы можем определить понятие  "амнезии" (amnesia, "потеря памяти") следующим образом : это стандартная функция ПО Sun Cluster, в общем случае позволяющая предотвратить загрузку ноды, когда-либо участвовавшей в рассматриваемом кластере, но для которой загрузка нежелательна в связи с тем, что данные конфигурации кластера, которые хранятся в её CCR (Cluster Configuration Repository), неактуальны или неконсистентны. Реализована функция при помощи механизма голосования формирующих кластер узлов таким образом, что  только нода с необходимым количеством голосов может организовать кластер и добавить все оставшиеся ноды для возможности продолжения работы. Нода, которую "исключили" из кластера по причине ее штатного или аварийного завершения работы теряет право организовать кластер если в нем остались другие активные ноды. Заметим что, основан механизм голосования на использовании SCSI-резерваций (или их эмуляции) и неразрывно связан с понятием "кворума" Sun Cluster.
 
Представим следующую ситуацию : мы имеем стандартный 2-х узловой кластер и по какой-либо  причине (для ремонта, апргейда и тд.) мы штатно выключаем одну из нод, при этом она теряет право организации кластера, а оставшиеся нода единолично выполняет "роль" кластера. Предположим, что далее происходит аппаратная/программная авария оставшейся ноды, которая приводит к невозможности запустить этот узел кластера. Мы принимаем решение, что для восстановления работоспособности кластера и, соответственно, работающих на нем сервисов необходимо запустить ноду, первоначально выведенную из эксплуатации. Однако, механизм предотвращения "амнезии"  запретит запуск ноды в кластерном режиме, так как она может иметь устаревшую конфигурацию (право организации кластера осталось за неисправным узлом).

В таком случае на консоле пользователь увидит следующие сообщения :
 
 "
 Booting as part of a cluster
 NOTICE: CMM: Node myclusternode-1 (nodeid = 1) with votecount = 1 added.                
 NOTICE: CMM: Node myclusternode-2 (nodeid = 2) with votecount = 1 added.
 NOTICE: CMM: Quorum device 1 (/dev/did/rdsk/d2s2) added; votecount = 1, bitmask of nodes  with configured paths = 0x3.                                
 NOTICE: CMM: Node myclusternode-1: attempting to join cluster.
 NOTICE: CMM: Quorum device 1 (gdevname /dev/did/rdsk/d2s2) can not be acquired by the current cluster members. This quorum device is held by node 2.
 NOTICE: CMM: Cluster doesn't have operational quorum yet; waiting for quorum
"
Таким образом, загрузка ноды будет остановлена до того момента, пока для нее не будут "добавлены" голоса при помощи активной ноды (имеющей достаточно голосов для организации кластера) посредством взаимодействия через транспортную сеть ("cluster interconnect"). В нашем случае этот узел неисправен и не может быть запущен.

Что необходимо предпринять в такой ситуации ? Как восстановить работоспособность кластера ?
Данная проблема решается при помощи внесения вручную необходимого кол-ва голосов  в  конфигурационном файле CCR infrastructure, в соответствии со следующей процедурой :

- В первую очередь необходимо запустить ноду  во "внекластерном" режиме, для этого :  в случае SPARC-системы из OBP запускаем "boot -x" , а для x86 в загрузчике GRUB добавляем " -x"  в конце строки "kernel /platform/i86pc/multiboot".

- Находим файл infrastructure в директории /etc/cluster/ccr. Делаем его резервную копию.

- Определяем значение nodeid для данного узла (он находится в /etc/cluster/nodeid)

- Открываем для редактирования  /etc/cluster/ccr/infrastructure и  находим записи  cluster.nodes.<nodeid>.name, cluster.nodes.<nodeid>.state, и главное, cluster.nodes.<nodeid>.properties.quorum_vote  (в соответствии с nodeid)

- Устанавливаем значение равное "1" для записи cluster.nodes.<nodeid>.properties.quorum_vote, проверяем что все записи, указанные выше, имеют корректные значения :

"   ...
    cluster.nodes.1.name    myclusternode-1
    cluster.nodes.1.state   enabled
    cluster.nodes.1.properties.quorum_vote  1
    ...
"
(в нашем случае значение nodeid=1)

- Для всех остальных записей  cluster.nodes.<nodeid>.properties.quorum_vote (для других нод) указываем кол-во голосов равное "0".

- Находим запись  cluster.quorum_devices.<q>.properties.votecount, где <q> - устройство "кворума", меняем ее значение кол-ва голосов также на  "0"

- Сохраняем файл infrastructure и пересчитываем его контрольную сумму (эта процедура обязательна) при помощи
команды  "/usr/cluster/lib/sc/ccradm -i /etc/cluster/ccr/infrastructure -o"

- Перезагружаем ноду в кластерном режиме  (загрузка без параметра "-x")

Комментарий :  Сброс в "0" значений голосов для всех нод кластера и кворума (кроме узла который Вы пытаетесь запустить) не обязателен, Вы можете просто увеличить кол-во голосов для нужной Вам ноды с целью получения большинства голосов  и, соответственно, возможности запуска в кластерном режиме (в данном случае).

Коротко о себе:

Работаю в компании TUNE-IT в качестве инженера и преподавателя.

В сферу профессиональных интересов входит все,  что связано с "большими" и не очень серверами и СХД от Sun Microsystems/Oracle и кластерами на их основе, но по долгу службы занимаюсь чаще всего их диагностикой и ремонтом... 

Делюсь опытом и  наработанными навыками в рамках курсов по  соответствующим направлениям.