COMAR - Computer Art Technology
Документация

Скачать

Купить WatchDog


Наши клиенты

Форумы

Контакты

 

 

Опрос
Откуда узнали о нас
Журнал "СисАдмин"
Журнал "Хакер"
Журнал "Компьютерра"
Портал "OpenNET"
Поисковик
От знакомых
Другие источники

 computer art программные и аппаратные разработки
icq 283175359 8-499-502-02-99 
 

Наш WatchDog протестирован журналом "Системный администратор" (номер 4(17) за 2004 г.).
По договоренности с редакцией журнала мы публикуем все без изменений.
Сторожевой пес
Скачать: Watchdog.pdf [4.7МБ]
Андрей Бешков

Н 
а прошлой неделе редакция нашего журнала попросила меня провести тестирование в боевых условиях устройства watchdog, предназначенного для мониторинга и восстановления работоспособности зависших серверов через принудительный перезапуск. На первый взгляд такое устройство имеет немного шансов для массового применения, так как любой сервер априори задумывается как сущность, которая должна работать круглосуточно и бесперебойно. Многие системные администраторы гордятся тем, что под их командованием есть сервера, которые функционируют без перезагрузки по 360 дней и более. В то же время серверные операционные системы специально разрабатываются с прицелом именно на такой режим использования. Хотя, судя по моему опыту эксплуатации разнообразных серверных систем, это еще ничего не значит, и как показывает практика, вместо исправленных ошибок постоянно находятся новые. К сожалению, на свете не существует безошибочных программ, плюс ко всему довольно часто на сервере работают службы, написанные сторонними производителями. А это в свою очередь также добавляет в систему нестабильности. Учитывая то, что мы живем в неидеальном мире, часто складывается ситуация, когда сам сервер настроен не очень правильно из-за недопонимания основ функционирования системы или халатности администратора. Поэтому довольно часто случается, что сервера виснут намертво в самый неподходящий момент. Хорошо, если администратор рядом, а что делать, если его нет поблизости и никто не знает, что делать. Или представим, что зависание произошло ночью, ехать на другой конец города только ради того, чтобы запустить злополучный сервер, удовольствие не из тех, что хочется испытывать как можно чаще.

Порыскав в сети, удалось узнать, что производителем устройства является Comar Technology. Честно говоря, сайт www.comar.ru дизайном не впечатлил, впрочем, тут же подумалось о том, что это не самое главное, поэтому, закрыв глаза на мелкие недочеты, я углубился в чтение технических спецификаций, инструкций по применению прибора и отзывов тех, кому уже пришлось воспользоваться данным устройством. Закончив с этим занятием, решил принять столь любезное предложение, да и самому было весьма интересно попробовать на зуб эту диковинку. Примерно через сутки расторопный и ужасно деловитый курьер DHL доставил загадочную посылку прямо на мой рабочий стол. С нетерпением разорвав упаковку, я стал разбираться в том, что находилось в заветном пакете. Итак, давайте посмотрим, что входит в стандартную поставку устройства watchdog.

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

Далее идет шнур RS232 для подключения к COM-порту компьютера. Два дополнительных провода бледнорозового цвета служат для присоединения к кнопке reset или power подопытного сервера. Это в свою очередь помогает правильно управлять питанием ATX серверов. В моем случае использовался именно такой сервер.

Следом за двумя вышеперечисленными предметами из коробки был извлечен знакомый всем до боли кабель для подвода электропитания.

И на закуску прилагается CD-диск с документацией и прикладным программным обеспечением. Кстати, стоит отметить хорошее чувство юмора человека, писавшего документацию и комментарии внутри всех конфигурационных файлов.

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

Таким образом, становится понятно, что watchdog может выключать и включать сервер, размыкая и соединяя вновь питающую цепь. Любопытный читатель обязательно спросит о том, как watchdog определяет, в каком состоянии находится наблюдаемый объект. Все очень просто: кабель RS232, о котором мы говорили ранее, подсоединяется одним концом к прибору, а вторым к COM-порту сервера. На сервере устанавливается и запускается демон watchdogd, который через определенные промежутки времени посылает по кабелю Live-пакет. Устройство ловит его и понимает, что дела у сервера идут отлично и пока вмешиваться в работу системы не нужно. Два дополнительных провода подсоединяются к контактам кнопки power или reset. Довольно часто бывает, что после потери питания сервера, собранные в ATX-корпусах, не поднимаются самостоятельно при восстановлении подачи питания. Благодаря дополнительным проводам watchdog умеет правильно реанимировать их. Запуск сервера будет происходить точно так же, как если бы человек нажал на кнопку power.

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

