Спонтанная перезагрузка HW2000

[borisk_1976]

Добрый день!

Есть два HW2000 Q3 собранные в кластер. Работали на 3й версии, обновили их до 4й (4.2.0-1112). Они проработали без проблем примерно неделю, а потом произошло спонтанное отключение электроэнергии. После восстановления питания HW начали спонтанно перезагружаться. Подумали может что-то "наелось" в кластере (хотя явных следов этому нет), отключили passive - не помогло, active все равно так же спонтанно перезагружается. Ладно, может что-то случилось с ним, выключаем его и загружаем второй - ситуация ни как не меняется, все равно спонтанная перезагрузка. Причем что самое - в rebootlog ни строчки, то есть причина перезагрузки непонятна совсем. Делали логгирование на удаленный хост - то же самое, идут строчки вида

Sep 21 14:54:56 hw2000-tagil-node2 iplircfg[5033]: [09-21 14:54:56] UdbDispatcher::Dispatch: command 201, GET_IFSTAT 
Sep 21 14:54:56 hw2000-tagil-node2 iplircfg[5033]: [09-21 14:54:56] UdbManager::DispatchCommand: [0x7f9b6f7fdb80] Command 201 processing complete on fd 58 
Sep 21 14:54:56 hw2000-tagil-node2 iplircfg[5033]: [09-21 14:54:56] UdbManager::DispatchCommand: [0x7f9b6f7fdb80] Command 201 processing start on fd 58 
Sep 21 14:54:56 hw2000-tagil-node2 iplircfg[5033]: [09-21 14:54:56] UdbDispatcher::Dispatch: command 201, GET_IFSTAT 
Sep 21 14:54:56 hw2000-tagil-node2 iplircfg[5033]: [09-21 14:54:56] UdbManager::DispatchCommand: [0x7f9b6f7fdb80] Command 201 processing complete on fd 58 

потом тишина на несколько минут и строчки загрузки системы. Что это может быть, как определить в чем проблема? Уже всю голову сломали.

 

[R.Sheyn]

Вообще обрыв лога обычно говорит о проблеме питания. Особенно учитывая то, что проблемы с питанием как раз послужили активатором. Спонтанные перезагрузки с какой-то регулярностью происходят или совсем рандомно? Предлагаю, взять одну ноду в файловер конфе выставить test лупбэком(если сейчас не стоит) и просто подключить в розетку какую-нибудь, ничего не коммутировать и посмотреть будут ли ребуты.

[borisk_1976]

То есть одновременно на двух железках сдохли БП? Конечно допускаю, но все же очень сомнительно. Перезагрузки совсем спонтанные, может 3 часа проработать, а может и через 15 минут перезагрузиться, но в среднем около часа находится в рабочем состоянии. В файловере уже и так test лупбэком. Более того - failover stop даже сказано, и в [misc] reboot = no

 

[Xenobius]

На обычном ПК такое поведение часто говорит как раз о проблемах с блоком питания. Тем более соответствующие настройки про перезапуск отключены. А учитывая, что ПАК по сути и есть ПК, хоть и "телекоммуникационный сервер", проблема вполне может быть в блоке питания.

[borisk_1976]

Мужики, я не отрицаю что на обоих ПАК могли сдохнуть БП одновременно. Мне больше для себя понять, ничего ли я не упустил в диагностике?

1) Физически выключил один координатор, на втором отключил failover с помощью failover stop

2) После перезагрузки смотрю информацию в everything.log и rebootlog

Может что-то еще можно сделать?

[azz]

11 часов назад, borisk_1976 сказал:

То есть одновременно на двух железках сдохли БП? Конечно допускаю, но все же очень сомнительно. Перезагрузки совсем спонтанные, может 3 часа проработать, а может и через 15 минут перезагрузиться, но в среднем около часа находится в рабочем состоянии. В файловере уже и так test лупбэком. Более того - failover stop даже сказано, и в [misc] reboot = no 

 

уже не раз было оговорено на форуме, что reboot = no  не спасёт Вас от перезагрузок кластера или ноды. читайте документацию. А логи лучше техподдержке на анализ предоставить. Там эксперты быстрее разберуться, что у них там в логе пишется

[borisk_1976]

azz, вы про это? "В случае сбоев, критичных для работоспособности ПО ViPNet на активном сервере, пассивный сервер переключается в активный режим для выполнения

функций сбойного сервера. При этом сбойный сервер перезагружается и становится пассивным." Если нет, то можно пояснить о чем?

 

Было бы здорово еще понять что за критичные случаи.

[azz]

Для тех кому лень поискать самому:

