☰

Pacemaker: остановка ресурса после его миграции N раз из-за сбоя

tag-icon • tag-icon cluster pacemaker
Pacemaker: остановка ресурса после его миграции N раз из-за сбоя

У меня есть конфигурация с 5 узлами, 4 из которых могут размещать ресурсы, а 1 ресурс. Я хочу полностью остановить ресурс после миграции N раз с узла на узел.

Итак, пример сценария будет таким: ресурс VIP1 запущен на узле one; его монитор выходит из строя, migration-thresholdдостигается, он перемещается на узел two; затем он снова выходит из строя там и перемещается на узел three; а затем он снова выходит из строя, но какое-то правило (которое я ищу) не позволяет ему переместиться на узел four. Мне нужен какой-то счетчик миграции, я полагаю.

Это тестовая конфигурация, в реальности у меня будет больше узлов и больше ресурсов. Поэтому я хотел бы, чтобы конфигурация была максимально простой. Я полагаю, что могу добиться этого, используя стратегию выбора или отказа от местоположения для каждого ресурса, но это не просто и не легко поддерживать. Есть ли лучший способ?

P.S. При текущей конфигурации, если я заполню свой VIP hping, он будет циклически проходить по всем узлам, прежде чем полностью остановится (потому что у него больше нет узлов для работы, пока я не очистлю его или не добавлю опцию failure-timeout)

Версии:

[~] corosync -v
Corosync Cluster Engine, version '2.3.6'
Copyright (c) 2006-2009 Red Hat, Inc.
[~] crm --version
crm 2.2.0
[~] cat /etc/debian_version
8.5

Конфигурация кардиостимулятора:

[~] crm configure show
node 1: one
node 2: two
node 3: three
node 4: arbitr \
        attributes standby=on
node 5: four
primitive VIP1 IPaddr2 \
        params ip=10.10.11.230 cidr_netmask=22 \
        op monitor interval=1s timeout=40ms \
        meta migration-threshold=1 target-role=Started
location preferOne VIP1 50: one
property cib-bootstrap-options: \
        dc-version=1.1.14-70404b0 \
        cluster-infrastructure=corosync \
        cluster-name=debian \
        stonith-enabled=false \
        last-lrm-refresh=1474984960 \
        have-watchdog=false

EDIT: Контекст и история всей конфигурации таковы: у нас есть два балансировщика нагрузки с LVS, которые проксируют трафик на наши фронтенды. Высокая доступность раньше достигалась с помощью простой конфигурации keepalived и 2 VIP (конфигурация active-active; в обычной ситуации у каждого LVS есть 1 VIP). Но в последнее время некоторые ребята начали регулярно устраивать нам DDoS, и настройка keepalived больше не работает так, как ожидалось: даже если они делают DDoS только на 1 VIP, т. е. на 1 хост, его keepalived теряет входящий трафик с другого хоста, захватывает второй VIP и парализует всю систему.

Поэтому мы подумали, что нам следует а) найти способ управлять VIP-клиентами с кворумом, чтобы избежать разделения мозга; б) по крайней мере удвоить количество хостов LVS.

Итак, я протестировал pacemaker+corosync, и его конфигурация действительно проста, когда у нас есть два активных и один резервный узел. Как и ожидалось, когда один из VIP подвергается DDoS, этот VIP сначала мигрирует на другой узел, а затем полностью отключается. По мере добавления узлов этот «обход ресурсов» становится длиннее, что не совсем то, что нам нужно: мы хотим, чтобы VIP отключался как можно скорее, но также мы, конечно, хотим оставить возможность автоматического восстановления после внутренней аппаратной проблемы (если узел внезапно выйдет из строя, FE). Поэтому я подумал... может быть, есть способ мигрировать ресурс только ОДИН РАЗ, и если все равно не получится, то покончить с этим. Спасает нас от аппаратных сбоев; экономит нам время, когда мы находимся под частичным DDoS.

Вот, пожалуй, и все, извините, если слишком подробно. Если мы изначально выбрали не тот инструмент для решения этой проблемы, пожалуйста, дайте мне знать. (Конечно, мы защищаемся от DDoS другими методами, но если атака все же пройдет, мы хотим минимизировать ущерб).

решение1

Это определенно интересный вариант использования, спасибо, что поделились...

Пока ваши VIP-ы подвергаются DDoS-атакам, они, вероятно, не могут надежно пинговать. Возможно, вам стоит взглянуть на ресурс-агент 'ping' для Pacemaker.

В документации clusterlabs об этом кратко упоминается здесь: http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ch09s03s03.html

Более подробную информацию можно найти, проверив информацию об агенте ресурсов с помощью предпочитаемого вами инструмента управления конфигурацией кластера:

# crm ra info ping
--or--
# pcs resource describe ping

Надеюсь, это будет полезно.

Связанный контент