Single point of failure

Un single point of failure (SPOF) descrive una vulnerabilità del sistema sotto forma di un singolo componente. Se il componente ha un malfunzionamento, l’intero sistema si guasta. Quali sono i diversi tipi di SPOF e come si può minimizzare il rischio che si verifichino?

Un single point of failure (SPOF) descrive un tipo di vulnerabilità all’interno di un sistema. Un SPOF esiste quando il malfunzionamento di un singolo componente causa il guasto dell’intero sistema. Esistono diverse “modalità di guasto”. Queste possono essere distinte in tre categorie:

1. Tallone d’Achille o “anello più debole della catena”: la perdita di un componente porta a un’improvvisa perdita di funzionalità dell’intero sistema.
2. Reazione a catena o “effetto domino”: il guasto di un componente causa il successivo malfunzionamento di altri componenti che porta al guasto dell’intero sistema.
3. Collo di bottiglia: un componente agisce come fattore limitante dell’intero sistema. Se il componente limitante è danneggiato, le prestazioni del sistema si riducono alla capacità del componente.

I SPOF sono comuni nei sistemi complessi con componenti interconnessi a più livelli. A seconda della struttura del sistema, il malfunzionamento di un componente critico causa il guasto dell’intero sistema. Il single point of failure assume la forma di un componente critico.

La complessità di un sistema a più livelli può rendere difficile l’individuazione di SPOF. Non esiste un modo semplice per identificare le interazioni dei singoli componenti. I guasti o i problemi sono difficili da individuare. In linea di massima, ogni componente non ridondante critico per il funzionamento deve essere trattato come un single point of failure.

Prendiamo ad esempio il corpo umano. Abbiamo un solo cuore e un solo cervello: gli organi critici non sono progettati in modo ridondante. Se uno di questi organi funziona male, l’intero corpo si guasta. I SPOF funzionano come cuore e cervello. Al contrario, occhi, orecchie, polmoni e reni sono duplicati. Se necessario, il corpo compensa il guasto di uno di essi e continua a funzionare con un’efficienza ridotta.

In un data center, tutti i componenti critici per il funzionamento sono potenziali SPOF. Pertanto, i server sono solitamente dotati di connessioni ridondanti alla rete elettrica e alla rete. La memoria di massa è fornita in modo ridondante tramite RAID o tecnologie simili. L’obiettivo è garantire che il sistema continui a funzionare in caso di guasto di un singolo componente critico.

Esistono diversi tipi di single point of failure (SPOF). Dopotutto, i SPOF non riguardano solo i sistemi informatici. Vediamo alcuni esempi.

Nei famosi film di “Guerre stellari”, un single point of failure porta alla distruzione della temuta “Morte Nera”. Un singolo siluro protonico sparato dal protagonista colpisce un punto critico del reattore. L’esplosione provoca una catastrofica reazione a catena che distrugge l’intera Morte Nera.

Nel 2021, la nave container “Ever Given” è rimasta bloccata nel Canale di Suez. La nave si è incagliata in una sezione critica del canale che funge da unica via d’acqua. Il blocco ha paralizzato il traffico marittimo lungo l’intero canale. In questo caso il single point of failure è stata la via d’acqua non ridondante.

Nel 2018 e nel 2019 si sono verificati due incidenti di aerei “Boeing 737 MAX” che hanno portato alla perdita di centinaia di vite. La causa degli incidenti è stato un singolo sensore che ha fornito dei dati errati. Sulla base dei dati del sensore, il sistema di controllo automatico del volo non ha funzionato correttamente causando la precipitazione degli aerei. Sebbene in questo caso siano stati commessi diversi errori, il single point of failure è stato il sensore.

Anche i sistemi progettati per l’alta disponibilità non sono completamente protetti dai SPOF. Negli ultimi anni, i principali servizi cloud hanno subito ripetutamente gravi guasti. Nella maggior parte dei casi, il single point of failure è stato umano. I dati di configurazione sbagliati possono paralizzare rapidamente un intero sistema di produzione, anche se i suoi componenti sono progettati in modo ridondante.

Immaginate il seguente esempio: il vostro dispositivo è connesso al WiFi ma il browser web non funziona. L’orologio inizia quindi a regolare automaticamente l’ora. Questo piccolo problema è abbastanza da farvi strappare i capelli ma la soluzione è semplice:

