Я установил три виртуальные машины Centos 7 KVM на хосте Centos 7 с целью тестирования различных аспектов конфигурации кластера перед развертыванием производственной системы.
Узлы называются clua, club и cluc. Настроено несколько ресурсов:
Я тестировал различные сценарии сбоев. Проблема, которая вызывает проблемы, заключается в том, что я заставляю узлы терять контакт друг с другом, отключая интерфейсы на двух из трех узлов.
В тесте здесь у меня ifdownизменили интерфейсы на clua и cluc, оставив club в покое. Я подтвердил, что не могу пинговать между узлами в этом состоянии.
В клубе он делает более или менее то, что я ожидал:
root@itkclub ~ # pcs status
Cluster name: tclu
Stack: corosync
Current DC: club (version 1.1.15-11.el7_3.4-e174ec8) - partition WITHOUT quorum
Last updated: Thu Apr 6 16:23:28 2017 Last change: Thu Apr 6 16:18:33 2017 by root via cibadmin on clua
3 nodes and 12 resources configured
Node clua: UNCLEAN (offline)
Node cluc: UNCLEAN (offline)
Online: [ club ]
Full list of resources:
Clone Set: dlm-clone [dlm]
dlm (ocf::pacemaker:controld): Started clua (UNCLEAN)
dlm (ocf::pacemaker:controld): Started cluc (UNCLEAN)
Started: [ club ]
Clone Set: clvmd-clone [clvmd]
clvmd (ocf::heartbeat:clvm): Started clua (UNCLEAN)
clvmd (ocf::heartbeat:clvm): Started cluc (UNCLEAN)
Started: [ club ]
Clone Set: varopt_fs-clone [varopt_fs]
varopt_fs (ocf::heartbeat:Filesystem): Started clua (UNCLEAN)
varopt_fs (ocf::heartbeat:Filesystem): Started cluc (UNCLEAN)
Started: [ club ]
Clone Set: virsh-fencing-clone [virsh-fencing]
virsh-fencing (stonith:fence_virsh): Started clua (UNCLEAN)
virsh-fencing (stonith:fence_virsh): Started cluc (UNCLEAN)
Started: [ club ]
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
Но на обоих других узлах (тех, где я ifdowned интерфейсы) похоже, что что-то не так:
root@itkcluc ~ # pcs status
Cluster name: tclu
Stack: corosync
Current DC: club (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Thu Apr 6 16:26:01 2017 Last change: Thu Apr 6 16:18:33 2017 by root via cibadmin on clua
3 nodes and 12 resources configured
Online: [ clua club cluc ]
Full list of resources:
Clone Set: dlm-clone [dlm]
Started: [ clua club cluc ]
Clone Set: clvmd-clone [clvmd]
Started: [ clua club cluc ]
Clone Set: varopt_fs-clone [varopt_fs]
Started: [ clua club cluc ]
Clone Set: virsh-fencing-clone [virsh-fencing]
Started: [ clua club cluc ]
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
root@itkcluc ~ # ping club
PING club (192.168.1.12) 56(84) bytes of data.
^C
--- club ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms
root@itkcluc ~ # ping clua
PING clua (192.168.1.2) 56(84) bytes of data.
^C
--- clua ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms
Почему кардиостимулятор на clua и cluc не обнаружил, что он не может разговаривать ни с одним из других узлов?
Какова правильная процедура восстановления, когда он переходит в такое состояние?
Ни у одного из оставшихся узлов нет кворума, поэтому никакие действия STONITH не могут быть выполнены, и поэтому никакие действия кластера не считаются «безопасными».
Что ставили кластеры no-quorum-policy собственность? Это freeze случайно? Вы не можете использовать stop, который используется по умолчанию, потому что узел без кворума не сможет остановить свои ресурсы, поскольку GFS2 требует кворума для размонтирования или иного доступа к своим данным.
Также, club - это DC (назначенный контроллер) в вашем примере; он отслеживает ресурсы кластера. Другим узлам необходимо достичь кворума, прежде чем они смогут избрать новый DC.
В кластере из трех узлов вероятность отказа сетевых адаптеров двух узлов в одно и то же время очень маловероятна. Однако, если вас по-прежнему беспокоит какая-либо причина, вы можете добавить в кластер дополнительные узлы, которые будут действовать исключительно как узлы кворума (используйте -inf: ограничения местоположения, чтобы держать ресурсы подальше от них), пока этот риск не станет достаточно малым.
Чтобы выйти из этого, я бы просто сбросил все три поля «вручную»: echo b > /proc/sysrq-trigger
Я столкнулся с подобной проблемой. В моем случае, вместо того, чтобы отключать сетевой интерфейс на данном узле, я изменил группу безопасности AWS, чтобы запретить обмен данными между clua и cluc (где club является первичным).
Когда я это сделал, все узлы кластера, казалось, думали, что все узлы подключены к сети. Отсутствие связи между clua и cluc остается незамеченным всеми узлами в течение примерно 20 минут. После этого узлы показали следующий статус:
clua пила club и cluc как офлайн и все ресурсы остановленыclub пила clua в автономном режиме, и все ресурсы работают на clubcluc пила clua в автономном режиме, и все ресурсы работают на clubВ вашем случае состояние изменилось после более длительного ожидания?