L'affidabilità del 99,9999999% di Erlang (nove nove)

È stato segnalato che Erlang è stato utilizzato nei sistemi di produzione per oltre 20 anni con una percentuale di uptime del 99,9999999%.

Ho fatto i calcoli come segue:

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

Ciò significa che il sistema ha solo meno di un secondo di inattività durante il periodo di 20 anni. Non sto cercando di contestare la validità di questo, sono solo curioso di sapere come possiamo spegnere un sistema (apposta o per sbaglio) per soli 0,631 secondi. Qualcuno che ha familiarità con un sistema software di grandi dimensioni potrebbe spiegarcelo? Grazie.

Qualcuno sa come calcolare il tempo di inattività di un servizio su un cluster di unità di elaborazione (o macchine)?

La cifra di affidabilità non doveva misurare il tempo totale in cui una parte del AXD301(progetto in questione) è stata chiusa per oltre 20 anni. Rappresenta il tempo totale in questi 20 anni in cui il servizio fornito dal AXD301sistema è rimasto offline. Sottile differenza. Come dice Joe Armstrong qui :

L'AXD301 ha raggiunto un'affidabilità di NOVE nove (sì, avete letto bene, 99,9999999%). Mettiamolo nel contesto: 5 nove è considerato buono (5,2 minuti di inattività / anno). 7 nove quasi irraggiungibili ... ma abbiamo fatto 9.

Perchè è questo? Nessuno stato condiviso, oltre a un sofisticato modello di ripristino degli errori.

Se scavi un po 'più a fondo, nella tesi di dottorato scritta da Joe, l'autore originale di Erlang (che include un caso di studio di AXD301), leggi:

Uno dei progetti studiati in questo capitolo è Ericsson AXD301, uno switch ATM ad alte prestazioni e affidabilità .

Quindi, fintanto che la rete di cui faceva parte lo switch funzionava senza tempi di inattività, l'autore può dichiarare "affidabilità nove nove" per AXD301 (che era tutto ciò che ha mai detto, evitando le specifiche). Non significa necessariamente che Erlang sia l'unica causa di un'affidabilità così elevata.

EDIT: In effetti, "20 anni" in sé sembra un'interpretazione errata. Joe menziona una cifra di 20 anni nello stesso articolo, ma in realtà non è collegata alla cifra di affidabilità di nove nove, che potenzialmente è risultata da uno studio molto più breve (come altri hanno menzionato).

Mentre gli altri hanno affrontato il caso specifico di cui stai chiedendo, la tua domanda sembra essere basata su un malinteso. Il modo in cui hai posto la domanda mi fa credere che tu stia pensando che ci sia un processo manuale per far funzionare nuovamente il sistema dopo che si blocca o è stato arrestato per manutenzione.

Erlang ha diverse funzionalità che rimuovono l'orario di lavoro umano come fonte di tempi di inattività:

1. Ricarica hot code . In un sistema Erlang, è facile compilare e caricare un modulo sostitutivo per uno esistente. L'emulatore BEAM esegue lo scambio automaticamente senza apparentemente fermare nulla. C'è senza dubbio una piccola quantità di tempo durante il quale avviene questo trasferimento, ma avviene automaticamente nel tempo del computer, piuttosto che manualmente nel tempo umano. Ciò rende possibile eseguire aggiornamenti con tempi di inattività essenzialmente pari a zero . (Potresti avere tempi di inattività se il modulo sostitutivo ha un bug che blocca il sistema, ma è per questo che esegui il test prima di distribuirlo in produzione.)

2. Supervisori . La libreria OTP di Erlang ha un framework di supervisione integrato che consente di definire come il sistema dovrebbe reagire se un modulo si blocca. L'azione standard qui è riavviare il modulo guasto. Supponendo che il modulo riavviato non si blocchi immediatamente, il tempo di inattività totale addebitato al sistema potrebbe essere una questione di millisecondi. Un sistema solido che difficilmente si arresta in modo anomalo potrebbe infatti accumulare solo una frazione di secondo del tempo di inattività totale nel corso di anni di funzionamento.

3. Processi . Questi corrispondono all'incirca a thread in altre lingue, tranne per il fatto che non condividono lo stato se non tramite archivi dati persistenti. Oltre a questo, la comunicazione avviene tramite il passaggio di messaggi. Poiché i processi Erlang sono molto economici (molto più economici dei thread del sistema operativo), questo incoraggia un design ad accoppiamento lasco, in modo che se un processo muore, solo una piccola parte del sistema subisce tempi di inattività. In genere, il supervisore riavvia quell'unico processo, con un impatto minimo o nullo sul resto del sistema.

4. Passaggio di messaggi asincrono . Quando un processo vuole dire qualcosa a un altro, c'è un operatore di prima classe nella lingua Erlang che gli permette di farlo. Il processo di invio del messaggio non deve attendere che il destinatario elabori il messaggio e non deve coordinare la proprietà dei dati inviati. La natura funzionale asincrona del sistema di trasmissione dei messaggi di Erlang si prende cura di tutto ciò. Ciò aiuta a mantenere tempi di attività elevati perché riduce l'effetto che i tempi di inattività in una parte di un sistema possono avere su altre parti.

5. Clustering . Ciò segue dal punto precedente: il meccanismo di passaggio dei messaggi di Erlang funziona in modo trasparente tra le macchine su una rete, quindi un processo di invio non deve nemmeno preoccuparsi che il destinatario sia su una macchina separata. Ciò fornisce un meccanismo semplice per suddividere un carico di lavoro tra molte macchine, ognuna delle quali può spegnersi separatamente senza danneggiare il tempo di attività complessivo del sistema.

La cifra di disponibilità del 99,9999999% è una statistica spesso citata ma fondamentalmente fuorviante. Mats Cronqvist, uno dei membri del team dell'AXD-301, ha tenuto una presentazione (video) (a cui ho partecipato) alla conferenza 2010 della Erlang Factory a San Francisco, discutendo questa precisa statistica di disponibilità. Secondo lui, è stato rivendicato dalla British Telecom per un periodo di prova (credo da gennaio a settembre 2002) di "5 anni nodo" utilizzando l'AXD-301. Alla fine del periodo di prova c'erano 14 nodi che trasportavano traffico in tempo reale.

Cronqvist ha specificamente affermato che questo non è rappresentativo dell'intera storia dell'AXD-301, o di Erlang in generale, e che non era contento che Joe Armstrong continuasse a citarlo, portando a aspettative esagerate sull'affidabilità di Erlang. Altri hanno scritto che cinque nove è una cifra più realistica.

Va detto che sono un fervente sostenitore e sviluppatore di Erlang, che crede che l'uso esperto di Erlang possa effettivamente portare a sistemi ad altissima disponibilità, ma vuole solo ridurre l'hype. Naturalmente presumo che la rappresentazione dei fatti di Cronqvist sia accurata e non ho motivo di credere il contrario.

La mia comprensione di queste statistiche è che vengono calcolate su TUTTI i sistemi AXD301 in produzione. Possiamo aspettarci che quando un AXD301 ha un problema grave, rimarrebbe inattivo per più di 0,631 secondi. Durante questo periodo, altri AXD301 subentreranno per mantenere la rete operativa.

Tuttavia, quando si somma il numero totale di ore di tutti gli AXD301 in esecuzione, il rapporto per quello AXD301 in errore, si trova 99,999999%

È così che intendo questa cifra.

Spero che questo aiuto.