Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: 1
RSS
System hang - hearbeat problems ?
 
OS: Gentoo

Есть два сервака которые работают под кластер. Связка heartbeat + drbd

Серваки работали без проблем 2 года. Потом буум, один из серваков (cluster1) начал зависать до такой степени, что даже не принимал команды halt -p, reboot, kiil -9 1. Хотя пинги шли, но по SSH не вазможно было конектится, сессия зависала после ввода username. По SSH можно достучатся только через второй (cluster2) сервак.
Подумал может время варнинга и dead time слишком коротки из-за нагурзки (хотя там нечего особенного не крутится) и поменял. Сейчас стоит вот так.

ha.cf
Код
keepalive 5
warntime 10
deadtime 20
initdead 40

и это не помогло. Сейчас отключил инит скрипты для heartbeat & drbd на первом серваке. И сервак по себе работает. Хочу просто узнать вся система зависает из-за heartbeat или что-то другое...
Хотя с другой стороны ни как не врубаюсь как из-за одной софтины может так зависать вся система в то время когда все нормально работало 2 года. Другое предположение на хард ОЗУ или винт. Следуюшим шагом будет проверка этого железа если не найдётся проблема.

И в логах всё странно.
На cluster1
Код
heartbeat[6470]: 2011/01/15_00:14:57 info: Received shutdown notice from 'cluster2'.
heartbeat[8827]: 2011/01/15_00:14:57 info: acquire all HA resources (standby).
heartbeat[6470]: 2011/01/15_00:14:57 info: Resources being acquired from cluster2.
heartbeat[6470]: 2011/01/15_00:14:57 info: Heartbeat restart on node cluster2
heartbeat[6470]: 2011/01/15_00:14:57 info: Status update for node cluster2: status init
heartbeat[6470]: 2011/01/15_00:14:57 info: Status update for node cluster2: status up

в то время как на втором
Код
heartbeat[6471]: 2011/01/15_00:15:11 WARN: node cluster1: is dead
heartbeat[6471]: 2011/01/15_00:15:11 info: Dead node cluster1 gave up resources.
heartbeat[6471]: 2011/01/15_00:15:11 info: Link cluster1:eth0 dead.
ipfail[6959]: 2011/01/15_00:15:11 info: Status update: Node cluster1 now has status dead
ipfail[6959]: 2011/01/15_00:15:13 info: NS: We are still alive!
ipfail[6959]: 2011/01/15_00:15:13 info: Link Status update: Link cluster1/eth0 now has status dead
ipfail[6959]: 2011/01/15_00:15:14 info: Asking other side for ping node count.
ipfail[6959]: 2011/01/15_00:15:14 info: Checking remote count of ping nodes.
heartbeat[6471]: 2011/01/15_00:15:47 info: Link cluster1:eth0 up.
ipfail[6959]: 2011/01/15_00:15:47 info: Link Status update: Link cluster1/eth0 now has status up
heartbeat[6471]: 2011/01/15_00:16:07 info: Link cluster1:eth0 dead.
ipfail[6959]: 2011/01/15_00:16:07 info: Link Status update: Link cluster1/eth0 now has status dead

Логи для обеих серверов - /var/log/ha/log
cluster1
cluster2

Какие будут рекомендации ?
 
Сдается мне, что они связь с друг дружкой теряют (взаимный пинг). И начинается маппет-шоу под названием split-brain, когда каждая из нод считает себя основной. Зырь сюда:
Цитата

#
heartbeat[6470]: 2011/01/15_00:15:02 ERROR: Both machines own our resources!
#
heartbeat[6470]: 2011/01/15_00:15:02 ERROR: Both machines own foreign resources!
#
heartbeat[6470]: 2011/01/15_00:15:02 ERROR: Both machines own our resources!
#
heartbeat[6470]: 2011/01/15_00:15:02 ERROR: Both machines own foreign resources!
Проверь патчкорд, обжимку коннекторов и сами сетевухи (мож глючить стали). Помнится, у тебя ноды были друг с дружкой соединены прямым патчкордом (сетевуха в сетевуху)? И эта. На всяк случай уточню - а в качестве внешнего источника пинга у тебя в конфиге что-нить задано? Я, помнится, там адрес шлюза на каждой из нод прописывал.
 
