Статья из «Системного администратора» за апрель 2004

Заголовок новости на редкость неудачный. Сама статья на 80% про установку железки на windows-сервер, и пара абзацев в конце про linux.

Интересно было бы увидеть сравнение этого watchdog с тем, который некорое время тому назад несколько раз упоминался на ЛОРе, и у которого, кажется, схема устройства распространялась под свободной лицензией.

Есть намного более надежное и дешевое решение

http://www.botik.ru/tech/chapt3.koi8.html#ris2

Это и есть то самое устройство ;) Схема, исходники прошивки и все остальное на сайте www.comar.ru

> Есть намного более надежное и дешевое решение Я бы сказал именно более дешевое.

Насчет более надежного, вы на сайте www.comar.ru пожалуйста почитайте FAQ. Там перечисляются различные ньюансы имеющие отношение к надежности.

>Это и есть то самое устройство ;) Схема, исходники прошивки и все
>остальное на сайте www.comar.ru

Такие устройства нужны очень и очень старым серверам, потому как все
современные материнки уже имеет встроенный watchdog, для nForce2
ставят отдельную микруху, типа ATXP1, а для intel все встроено в чипсет,
для VIA аналогично как для nForce2...

2SVpcom: Верно... А то что они предлагают, уж сильно смахивает из пушки
по воробьям...

он еще и с ком портом, точно древняя штука :) И в статье описано не тестирование а установка, тестировать этот человек не знает как :)

> 2SVpcom: Верно... А то что они предлагают, уж сильно смахивает из >пушки > по воробьям.. Просто не по воробьям, мы стреляем строго из темроядерного гипербластера. Ну а когда он не нужен - юзаем старенькие пушки. Все равно скоро списывать. ;)

> Таким образом, указав номер порта интересующей службы, можно быть четко уверенным, что watchdog не перезапустит машину до тех пор, пока наблюдаемая служба жива.

Сразу пришла в голову мысль повесить на этот порт, что-нибудь программно перезагружающее сервер.

Гы!

Поставили на работе умывальники автоматические. Руки засунул -- вода течёт. Вынул -- не течёт. Очень удобно до тех пор пока раковина не засорится :-)))))))))

А вообще-то нормальная статья, правда не столько о тестировании, сколько просто рассказано об устройстве. Ну и приятно, что это отечественного производителя.

После длительного (более года) использования подобных устройств в тч встроенных в материнку могу сказать, рано или подзно нарветесь на многократную перезагрузку в момент fsck -y /dev/XXX с последующим (многочасовым) ручным восстановлением диска. Увы, watchdog проблем плохого железа не решает и для продакшн никак не подходит.

> Такие устройства нужны очень и очень старым серверам, потому как все современные материнки уже имеет встроенный watchdog, для nForce2
ставят отдельную микруху, типа ATXP1.

Эмм, а поподробнее нельзя ли, что это за ATXP1 и куда ставят микруху в матплатах на VIA чипсете?

А у вас что watchdog стартует до fsck или нельзя инициализировать его после загрузки ОС? Ну или хотя бы отложенная инициализация на 15 мин после перезагрузки/включения сервера?

watchdog про ос ничего не знает и зависит только от сигнала сброса. Можно инициализировать только один раз. В любых других вариантах - это не watchdog.

Да тут тонкая грань. Но почему нельзя его инициализировать сразу после fsck и через драйвер ОС?

Типовые сценарии:
1. watchdog инициализируется по reset или power on
2. watchdog инициализируется BIOS
3. watchdog инициализируется драйвером
4. watchdog инициализируется из userspace командой пользователя, возможно через драйвер

Чем последний вариант не нравится? Как часто реализованы 1 и 2, я особо не встречал. i810_tco это 3, правильно, сделать из него 4 несложно, например загружая его драйвер модулем, хотя для сервера это не всегда хорошо (грузить модули).

Разумеется, из подконтрольного участка времени можно выбросить любой кусок в тч этап загрузки . Не очень ясно, что делать с зависанием на этом этапе ? Например, используя альфа-драйвера сетевых карт можно запросто зависнуть именно на этапе загрузки ...

Так на комаре.ру вроде бы решили эту проблему выставлением запрета (блокировки)перезагрузки на время работы fsck... По крайней мере на ихнем сайте описана данная ситуация и метод ее решения.

>Эмм, а поподробнее нельзя ли, что это за ATXP1 и куда ставят микруху в
>матплатах на VIA чипсете?

2saper: Это одна из возможных, но не факт что именно такая стоит у
многих, просто аналогичных множество...
Информация здесь - http://www.attansic.com.tw/english/products/