reboot — задает действия системы в случае обнаружения полной неработоспособности какого-либо демона или драйвера ViPNet Coordinator HW. Возможные значения:
o yes (по умолчанию) — включить механизм регистрации в watchdog-драйвере и перезагружать систему, если какой-либо демон или драйвер не может восстановить свою работу;
o no — выключить механизм регистрации в watchdog-драйвере и не перезагружать систему, если какой-либо демон или драйвер не может восстановить свою работу.

 

 

26 минут назад, borisk_1976 сказал:

Было бы здорово еще понять что за критичные случаи. 

Например не доступен testip - что свидельствует, что есть проблемы в канале, выход из строя активной ноды

[borisk_1976]

azz, я это знаю и читал, и как указано у меня выше, reboot = no стоит. Вы же пишите "Уже не раз было оговорено на форуме, что reboot = no  не спасёт Вас от перезагрузок кластера или ноды. читайте документацию". Вот я и спрашиваю - где в документации написано что не спасёт? Ткните носом, пожалуйста, меня ленивого. Так же я выше писал, что _все_ testip указаны 127.0.0.1. loopback недоступен? ну я тогда не знаю.... Не говоря уже о том, что failover stop сделано

 

[azz]

Только что, borisk_1976 сказал:

azz, я это знаю и читал, и как указано у меня выше, reboot = no стоит. Вы же пишите "Уже не раз было оговорено на форуме, что reboot = no  не спасёт Вас от перезагрузок кластера или ноды. читайте документацию". Вот я и спрашиваю - где в документации написано что не спасёт? Ткните носом, пожалуйста, меня ленивого. Так же я выше писал, что _все_ testip указаны 127.0.0.1. loopback недоступен? ну я тогда не знаю....

 

Вы не знаете из-за чего происходят перезагрузки. reboot = no не поможет, если у Вас нет проблем с демонами или драйверами(а судя по перезагрузкам - не помогло). Здесь нет экспертов, чтобы ответить Вам в чём может быть дело в такой ситуации. У Вас единственный выход обратиться в ТП, если контракт есть, конечно. А так, можете перепрошить устройства и заново всё собрать.

[borisk_1976]

azz, понятно. Большей части мои вопросы касались не "объясните почему так", а "все ли я сделал для того чтобы диагностировать проблему, или есть еще какие-то варианты"

ТП многозначительно молчит уже сутки, а система перезагружается. Да, и тут действительно дилемма, пересобрать все с нуля и (возможно), проблема уйдет и ТП потеряет бесценный опыт, либо бесценный опыт шаманства приобрету я.

[azz]

1 минуту назад, borisk_1976 сказал:

azz, понятно. Большей части мои вопросы касались не "объясните почему так", а "все ли я сделал для того чтобы диагностировать проблему, или есть еще какие-то варианты"

ТП многозначительно молчит уже сутки, а система перезагружается. Да, и тут действительно дилемма, пересобрать все с нуля и (возможно), проблема уйдет и ТП потеряет бесценный опыт, либо бесценный опыт шаманства приобрету я.

Если логи предоставили, скорее всего они на анализе у экспертов, иногда, к сожалению, это занимает время.

[R.Sheyn]

3 часа назад, borisk_1976 сказал:

Может что-то еще можно сделать?

Я Вам уже посоветовал, возьмите одну ноду, никуда не коммутируйте, подключите в другую розетку и понаблюдайте. Если возникнет случайный ребут, значит проблема в БП, так как никаких процессов на этой ноде происходить не будет.

[borisk_1976]

R.Sheyn, да спасибо, ваш совет принят и именно этим сейчас и занимаюсь.

 

[borisk_1976]

В общем никакой магии. Что-то наелось в APCшном блоке розеток и он вот так вот спонтанно лишал координаторы электричества. Про то, что оба координатора запитаны с одного блока я техникам уже высказал

 

[azz]

55 минут назад, borisk_1976 сказал:

В общем никакой магии. Что-то наелось в APCшном блоке розеток и он вот так вот спонтанно лишал координаторы электричества. Про то, что оба координатора запитаны с одного блока я техникам уже высказал

 

А Вы в демонах и драйверах проблему искали

[borisk_1976]

Потому что весь инет пестрит сообщениями "vipnet координаторы перезагружаются", да и в самой доке на vipnet тоже есть пункт "проверьте, в течение 10 минут, что координаторы самовольно не перезагружаются"

 

[Vintik]

В 26.09.2018 в 11:31, borisk_1976 сказал:

Про то, что оба координатора запитаны с одного блока я техникам уже высказал

Это не им надо а начальству, не раз было как начинаешь говорить как надо 2 АПС и.... а потом получаешь - ненене это дорого.. так что служебку начальству, пусть один раз останутся без отпуска 

[borisk_1976]

Мечтатель