Кстати. У меня, когда ещё был кластер (сейчас убрал его в силу ряда причин) - файловая система периодически переходила read-only. Долго копался, но выяснил, что при создании fdisk-ом разделов для drbd надо около каждого из них делать "дырку" в пару сотен мегабайт. Сейчас уже точно нюансов не помню, но что-то связано с работой самого drbd и того, что у него называется экстентами.
Изменено: SOLDIER - 23.01.2011 22:15:44
 
Насчет патчкордов и конекторов поменяю на всякий спасибо.

там 2 интерфейса на каждой. Прямым патчкородом соединены для синхронизации разделов (drbd). А heartbeat следит за нодами через "внешний" интерфейс. Я тут ещё попросил дать мне логи из мониторинга. Если внешний мониторинг покажет задержки или потери то думаю, что проблема в сети. Между нодами стоит 5 или 8 портовый тупой длинк свитч. За одно и это надо поменять, не знаю отключался ли он за эти 2 года.

А насчет read-only странно, я даже не смотрел на это. Файловая система это про дрбд раздел или системный ?
 
Я до работы дойду, если не забуду - кину тебе конфиг heartbeat. За доступностью нод он следит. Я просто помню, что там 2 параметра было. Один - взаимный пинг между 2-мя нодами (через прямой линк, естественно). А второй - как раз пинг шлюза (где у тебя свич стоит в промежутке). А вообще - поднял бы в стороне (не на кластере) cacti - и тупо бы мониторил доступность снаружи обоих нод (пингом простейшим). И кстати - у тебя какая схема? У меня было так. Внутренние интерфейсы (соединенные друг в дружку) - 192.168.1.1, 192.168.1.2 (они же - для синхронизации по drbd). Внешний 10.10.10.20, 10.10.10.21. heartbeat поднимает виртуальный интерфейс на одной из нод - eth0:0 - 10.10.10.22. Этот же интерфейс используется для доступа к службам кластера. Плюс такой схемы - ты в случае глюков кластера всегда имеешь прямой доступ (отдельный) к нодам.

Цитата
°°°Trojan°°°™ пишет:
А насчет read-only странно, я даже не смотрел на это. Файловая система это про дрбд раздел или системный ?

Раз не смотрел - значит не напоролся на эти грабли. :) Файловая система - это про системные разделы. Которые потом прописываются в конфиге drbd. У меня их было 2 (синхронизируемых) - sda3 и sda4. При разбивке (вернее, последуюшей переразбивке - пришлось двигать файловые системы потом) я сделал по дырке после sda3 и sda4. Вроде по 150-200 мег. Их использовал как раз drbd для своих экстентов. Но это зависит от конфига drbd - там как-то служебные данные можно держать или на самом разделе (sda3,4) или вот в этих "дырках". Просто сейчас нюансов не помню. Да и объяснение там было достаточно мутное.
 
Схема у меня такая же.

Цитата
SOLDIER пишет:
Один - взаимный пинг между 2-мя нодами (через прямой линк, естественно).
Только вот взаимный пинг у меня удет на внешних интерфейсах  :oops:  + IP адресс одного из сервака для мониторинга если один из нодов будет в дауне.

