Eu tenho uma configuração com 5 nós, 4 capazes de hospedar recursos e 1 recurso. O que eu quero fazer é fazer com que o recurso pare completamente depois de migrar N vezes de nó para nó.
Portanto, um cenário de amostra seria: o recurso VIP1 em execução no nó one ; seu monitor falha, migration-threshold é atingido, move-se para o nó two ; então ele falha novamente e move para o nó three ; e depois falha novamente, mas algum tipo de regra (que estou procurando) impede que ela migre para o nó four . Eu 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, eu gostaria que a configuração fosse o mais simples possível. Eu acho que posso conseguir isso usando uma estratégia de preferência de local de opt-in ou opt-out para cada recurso, mas não é simples nem fácil de manter. Existe uma maneira melhor?
P.S. Com a configuração atual, se eu inundar meu VIP com hping , ele passará por todos os nós antes de parar completamente (porque não tem mais nós para serem executados, até eu limpá-lo ou introduzir uma opção failure-timeout )
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 são os seguintes: temos dois balanceadores de carga com LVS que enviam 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 tem 1 VIP). Mas alguns caras recentemente começaram a nos usar DDoS regularmente, e a configuração keepalived não funciona mais como esperado: mesmo que o DDoS tenha apenas 1 VIP, ou seja, 1 host, o keepalive perde o tráfego de entrada de outro host, pega o segundo VIP sistema.
Então pensamos que a) encontramos algo para gerenciar VIPs com quórum, para evitar rachaduras; b) pelo menos o dobro dos hosts LVS.
Então eu testei o pacemaker + corosync, e sua configuração é muito simples quando temos dois nós ativos e um standby. Assim como esperado, quando um dos VIPs é DDoSed, esse VIP primeiro migra para outro nó e, em seguida, desliga completamente. À medida que adicionamos nós, essa "caminhada de recursos" se torna 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 deixar uma chance de recuperar automaticamente de um local interno problema de hardware (se o nó cair repentinamente, FE). Então eu pensei ... talvez haja uma maneira de migrar um recurso apenas uma vez, e se ainda falhar, então termine com isso. Nos poupa de falhas de hardware; nos poupa tempo quando estamos sob DDoS parcial.
Isso é muito bonito, desculpe se é muito elaborado. Se escolhermos o instrumento errado para lidar com isso desde o início, por favor me avise. (Claro, defendemos o DDoS com outros métodos, mas se o ataque conseguir passar, queremos minimizar o dano).