osod57 Опубликовано 3 Сентября 2018 Жалоба Поделиться Опубликовано 3 Сентября 2018 Добрый день! Возникла следующая ситуация: Понадобилось настроить для тестирования кластер горячего резервирования на двух координаторах hw1000 версии 4.2.0-1958. Схема следующая: Coordinator1 - 89.175.27.5 (eth0 - внешний), 192.168.120.3 (eth1 - внутренний) и 172.16.1.1 (eth2 - канал для связи со вторым координатором) Coordinator2 - 89.175.27.6 (eth0 - внешний), 192.168.120.4 (eth1 - внутренний) и 172.16.1.2 (eth2 -канал для связи с первым координатором) Active IP - 89.175.27.2 (внешний) и 192.168.120.2 (внутренний) В качестве testip на внешнем и внутреннем интерфейсах обоих координаторов указал адрес 127.0.0.1. Остальные параметры оставлены по умолчанию. Собственно сама проблема: запускаю первый координатор в активном режиме, второй координатор - в пассивном, при этом второй координатор спустя примерно минуту переводится в активный режим, а первый - в пассивный. Далее спустя несколько секунд второй координатор уходит в перезагрузку, после перезагрузки начинается опять то же самое: переход этого координатора в активный режим и опять перезагрузка. Адреса каналов связи координаторов пингуются без проблем. В чем может быть причина бесконечной перезагрузки одного из координаторов? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
azz Опубликовано 3 Сентября 2018 Жалоба Поделиться Опубликовано 3 Сентября 2018 без конфигов не разобраться ещё можно приложить выводы in sh mac Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
KIV Опубликовано 3 Сентября 2018 Жалоба Поделиться Опубликовано 3 Сентября 2018 failover show info показывает что связь между нодами есть? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
osod57 Опубликовано 3 Сентября 2018 Автор Жалоба Поделиться Опубликовано 3 Сентября 2018 1 минуту назад, KIV сказал: failover show info показывает что связь между нодами есть? да, связь между ними есть Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
osod57 Опубликовано 4 Сентября 2018 Автор Жалоба Поделиться Опубликовано 4 Сентября 2018 В 03.09.2018 в 15:30, azz сказал: без конфигов не разобраться ещё можно приложить выводы in sh mac Failover и iplir конфиги приложить? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
azz Опубликовано 4 Сентября 2018 Жалоба Поделиться Опубликовано 4 Сентября 2018 failover думаю будет достаточно, но если можете приложите iplir Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
osod57 Опубликовано 4 Сентября 2018 Автор Жалоба Поделиться Опубликовано 4 Сентября 2018 10 минут назад, azz сказал: failover думаю будет достаточно, но если можете приложите iplir Failover и in sh mac первого координатора [network] checktime = 10 timeout = 2 activeretries = 3 channelretries = 3 synctime = 5 fastdown = yes [channel] device = eth0 ident = external activeip = 89.175.27.2 passiveip = 89.175.27.5 testip = 127.0.0.1 checkonlyidle = yes [channel] device = eth1 ident = internal activeip = 192.168.120.2 passiveip = 192.168.120.3 testip = 127.0.0.1 checkonlyidle = yes [sendconfig] activeip = 172.16.1.2 sendtime = 60 device = eth2 config = yes keys = yes journals = yes port = 10090 [misc] activeconfig = /etc/iplirpsw passiveconfig = /etc/iplirpsw maxjournal = 30 #days reboot = yes [debug] debuglevel = 3 debuglogfile = syslog:daemon.debug [events] Address HWtype HWaddress Flags Mask Iface 172.16.1.2 ether 10:bf:48:d7:b7:61 C eth2Failover и in sh mac второго координатора [network] checktime = 10 timeout = 2 activeretries = 3 channelretries = 3 synctime = 5 fastdown = yes [channel] device = eth0 ident = external activeip = 89.175.27.2 passiveip = 89.175.27.6 testip = 127.0.0.1 checkonlyidle = yes [channel] device = eth1 ident = internal activeip = 192.168.120.2 passiveip = 192.168.120.4 testip = 127.0.0.1 checkonlyidle = yes [sendconfig] activeip = 172.16.1.1 sendtime = 60 device = eth2 config = yes keys = yes journals = yes port = 10090 [misc] activeconfig = /etc/iplirpsw passiveconfig = /etc/iplirpsw maxjournal = 30 #days reboot = yes [debug] debuglevel = 3 debuglogfile = syslog:daemon.debug [events] Address HWtype HWaddress Flags Mask Iface 172.16.1.1 ether 30:85:a9:a9:9b:97 C eth2 Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
zero Опубликовано 4 Сентября 2018 Жалоба Поделиться Опубликовано 4 Сентября 2018 Причина перезагрузок указывается в логе. Лог не очень читабельный для неподготовленного пользователя, но причина там точно есть. Логи читали? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Vintik Опубликовано 4 Сентября 2018 Жалоба Поделиться Опубликовано 4 Сентября 2018 Точно такое же было не давно совсем, но там бывший коллега забил на это и бросил. Но если и у вас такое же то думаю это уже не случайность. Интересно чем закончится. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
osod57 Опубликовано 5 Сентября 2018 Автор Жалоба Поделиться Опубликовано 5 Сентября 2018 18 часов назад, zero сказал: Причина перезагрузок указывается в логе. Лог не очень читабельный для неподготовленного пользователя, но причина там точно есть. Логи читали? Имеете в виду лог failover view? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
osod57 Опубликовано 5 Сентября 2018 Автор Жалоба Поделиться Опубликовано 5 Сентября 2018 18 часов назад, Vintik сказал: Точно такое же было не давно совсем, но там бывший коллега забил на это и бросил. Но если и у вас такое же то думаю это уже не случайность. Интересно чем закончится. А техподдержка ничего не ответила вам по этому поводу? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
zero Опубликовано 5 Сентября 2018 Жалоба Поделиться Опубликовано 5 Сентября 2018 38 минут назад, osod57 сказал: Имеете в виду лог failover view? Да. Там будет указано резюме по переключению и его время. Сама причина исследуется по логу. Пасссивная может стать активной только в одном случае: перестала видеть arp активных адресов. Это проблема скорее коммутации. Очень полезно вручную одну ноду стартовать в активном режиме, а вторую в пассивном и тут же остановить на обеих failover. Так они не перезагрузятся. Следом смотрите mac-адреса на пассивной, видит ли она arp активных ip-адресов. Или решение гораздо проще. Снимите логи с обеих нод и отправьте в ТП. Там скажут быстрее. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
osod57 Опубликовано 5 Сентября 2018 Автор Жалоба Поделиться Опубликовано 5 Сентября 2018 30 минут назад, zero сказал: Да. Там будет указано резюме по переключению и его время. Сама причина исследуется по логу. Пасссивная может стать активной только в одном случае: перестала видеть arp активных адресов. Это проблема скорее коммутации. Очень полезно вручную одну ноду стартовать в активном режиме, а вторую в пассивном и тут же остановить на обеих failover. Так они не перезагрузятся. Следом смотрите mac-адреса на пассивной, видит ли она arp активных ip-адресов. Или решение гораздо проще. Снимите логи с обеих нод и отправьте в ТП. Там скажут быстрее. Запустил один координатор в активном режиме, затем сразу же другой координатор - в пассивном, затем в той же последовательности остановил failover. Вот что показала команда in sh mac: Address HWtype HWaddress Flags Mask Iface 172.16.1.2 ether 10:bf:48:d7:b7:61 C eth2 89.172.27.2 (incomplete) eth0 192.168.120.2 (incomplete) eth1 Подскажите, это и есть проблемы с коммутацией и можно ли их как-то решить, допустим, прописанием роутов? Причем при отключенном failover с обоих координаторов пингуются абсолютно все интерфейсы этих координаторов. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
zero Опубликовано 5 Сентября 2018 Жалоба Поделиться Опубликовано 5 Сентября 2018 activeip = 89.175.27.2 activeip = 192.168.120.2 89.172.27.2 (incomplete) eth0 192.168.120.2 (incomplete) eth1 У Вас нет ни одного arp активных интерфейсов на пассивной ноде. И при такой ситуации гаратированно будет пассивная переходить в активный режим. Эту проблему нельзя решить маршрутизацией, так как одинаковые интерфейсы нод должны быть в одном коммутаторе и между ними должны ходить arp. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
osod57 Опубликовано 5 Сентября 2018 Автор Жалоба Поделиться Опубликовано 5 Сентября 2018 55 минут назад, zero сказал: activeip = 89.175.27.2 activeip = 192.168.120.2 89.172.27.2 (incomplete) eth0 192.168.120.2 (incomplete) eth1 У Вас нет ни одного arp активных интерфейсов на пассивной ноде. И при такой ситуации гаратированно будет пассивная переходить в активный режим. Эту проблему нельзя решить маршрутизацией, так как одинаковые интерфейсы нод должны быть в одном коммутаторе и между ними должны ходить arp. Большое спасибо, проблема решилась, пока что нет свободных коммутаторов, поэтому подключил друг в друга соответствующие интерфейсы обоих координаторов и вуаля! Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Vintik Опубликовано 5 Сентября 2018 Жалоба Поделиться Опубликовано 5 Сентября 2018 4 часа назад, osod57 сказал: А техподдержка ничего не ответила вам по этому поводу? Я ему предлагал поработать и даже людей для этого проекты выделяли, но видно желание не было, потому он ушёл и это всё разобралось. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Vintik Опубликовано 5 Сентября 2018 Жалоба Поделиться Опубликовано 5 Сентября 2018 2 часа назад, osod57 сказал: и вуаля! + Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
NewYear Опубликовано 26 Декабря 2018 Жалоба Поделиться Опубликовано 26 Декабря 2018 В 05.09.2018 в 16:02, zero сказал: activeip = 89.175.27.2 activeip = 192.168.120.2 89.172.27.2 (incomplete) eth0 192.168.120.2 (incomplete) eth1 У Вас нет ни одного arp активных интерфейсов на пассивной ноде. И при такой ситуации гаратированно будет пассивная переходить в активный режим. Эту проблему нельзя решить маршрутизацией, так как одинаковые интерфейсы нод должны быть в одном коммутаторе и между ними должны ходить arp. Здравствуйте. Напишу в эту же тему. Возникли непонятки с написанием данной команды. Если правильно понял, то писать нужно: failover view 01.01.2018.01.01.01 Но ничего не получается. Просьба написать пример данной команды. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
R.Sheyn Опубликовано 26 Декабря 2018 Жалоба Поделиться Опубликовано 26 Декабря 2018 Конец периода тоже обязательный параметр, а вот время как раз необязательный. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
NewYear Опубликовано 26 Декабря 2018 Жалоба Поделиться Опубликовано 26 Декабря 2018 1 час назад, R.Sheyn сказал: Конец периода тоже обязательный параметр, а вот время как раз необязательный. напишите, плиз пример. Я пробовал и так и так, разделителем пробовал тире. Ругается координатор. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
R.Sheyn Опубликовано 26 Декабря 2018 Жалоба Поделиться Опубликовано 26 Декабря 2018 Пример из документации. Но это для актуальных версий 4х, для 3 не помню была ли такая команда. Вы просто не написали какая у Вас версия. failover view 20.10.2014.08.00.00 21.10.2014.19.00.00 Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
zero Опубликовано 26 Декабря 2018 Жалоба Поделиться Опубликовано 26 Декабря 2018 failover view 20.10.2014.00.00.00 21.10.2014.00.00.00 failover view 20.10.2014 21.10.2014 так в актуальной версии работает. Но это если у Вас кластер. В одиночной конфигурации даже failover view нет. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
NewYear Опубликовано 27 Декабря 2018 Жалоба Поделиться Опубликовано 27 Декабря 2018 Всем спасибо! Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Рекомендуемые сообщения
Присоединиться к обсуждению
Вы можете ответить сейчас, а зарегистрироваться позже. Если у вас уже есть аккаунт, войдите, чтобы ответить от своего имени.