С помощью стандартного кабеля подаем питание на прибор watchdog и подсоединяем к нему сервер с помощью кабеля RS232. Сервер запитываем пока не от watchdog, а от обычной электросети. Включаем черный и серый переключатели. Оба светодиода начинают синхронно мигать раз в секунду. Это означает что прибор находится в режиме ожидания контакта с демоном watchdogd. Поступаем мы так с той целью, чтобы неосторожными движениями в процессе настройки и отладки не уронить наш сервер.

Инсталляция программного продукта начинается довольно буднично с выбора каталога, где он впоследствии будет жить.

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

Вот тут нас уже поджидают первые неполадки. На снимке экрана четко видно, что нам предоставлена возможность самостоятельно выбрать, какие именно компоненты необходимо поставить. Свое волеизъявление можно выразить двумя путями, либо расставляя галочки рядом с нужными частями программного обеспечения, либо выбрав из ниспадающего меню одно из предопределенных типов установки. До тех пор, пока вы пользуетесь вариантом Полная установка, никаких проблем быть не должно. Но стоит только выбрать опцию Выборочная или Только документация, или отключить галочку напротив компонента Серверное ПО, как вы начинаете стремительно приближаться к граблям, забытым разработчиками в коде инсталлятора.

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

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

Закончив с установкой, приступаем к конфигурированию. Производится оно с помощью редактирования файла настроек, находящегося по следующему пути C:\Program Files\Comar\Watchdog\watchdog.conf. Тут нас ожидает очередной ляпсус, все комментарии в файле конфигурации написаны в кодировке koi8-r, что, скажем, выглядит довольно странно в системах Windows, родной кодировкой для которых является cp-1251. Комментарии почитать очень хочется, поэтому приходится одной копии файла дать расширение html и открыть ее в Internet Explorer, чтобы появилась возможность переключать кодировку текста, а вторую в редакторе, дабы вносить в файл изменения, закрыв глаза на каракули. Опции, на значения которых нужно обратить пристальное внимание, перечислены ниже:

  • rs_port - имя COM-порта, к которому подключен кабель от устройства watchdog. В моем случае это был COM1. Определить, какой порт будет у вас, можно, перебрав все возможные. Думаю, это будет нетрудно, ведь их всего четыре.
  • test_host - адрес тестируемого хоста. Обычно используется localhost.
  • test_port - порт тестируемой службы. Эта опция позволяет сервису watchdog проводить дополнительные проверки жизнеспособности машины. К примеру, может случиться так, что сервер отвечает по сети на ping, но все службы, кроме watchdog, на нем уже в нерабочем состоянии. Таким образом, указав номер порта интересующей службы, можно быть четко уверенным, что watchdog не перезапустит машину до тех пор, пока наблюдаемая служба жива. Для моего тестового сервера таким показателем служит 135-й порт, задействованный в стандартной реализации интерфейса вызова удаленных процедур (RPC). Ну а вы, к примеру, можете выбрать любой другой порт, на котором работает интересная для вас служба. Кандидатом на этот почетный пост может выступить, например, ssh, telnet, smtp или любая другая служба.
  • ctl_secret - секретная фраза, которая будет использоваться во время общения между демоном watchdogd и устройством. Такая мера применяется ради повышения безопасности, хотя мне кажется весьма сомнительным, что кто-то будет пытаться взломать устройство с целью получить контроль над ним. Непонятно, как сделать это без физического доступа к устройству. В то же время, если есть физический доступ, то, наверное, целесообразнее взламывать сам сервер.

После того как эти минимальные настройки выполнены, можно пытаться запустить сервис watchdog. Немного подумав, специально решил проверить, каким образом обстоит дело с отладочными сообщениями и насколько удобно будет проводить по ним диагностику неисправностей и ошибок конфигурирования. Задавшись такой целью, я намеренно внес ошибки в конфигурационный файл. Проблема была в том, что я не вписал секретное слово в опцию ctl_secret. Как и ожидалось, ни с первого, ни с какого-либо другого раза запустить сервис не удалось, в ответ на все попытки на экране появлялось вот такое сообщение.

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

