☰

Pacemaker: interrompendo o recurso após migrar N vezes devido ao failover

tag-icon • tag-icon cluster pacemaker
Pacemaker: interrompendo o recurso após migrar N vezes devido ao failover

Tenho uma configuração com 5 nós, sendo 4 capazes de hospedar recursos e 1 recurso. O que eu quero fazer é parar completamente o recurso após migrar N vezes de nó para nó.

Portanto, um exemplo de cenário seria: recurso VIP1 em execução no nó one; seu monitor falha, migration-thresholdé alcançado, ele se move para o nó two; então ele falha novamente e passa para node three; e então falha novamente, mas algum tipo de regra (que estou procurando) impede que ele migre para node four. Preciso de algum tipo de contador de migração, eu acho.

Esta é uma configuração de teste, na realidade terei mais nós e mais recursos. Então, gostaria que a configuração fosse o mais simples possível. Acho que posso conseguir isso usando uma estratégia de preferência de localização de aceitação ou exclusão para cada recurso, mas não é simples nem fácil de manter. Existe uma maneira melhor?

PS Com a configuração atual, se eu inundar meu VIP com hping, ele percorrerá todos os nós antes de parar completamente (porque não há mais nós para executar, até que eu o limpe ou introduza uma failure-timeoutopção)

Versões:

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

Configuração do marcapasso:

[~] 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: O contexto e a história de toda a configuração é este: temos dois balanceadores de carga com LVS que fazem proxy do tráfego para nossos frontends. A alta disponibilidade costumava ser alcançada com uma configuração simples de manutenção de atividade e 2 VIPs (uma configuração ativa-ativa; em uma situação normal, cada LVS possui 1 VIP). Mas recentemente alguns caras começaram a fazer DDoS regularmente, e a configuração do keepalived não funciona mais como esperado: mesmo que eles façam DDoS apenas em apenas 1 VIP, ou seja, 1 host, seu keepalived perde o tráfego de entrada de outro host, captura o segundo VIP e prejudica todo o sistema.

Então pensamos em a) encontrar algo para gerenciar VIPs com quórum, para evitar divergências; b) pelo menos dobrar os hosts LVS.

Então testei o pacemaker+corosync, e sua configuração é muito simples quando temos dois nós ativos e um em standby. Assim como esperado, quando um dos VIP sofre um DDoS, esse VIP primeiro migra para outro nó e depois é completamente desligado. À medida que adicionamos nós, essa 'caminhada de recursos' torna-se mais longa, o que não é bem o que queremos: queremos que o VIP seja encerrado o mais rápido possível, mas também queremos, é claro, deixar uma chance de recuperação automática de um problema interno. problema de hardware (se o nó cair repentinamente, FE). Então pensei... talvez haja uma maneira de migrar um recurso apenas UMA VEZ e, se ainda falhar, termine com isso. Nos salva de falhas de hardware; economiza tempo quando estamos sob DDoS parcial.

É basicamente isso, desculpe se for muito elaborado. Se escolhermos o instrumento errado para lidar com isto desde o início, por favor avisem-me. (É claro que nos defendemos contra DDoS com outros métodos, mas se o ataque conseguir passar, queremos minimizar os danos).

Responder1

Esse é definitivamente um caso de uso interessante, obrigado por compartilhar...

Enquanto seus VIPs estão recebendo DDoS, eles provavelmente não conseguem fazer ping de maneira confiável. Talvez você possa dar uma olhada no agente de recursos 'ping' do Pacemaker.

A documentação do clusterlabs menciona isso brevemente aqui: http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ch09s03s03.html

Mais informações podem ser encontradas verificando as informações do agente de recursos por meio de sua ferramenta preferida de gerenciamento de configuração de cluster:

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

Espero que isso seja útil.

informação relacionada