> рано или подзно нарветесь на многократную перезагрузку в момент fsck -y /dev/XXX

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

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

Почитайте документацию и FAQ там много таких ньюансов описано.

>Почитайте документацию и FAQ там много таких ньюансов описано.

Тут читать - не круто :-(

Вот сразу обгадить - это да...

Что-то я не догоняю. Стоит у нас сервер, там Oracle крутиться. Если питание вырубается, бесперебойник посылает reboot, противно пищит, а затем выключает питание. При появлении электричества он включает сервер. Зачем Watchdog?

А если не завис в мертвой зоне, то почему зависнет за ее пределами ? Расширяем мертвую зону и получаем "неубиваемое оборудование" ;)

На мой взгял, если на сервере стоят alpha-версии драйверов и они там нужны, то это риски на которые вы идете. Иначе грохнете файловую систему. Кстати, как вариант - почему нельзя watchdog запустить на этапе проверки, или ему нужен соответствующий dev ... да уж ... можно использовать initrd как в некоторых дистрибутивах, но мне это мало нравится.

> Что-то я не догоняю. Стоит у нас сервер, там Oracle крутиться. Если питание вырубается, бесперебойник посылает reboot, противно пищит, а затем выключает питание. При появлении электричества он включает сервер. Зачем Watchdog?

Все просто. Вы описали работающую конфигурацию. Watchdog нужен для подстраховки в том случае, когда что-то НЕ СРАБОТАЛО как надо.

Например недавно дырку в ядре Linux нашли очередную, позволяющую ядро намертво подвестить. Так вот подвис сервер намертво и все. Питание есть и с UPS все в порядке, только ничего не работает.

И так будет до тех пор как не среагирует обслуживающий персонал. Watchdog автоматом перезапустит сервер снизив время простоя. Разумееться с причиной зависания все равно надо будет разбираться. Но в более спокойной обстановке.

> Кстати, как вариант - почему нельзя watchdog запустить на этапе проверки

Потому что если сервер обнаружил серъезный сбой файловой системы и попросил ввести пароль root-а для ручного лечения. То попытки перезапуска сервера ничего не дадут. Тут уже без вмешательства человека ничего не сделаешь. Наше устройство позволяет правильно обыграть эту ситуацию.

И это одна из причин почему Watchdog должен быть достаточно умный. Иначе он сделает еще хуже. Иначе говоря это один из ответов на вопрос: "а почему не сделать Watchdog из пары транзисторов и одной тупой микрухи"?

В сложной ситуации всегда лучше иметь на сервере serial console + еще например нечто, что позволяет ему нажать на reset удаленно, так как запихивать в watchdog сложную логику врядли имеет смысл и при падении сервера watchdog перезагрузив его тем самым не даст узнать причину его падения. А для простого diskless router'а намного проще сделать watchdog работающий от pc-speaker'а.

P.S. К фирме Комар: сделали бы девайс который мог бы нажимать reset и power куче машин, получая такие команды например через COM порт или USB. А то на стойку из 20 серверов не хочется ставить 20 watchdog'ов. Я думаю довольно большое число людей нуждается в такой штуке.

>P.S. К фирме Комар: сделали бы девайс который мог бы нажимать reset
>и power куче машин, получая такие команды например через COM порт
>или USB. А то на стойку из 20 серверов не хочется ставить 20
>watchdog'ов. Я думаю довольно большое число людей нуждается в
>такой штуке.

Лет 5-ть назад делал примерную штуку для модемов, через LPT все
работало, ведь он больше всего не нужен серверам, а вот COM портов
иногда не хватает, вообщем я не вижу смысла в крутых и сложных
устройствах подобного типа, все ситуации проще решить програмно,
чем усложнением схемы, дабы для watchdog это решается довольно
просто...

> В сложной ситуации всегда лучше иметь на сервере serial console + еще например нечто, что позволяет ему нажать на reset удаленно, так как запихивать в watchdog сложную логику врядли имеет смысл и при падении сервера watchdog перезагрузив его тем самым не даст узнать причину его падения. А для простого diskless router'а намного проще сделать watchdog работающий от pc-speaker'а.

Интересно а как это Watchdog работающий от спикера отличит сложную ситуацию от простой что не не перезапускать сервер в сложной? ;)))

А на счет стоек, через полтора месяца мы начинаем продажу LightWatchdog. Он будет подешевле (50$) и в корпусе размером со спичечный коробок (одевающийся прямо на com порт).

Из-за такой компактности он как раз хорошо подойдет для стоечных серверов.

Перезапускать он будет только замыканием reset. Во всем остальном (кроме кое-какой мелочи) он будет аналогичен этому Watchdog-у. И самое главное он будет работать с тем же софтом.