Как видите, сообщение об ошибке, несмотря на свою краткость, точно и исчерпывающе описывает суть проблемы и явно указывает номер строки, а также опцию, на которой споткнулась программа. Удовлетворенные полученным результатом, ставим программе еще один жирный плюс. Исправив ошибку в конфигурационном файле, снова пытаемся запустить сервис. В этот раз все прошло как по маслу, сервис удачно стартовал, и в журнале системных событий можно увидеть следующие записи.

После того как демон успешно связался с устройством, зеленый светодиод начинает редко мигать. Такое состояние дел указывает на то, что сервер в порядке и устройство работает в штатном режиме. Плюс ко всему в директории C:\Program Files\Comar\Watchdog\log\ появятся файлы протокола, отражающие четкую последовательность происходивших событий и действий, предпринятых устройством в случае, если требовалось его вмешательство.

Думаю, что вышеприведенные записи в файле протокола, описывающие ход одного из моих экспериментов, довольно легко понять. Судя по надписям, я очень часто прерывал работу устройства и сервера самыми разными способами. Если обратиться к документации, то можно узнать, что именно означает каждое ключевое слово и какие события стоят за ним:
  • watchdog on - произошло включение устройства;
  • repower - watchdog выполнил прерывание питания сервера;
  • notify: boot - произошел первый запуск демона;
  • restart procedure - начата процедура перезапуска сервера;
  • normal shutdown - сервер начал плановую остановку, в отличие от события repower, четко видно, что тут вмешался пользователь и вручную остановил сервер;
  • watchdog locked - устройство вошло в режим блокировки;
  • watchdog unlocked - устройство разблокировано;
  • reset - watchdog перезапущен командой reset.

Изначально все события между перезагрузками сервера хранятся в энергонезависимой памяти устройства и в момент удачного контакта с демоном watchdogd записываются в файл протокола на жестком диске. Такая возможность мне кажется очень полезной, поэтому добавляем комплексу еще один плюс. Даже при многократных перезагрузках сервера, происходивших в отсутствие администратора, протокол не портится и продолжает пополняться событиями. Время, которым помечены все происходившие события, обязательно будет совпадать с временем системных часов сервера. Это возможно реализовать благодаря тому, что в устройство встроены автономные часы с питанием от батарейки. При получении Live-пакета часы устройства будет установлены на то же самое время, что и часы сервера. При таком потреблении батарейки должно хватить на долгие годы.

Кстати, при желании можно легко заглянуть внутрь прибора и самолично оценить простоту и изящество внутреннего устройства.

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

Итак, завершив начальные тесты, пришло время заняться серьезными вещами. Выключаем сервер через системное меню, созданное watchdog, или через использование программы wd_ctl. В результате этого действия сервер должен быть остановлен, и оба светодиода должны погаснуть.

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

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

А теперь давайте проверим, как устройство отреагирует на потерю сигнала, с этой целью отключаем от сервера кабель RS232 либо останавливаем демона. В зависимости от настроек устройство ждет прибытия сигнала от демона строго отведенное время и затем начнет подготовку к перезапуску сервера. Красный светодиод начнет часто мигать, указывая на то, что сейчас произойдет прерывание питания. Если присоединить кабель на место или вновь запустить демона, то положение нормализуется и снова редко замигает зеленый огонек, но мы делать этого не станем. Еще через несколько секунд красный огонек начнет гореть постоянно, и мы услышим характерный щелчок реле, разрывающего цепь питания. Сервер должен пройти через стандартную процедуру загрузки, интересно, что будет, если начать вмешиваться в этот процесс и не давать ему завершиться. С этой целью можно или нажать и удерживать любую клавишу, тем самым генерируя ошибку диагностики клавиатуры, либо сразу после завершения диагностики входить в настройку BIOS. Таким образом мы сможем имитировать потенциально опасные ситуации, такие как возникновение аппаратных неполадок на сервере или, к примеру, долгий процесс починки файловой системы. Как только время, отведенное на нормальную загрузку сервера (по умолчанию это пять минут) истечет, watchdog снова прервет питание. Но мы опять не даем серверу нормально загрузиться. Подождав еще пять минут, устройство снова перезагрузит сервер, в случае неудачи такая последовательность будет повторена еще один раз. Поняв, что так быстро сервер поднять невозможно, watchdog увеличит интервал ожидания до 30 минут.

Стоит заметить, что все настройки, влияющие на поведение watchdog, можно изменить сообразно собственному понимаю того, как должна вести себя мониторинговая система. Исхода у описанных выше событий может быть два: либо сервер поднимется после столь долгой паузы самостоятельно и watchdog это сразу же заметит, либо после нескольких проходов по циклу наступит рабочий день и администратор вмешается в ход событий. Такая интеллектуальность в выполнении функций позволяет быть уверенным, что watchdog не доведет сервер до смерти бесконечными перезапусками.

