Confiabilidade de 99,9999999% (nove noves) de Erlang

Erlang foi relatado para ter sido usado em sistemas de produção por mais de 20 anos com uma porcentagem de tempo de atividade de 99,9999999%.

Fiz as contas da seguinte forma:

20*365.25*24*60*60*(1 - 0.999999999) == 0.631 s

Isso significa que o sistema tem apenas menos de um segundo de tempo de inatividade durante o período de 20 anos. Não estou tentando contestar a validade disso, estou apenas curioso sobre como podemos desligar um sistema (propositalmente ou por acidente) por apenas 0,631 segundo. Alguém familiarizado com grandes sistemas de software poderia nos explicar isso? Obrigado.

Alguém sabe como calcular o tempo de inatividade de um serviço em um cluster de unidades de processamento (ou máquinas)?

O número de confiabilidade não deveria medir o tempo total que qualquer parte do AXD301(projeto em questão) permaneceu paralisado por mais de 20 anos. Representa o tempo total nesses 20 anos que o serviço prestado pelo AXD301sistema esteve sempre offline. Diferença sutil. Como Joe Armstrong diz aqui :

O AXD301 alcançou uma confiabilidade de NOVE noves (sim, você leu certo, 99,9999999%). Vamos colocar isso em contexto: 5 noves é considerado bom (5,2 minutos de inatividade / ano). 7 noves quase inatingíveis ... mas conseguimos 9.

Por que é isso? Nenhum estado compartilhado, além de um modelo de recuperação de erro sofisticado.

Se você se aprofundar um pouco mais, na tese de doutorado escrita por Joe, o autor original de Erlang (que inclui um estudo de caso de AXD301), você lerá:

Um dos projetos estudados neste capítulo é o Ericsson AXD301, um switch ATM altamente confiável de alto desempenho .

Portanto, desde que a rede da qual o switch fazia parte estivesse funcionando sem tempo de inatividade, o autor pode declarar "nove noves de confiabilidade" para AXD301(que foi tudo o que ele disse, evitando detalhes). Isso não significa necessariamente que Erlang seja a única causa dessa alta confiabilidade.

EDIT: Na verdade, "20 anos" em si parece uma interpretação errônea. Joe menciona um número de 20 anos no mesmo artigo, mas não está realmente conectado ao número de confiabilidade de nove noves, que potencialmente saiu de um estudo muito mais curto (como outros mencionaram).

Embora os outros tenham abordado o caso específico sobre o qual você está perguntando, sua pergunta parece estar baseada em um equívoco. A maneira como você fez a pergunta me faz acreditar que você está pensando que existe um processo manual para colocar o sistema em execução novamente após ele travar ou ser retirado do ar para manutenção.

Erlang tem vários recursos que removem o tempo de trabalho humano como fonte de inatividade:

1. Recarregamento de código quente . Em um sistema Erlang, é fácil compilar e carregar um módulo de substituição para um existente. O emulador BEAM faz a troca automaticamente sem aparentemente interromper nada. Sem dúvida, há um pequeno período de tempo durante o qual essa transferência acontece, mas está acontecendo automaticamente no tempo do computador, em vez de manualmente no tempo humano. Isso torna possível fazer atualizações com praticamente nenhum tempo de inatividade. (Você pode ter um tempo de inatividade se o módulo de substituição tiver um bug que trava o sistema, mas é por isso que você testa antes de implantar para produção.)

2. Supervisores . A biblioteca OTP de Erlang tem uma estrutura de supervisão integrada que permite definir como o sistema deve reagir se um módulo falhar. A ação padrão aqui é reiniciar o módulo com falha. Supondo que o módulo reiniciado não trave imediatamente novamente, o tempo total de inatividade cobrado em seu sistema pode ser uma questão de milissegundos. Um sistema sólido que quase nunca falha pode de fato acumular apenas uma fração de segundo do tempo total de inatividade ao longo de anos de tempo de execução.

3. Processos . Eles correspondem aproximadamente a threads em outras linguagens, exceto que eles não compartilham estado, exceto por meio de armazenamentos de dados persistentes. Fora isso, a comunicação acontece por meio de passagem de mensagens. Como os processos Erlang são muito baratos (muito mais baratos do que os encadeamentos do SO), isso incentiva um design fracamente acoplado, de forma que, se um processo morrer, apenas uma pequena parte do sistema ficará inativa. Normalmente, o supervisor reinicia aquele processo, com pouco ou nenhum impacto no resto do sistema.

4. Passagem de mensagem assíncrona . Quando um processo quer dizer algo a outro, existe um operador de primeira classe na linguagem Erlang que permite isso. O processo de envio da mensagem não precisa esperar que o receptor processe a mensagem e não precisa coordenar a propriedade dos dados enviados. A natureza funcional assíncrona do sistema de passagem de mensagens de Erlang cuida de tudo isso. Isso ajuda a manter tempos de atividade elevados porque reduz o efeito que o tempo de inatividade em uma parte do sistema pode ter em outras partes.

5. Clustering . Isso segue do ponto anterior: o mecanismo de passagem de mensagens de Erlang funciona de forma transparente entre as máquinas em uma rede, de modo que um processo de envio nem mesmo precisa se preocupar se o receptor está em uma máquina separada. Isso fornece um mecanismo fácil para dividir uma carga de trabalho entre várias máquinas, cada uma das quais pode ser desativada separadamente sem prejudicar o tempo de atividade geral do sistema.

O número de disponibilidade de 99,9999999% é uma estatística freqüentemente citada, mas fundamentalmente enganosa. Mats Cronqvist, um dos membros da equipe do AXD-301, fez uma apresentação (vídeo) (da qual participei) na conferência Erlang Factory de 2010 em San Francisco, discutindo essa estatística de disponibilidade precisa. Segundo ele, foi reivindicado pela British Telecom por um período de teste (acredito que de janeiro a setembro de 2002) de "5 nós-anos" usando o AXD-301. Havia 14 nós transportando tráfego ao vivo até o final do teste.

Cronqvist afirmou especificamente que isso não é representativo de toda a história do AXD-301, ou de Erlang em geral, e que ele não estava feliz que Joe Armstrong continuasse citando isso, levando a expectativas exageradas sobre a confiabilidade de Erlang. Outros escreveram que cinco noves é uma figura mais realista.

Deve-se afirmar que sou um fervoroso apoiador e desenvolvedor do Erlang, que acredita que o uso especializado do Erlang pode realmente levar a sistemas altamente disponíveis, mas só quero reduzir o hype. É claro que presumo que a representação dos fatos de Cronqvist é precisa e não tenho razão para acreditar de outra forma.

Meu entendimento dessas estatísticas é que elas são computadas em TODOS os sistemas AXD301 em produção. Podemos esperar que, quando um AXD301 tem um problema grave, ele fique inativo por mais de 0,631 segundos. Durante este período, outro AXD301 assumirá para manter a rede operacional.

No entanto, quando você soma o número total de horas de todos os AXD301 em execução, faça a proporção para o AXD301 com falha, você encontra 99,999999%

É assim que eu entendo essa figura.

Espero essa ajuda.