Т.е. они будут полностью взаимозаменяемы.

>Интересно а как это Watchdog работающий от спикера отличит сложную ситуацию от простой что не не перезапускать сервер в сложной? ;)))

у бездисковых роутеров не бывает сложных ситуаций и поэтому более сложного watchdog'а чем тот, что вешается на pc-speaker им не нужно.

>А на счет стоек, через полтора месяца мы начинаем продажу LightWatchdog. Он будет подешевле (50$) и в корпусе размером со спичечный коробок (одевающийся прямо на com порт).

не у каждого сервера есть свободный com-порт и хочется иметь устройтсво, которое позволяет перезагрузить сервер с _другой_ машины (например с той, куда воткнута serial-console сервера), то есть даже в большинстве случаев нужен не watchdog, а удаленный reset и power. Сделали бы девайс, имеюший кучу выходов и понимающий команды типа "нажать reset для сервера номер N", которые он получал например через COM-порт

> у бездисковых роутеров не бывает сложных ситуаций и поэтому более сложного watchdog'а чем тот, что вешается на pc-speaker им не нужно. Я говорил про сервер. Бездисковый роутер вообще должен работать без всякого Watchdog-а. Они обычно не дешевые и в них все и так есть.

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

Кстати как Вам идея Linux компа с загрузкой с flash на ARM 64Flash и 64M RAM 4 100Mbit/s сетевухи. процессоре примерно за 350$ ?

> вообщем я не вижу смысла в крутых и сложных устройствах подобного типа, все ситуации проще решить програмно

А мы глубоко изучив тему - видим. Решение должно быть прогаммно-аппаратное, функцинальность разумено распределена между софтом и аппаратурой.

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

Насчет com порта да, но пока чаще бывает что нет USB чем что нет com порта. Сервера ведь бывают и P166 и даже 486-ые. И замечательно работают под Linux или FreeBSD.

Кроме того с USB есть свои заморочки. Она ведь делиться между собой несколькими устройствами.

Все не так просто, если капнешь тему основательно. В том и смысл продукта, что мы просто выкопали до дна эту тему для наших клиентов.

А так, после беглого взгляда, все очень просто, главное только на рабочем сервере так "просто" не делать. А то последствия сложные будут ;)

>Бездисковый роутер вообще должен работать без всякого Watchdog-а. Они обычно не дешевые и в них все и так есть.

почему же? обычно бездисковый роутер представляет из себя что-нибудь вида P-MMX/P2 с кучей сетевых карточек в одну из которых прошит например etherboot и грузящий по сети ядро + initrd с полезным софтом (quagga, dhcpd и т.д.) Иногда бывают ситуации что после замены софта или исправления конфигурации такая штука не загружается и вот здесь как раз и нужен watchdog. Встроенные в чипсет watchdog'и обычно тут не спасают, так как их для начала нужно инициализировать, а сбой в загрузке бывает и на этапе получения по DHCP конфига etherboot'а (например неправильный IP ему дается). Поскольку такие действия обычно делаются удаленно и в ночное время, то очень не хочется бежать до роутера, который обычно черти-где стоит и жать ему на reset. Так что в данном конкретном случае наиболее оптимальным порлучается делать watchdog на спикер. Кстати почему бы вашей фирме на наладить выпуск таких watchdog'ов? А то собирать их вручную довольно тяжко :-((

По поводу компа на ARM'е - тут все зависит от того, какие там будут сетевые карты и какая пропускная способность у шины.

> Так что в данном конкретном случае наиболее оптимальным порлучается делать watchdog на спикер Понятно, я имел ввуду cisco и т.п. ;) Все равно там нужна нормальная логика, хоть и по проще.

И всегда не надо забывать что наш продукт это еще и софт. Это как минимум 60% всей разработки.

Например работоспособность сервера демон тоже должен проверить как положено. А то можно нарваться на ситуацию когда ядро работает а сервер нет. и Watchdog ничего не делает.

По этому все равно ньюансы, все равно все не так просто.

Я думаю тут оптимальным будет тот LightWatchdog что я уже упоминал. А еще более оптимальным тоже уже упомянутый маршрутизатор на ARM для которого вообще не нужно будет Watchdog.

> По поводу компа на ARM'е - тут все зависит от того, какие там будут сетевые карты и какая пропускная способность у шины. Предполагается что он выдержит честные 100Mbit/s на всех 4-ех картах.

Вас стоит подписаться на рассылку на www.comar.ru У нас будут появляться новые разработки, тот же Light Watchdog или маршрутизатор. Мы тогда Вас оповестим, возможно Вас что-то заинтересует.