Закончив изуверские фокусы с Windows, перейдем к UNIX-системам. Тестирование устройства производилось под управлением ALT Linux Master 2.2 и FreeBSD 4.9. Процесс сборки и последующей инсталляции прост, как три копейки, а посему доступен даже самому неопытному администратору. Большим плюсом программного обеспечения watchdog является тот факт, что оно написано на языке C и не содержит в себе каких-либо объектно-ориентированных излишеств, поэтому для его компиляции не нужно никаких сторонних пакетов, только стандартные библиотеки языка C. Такая простота, заложенная в изначальный дизайн программы, позволяет перенести ее на любую UNIX-платформу без каких-либо существенных изменений.

Нынче же приступим к компиляции, для этого нужно всего лишь распаковать исходные тексты демона и утилит, затем перейти в получившуюся директорию и выполнить команду make. Конфигурационный файл будет скопирован в /etc/watchdog.conf, а демон и вспомогательные утилиты в /sbin. Протоколы работы будут складываться в /var/log/watchdog. Для Linux создаем свой собственный скрипт загрузки демона в каталоге /etc/rc.d, где хранятся сценарии запуска всех остальных системных демонов и не забываем создать на него ссылку из каталога представляющего соответствующий уровень выполнения. Для FreeBSD такую команду можно добавить в системный файл /etc/rc или создать свой скрипт в /usr/local/etc/rc.d. Если файл конфигурации демона watchdogd по какой-либо причине называется не /etc/watchdog.conf, то нужно обязательно передать демону правильное имя с помощью опции f. Кроме изменения настроек /etc/watchdog.conf, больше можно ничего не делать. Впрочем, изменять настройки несложно, так как файлы конфигурации идентичны для Windows и UNIX-платформ. В остальном же функционирование программы под управлением UNIX ничем не отличается от работы Windows.

Еще одним интересным для нас моментом является понятие мертвая зона. Во время загрузки сервера бывают такие моменты, когда процессы, происходящие внутри, лучше не прерывать. Примером такого опасного процесса может служить программа fsck, выполняющая починку файловой системы после неудачного завершения работы. В такие моменты самое лучшее, что может сделать watchdog, это не вмешиваться в естественный ход событий. Под UNIX такого эффекта добиться довольно легко, нужно всего лишь добавить в системные скрипты перед командой fdisk команду wd_ctl dzone_in, указывающую watchdog, что сервер вошел в мертвую зону и его нельзя тревожить. И затем команду wd_ctl dzone_out, уведомляющую устройство о том, что мертвая зона благополучно пройдена. По идее, никто не мешает нам описать не одну, а несколько мертвых зон при необходимости. К сожалению, под Windows выполнить подобные трюки, по крайней мере сейчас, невозможно по той простой причине, что не совсем понятно, как встроить выполнение своей программы в системный загрузчик, не нарушив ход его выполнения.

Мое повествование о работе с watchdog подходит к концу. Хотелось бы сказать, что комплекс кажется мне достаточно зрелым и надежным для того, чтобы его можно было с успехом применять в мониторинге серверов. Очень понравилась гибкость настроек и простота конфигурирования устройства. Собственноручно протестировав все режимы работы прибора, могу сказать, что его поведение точно соответствует характеристикам, заявленным разработчиками. За исключением мелких ошибок, о которых я писал выше по тексту, нескольких опечаток в документации и довольно скудного описания процесса инсталляции на UNIX-платформу недостатков найдено не было. Кстати, еще интересен вопрос о том, как watchdog будет справляться с оборудованием, у которого два независимых ввода питания и автоматическое переключение между ними. Видимо, для этого придется создавать какую-то новую модель устройства. В качестве пожелания разработчикам можно сказать, что хотелось бы видеть несколько устройств watchdog, собранных в один корпус, таким образом, разработка будет лучше всего подходить для монтажа в стандартную серверную стойку. В такой вид устройства можно было бы и веб-интерфейс встроить.

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

Со своей стороны скажем, что выявленные недочеты исправлены. Благодарим журнал "Системный администратор" и Андрея Бешкова за тестирование и за статью. Обсуждение статьи можно найти на нашем Форуме.

 

Тел: 8-499-502-02-99 (г. Москва), email: info@comar.ru, icq: 283175359.


Rambler's Top100