Ponto de verificação de aplicativo

Origem: Wikipédia, a enciclopédia livre.

Ponto de verificação (do inglês, checkpoint) é uma técnica que fornece tolerância a falhas para sistemas de computação. Consiste basicamente em salvar uma captura do estado do aplicativo, para que ela possa reiniciar a partir desse ponto, em caso de falha. Isso é particularmente importante para os aplicativos de execução longa executados nos sistemas de computação propensos a falhas.

Ponto de verificação em sistemas distribuídos[editar | editar código-fonte]

Em ambiente de computação distribuída, o ponto de verificação é uma técnica que ajuda a tolerar falhas que, de outra forma, forçariam o reinício do aplicativo de longa execução desde o início. A maneira mais básica de implementar o ponto de verificação é parar o aplicativo, copiar todos os dados necessários da memória para um armazenamento confiável (por exemplo, sistema de arquivos paralelo) e continuar com a execução.[1] Em caso de falha, quando o aplicativo é reiniciado, não é necessário iniciar do zero. Em vez disso, ele lerá o estado mais recente ("o ponto de verificação") do armazenamento estável e será executado a partir dele. Embora haja um debate em andamento sobre se o ponto de verificação é a carga de trabalho de E/S dominante em sistemas de computação distribuídos, existe um consenso geral de que o ponto de verificação é uma das principais cargas de trabalho de E/S.[2][3]


Existem duas abordagens principais para o ponto de verificação nos sistemas de computação distribuídos: ponto de verificação coordenado e ponto de verificação não-coordenado. Na abordagem de ponto de verificação coordenado, os processos devem garantir que seus pontos de verificação sejam consistentes. Isso geralmente é alcançado por algum tipo de algoritmo de protocolo de confirmação de duas fases. No ponto de verificação não-coordenado, cada processo verifica seu próprio estado, independentemente. Deve-se enfatizar que simplesmente forçar os processos a verificar seu estado em intervalos de tempo fixos não é suficiente para garantir consistência global. A necessidade de estabelecer um estado consistente (ou seja, sem mensagens ausentes ou duplicadas) pode forçar outros processos a reverterem para seus pontos de verificação, o que, por sua vez, pode fazer com que outros processos retornem a pontos de verificação ainda mais antigos, o que, no caso mais extremo, pode significa que o único estado consistente encontrado é o estado inicial (o chamado efeito dominó).[4][5]

Referências

  1. Plank, J. S., Beck, M., Kingsley, G., & Li, K. (1994). Libckpt: Transparent checkpointing under unix. Computer Science Department.
  2. Wang, Teng; Snyder, Shane; Lockwood, Glenn; Carns, Philip; Wright, Nicholas; Byna, Suren (Setembro de 2018). «IOMiner: Large-Scale Analytics Framework for Gaining Knowledge from I/O Logs». 2018 IEEE International Conference on Cluster Computing (CLUSTER). [S.l.]: IEEE. pp. 466–476. ISBN 978-1-5386-8319-4. doi:10.1109/CLUSTER.2018.00062 
  3. «Comparative I/O workload characterization of two leadership class storage clusters Logs» (PDF). ACM. Novembro de 2015 
  4. Bouteiller, B., Lemarinier, P., Krawezik, K., & Capello, F. (2003, Dezembro). Coordinated checkpoint versus message log for fault tolerant MPI. In Cluster Computing, 2003. Proceedings. 2003 IEEE International Conference on (p. 242-250). IEEE.
  5. Elnozahy, E. N., Alvisi, L., Wang, Y. M., & Johnson, D. B. (2002). A survey of rollback-recovery protocols in message-passing systems. ACM Computing Surveys, 34(3), 375-408.