Análise pós-incidente da interrupção do serviço Tarsnap

 (mail.tarsnap.com)
1 pontos por GN⁺ 2023-07-28 | 1 comentários | Compartilhar no WhatsApp
  • O servidor central do Tarsnap caiu no Amazon EC2 us-east-1 com failed system status check, e o serviço ficou indisponível por cerca de 26 horas e 16 minutos a partir de 2023-07-02 13:07:58 UTC
  • A falha foi detectada às 13:10 UTC, mas após uma reinicialização inesperada aplicou-se a política operacional de manter desativada a inicialização automática do código do servidor até que uma pessoa fizesse a verificação direta
  • A recuperação foi conduzida lendo os headers de metadados do sistema de arquivos estruturado em log no Amazon S3 e depois reproduzindo localmente as operações em ordem; a primeira etapa terminou em 2023-07-03 01:49:49 UTC
  • Durante a reconstrução do estado, vieram à tona um caso não validado do tratamento de machine re-owned escrito em 2014 e a ausência de reinicialização da lógica de retomada, e o limite de throughput de disco também atrasou a recuperação
  • Embora o Tarsnap não tenha um SLA explícito, seguindo a política de conceder créditos em incidentes considerados justos, em 2023-07-13 foi concedido a todas as contas um crédito de 50% do custo mensal de armazenamento

Ocorrência da falha e resposta inicial

  • Por volta de 2023-07-02 13:07:58 UTC, o servidor central do Tarsnap ficou offline na região us-east-1 do Amazon EC2
    • O estado do EC2 era failed system status check
    • Em uma máquina virtual, esse estado pode indicar várias causas, como queda de energia, falha de hardware no servidor físico ou falha de rede do EC2
    • Não havia relatos visíveis de uma falha ampla no EC2 naquele momento, então a hipótese mais provável era uma falha isolada de hardware
  • O monitoramento detectou a falha em 2023-07-02 13:10 UTC
    • O monitoramento era feito a partir de outra região do EC2, realizando a cada 5 minutos operações de escrita, leitura e exclusão de arquivos
    • O alerta por SMS às 13:10 UTC não acordou ninguém, mas o alerta por telefone às 13:15 UTC deu início à resposta
    • Na investigação inicial não apareceu nenhum erro transitório claro, então concluiu-se que o sistema havia morrido e começou-se a preparar uma instância EC2 substituta

Política operacional para evitar reinício automático

  • Por volta de 2023-07-02 13:52 UTC, a Amazon reiniciou o servidor com problema em uma nova instância EC2
    • Isso ocorreu cerca de 45 minutos após o início da falha
    • O sistema operacional FreeBSD subiu, mas o código do servidor Tarsnap não foi iniciado automaticamente
  • O motivo para desativar a inicialização automática era verificar manualmente o estado antes de voltar a receber tráfego após uma reinicialização inesperada
    • Pela política operacional, “evitar perda de dados quando algo quebra” é mais importante do que “maximizar a disponibilidade do serviço”
  • Após a reinicialização, os logs do servidor mostraram corrupção de sistema de arquivos
    • Considerou-se que a causa da falha matou o hardware ou rompeu a conexão entre o servidor e o Elastic Block Store que continha o sistema de arquivos
    • Decidiu-se continuar a configuração de um novo servidor em vez de tentar recuperar o servidor antigo

Estrutura em log no S3 e procedimento de recuperação

  • O serviço Tarsnap armazena os dados no Amazon S3 como um sistema de arquivos estruturado em log
    • Cada objeto do S3 contém um header com os metadados de todas as entradas de log e, opcionalmente, os dados dessas entradas
    • A entrada de log start write transaction contém apenas um header que identifica a máquina e o nonce da transação, sem dados de log
    • A entrada de log store data block inclui tanto um header que identifica a máquina e o nome do bloco quanto os dados do bloco
  • Em estado normal, os metadados das entradas de log ficam em cache no EC2 e não são relidos do Amazon S3
    • Leituras no Amazon S3 só ocorrem ao ler dados de blocos para responder a solicitações de clientes do tarsnap
  • A recuperação do estado da instância EC2 foi dividida em duas etapas
    • Primeiro, são lidos do S3 todos os headers de metadados
    • Depois, todas as operações são reproduzidas (replay) localmente
    • Em armazenamento estruturado em log, ao excluir dados as entradas de log são reescritas para liberar espaço, portanto as duas etapas não podem ser executadas ao mesmo tempo
    • As entradas de log têm números de sequência, o que permite reproduzi-las na ordem correta, mas após a busca é preciso ordená-las primeiro

