Disponibilidade do sistema distribuído
Os sistemas distribuídos são compostos por componentes de software e componentes de hardware. Alguns dos componentes do software podem ser, eles próprios, outro sistema distribuído. A disponibilidade dos componentes subjacentes de hardware e software afeta a disponibilidade resultante de sua workload.
O cálculo da disponibilidade usando MTBF e MTTR tem suas raízes nos sistemas de hardware. No entanto, os sistemas distribuídos falham por motivos muito diferentes dos de um hardware. Quando um fabricante pode calcular consistentemente o tempo médio antes que um componente de hardware se desgaste, o mesmo teste não pode ser aplicado aos componentes de software de um sistema distribuído. O hardware normalmente segue a curva “banhada” da taxa de falhas, enquanto o software segue uma curva escalonada produzida por defeitos adicionais que são introduzidos a cada nova versão (consulte Confiabilidade do software
Taxas de falha de hardware e software
Além disso, o software em sistemas distribuídos normalmente muda a taxas exponencialmente maiores do que o hardware. Por exemplo, um disco rígido magnético padrão pode ter uma taxa média de falha anualizada (AFR) de 0,93%, o que, na prática, para um HDD, pode significar uma vida útil de pelo menos 3 a 5 anos antes de atingir o período de desgaste, potencialmente mais longa (consulte Dados e estatísticas do disco rígido Backblaze, 2020).
O hardware também está sujeito ao conceito de obsolescência planejada, ou seja, tem uma vida útil integrada e precisará ser substituído após um determinado período de tempo. (Veja A Grande Conspiração da Lâmpada
Tudo isso significa que os mesmos modelos de teste e previsão usados pelo hardware para gerar números MTBF e MTTR não se aplicam ao software. Houve centenas de tentativas de criar modelos para resolver esse problema desde a década de 1970, mas todas elas geralmente se enquadram em duas categorias: modelagem de previsão e modelagem de estimativa. (Consulte a lista de modelos de confiabilidade de software
Assim, o cálculo de um MTBF e MTTR prospectivos para sistemas distribuídos e, portanto, de uma disponibilidade prospectiva, sempre será derivado de algum tipo de previsão ou previsão. Eles podem ser gerados por meio de modelagem preditiva, simulação estocástica, análise histórica ou testes rigorosos, mas esses cálculos não garantem tempo de atividade ou inatividade.
Os motivos pelos quais um sistema distribuído falhou no passado podem nunca mais ocorrer. As razões pelas quais ele falhará no futuro provavelmente serão diferentes e possivelmente desconhecidas. Os mecanismos de recuperação necessários também podem ser diferentes para futuras falhas dos usados no passado e levar períodos de tempo significativamente diferentes.
Além disso, MTBF e MTTR são médias. Haverá alguma variação do valor médio em relação aos valores reais vistos (o desvio padrão, σ, mede essa variação). Assim, as workloads podem passar por um tempo menor ou maior entre falhas e tempos de recuperação no uso real da produção.
Dito isso, a disponibilidade dos componentes de software que compõem um sistema distribuído ainda é importante. O software pode falhar por vários motivos (discutidos mais na próxima seção) e afetar a disponibilidade da workload. Assim, para sistemas distribuídos de alta disponibilidade, o mesmo foco no cálculo, medição e melhoria da disponibilidade dos componentes de software deve ser dado ao hardware e aos subsistemas externos de software.
Rule2
A disponibilidade do software em sua workload é um fator importante da disponibilidade geral de sua workload e deve receber o mesmo foco que outros componentes.
É importante observar que, apesar de serem difíceis de prever o MTBF e o MTTR para sistemas distribuídos, eles ainda fornecem informações importantes sobre como melhorar a disponibilidade. Reduzir a frequência de falhas (MTBF mais alto) e diminuir o tempo de recuperação após a ocorrência da falha (MTTR mais baixo) levarão a uma maior disponibilidade empírica.
Tipos de falhas em sistemas distribuídos
Geralmente, há duas classes de bugs em sistemas distribuídos que afetam a disponibilidade, carinhosamente chamadas de Bohrbug e Heisenbug (consulte “Uma conversa com Bruce Lindsay”, ACM Queue vol. 2, nº 8 – novembro de 2004
Um Bohrbug é um problema repetível de software funcional. Com a mesma entrada, o bug produzirá consistentemente a mesma saída incorreta (como o modelo determinístico do átomo de Bohr, que é sólido e facilmente detectado). Esses tipos de bugs são raros quando uma workload chega à produção.
Um Heisenbug é um bug transitório, o que significa que só ocorre em condições específicas e incomuns. Essas condições geralmente estão relacionadas a coisas como hardware (por exemplo, uma falha transitória do dispositivo ou especificidades da implementação de hardware, como tamanho do registro), otimizações do compilador e implementação da linguagem, condições de limite (por exemplo, temporariamente fora do armazenamento) ou condições de corrida (por exemplo, não usar um semáforo para operações com vários processos).
Os Heisenbugs compõem a maioria dos bugs em produção e são difíceis de encontrar porque são ilusórios e parecem mudar de comportamento ou desaparecer quando você tenta observá-los ou depurá-los. No entanto, se você reiniciar o programa, a operação com falha provavelmente será bem-sucedida porque o ambiente operacional é um pouco diferente, eliminando as condições que introduziram o Heisenbug.
Assim, a maioria das falhas na produção são transitórias e, quando a operação é repetida, é improvável que falhe novamente. Para serem resilientes, os sistemas distribuídos precisam ser tolerantes a falhas da Heisenbugs. Exploraremos como isso pode ser feito na seção Aumentando o MTBF do sistema distribuído.