La famosa frase “È sempre il DNS” sembra divertente, ma è una descrizione seria del potenziale di errore del Domain Name System (DNS). Dopo tutto, quando i server DNS non rispondono, i siti web e i servizi possono non funzionare in vari modi. L’effetto è simile all’interruzione della connessione a Internet. Tuttavia, in questo caso il traffico di pacchetti tra indirizzi IP continua a funzionare.

Gli errori DNS si verificano solitamente sul lato utente se i server DNS memorizzati nel sistema non sono accessibili. È quindi buona norma memorizzare due indirizzi di name server. Se il primo server non è disponibile, viene utilizzato il secondo. In questo modo si crea ridondanza e si risolve il single point of failure.

Spesso, entrambi i server DNS appartengono alla stessa organizzazione. Se uno di essi si guasta, vi è un’alta probabilità che anche l’altro venga coinvolto nel malfunzionamento. Per sicurezza si possono memorizzare gli indirizzi di due name server di organizzazioni diverse. Una combinazione molto diffusa è 1.1.1.1 e 9.9.9.9 di Cloudflare e Quad9 come server DNS primario e secondario.

Alla fine del 2021, un gran numero di servizi web basati su Java erano affetti dalla falla di sicurezza Log4Shell. Il single point of failure era una libreria di logging Java chiamata Log4J. Quindi, un attacco di sistema poteva portare nel peggiore dei casi all’acquisizione di un intero sistema vulnerabile.

In generale, la prevenzione è la strategia migliore per evitare i SPOF. Per definizione, un single point of failure porta alla perdita di funzionalità dell’intero sistema. Quando ciò accade, spesso è troppo tardi. Limitare i danni può quindi essere l’unica opzione possibile.

Per questi motivi le misure preventive e la pianificazione delle emergenze sono una strategia migliore. È possibile simulare scenari di guasto credibili e analizzare i rischi e le possibili misure di protezione. Diversi tipi di single point of failure possono essere prevenuti da alcune caratteristiche del sistema:

I sistemi critici ben preparati sono sottoposti a un monitoraggio continuo per rilevare gli errori il prima possibile e correggerli se necessario.

Una raccomandazione per contrastare i SPOF è quella di creare ridondanze. Diverse istanze di un componente critico (ad esempio alimentazione, connessione di rete, server DNS) vengono gestite in parallelo. Se uno di essi si guasta, il sistema continua a funzionare senza che si verifichino cali delle prestazioni.

La ridondanza impedisce anche molti SPOF sul lato software. Un esempio sono i famosi microservizi rispetto ai software monoliti. Un sistema di microservizi è disaccoppiato e meno complesso, il che lo rende più robusto contro i SPOF. Inoltre, poiché i microservizi vengono avviati come contenitori, è più facile creare ridondanze.

Come fa esattamente la ridondanza a proteggere un sistema? Utilizziamo la stima dell’affidabilità di un sistema nota come “legge di Lusser” per illustrarlo. Di seguito riportiamo un esempio:

Supponiamo che un sistema abbia due connessioni indipendenti e parallele a un alimentatore. Supponiamo inoltre che la probabilità che il collegamento si guasti in un determinato periodo sia dell’1%. La probabilità di guasto completo del collegamento di alimentazione può essere calcolata come il prodotto delle probabilità:

1. Probabilità di fallimento di un’istanza:

1% = 1 / 100 = 1 / 10 ^ 2 = 0,01

1. Probabilità di fallimento di due istanze in successione:

1% * 1% = (1 / 10 ^ 2) ^ 2 = 1 / 10 ^ 4 = 0,0001

Come si può vedere, la probabilità di un SPOF non si dimezza quando si eseguono due istanze, ma si riduce di due dimensioni. Si tratta di un miglioramento considerevole. Con tre istanze in esecuzione in parallelo, un guasto dell’intero sistema dovrebbe essere quasi impossibile.

Purtroppo, la ridondanza non è una panacea. Piuttosto, questo metodo protegge un sistema dai SPOF entro certi limiti. In primo luogo, la probabilità di guasto di un’istanza deve essere indipendente dalla probabilità di guasto dell’istanza o delle istanze ridondanti. Questo non è il caso in cui il guasto è causato da un evento esterno. Se un data center va a fuoco, i componenti ridondanti si guastano insieme.

