Jump to content

Recommended Posts

Добрый день! Возникла следующая ситуация:
Понадобилось настроить для тестирования кластер горячего резервирования на двух координаторах 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. Остальные параметры оставлены по умолчанию.
Собственно сама проблема: запускаю первый координатор в активном режиме, второй координатор - в пассивном, при этом второй координатор спустя примерно минуту переводится в активный режим, а первый - в пассивный. Далее спустя несколько секунд второй координатор уходит в перезагрузку, после перезагрузки начинается опять то же самое: переход этого координатора в активный режим и опять перезагрузка. Адреса каналов связи координаторов пингуются без проблем. В чем может быть причина бесконечной перезагрузки одного из координаторов?

Share this post


Link to post
Share on other sites

без конфигов не разобраться

ещё можно приложить выводы in sh mac

Share this post


Link to post
Share on other sites

failover show info показывает что связь между нодами есть?

Share this post


Link to post
Share on other sites
1 минуту назад, KIV сказал:

failover show info показывает что связь между нодами есть?

да, связь между ними есть

Share this post


Link to post
Share on other sites
В 03.09.2018 в 15:30, azz сказал:

без конфигов не разобраться

ещё можно приложить выводы in sh mac

Failover и iplir конфиги приложить? 

Share this post


Link to post
Share on other sites
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                     eth2


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.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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
18 часов назад, zero сказал:

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

Имеете в виду лог failover view?

Share this post


Link to post
Share on other sites
18 часов назад, Vintik сказал:

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

А техподдержка ничего не ответила вам по этому поводу?

Share this post


Link to post
Share on other sites
38 минут назад, osod57 сказал:

Имеете в виду лог failover view?

Да. Там будет указано резюме по переключению и его время. Сама причина исследуется по логу. Пасссивная может стать активной только в одном случае: перестала видеть arp активных адресов. Это проблема скорее коммутации. 

 Очень полезно вручную одну ноду стартовать в активном режиме, а вторую в пассивном и тут же остановить на обеих failover. Так они не перезагрузятся. Следом смотрите mac-адреса на пассивной, видит ли она arp активных ip-адресов.

  Или решение гораздо проще. Снимите логи с обеих нод и отправьте в ТП. Там скажут быстрее.

Share this post


Link to post
Share on other sites
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 с обоих координаторов пингуются абсолютно все интерфейсы этих координаторов.

Share this post


Link to post
Share on other sites

activeip = 89.175.27.2

activeip = 192.168.120.2

89.172.27.2                                 (incomplete)                                            eth0
192.168.120.2                            (incomplete)                                             eth1

У Вас нет ни одного arp активных интерфейсов на пассивной ноде. И при такой ситуации гаратированно будет пассивная переходить в активный режим.

Эту проблему нельзя решить маршрутизацией, так как одинаковые интерфейсы нод должны быть в одном коммутаторе и между ними должны ходить arp.

 

 

Share this post


Link to post
Share on other sites

 

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.

 

 

Большое спасибо, проблема решилась, пока что нет свободных коммутаторов, поэтому подключил друг в друга соответствующие интерфейсы обоих координаторов и вуаля!

Share this post


Link to post
Share on other sites
4 часа назад, osod57 сказал:

А техподдержка ничего не ответила вам по этому поводу?

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

Share this post


Link to post
Share on other sites
В 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

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

Share this post


Link to post
Share on other sites

Конец периода тоже обязательный параметр, а вот время как раз необязательный.

Share this post


Link to post
Share on other sites
1 час назад, R.Sheyn сказал:

Конец периода тоже обязательный параметр, а вот время как раз необязательный.

напишите, плиз пример.
Я пробовал и так и так, разделителем пробовал тире. Ругается координатор.

Share this post


Link to post
Share on other sites

Пример из документации. Но это для актуальных версий 4х, для 3 не помню была ли такая команда. Вы просто не написали какая у Вас версия.

failover view 20.10.2014.08.00.00 21.10.2014.19.00.00
 

Share this post


Link to post
Share on other sites

failover view 20.10.2014.00.00.00  21.10.2014.00.00.00

failover view 20.10.2014  21.10.2014

так в актуальной версии работает.

Но это если у Вас кластер. В одиночной конфигурации даже failover view нет.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.