Progettazione software fault-tolerant dell'applicazione in esecuzione come cluster distribuito

1

Il sistema software mission-critical (come il software di controllo dei sistemi nei veicoli spaziali) spesso impiega più moduli software ridondanti sviluppati da diversi team (a volte utilizzando diversi linguaggi di programmazione), alla stessa interfaccia e alle specifiche comportamentali. L'idea è che i bug del software che emergono solo durante alcuni casi estremi, non presi nei test di pre-produzione, dovrebbero essere localizzati per l'implementazione in uno solo dei moduli, lasciando gli altri moduli intatti dal momento che sono sviluppati da diversi team che usano strumenti diversi / lingue.

Tuttavia, ci sono questi sistemi un po 'meno (mission) critici che l'intero malfunzionamento può avere un impatto finanziario significativo, riescono a essere tolleranti ai guasti, apparentemente usando un'istanza ridondante di software scritto nella stessa lingua, forse dallo stesso team di sviluppatori, che non solo garantiscono l'alta disponibilità ma anche la tolleranza d'errore per le transazioni in corso, in modo tale che l'errore su un nodo che serve una richiesta possa continuare senza problemi su un altro nodo. In caso di guasto hardware, posso capire perché questo potrebbe funzionare. Tuttavia, in caso di errore del software, perché / come funziona? Non è che lo stesso errore software che ha causato il fallimento del primo nodo, avrebbe avuto un impatto anche sull'altro nodo?

Inoltre, ci sono alcuni schemi di progettazione che consentono di comporre un sistema fault tolerant utilizzando componenti intrinsecamente non fault tolerant?

    
posta icarus74 05.03.2016 - 06:00
fonte

2 risposte

2

Se l'errore è all'interno dell'hardware come CPU , o con non- memoria ECC , quindi avere più nodi utilizzando lo stesso codice ma un hardware diverso sarebbe davvero d'aiuto.

Ma se l'errore è all'interno del codice ed è indipendente dall'hardware, si manifesterà su ogni nodo se tutti i nodi condividono lo stesso codice.

Da qui, hai tre scelte:

  • Scrivi software migliore in primo luogo. Esegui le revisioni del codice, aumenta la copertura dei test. Questa è la tecnica utilizzata dalla maggior parte delle aziende per progetti che non sono cruciali per la vita, ma che dovrebbero comunque essere affidabili.

  • Utilizza prova formale . parzialmente utilizzato per alcuni progetti life-critical, questo approccio ha un costo così elevato che non è possibile utilizzarlo in modo ragionevole per i normali prodotti software.

  • Chiedi a due team di scrivere indipendentemente lo stesso software utilizzando diversi linguaggi di programmazione e piattaforme diverse. Questo è esattamente ciò di cui stai parlando nella tua domanda e potrebbe essere un buon compromesso tra altri due approcci.

risposta data 05.03.2016 - 08:42
fonte
2

L'aspetto del software dei sistemi fault tolerant risiede nell'ambiente. Durante l'esecuzione di 2 sistemi identici si vedrebbe replicare lo stesso bug del software, spesso è un caso che un sistema si ritrovi in uno stato in cui va storto (ad es. Un problema di blocco del thread, esaurimento della memoria ecc.), Lo spostamento dell'elaborazione su un secondario il server non avrebbe lo stesso ambiente e continuerà a funzionare correttamente (o almeno fino a quando il primo è stato corretto / riavviato).

I bug si dividono in 2 categorie principali: ci sono bug che si mostrano nel normale funzionamento e sono facilmente riproducibili (ad es. fai clic su una voce di menu e compare una finestra di errore a causa di un errore nella codifica). Ma l'altro tipo di bug sembra quasi casuale a causa del modo in cui il software è così complesso e interdipendente da altri fattori. Il threading è un ottimo esempio: un programma può funzionare perfettamente per anni fino a quando un giorno si blocca improvvisamente. Indagare su questo bug può mostrare un punto morto che nessuno ha preso in considerazione fino al giorno in cui si è dimostrato.

Questi sono i bug che sono difficili da rilevare e sono la ragione per cui vengono creati i sistemi fault-tolerant. È possibile riavviare il sistema e cancellare l'errore, ma il riavvio richiede tempo e provoca tempi di inattività. Se hai un sistema ridondante pronto a prendere il sopravvento, puoi riavviare senza tempi di fermo. Comprendi che la maggior parte dei sistemi funziona correttamente per molto tempo fino a quando qualcosa non si verifica. Anche un sistema con un bug funzionerà correttamente

    
risposta data 04.05.2016 - 11:50
fonte

Leggi altre domande sui tag