☰

Pacemaker: detiene el recurso después de migrar N veces debido a una conmutación por error

tag-icon • tag-icon cluster pacemaker
Pacemaker: detiene el recurso después de migrar N veces debido a una conmutación por error

Tengo una configuración con 5 nodos, 4 capaces de alojar recursos y 1 recurso. Lo que quiero hacer es hacer que el recurso se detenga por completo después de migrar N veces de un nodo a otro.

Entonces, un escenario de muestra sería: recurso VIP1 ejecutándose en el nodo one; su monitor falla, migration-thresholdse alcanza, se mueve al nodo two; luego vuelve a fallar allí y se mueve al nodo three; y luego vuelve a fallar, pero algún tipo de regla (que estoy buscando) le impide migrar al nodo four. Supongo que necesito algún tipo de mostrador de inmigración.

Esta es una configuración de prueba, en realidad tendré más nodos y más recursos. Por eso me gustaría que la configuración fuera lo más simple posible. Me imagino que puedo lograr esto usando una estrategia de preferencia de ubicación de inclusión o exclusión voluntaria para cada recurso, pero no es simple ni fácil de mantener. ¿Existe una mejor manera?

PD: Con la configuración actual, si inunda mi VIP con hping, recorrerá todos los nodos antes de detenerse por completo (porque no tiene más nodos en los que ejecutarse, hasta que lo borre o introduzca una failure-timeoutopción).

Versiones:

[~] 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

Configuración del marcapasos:

[~] 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

EDITAR: El contexto y la historia de toda la configuración es la siguiente: tenemos dos balanceadores de carga con LVS que envían tráfico a nuestras interfaces. La alta disponibilidad solía lograrse con una configuración simple de keepalived y 2 VIP (una configuración activo-activo; en una situación normal, cada LVS tiene 1 VIP). Pero últimamente algunos chicos empezaron a hacernos DDoS con regularidad, y la configuración de keepalived ya no funciona como se esperaba: incluso si atacan con DDoS solo a 1 VIP, es decir, 1 host, keepalived pierde el tráfico entrante de otro host, toma el segundo VIP y paraliza todo. sistema.

Entonces pensamos que a) encontraríamos algo para administrar a los VIP con quórum, para evitar divisiones de cerebro; b) al menos duplicar los hosts LVS.

Así que probé marcapasos+corosync y su configuración es realmente sencilla cuando tenemos dos nodos activos y uno en espera. Tal como se esperaba, cuando uno de los VIP sufre un ataque DDoS, ese VIP primero migra a otro nodo y luego se apaga por completo. A medida que agregamos nodos, ese 'recorrido de recursos' se hace más largo, lo cual no es exactamente lo que queremos: queremos que el VIP se apague lo antes posible, pero también queremos, por supuesto, dejar la posibilidad de recuperarse automáticamente de un proceso interno. problema de hardware (si el nodo se cae repentinamente, FE). Entonces pensé... tal vez haya una manera de migrar un recurso solo UNA VEZ, y si aún falla, entonces terminar de una vez. Nos salva de fallos de hardware; nos ahorra tiempo cuando estamos bajo DDoS parcial.

Eso es todo, lo siento si es demasiado elaborado. Si elegimos el instrumento equivocado para abordar esto desde el principio, háganmelo saber. (Por supuesto, nos defendemos de DDoS con otros métodos, pero si el ataque logra pasar, queremos minimizar el daño).

Respuesta1

Definitivamente es un caso de uso interesante, gracias por compartir...

Si bien sus VIP reciben DDoS, probablemente no puedan hacer ping de manera confiable. Quizás podrías echarle un vistazo al agente de recursos 'ping' de Pacemaker.

La documentación de clusterlabs lo menciona brevemente aquí: http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ch09s03s03.html

Puede encontrar más información consultando la información del agente de recursos a través de su herramienta de administración de configuración de clúster preferida:

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

Espero que sea útil.

información relacionada