Oltre alla ridondanza dei componenti distribuiti, la distribuzione di alcuni componenti è fondamentale per mitigare i SPOF. La distribuzione geografica dell’infrastruttura di archiviazione dati e di calcolo protegge dai disastri ambientali. Inoltre, è utile cercare di ottenere una certa eterogeneità o diversità dei componenti critici del sistema. La diversità riduce la probabilità che le istanze ridondanti si guastino.

Illustriamo il vantaggio della diversità usando la ((sicurezza informatica|server/sicherheit/was-ist-cybersicherheit/)) come esempio. Immaginate un data center con load balancer ridondanti dello stesso tipo. Una vulnerabilità di sicurezza in uno dei load balancer si presenta anche nelle istanze ridondanti. Nel peggiore dei casi, un attacco paralizzerà tutte le istanze. Utilizzando modelli diversi, l’intero sistema ha maggiori possibilità di continuare a funzionare a prestazioni ridotte.

La ridondanza non è sempre sufficiente a prevenire i SPOF. Inoltre, alcuni componenti non possono essere progettati in modo ridondante. Quando la ridondanza non è un’opzione, entrano in gioco altre strategie.

L’approccio della “difesa in profondità” è ben noto nel campo della sicurezza informatica. Si tratta di erigere più anelli di protezione indipendenti intorno a un sistema. Questi devono essere violati uno dopo l’altro per provocare un guasto al sistema. La probabilità che l’intero sistema si guasti a causa di un singolo componente è infatti minore.

Per quanto riguarda i sistemi digitali, esistono linguaggi di programmazione speciali con tolleranza ai guasti incorporata. L’esempio più noto è il linguaggio “Erlang”, sviluppato alla fine degli anni Ottanta. Insieme all’ambiente di runtime associato, questo linguaggio è adatto per creare sistemi altamente disponibili e tolleranti ai guasti.

Il trionfo globale del World Wide Web e la diffusione dello sviluppo web hanno rappresentato una nuova sfida. I programmatori sono stati costretti a sviluppare siti web che funzionassero su una varietà di dispositivi. L’approccio di base utilizzato in questo processo è noto come “graceful degradation” (in italiano: “degradazione graduale”). Se un browser o un dispositivo non supporta una particolare tecnologia in una pagina, questa viene resa nel modo migliore possibile. Si tratta di un approccio “fail-soft”:

Non aspettate che il sistema si guasti per identificare i single point of failure nel vostro sistema. È meglio procedere in modo proattivo considerandoli come parte integrante di una strategia di gestione del rischio. In questo modo si utilizzano le analisi dell’ingegneria dell’affidabilità, come l’analisi dell’albero dei guasti o dell’albero degli eventi. L’analisi delle modalità e degli effetti dei guasti (FMEA) viene utilizzata per identificare le fonti di guasto più critiche.

L’approccio generale per identificare i single point of failure nell’IT aziendale consiste nell’eseguire una valutazione del rischio sulle tre dimensioni principali:

• Hardware
• Software/servizi/provider
• Personale

In primo luogo, si crea una lista di controllo dell’analisi SPOF per mostrare le aree generali da analizzare ulteriormente. Successivamente, viene eseguita un’analisi SPOF dettagliata delle singole aree:

• Dispositivi non monitorati nella rete
• Sistemi software o hardware non ridondanti
• Personale e fornitori che non possono essere sostituiti in caso di emergenza
• Tutti i dati non inclusi nei backup

Per ogni componente del sistema viene analizzato l’effetto negativo di un guasto. Inoltre, viene stimata la probabilità approssimativa di un guasto catastrofico. I risultati sono incorporati in un piano generale di “disaster recovery” per garantire la sicurezza nel data center.

Come misura di base per evitare i SPOF, la ridondanza dell’archiviazione dei dati e della potenza di calcolo deve essere garantita a tre livelli:

• A livello di server attraverso componenti hardware ridondanti
• A livello di sistema attraverso il clustering, ovvero l’uso di più server
• A livello di data center utilizzando più siti distribuiti in diversi luoghi geografici