L'Anello Più Debole: Come le Dipendenze Concatenate Influenzano il Rischio di Sistema

Quando si valutano gli scenari di rischio di un sistema è molto facile trascurare le dipendenze “concatenate”. Siamo abituati a considerare il rischio a livello di “nodo”, chiedendoci “quanto è probabile che questa singola cosa si guasti.” Ma il rischio di sistema è molto più complicato di così.

Nella maggior parte dei sistemi vi sono alcuni componenti che dipendono da altri componenti. Il punto più comune in cui osserviamo questo fenomeno è nella progettazione dello storage per i server, ma si verifica in qualsiasi progettazione di sistema. Un altro buon esempio è il modo in cui le applicazioni web hanno bisogno sia di host applicativi sia di host di database per funzionare.

È più facile spiegare le dipendenze concatenate con un esempio. Esamineremo una progettazione di virtualizzazione standard con storage SAN per capire dove esistono i confini dei domini di guasto, dove esistono le dipendenze concatenate e quale ruolo svolge la ridondanza nella mitigazione del rischio a livello di sistema.

In una progettazione SAN (storage area network) standard per la virtualizzazione si hanno gli host di virtualizzazione (che, per semplicità, chiameremo i “server”), gli switch SAN (switch dedicati alla rete di storage) e gli array di dischi veri e propri. Ciascuno di questi tre “livelli” dipende dagli altri affinché il sistema, nel suo insieme, funzioni. Se avessimo l’insieme più semplice possibile, con un server, uno switch e un array di dischi, avremmo molto chiaramente tre dispositivi che rappresentano tre distinti punti di guasto. Il guasto di uno qualsiasi dei tre causa il guasto dell’intero sistema. Nessuno dei pezzi è utile da solo. Questa è una dipendenza concatenata e la catena è forte solo quanto il suo anello più debole.

Nel nostro esempio semplificato, ciascun dispositivo rappresenta un dominio di guasto. Possiamo mitigare il rischio migliorando l’affidabilità di ciascun dominio. Possiamo aggiungere un secondo server e implementare una strategia di alta disponibilità o di fault tolerance a livello di virtualizzazione per ridurre il rischio di guasto del server. Questo migliora l’affidabilità di un dominio di guasto, ma ne lascia due intatti e altrettanto rischiosi di prima. Possiamo poi affrontare il livello di switching aggiungendo uno switch ridondante e configurando una strategia di multi-pathing per gestire la perdita di un singolo percorso di switching, riducendo il rischio a quel livello. A questo punto sono stati affrontati due domini di guasto. Infine dobbiamo affrontare il dominio di guasto dello storage, cosa che si fa, in modo analogo, aggiungendo ridondanza tramite un secondo array di dischi che viene mirrorato sul primo ed è in grado di effettuare il failover in modo trasparente in caso di guasto.

Ora che abbiamo rafforzato il nostro sistema, abbiamo comunque tre domini di guasto in una catena di dipendenze. Ciò che abbiamo fatto è rendere ciascun “anello” della catena, ciascun dominio di guasto, particolarmente resiliente di per sé. Ma la catena esiste ancora. Questo significa che il sistema, nel suo insieme, è di gran lunga meno affidabile di quanto lo sia da solo un qualsiasi singolo dominio di guasto all’interno della catena. Abbiamo realizzato qualcosa di molto migliore rispetto al punto di partenza, ma abbiamo comunque molti domini di guasto. Questi rischi si sommano.

Ciò che è difficile nel determinare il rischio complessivo è che dobbiamo valutare il rischio di ciascun elemento, poi determinare il nuovo rischio dopo la mitigazione (mediante l’aggiunta di ridondanza) e poi trovare il rischio cumulativo di ciascuno dei domini di guasto insieme, in catena, per determinare il rischio totale dell’intero sistema. È estremamente difficile determinare il rischio all’interno di ciascun dominio di guasto, dato che la modalità di mitigazione del rischio svolge un ruolo significativo. Per esempio, un cluster di array di dischi di storage che effettua il failover troppo lentamente può dar luogo a un guasto complessivo del sistema anche quando il cluster di storage stesso sembra aver funzionato correttamente. Persino definire con chiarezza un guasto può quindi rivelarsi una sfida.