Falhas e gargalos revelados durante a recuperação

  • A primeira etapa ocorreu sem problemas e foi concluída em 2023-07-03 01:49:49 UTC
    • O processo de recuperação estava configurado para enviar 250 requisições simultâneas ao Amazon S3
    • Esse valor havia sido ajustado ao que o Amazon S3 conseguia suportar 10 anos antes, e hoje provavelmente poderia ter sido muito maior
  • A segunda etapa falhou quase imediatamente
    • Ocorreu um erro indicando que entradas de log reproduzidas estavam gravando dados pertencentes a uma máquina que não existia
    • A causa era o código de movimentação de conta de máquina escrito em 2014
    • Quando um usuário do Tarsnap precisava mover uma máquina entre contas, era gravada uma nova entrada de log machine registration e a entrada anterior era apagada
    • Havia testes, mas faltava o caso de reconstruir o estado do servidor depois que uma máquina tivesse sido re-owned com dados já armazenados
    • Como a nova entrada de registro da máquina tinha um número de sequência mais alto, durante o replay parecia que os dados estavam sendo gravados em uma máquina que ainda não existia
  • Depois de identificar a causa, esse “seatbelt” foi desativado e a reconstrução do estado foi retomada
    • Logo em seguida ocorreu um erro dizendo que os dados não podiam ser encontrados no Amazon S3
    • Isso aconteceu porque, ao retomar a tentativa, a etapa de download dos dados do S3 foi pulada e o valor de maximum log entry sequence number não foi reinicializado, permanecendo em 0
    • Após corrigir esse problema, a reconstrução do estado prosseguiu normalmente
  • A reconstrução do estado avançou mais lentamente do que o necessário
    • Se tivesse sido percebido que o gargalo era o throughput de disco, teria sido possível configurar uma taxa maior para o volume EBS correspondente
    • Por falta de sono, o processo não foi acompanhado com o devido cuidado; caso contrário, seria possível identificar o gargalo com gstat(8) e Amazon CloudWatch e reconfigurar o volume EBS

Retomada do serviço e concessão de créditos

  • Por volta de 2023-07-03 15:10 UTC, o processo de reconstrução do estado foi concluído
    • O horário exato de conclusão não foi registrado
    • O servidor foi mantido em modo somente leitura e passaram por testes rápidos
    • Comparando com o estado do servidor antigo, verificou-se que tudo coincidia, exceto os últimos poucos segundos de dados que o sistema de arquivos do servidor antigo perdeu no momento da falha
  • O primeiro tráfego real de produção após a falha ocorreu em 2023-07-03 15:25:58 UTC
    • Isso foi cerca de 26 horas e 16 minutos após o início da falha
  • Embora o Tarsnap não tenha um SLA explícito, aplica uma política de conceder créditos em falhas consideradas justas
    • Em 2023-07-13, foi concedido a todas as contas do Tarsnap um crédito de 50% do custo mensal de armazenamento
    • O processamento dos créditos foi feito após a contenção do incidente e um período de descanso

Leituras relacionadas

