Entrar ou criar conta

Upnetix Labs · protocolo de experimento

Protocolo: Qual o tempo de failover de um serviço Apache em cluster Pacemaker+Corosync sob falha de nó?

Este protocolo mede o tempo necessário para o Pacemaker transferir um serviço Apache ativo para outro nó após a simulação de falha do nó primário. O objetivo é quantificar a eficiência do failover em clusters de alta disponibilidade.

Alta disponibilidade de serviços Linux com Pacemaker e Corosync
Ligado ao treinamento Alta disponibilidade de serviços Linux com Pacemaker e Corosync
Protocolo, não resultado. Esta página descreve como medir. Execução pela engenharia Upnetix: ainda não realizada. Nenhum valor aqui é resultado de medição da Upnetix; os números que valem são os que você obtém na sua bancada.
Pergunta

Quanto tempo o cluster Pacemaker+Corosync leva para restaurar o serviço Apache após a falha do nó ativo?

Hipótese

O tempo de failover do serviço Apache em cluster Pacemaker+Corosync permanece inferior a 30 segundos em ambiente padrão.

Variáveis

Independentes (o que varia)nó onde ocorre a falha
Dependentes (o que se mede)tempo de failover do serviço Apache (segundos)
Controladas (o que fica fixo)versão do Pacemaker; versão do Corosync; versão do Apache; configuração dos recursos; hardware dos nós; rede (latência e banda); configuração do STONITH; mesmo arquivo de configuração

Ambiente

Cluster de 2 nós Linux com Pacemaker, Corosync e Apache instalados. STONITH configurado. Ferramenta de monitoramento: script shell com timestamps e journalctl. Teste executado em rede dedicada, como em uma rede de fibra dedicada como a da Upnetix.

Procedimento

  1. Preparação

    Configure o cluster Pacemaker+Corosync com recurso Apache ativo em um nó e STONITH habilitado.

  2. Monitoramento

    Inicie monitoramento contínuo do status do recurso Apache no cluster.

    watch -n 1 'crm_resource --resource apache --locate'
  3. Simulação de falha

    Simule a falha do nó primário (por exemplo, forçando reboot ou desligamento).

    sudo reboot
  4. Registro de tempo

    Anote o timestamp do início da falha e do momento em que o recurso Apache volta a ficar online em outro nó.

    journalctl -u pacemaker -f
  5. Repetição

    Repita o experimento alternando o nó de falha em cada rodada.

Planilha de coleta

nó_falhado (nome)timestamp_falha (YYYY-MM-DD HH:MM:SS)timestamp_recuperacao (YYYY-MM-DD HH:MM:SS)tempo_failover_s (segundos)
nó1, 2024-06-01 14:00:00, 2024-06-01 14:00:18, 18 (EXEMPLO)

Repetições recomendadas: 5. Baixe a planilha vazia em CSV: colunas prontas.

Análise

Calcule a média, mediana e desvio padrão dos tempos de failover. Compare os resultados entre os nós. Interprete valores acima de 30 segundos como possíveis indícios de gargalo ou configuração inadequada.

Critérios de decisão

  • O tempo de failover deve ser consistente (variação máxima de 20% entre repetições).
  • Nenhuma falha de failover (serviço não restaurado) é aceitável.
  • Resultados acima de 30 segundos devem ser investigados.

Fontes de erro e mitigação

  • Latência de rede pode afetar o tempo de failover; usar rede dedicada.
  • Carga extra nos nós pode distorcer resultados; garantir ambiente ocioso.
  • Logs de tempo imprecisos podem gerar erro; sincronizar relógios com NTP.

Referências

  1. Pacemaker Documentation · ClusterLabs (Pacemaker) (clusterlabs.org)
  2. Corosync Documentation · Corosync.github (corosync.github.io)
Verificação editorial
Publicado
09/09/2026
Última revisão
09/09/2026
Versão do conteúdo
1.0
Referências
2 oficiais
Revisão técnica
redação e revisão por IA, URLs conferidas na publicação
Status
Atual
Encontrou um erro? Escreva para comercial@upnetix.com.br com o endereço da página. A revisão semestral por IA nunca altera comandos ou configurações sem passar pela fila de revisão.