desde que usamos o CentOS 7, mudamos de uma configuração de pulsação normal para o pacemker.
Principalmente, temos recursos IP que estão ativos em um nó e mudam para um segundo nó se ocorrer um failover. Também executamos alguns scripts em caso de failover. Nada especial.
Para que os recursos sempre iniciem no nó primário, eu uso
pcs constraint location Cluster_IP prefers server1=master-server
Eu também uso
pcs resource defaults resource-stickiness=INFINITY
para evitar que os recursos voltem após o failover.
Isso funciona bem para mim, se o mestre falhar (falha de hardware, por exemplo).
Como não é um problema para mim se o failover demorar algum tempo, gostaria de implementar algum tipo de atraso no caso de uma pequena divisão do cérebro.
Antes de fazer qualquer coisa, o escravo deve esperar cerca de 2 minutos, antes de assumir o controle, caso o mestre esteja acessível novamente nestes cerca de 2 minutos.
Eu queria saber, qual seria a melhor maneira de fazer isso?
Responder1
Nunca defini um tempo limite de token no Corosync para algo acima de 10 segundos, mas você pode tentar aumentar/definir o tokenvalor corosync.confpara 120000(120 segundos em milissegundos). tokendeve ser definido na totem{}seção do seu corosync.conf; man corosync.confpara mais detalhes.
Isso deve evitar que o Corosync declare um nó morto por 120 segundos quando a rede falhar.
Responder2
Você pode alterar o intervalo de monitoramento do recurso com op monitor interval=Nsonde Nestá o número de segundos e, em seguida, definir migration-thresholdno recurso como 2. Lembre-se de que com uma configuração 120svocê poderá ver um atraso total de 120-240s, dependendo de quando a falha inicial ocorrer no intervalo de monitoramento.
Há outras advertências quanto a isso, pois o contador de falhas aplicado migration-thresholdnão é zerado em caso de sucesso. Para fazer isso, você também precisaria definir failure-timeoutou intervir manualmente.
Com op monitor interval=120s, e sua configuração, você precisaria testar para garantir que fornece a funcionalidade esperada e como os contadores de falha se comportam quando o mestre original se recupera migration-threshold=2. Pode exigir intervenção manual, mas não estou 100% certo dissofailure-timeout=121sresource-stickiness