È spesso allettante adottare una valutazione del rischio “dall’alto”, cosa molto pericolosa, ma molto comune per chi non pratica regolarmente la valutazione del rischio. La tendenza, in questo caso, è di considerare il rischio osservando soltanto il dominio di guasto “più in alto” – generalmente i server, in un caso come questo – e ignorando qualsiasi rischio che si trovi al di sotto di quel punto, considerandolo “sotto il cofano” anziché parte della valutazione del rischio. È facile ignorare i componenti più tecnici, meno esposti e compresi peggio, come il networking e lo storage, e concentrarsi sugli aspetti di affidabilità relativamente facili da comprendere e fortemente pubblicizzati del livello più alto. Questa “vista dall’alto” fa sì che i rischi al di sotto del livello superiore vengano oscurati e generalmente ignorati, portando a un rischio elevato senza una buona comprensione del perché.

Comprendere il concetto di dipendenze concatenate spiega perché i sistemi complessi, anche con strategie complesse di mitigazione del rischio, risultano spesso assai più fragili dei sistemi più semplici. Nel nostro esempio precedente potremmo fare diverse cose per “collassare” la catena, ottenendo un sistema complessivamente più affidabile.

Il componente più ovvio che può essere collassato è il dominio di guasto del networking. Se rimuovessimo del tutto gli switch e collegassimo lo storage direttamente ai server (non sempre possibile, ovviamente), elimineremmo di fatto un intero dominio di guasto e rimuoveremmo un anello dalla nostra catena. A questo punto, invece di tre catene, ciascuna delle quali ha un certo potenziale di guasto, ne avremmo solo due. Più semplice è meglio, a parità di tutte le altre condizioni.

Potremmo, in teoria, collassare anche il dominio di guasto dello storage passando dallo storage esterno all’utilizzo di storage locale ai server stessi, portandoci essenzialmente da due domini di guasto a un singolo dominio di guasto – l’unico dominio rimanente, ovviamente, porta con sé una complessità maggiore di quella che aveva prima del collasso, ma la complessità complessiva del sistema è notevolmente ridotta. Anche in questo caso, ciò vale a parità di tutti gli altri fattori.

Un altro approccio da considerare è rendere i singoli nodi più affidabili di per sé. Oggi è di tendenza guardare ai sistemi più grandi e affrontare la mitigazione del rischio in quel modo, aggiungendo nodi ridondanti e a basso costo per aggiungere affidabilità ai domini di guasto. Ma tradizionalmente questo non era il percorso predefinito verso l’affidabilità. In passato era assai più comune, come dimostra la precedente prevalenza dei mainframe e dei sistemi di classe simile, integrare elevati gradi di affidabilità in un singolo nodo. I mainframe e i sistemi di storage di fascia alta, per esempio, lo fanno tuttora. Questo può essere in realtà un approccio estremamente efficace, ma non riesce ad affrontare molti scenari ed è generalmente estremamente costoso, spesso amplificato dalla necessità di avere sistemi mantenuti parzialmente o persino completamente dal fornitore. Questo tende a funzionare solo in particolari circostanze di nicchia e non è pratico su una scala più generale.

Quindi, in qualsiasi sistema di questa natura abbiamo tre strategie chiave di mitigazione del rischio da considerare: migliorare l’affidabilità di un singolo nodo, migliorare l’affidabilità di un singolo dominio o ridurre il numero di domini di guasto (anelli) nella catena di dipendenze. Combinare queste strategie in modo prudente può aiutarci a raggiungere il livello di mitigazione del rischio appropriato per il nostro scenario aziendale.

