[toronin]

Кто нибудь использовал watchdog-и на серверах?

Ну это такая железка которая автоматически перезапускает сервер если он

подвис.

 

А то хотим попробовать, но может кто поделиться опытом.

[/b]

[lamer]

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

Описал, конечно, несколько сумбурно, но схемка в принципе небольшая и не подвисающая.

Оно конечно можно и на ПИКах или Атмелах, но в этом случае нужно программить контроллеры, а так, один паяльник:).

[toronin]

Описал, конечно, несколько сумбурно, но схемка в принципе небольшая и не подвисающая.

Оно конечно можно и на ПИКах или Атмелах, но в этом случае нужно программить контроллеры, а так, один паяльник:).

 

Паяльник это прикольно, но хотелось бы по возможности не изобретать

велоситпед если он уже есть ;)

 

Я уже нашел девайсину (на http://www.comar.ru), но интересно имеет-ли

кто опыт практического использования таких штуковин-диковин. ;)

Может кто еще какие устройства знает, пробовал?

 

А то сервера на чердаках стоят, и их бывает клинит.

А я человек ленивый, ну нехочу я на каждый апчхи, типа броска питания,

туда бегать. Да и в серверную на выходные.

 

А такая простая схемка мне кажеться не покатит, ведь если серваку совсем

плохо станет - она его без конца перезапускать будет? Тогда уж лучше

самому бегать переапускать.

[lamer]

Ну, если ленивый - тогда да, придётся платить бабло! С другой стороны, если взялся за паяльник, функционально можно сделать именно то, что нужно, нужно только немного свободного времени. А готовых аналогичных шняг полно - поищи на форумах и поисковиках.

[jab]

Я уже нашел девайсину (на http://www.comar.ru), но интересно имеет-ли

кто опыт практического использования таких штуковин-диковин. ;)

Может кто еще какие устройства знает, пробовал?

 

Дешевле будет поставить простенький UPS. Сами по себе сервера

не виснут, только от скачков питания. Правда бывают и UPS'ы такие

что не ловят, так что самые дешевые брать не рекомендуется.

[MaXToP]

Если на линухах сервер, то софтдог нужно ставить. Если железо не глючит, то помогает нормально.

[toronin]

Если на линухах сервер, то софтдог нужно ставить. Если железо не глючит, то помогает нормально.

 

Я предпочитаю перестраховаться, кроме того что значит железо не глючит?

Если это железо сервер на чердаке фиг знает при какой температуре, пыльности

и влажности. С такими аргументами и ECC память не зачем, если память

не глючит - зачем проверка CRC? И журналируемые файловые системы -

тоже не зачем. ;)

 

Я кстати хочу некоторые подобные сервера с винтов на flash перевести,

и тогда как раз на ups-е можно будет с экономить. Кстати еще, что бы ups действительно устранил проблемы с бросками питания, это должен быть online ups.

 

В общем, что нужен аппаратный watchdog (тот который я нашел кстати включает в себя и програмный тоже) - вопрос решенный.

 

Я собственно спрашивал если у кого опыт использования таких штук?

А то может кто знает какие-то плюсы или минусы конкретных устройств?

 

Я кстати еще один нашел, он попроще и подешевле:

http://www.cronyx.ru/hardware/wdog.html

 

Может кто еще какие знает?

[MaXToP]

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

[toronin]

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

 

Я посмотрел, там в конфиге (там на http://www.comar.ru конфиг выложен) задется порт, демон считает что с сервером

что-то не в порядке если он не может соедениться с заданым хостом (обычно

localhost на заданый порт), кол-во попыток и timeout задаются.

 

Ну и разумеется если демон перестает слать потверждения что сервак жив

по ком порту на аппаратный watchdog - железка перезапускает сервер

уже более грубо (демон делает это запуском заданной команды).

 

В общем-то из-за подобных моментов и не хочется ставить простую схемку.

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

на какие ситуации напарывался которых я не знаю.

 

Вдруг например он сам иногда виснет? И выдает синий экран смерти!

Интересно куда? ;)))

[jab]

если линух - то лучше сразу в морг, а freebsd не виснет :-)

[zoro]

если линух - то лучше сразу в морг' date=' а freebsd не виснет :-) [/quote']

если кривое железо или пропажа питания то даже ваша нахваленая фря..... :) и кстати видел много случеев когда после вырубания света(не коректного естестно) фря без ручек не заводилась.. а линух заводился чекался... и работал.. :). но не будем превращать топик в разборки что лучше фря или линух или винда...

[jab]

а зачем ставить кривое железо ? чтобы имитировать бурную деятельность потом ?

[toronin]

а зачем ставить кривое железо ? чтобы имитировать бурную деятельность потом ?

 

Сбой может быть всегда, кроме того не всегда (мягко выражаясь),

есть деньги на самое крутое железо.

 

В общем все, я купил устройство от www.comar.ru

вроде все работает. Оно правда почему-то не в том исполнении что на

сайте сфотано. Но даже лучше наверное.

 

А и еще, у них выложены ВСЕ МАТЕРИАЛЫ: схема, разводка платы,

прошивка и т.п. Так что кто предпочитают паять - могут спаять сами.

;)

 

Еще бы цену снизили, а то все класно, но дороговато однако.

[terapeut]

Если сервер виснет, то это не сервер! =) Проверяй железо.. ну и всё остальное. Могу из опыта сказать, что БСД-сервера работают _годами_ в самых разных условиях от подвалов до чердаков. Не требуют никакого внимания, кроме той профилактики, которая им полагается - кулера проверить, патчи там какие поставить, которые автоматом поставиться не могут. Железо самое обычное, но исправное. Память только в основном брендовая - на всякий случай, чтоб лишний раз не бегать.

[VM]

...проблема всех софт-хард догов в том, что они срабатывают при падении своего контрольного софта

 

Это как раз не проблема, когда будит и кормит собаку не контрольный софт, а сама контролируемая прикладная программа.

 

Intel ICH* Features:

- Timers to generate SMI# and Reset upon detection

of system hang

- Timers to detect improper processor reset

 

http://www.intel.com/design/chipsets/appln...ts/29227301.pdf describes what is needed to support the watchdog (so that stuck servers get unstuck)

 

I have some code at:

http://www.ambrisko.com/doug/watchdog/

The implements SW & HW watch dogs. If HW exists it links in via syctl

patches that lets the SW watch dog control HW watch dogs if they are in

the system. This was done to permit better watch dog timeouts then

HW since some hardware is very limited on the time duration so it is

used to "enforce" the SW watch dog is still running. If the SW watch dog

stops updated the HW watch dog then the machine reboots. The other advantage

is that if the SW can provide the main watch dog service then it can

cause a panic to figure out what went wrong.

 

It has support for the Intel TCO watchdog and SIS630 chipset.

 

This is prototype code that works. A scheme to add in sub drivers needs

to be added. When FreeBSD decides how this should work then I'll

probably redo in that sense.

 

Caveat is no real HW bounds checks are done for valid timeout.

 

The sysctl interface is nice in that you can kld{load,unload} the HW part

and leave the SW part working. It also allows the watch dogs to be

disabled when you enter the debugger etc.

 

| Is there any support for this in freebsd stable?

 

Yes it runs on -stable.

 

http://www.linuxhq.com/kernel/v2.4/22/Docu...mi_watchdog.txt