Насчет мониторинга есть. Написал об этом (:. Вот жду сейчас, думаю будет сегодня.

Вот полный конфиг навсякий.
Код
# What interfaces to heartbeat over?
ucast eth0 10.0.0.31
ucast eth0 10.0.0.32

# keepalive: how many seconds between heartbeats
keepalive 5

# Time in seconds before issuing a "late heartbeat" warning in the logs.
warntime 10

# Node is pronounced dead after 30 seconds.
deadtime 20

# With some configurations, the network takes some time to start working after a reboot.
# This is a separate "deadtime" to handle that case. It should be at least twice the normal deadtime.
initdead 40

# Mandatory. Hostname of machine in cluster as described by uname -n.
node    cluster1
node    cluster2

# When auto_failback is set to on once the master comes back online, it will take
# everything back from the slave.
auto_failback off

# Some default uid, gid info, This is required for ipfail
apiauth default uid=nobody gid=cluster
apiauth ipfail uid=cluster
apiauth ping gid=nobody uid=nobody,cluster

# This is to fail over if the outbound network connection goes down.
respawn cluster /usr/lib/heartbeat/ipfail

# IP to ping to check to see if the external connection is up.
ping 10.0.0.15
deadping 20

debugfile /var/log/ha/debug

# File to write other messages to
logfile /var/log/ha/log

# Facility to use for syslog()/logger
logfacility     local0
 
Вот мои настройки из архива (ha.cf):
Цитата

logfile /var/log/ha-log
logfacility     local0
keepalive 1
deadtime 10
warntime 2
initdead 120
ucast eth1 192.168.0.2 (на этом серваке IP 192.168.0.1 - то есть он пингует вторую ноду через второй интерфейс - напрямую).
auto_failback on
node    cluster1 cluster2
ping 10.10.10.1 (а вот это и есть пинг внешнего роутера - см. выше настройки)
respawn root /usr/lib/heartbeat/ipfail
apiauth ipfail gid=root uid=root
Вроде все.
 
Цитата
SOLDIER пишет:
ucast eth1 192.168.0.2 (на этом серваке IP 192.168.0.1 - то есть он пингует вторую ноду через второй интерфейс - напрямую).
А здесь не должно стоять и ИП второго нода ? Или на другой махине вайс верса ?
Спрашиваю потому что мне помнится что долбили в доке на каждой странице, что конфиг должен быть идентичным на обеих
 
Во нашлось. Вообщем мой конфиг будет работать.
Note that ucast directives which go to the local machine are effectively ignored. This allows the ha.cf directives on all machines to be identical.

Рекомендуеш поменять мониторинг на внутренный интерфейс ?
 
Цитата
°°°Trojan°°°™ пишет:
Рекомендуеш поменять мониторинг на внутренный интерфейс ?

Попробуй, по крайней мере. Ситуация split-brain - самая мерзкая из всего, что может случиться. Даже мой вариант read-only менее катастрофичен. :)
 
а можно вопрос, он канешно не очень в тему а какой был уход за серверами на протяжении двух лет, что делалось механически так и програмной средой?
 
Механически - периодически вылетали диски из RAID-массива. Там на серверах был ещё и RAID1. Судя по всему - виновато было неудачно подобранное железо (то ли мать, то ли контроллер 3Ware + диски WD). Приходилось выдергивать диск (он на салазках был) и опять вставлять и потом руками задавать REBUILD. По программной части? Я вон выше писал про то, что файловая система переходила в режим read-only. Но тут изначально моя вина - я неправильно выбрал метод хранения мета-данных (как ПОТОМ оказалось). :) А в общем и в целом - система работала. На ней крутился биллинг (UTM5), база мускульная того же биллинга + свои базы для работы и ещё данные по трафику - сливаемые по НетФлоу с магистральной циски. Потом в силу ряда причин перешли на другой биллинг и кластер как-то сам собой отошел. Я сейчас его на 2 сервера раздербанил. :)
 
Кстати - первоначальная настройка делалась по статейке на сайте NetUP. Потом уже допиливалось, дотюнивалось.
 
Понимаю, что уже поздновато но так и не написал. Может кто то столкнется.
Проблема решилась изменением сетевухи у одной из нод , хотя все тесты были нормальными и в системных логах / дмесг было пусто.
Страницы: 1
Читают тему