In quali casi sceglierei un sistema distribuito rispetto a un normale?

Tongue in guancia: quando hai un sacco di soldi in eccesso da bruciare, un sacco di tempo da dedicare al debug e sei abbastanza felice di sprecare l’80% delle tue risorse.

I sistemi distribuiti sono fantastici – sono complessi, possono affrontare classi di problemi che non sono suscettibili di sistemi non distribuiti (la mia interpretazione del termine “regolare”). Scuotono i tuoi concetti di temporalità, causalità, coerenza, consenso, ecc.

Possono essere usati per risolvere enormi problemi.

Spesso creano più problemi di quanti ne risolvano. Pochissimi problemi richiedono sistemi distribuiti. Uno dei miei articoli preferiti che tocca questo è il documento COST di Frank McSherry. Il suo punto è che spesso i sistemi distribuiti (quelli usati per risolvere in particolare problemi strutturati graficamente, dal momento che stava lavorando su Naiad) non sono particolarmente efficienti nel modo in cui risolvono i problemi. Non è il solo ad osservarlo sui sistemi distribuiti.

Vengo da una storia di file system distribuiti, quindi la mia prospettiva è meno sull’uso dei sistemi distribuiti per scalare l’elaborazione e più su come farlo per diffondere i tuoi dati. Si scopre che anche quando si guardano i sistemi di calcolo distribuito, il costo di ottenere i dati dove devono andare spesso domina tutto il resto. Quindi c’è ancora lavoro da fare per me per qualche altro anno.

Usiamo i sistemi distribuiti quando c’è qualcosa nel problema che stiamo cercando di risolvere che non si rende adatto ai singoli sistemi. Ciò potrebbe includere preoccupazioni sulla disponibilità: se memorizziamo tutti i dati su un disco rigido collegato al computer, perdiamo i dati quando il disco rigido si scioglie. In questi giorni vediamo SSD e la loro capacità sta aumentando notevolmente, con previsioni di unità SSD da 128 TB nel 2018. Ora puoi avere lo spazio di condivisione PB nel tuo rack. Perdere petabyte di dati perché si perde un rack amplifica sicuramente il rischio. Quindi dupliciamo i dati: il trucco tradizionale è quello di avere un duplicato locale, che protegge dagli errori di una singola copia, e quindi di avere una duplicazione remota, che protegge dagli errori del data center. Facciamo cose intelligenti come la codifica di cancellazione, che è più efficiente nello spazio rispetto alla replica più tradizionale.

Ma ci sono alcuni problemi per i quali abbiamo davvero bisogno di molta potenza di calcolo. Non molti, ma abbastanza che l’attuale cluster più grande è composto da oltre 10 milioni di core. Montare 10 milioni di elementi insieme non è un’impresa da poco, e 10 milioni di core sono impegnativi.

Qualcosa fallisce sempre. Ho partecipato al primo seminario su File system paralleli scalabili globali e una ricerca indica che questo è stato trattenuto nell’aprile 2002. Una delle storie di quel seminario che mi ha attaccato è che al momento avevano assemblato un gruppo di 128 workstation Sun , ciascuno con 40 dispositivi di archiviazione collegati. Questo era tutto l’hardware ad alta disponibilità e il tempo più lungo che erano stati in grado di far funzionare tutto era di 18 minuti.

I sistemi distribuiti devono gestire i guasti. Guasti hardware e guasti software. Devono affrontare la complessità. Devono preoccuparsi di una classe di problemi che i sistemi “normali” non hanno. Ci sono solo molte altre parti in movimento.

Costruirli è (per me) davvero divertente.

Quasi nessuno ha bisogno di loro, però. Quindi, la ragione per usare un “sistema normale” è perché risolve il problema attuale, il che significa che non devi preoccuparti delle sfide del sistema distribuito: la complessità di gestirne uno, possederne uno, programmarne uno, ripararlo o pagando uno.

Ma se hai un problema che giustifica uno e il finanziamento richiesto, sicuramente ci sono persone che vorrebbero aiutarti.

In quali casi sceglierei un sistema distribuito rispetto a un normale?

Uh … Uno “normale”?

Qualsiasi sistema software ha N processi indipendenti che insieme soddisfano le richieste dell’utente finale. Se la natura del sistema è tale che N = 1, il design naturale del sistema è sequenziale .

Nel caso molto probabile che N> 1, il sistema è concorrente . Ciò significa che in qualsiasi momento, potrebbe esserci più di un processo che contribuisce a soddisfare qualsiasi richiesta di un singolo utente. Non appena questo è il caso, gestire questi processi in parallelo (in un dato istante più di uno può essere eseguito) fornisce un vantaggio in termini di prestazioni. Spesso è un grande vantaggio.

I sistemi concorrenti si ridimensionano aggiungendo più hardware (anziché ottenere hardware sempre più veloce, che al momento non è possibile).

Per ridimensionare un sistema aggiungendo hardware, ogni processo all’interno dell’architettura deve essere eseguito in modo completamente indipendente e interagire tra loro tramite una qualche forma di canale di comunicazione.

E così siamo arrivati ​​ai sistemi distribuiti come mezzo per gestire la scala, sia dell’architettura del software che del grado di carico dell’utente.

Dovresti “scegliere” un tale design quando è nella natura del sistema. E se non lo è, avrai difficoltà a crescere. Fortunatamente, quasi tutti i sistemi ammettono un design concorrente e distribuito.

Quando si desidera maggiore affidabilità, disponibilità, capacità e / o throughput di quanto si potrebbe altrimenti notare che problemi di progettazione, implementazione e test producono sistemi meno affidabili del software in esecuzione su un singolo computer.

Quando hai bisogno di maggiori capacità e prestazioni. Soprattutto quando hai bisogno di un vero sistema scalabile.