Nodi slave nel Hadoop Distributed File System (HDFS) - manichini

In un cluster Hadoop, ogni nodo dati (noto anche come nodo slave ) esegue un processo in background denominato DataNode. Questo processo in background (noto anche come demone ) tiene traccia delle porzioni di dati che il sistema memorizza sul suo computer. Parla regolarmente al server master per HDFS (noto come NameNode) per segnalare l'integrità e lo stato dei dati memorizzati localmente.

I blocchi di dati sono memorizzati come file raw nel file system locale. Dal punto di vista di un utente Hadoop, non hai idea di quale dei nodi slave abbia i pezzi del file che devi elaborare. Dall'interno di Hadoop, non si vedono blocchi di dati o modalità di distribuzione all'interno del cluster: tutto ciò che vedi è un elenco di file in HDFS.

La complessità di come i blocchi di file sono distribuiti nel cluster è nascosta a te - non sai quanto sia complicato tutto e non bisogno di per conoscere. In realtà, i nodi slave non sanno nemmeno cosa si trovano all'interno dei blocchi di dati che stanno memorizzando. È il server NameNode che conosce le mappature di quali blocchi di dati compongono i file memorizzati in HDFS.

Miglioramento della ridondanza

Un principio di base del design di HDFS è il concetto di minimizzare il costo dei singoli nodi slave utilizzando componenti hardware commodity. Per sistemi massicciamente scalabili, questa idea è sensata perché i costi aumentano rapidamente quando occorrono centinaia o migliaia di nodi slave. L'utilizzo di hardware a basso costo ha una conseguenza, tuttavia, in quanto i singoli componenti non sono affidabili quanto l'hardware più costoso.

Quando si scelgono le opzioni di archiviazione, considerare l'impatto dell'uso di unità commodity piuttosto che di unità di qualità enterprise costose. Immagina di avere un cluster a 750 nodi, in cui ogni nodo ha 12 hard disk dedicati allo storage HDFS.

Sulla base di un tasso di guasto annuale (AFR) del 4 percento per le unità disco commodity (un dato disco rigido ha una probabilità del 4 percento di non riuscire in un dato anno, in altre parole), il tuo cluster probabilmente sperimenterà un hard disk fallimento ogni giorno dell'anno.

Perché ci possono essere così tanti nodi slave, il loro fallimento è anche un evento comune in cluster più grandi con centinaia o più nodi. Tenendo a mente queste informazioni, HDFS è stato progettato partendo dal presupposto che tutti i componenti hardware , anche a livello di nodo slave, non sono affidabili.

HDFS supera l'inaffidabilità dei singoli componenti hardware attraverso la ridondanza: questa è l'idea alla base di queste tre copie di ogni file memorizzato in HDFS, distribuito nel sistema.Più specificamente, ogni blocco di file memorizzato in HDFS ha un totale di tre repliche. Se un sistema si rompe con un blocco di file specifico di cui hai bisogno, puoi rivolgerti agli altri due.

Disegnare la progettazione del server dei nodi slave

Per bilanciare fattori così importanti come il costo totale di proprietà, la capacità di archiviazione e le prestazioni, è necessario pianificare attentamente la progettazione dei propri nodi slave.

Di solito si vedono i nodi slave ora dove ogni nodo ha in genere 12 o 16 unità disco fisso da 3 TB collegate in locale. I nodi slave utilizzano CPU dual-socket moderatamente veloci con da sei a otto core ciascuna - nessun demone della velocità, in altre parole. Questo è accompagnato da 48 GB di RAM. In breve, questo server è ottimizzato per l'archiviazione densa.

Poiché HDFS è un file system a livello di spazio utente, è importante ottimizzare il file system locale sui nodi slave per lavorare con HDFS. A questo proposito, una decisione di alto impatto durante la configurazione dei server è la scelta di un file system per l'installazione Linux sui nodi slave.

Ext3 è il file system più diffuso perché è stato l'opzione più stabile per un certo numero di anni. Dai un'occhiata a Ext4, comunque. È la prossima versione di Ext3, ed è stata disponibile abbastanza a lungo da essere considerata stabile e affidabile.

Ancora più importante per i nostri scopi, ha un numero di ottimizzazioni per la gestione di file di grandi dimensioni, che lo rende una scelta ideale per i server di nodi slave HDFS.

Non utilizzare Linux Logical Volume Manager (LVM) - rappresenta un ulteriore livello tra il file system Linux e HDFS, che impedisce ad Hadoop di ottimizzare le sue prestazioni. Nello specifico, LVM aggrega i dischi, cosa che ostacola la gestione delle risorse che HDFS e YARN fanno, in base a come i file vengono distribuiti sulle unità fisiche.