Dove esiste, e rimarrà, la vera difficoltà è nel confronto tra diverse strategie di mitigazione del rischio. Il rischio di un singolo nodo può generalmente essere stimato con un certo grado di affidabilità. Una strategia di ridondanza all’interno di un singolo dominio è assai meno stimabile – alcune strategie di ridondanza sono altamente efficaci, creando domini di guasto estremamente affidabili, mentre altre possono in realtà ritorcersi contro e ridurre l’affidabilità di un dominio! La complessità che spesso accompagna le strategie di ridondanza non è mai priva di riserve e, sebbene di norma ripaghi, raramente comporta il grado di beneficio in termini di affidabilità che ci si aspetta inizialmente. Stimare il rischio di una catena di dipendenze è quindi tanto più difficile, in quanto richiede una chiara comprensione dei rischi associati a ciascuno dei domini di guasto individualmente, oltre a una comprensione della possibilità di guasto esistente ai confini dei domini (come il guasto da ritardo del failover dello storage menzionato in precedenza.)

Esploriamo le questioni relative alla determinazione del rischio in due approcci molto comuni allo stesso scenario, basandoci su quanto abbiamo discusso finora.

Due esempi estremi della stessa situazione di cui abbiamo parlato sono un singolo server con storage interno usato per ospitare macchine virtuali, rispetto a una “catena” di sei dispositivi con due server, che utilizza una soluzione di alta disponibilità a livello di server, due switch con ridondanza a livello di switching e due array di dischi che forniscono alta disponibilità a livello di storage. Se modifichiamo un qualsiasi fattore importante in questo caso, possiamo generalmente fornire una stima piuttosto chiara del rischio relativo – se, per esempio, uno qualsiasi dei domini di guasto è privo di una ridondanza affidabile – possiamo stabilire abbastanza chiaramente che il singolo server è il sistema complessivamente più affidabile, salvo nei casi in cui a un singolo nodo venga assegnato un grado estremo di affidabilità a livello di singolo nodo, il che è generalmente una strategia impraticabile dal punto di vista finanziario. Ma con ciascun dominio di guasto che mantiene la ridondanza, siamo costretti a confrontare i rischi relativi dell’affidabilità intra-dominio (la catena ridondante) rispetto all’affidabilità inter-dominio (la catena collassata, il singolo server.)

Con i due approcci del tutto differenti non esiste un modo ragionevole per valutare i rischi comparativi dei due metodi di mitigazione del rischio. È generalmente accettato che l’approccio a sei (o più) nodi con un’estesa mitigazione del rischio intra-dominio sia il più affidabile dei due approcci e questo è quasi certamente vero in generale. Ma non è sempre vero e raramente questo approccio supera la strategia a singolo nodo con un margine davvero significativo, mentre comunemente costa da quattro a dieci volte tanto rispetto alla strategia a singolo server. Questo è un costo potenzialmente molto elevato per quello che è probabilmente un piccolo guadagno in affidabilità e un piccolo rischio potenziale di una perdita di affidabilità. Ogni ulteriore elemento di ridondanza aggiunge complessità che un essere umano deve implementare, monitorare e mantenere e con la complessità e l’interazione umana arriva sempre più rischio. Evitare l’errore umano può spesso essere più importante che evitare il guasto meccanico.

Dobbiamo inoltre considerare il costo del ripristino. Se si verifica un guasto, è generalmente banale ripristinare il guasto di un sistema semplice. Un sistema estremamente complesso, una volta guastatosi, può richiedere un grande sforzo per essere riportato in condizioni di funzionamento. I sistemi complessi richiedono inoltre gradi di esperienza e di sicurezza molto più ampi e profondi per essere mantenuti.

Non esiste una risposta facile per determinare l’affidabilità dei sistemi. I moderni sistemi di erogazione delle informazioni sono semplicemente troppo grandi e troppo complessi, con troppi fattori indeterminabili, per poter essere valutati in tutti i casi. Con una buona comprensione delle dipendenze concatenate, tuttavia, e con una comprensione delle strategie di mitigazione del rischio, possiamo adottare misure pratiche per determinare livelli di rischio all’incirca relativi, vedere come si confrontano in termini di costo scenari di rischio simili, individuare i punti di fragilità, riconoscere i domini di guasto e le catene di dipendenze e apprezzare come i cambiamenti nella progettazione del sistema ci sposteranno chiaramente verso l’affidabilità o lontano da essa.