1 comentários

 
GN⁺ 2023-07-28
Opiniões no Hacker News

  • Eu realmente não esperava que este post fosse parar no topo do HN. Gostaria de responder às perguntas, mas agora são 22h e meu filho acabou dormindo às 17h, então, se eu tiver sorte, devo conseguir dormir umas 4 horas antes de ele acordar
    Vou conferir de novo de manhã e responder às perguntas

    • Fico me perguntando qual seria o motivo para usar este serviço em vez do restic. Agradeço ao Colin, mas, lendo este texto, parece que o serviço tem, na prática, uma única pessoa como responsável pela infraestrutura
      É bom que tenham deixado claro que não há SLA, mas dá a sensação de que existe um grande risco entre mim e meus backups
    • Se no futuro você escrever outra análise pós-incidente — espero, claro, que isso aconteça raramente ou nunca — seria bom explicitar as lições aprendidas, para mostrar quais itens não vão se repetir e por quê
    • Uma análise pós-incidente muito bem escrita e ponderada, mas espero nunca mais ver um texto desses :)
    • Chegou a hora de colocar a criança no suporte 24 horas ;)
      Tenho lido https://www.amazon.com/No-Cry-Sleep-Solution-Toddlers-Presch... e tive algum resultado. Dá para encontrar em qualquer biblioteca, isto é, um tipo de Blockbuster para livros
    • Fico curioso para saber por quanto tempo os logs de transação são mantidos antes de serem sobrescritos
      Nas últimas semanas, eu também tive algumas instâncias EC2 que caíram com sintomas parecidos de terem sido desconectadas do EBS; no meu caso foi em eu-west

  • A parte em que, seguindo a política meio ambígua de que “o Tarsnap não tem SLA, mas concede créditos por indisponibilidades quando isso parece justo”, foi creditado em todas as contas Tarsnap, em 2023-07-13, 50% do custo de armazenamento de um mês, mostra bem que tipo de pessoa Percival é
    Esse crédito parece bastante generoso no sentido de compensar adequadamente os clientes e, diferentemente dos grandes provedores de nuvem, não fez cada cliente vir individualmente implorar. Além disso, houve uma análise pós-incidente clara, técnica e detalhada. Acho que todo lugar deveria agir assim

    • A expressão “obrigado por ser um farol na escuridão” é perfeita
      Fico bem feliz por viver em um mundo em que o Tarsnap existe e cobra em picodollars

  • Se os procedimentos de recuperação de desastre tivessem sido configurados e testados corretamente, o downtime poderia ter sido muito menor
    É preciso criar um sistema de staging totalmente separado, que possa ser derrubado e recriado, testar periodicamente diversos modos de falha e documentar todos os detalhes dos procedimentos de recuperação do sistema
    No longo prazo, também vale pensar em aumentar a receita para poder contratar mão de obra em meio período, o que ajudaria muito se algo parecido acontecesse
    Nós também somos um pequeno provedor de soluções em nuvem, com foco em APIs de ML, e, com o passar dos anos, ficou claro que, ao usar hardware de nuvem, seja dedicado ou virtual, falhas acontecem periodicamente. RAM, HDD ou outros componentes de hardware podem falhar a qualquer momento, então isso precisa ser 100% considerado ao operar um serviço online de alta disponibilidade no longo prazo

  • Respeito pela análise pós-incidente honesta e por lidar bem com uma situação difícil. Dito isso, sobre a privação de sono, se há apenas uma pessoa capaz de corrigir o problema, não há motivo para se envergonhar de aceitar um pouco mais de tempo de indisponibilidade para garantir que a cabeça esteja clara
    Parece estranho ir dormir um pouco enquanto os alertas estão disparando, mas a combinação de adrenalina e pouco sono torna muito fácil piorar o problema

    • Não se preocupe, tirei algumas sonecas no meio. “Isso parece estar funcionando, mas ainda vai levar algumas horas, então vou colocar o alarme para daqui a 2 horas e dormir um pouco” foi um dos motivos pelos quais não percebi que a segunda etapa estava desnecessariamente presa em um gargalo de I/O

  • Só pela descrição, este processo de recuperação parece relativamente fácil de testar regularmente, e isso deve ajudar a encontrar bugs restantes ou avaliar o tempo de recuperação
    Como se costuma dizer, só um backup testado é um backup de verdade

    • Concordo 100%, falando como alguém que só descobriu que meu processo de recuperação de desastre não funcionava depois de testá-lo. O único plano com chance real de funcionar é um plano repetível e testado
    • Sim. Eu vinha querendo fazer isso havia algum tempo, mas sempre havia algo de prioridade maior. Não percebi que tinha ficado quase 10 anos sem testar até esta falha acontecer
      Daqui para frente, vou definitivamente colocar ensaios anuais como alta prioridade

  • É sempre bom ver uma análise pós-incidente profissional, educada e honesta

  • Talvez eu esteja falando com base em informações antigas sobre a empresa Tarsnap, mas o único fator que me fez hesitar em usar o Tarsnap a sério foi a possibilidade de uma falha inesperada de Colin Percival, ou seja, o risco de pessoa-chave
    Acho que não sou o único

    • É parecido com um cálculo de tempo médio entre falhas. A questão é se você confia em uma solução bem projetada, de uma empresa de uma pessoa só, com poucas peças móveis, ou em uma solução de uma empresa muito maior, mas com muito mais peças móveis e provavelmente menos bem projetada
      Pessoalmente, eu escolheria a solução mais simples. Pela minha experiência, é preciso uma enorme complexidade adicional para chegar ao nível de confiabilidade que sistemas simples têm, e a maior parte da complexidade piora as coisas
      Isso fica claro em clustering de servidores. Um único servidor com energia e rede estáveis é mais confiável do que qualquer tentativa de redundância desse serviço até se chegar a algo como 5 vezes mais custo e complexidade. Só nesse ponto é que se obtém um tempo médio entre falhas parecido com o de um servidor único, e só depois disso há melhoria real
      Acredito firmemente que o melhor caminho para confiabilidade de verdade é o máximo de simplicidade possível e bons backups. Quando é necessária disponibilidade 24/7, as tecnologias disponíveis ficam bastante limitadas
    • Entendo que isso seja um risco, mas não tenho certeza de que seja necessariamente mais arriscado do que uma empresa maior
      Este é o trabalho do Colin, leva o nome do Colin e é muito importante para o Colin
      Na BigBackupCorp, é difícil receber esse mesmo tipo de serviço. Funcionários são substituíveis, executivos são substituíveis e, sinceramente, eu como cliente também sou substituível se a empresa decidir mudar de rumo e virar a BigFlowerArrangementShippingCorp
      O lado bom de um pequeno negócio é que ele funciona inteiramente por interesse próprio. Não há manipulação de preço de ação nem truques de VC. Se for um negócio lucrativo, alguém pode vir, comprá-lo e transformá-lo em algo seu, com seu próprio nome associado. Acho que a internet aberta se beneficia muito desse tipo de coisa
    • Se fizermos uma lista dos concorrentes que desapareceram antes do Tarsnap, o cálculo pode mudar um pouco. O risco a avaliar não deveria ser “e se algo acontecer com o operador?”, mas sim “e se algo acontecer com ele, o serviço cair e eu também não tiver feito backup do backup?”
      Esse risco pode ser reduzido tanto quanto você quiser com planejamento cuidadoso
    • Se você acompanha o HN, provavelmente ficará sabendo em até 24 horas se algo aconteceu com o Colin. Na prática, só haveria um problema real se, na janela de cerca de 24 horas antes de migrar para um novo provedor de backup, o armazenamento principal, o Tarsnap e o Colin falhassem todos ao mesmo tempo
    • Não pretendo confiar em um provedor de backup mais do que isso. No momento em que você passa a depender dele, ele vai falhar justamente na hora mais difícil
      É melhor tratar um serviço como o Tarsnap como uma de várias camadas, criar backups em múltiplas camadas e verificá-los regularmente

  • Um erro como registros de log reproduzidos registrando dados de uma máquina que não existe parece algo que daria para detectar escrevendo um modelo em TLA+

  • Com uma combinação como restic+backblaze, o custo cai várias ordens de magnitude, então fico curioso sobre qual é a vantagem de usar o Tarsnap. Não sei que necessidade específica motivaria alguém a pagar 3.000 dólares por TB-ano

    • Alguns de nós têm bastante dinheiro sobrando e gostam de uma desculpa para pagar ao cperciva para que ele não trabalhe em um emprego ruim e use suas habilidades e talento em coisas maiores e melhores
      Para quem pergunta sobre o baixo bus factor: você não deixaria seus backups em um único serviço ou em um único local, certo? Usaria Tarsnap junto com Restic+Backblaze, Rsync.net, S3 etc., certo? “Backup é o imposto que se paga pelo luxo da recuperação”
    • A deduplicação funciona muito bem, então o custo do conjunto de dados essencial e muito importante que faço backup no Tarsnap é desprezível. Acho que, se os dados mudassem com mais frequência, a conta seria diferente
      Por exemplo, uso outros serviços para minha biblioteca de vídeos e fotos, mas faço backup no Tarsnap de bancos de dados contábeis, documentos importantes e coisas assim
      Uso o Tarsnap há 10 anos, e quase não tive problemas de disponibilidade nem, pelo que me lembro, problemas de qualquer outro tipo

  • Parece que a maior parte das 26 horas de downtime foi gasta restaurando backups. Por coincidência, esse é exatamente o motivo pelo qual não posso usar o Tarsnap em um ambiente de produção
    Do ponto de vista do usuário, a restauração de backups é dolorosamente lenta. Quando meus sistemas estão offline, não tenho paciência para esperar horas por causa do serviço de backup. Talvez esteja melhor agora, mas, da última vez que usei, alguns anos atrás, restaurar um backup de alguns GB levava algo na faixa de uma hora