с момента использования CentOS 7 мы перешли с обычной настройки heartbeat на pacemker.
В основном у нас есть IP-ресурсы, которые активны на одном узле и переключаются на второй узел, если происходит отказ. Также мы выполняем некоторые скрипты в случае отказа. Ничего особенного.
Чтобы ресурсы всегда запускались на основном узле, я использую
pcs constraint location Cluster_IP prefers server1=master-server
Я также использую
pcs resource defaults resource-stickiness=INFINITY
для предотвращения обратного перемещения ресурсов после сбоя.
У меня это отлично работает, если главный узел выходит из строя (например, из-за сбоя оборудования).
Поскольку для меня не проблема, если аварийное переключение займет некоторое время, я хотел бы реализовать некоторую задержку на случай короткого разделения мозга.
Прежде чем что-либо делать, подчиненное устройство должно подождать около 2 минут, прежде чем оно перехватит управление, на случай, если главное устройство снова будет доступно в течение этих ~2 минут.
Мне было интересно, как лучше всего это сделать?
решение1
Я никогда не устанавливал тайм-аут токена в Corosync больше 10 секунд, но вы можете попробовать увеличить/установить значение tokenв вашем файле corosync.confto 120000(120 секунд в миллисекундах). tokenдолжно быть определено в totem{}разделе вашего corosync.conf; man corosync.confдля получения более подробной информации.
Это должно помешать Corosync объявлять узел неработоспособным в течение 120 секунд при сбоях в работе сети.
решение2
Вы можете изменить интервал мониторинга ресурса с помощью , op monitor interval=Nsгде N- это количество секунд, а затем установить migration-thresholdдля ресурса значение 2. Имейте в виду, что при настройке 120sвы можете увидеть общую задержку в 120-240 с в зависимости от того, когда в интервале мониторинга произошел первоначальный сбой.
Есть и другие предостережения, в том, что счетчик неудач, примененный к, migration-thresholdне сбрасывается при успехе. Чтобы сделать это, вам также нужно будет установить failure-timeoutили вручную вмешаться.
С op monitor interval=120s, migration-threshold=2, failure-timeout=121sи вашей resource-stickinessнастройкой вам нужно будет протестировать, чтобы убедиться, что это обеспечивает ожидаемую вами функциональность и как счетчики сбоев ведут себя при восстановлении исходного мастера. Это может потребовать ручного вмешательства, но я не уверен на 100% в этом