Considerazioni sulle prestazioni e sulle forme
Esistono notevoli considerazioni sui prezzi e sulle prestazioni per l'esecuzione di Hadoop su Oracle Cloud Infrastructure. Inoltre, dovrai valutare in che modo i tuoi requisiti influenzano le forme di distribuzione.
Analisi comparativa
Oracle Cloud Infrastructure offre vantaggi sia a livello di prestazioni che a livello di costi per le aziende interessate all'esecuzione di cluster Hadoop su Oracle Cloud.
TeraSort è un benchmark comune per Hadoop in quanto sfrutta tutti gli elementi del cluster (computazione, memoria, storage, rete) per generare, mappare/ridurre e convalidare un set di dati casuale.
Un'analisi comparativa cluster Oracle Cloud Infrastructure normalizzati a 300 OCPU e volumi a blocchi utilizzati per la memorizzazione HDFS. In particolare analisi è stato rilevato che Oracle Cloud Infrastructure ha eseguito tre volte e ha fornito un costo inferiore del 80% rispetto a una distribuzione concorrente nel cloud di un concorrente.
Il seguente grafico illustra le prestazioni complessive delle varie forme di Oracle Cloud Infrastructure durante l'esecuzione di questa istanza di 10TB TeraSort alla dimensione normalizzata del cluster:
Descrizione dell'immagine comparison-terasort-phase-cpu.png
Oracle Cloud Infrastructure fornisce istanze di computazione Bare Metal standard con CPU Intel e AMD, nonché un'opzione HPC specializzata. Come mostrato nel grafico, i cluster HPC specializzati vengono eseguiti più rapidamente rispetto alle controparti Intel e AMD, anche se queste istanze hanno conteggi di base inferiori. Questo risultato si è verificato principalmente perché il cluster utilizza un numero maggiore di nodi per raggiungere lo stesso conteggio delle OCPU normalizzate, che influisce direttamente sul throughput aggregato HDFS globale, aumentando le prestazioni.
Le forme HPC traggono inoltre vantaggio da una capacità di rete 100-GBps, che consente un rapido trasferimento dei dati all'interno del cluster.
La figura riportata di seguito confronta le prestazioni dei lavoratori basati su VM con volumi a blocchi e NVMe Bare Metal, con Cloudera in esecuzione e normalizzate a 10 nodi operativi nel cluster.
Descrizione dell'immagine comparison-terasort-vm-bm-performance.png
Il miglioramento delle prestazioni dovuto al fatto che la dimensione della VM del lavoratore da 8 a 16 memorie centrali si rivela più efficiente, grazie al fatto che il throughput di rete VM è una quota frazionale del NIC fisico di base. Sono inoltre visibili i vantaggi di Bare Metal con NVMe locale. Il cluster sfrutta le alta velocità di storage NVMe locale combinate con l'interfaccia di rete 25-Gbps.
Definire le forme da utilizzare per il calcolo in un cluster Hadoop coerente tra gli ISV Hadoop.
Selezione istanza computazione
Questa sezione fornisce le procedure ottimali quando si seleziona una forma per ogni ruolo del nodo.
Nodi principali
I nodi principali sono applicabili solo alle distribuzioni Cloudera, Hortonworks e Apache Hadoop. Per impostazione predefinita, MapR non separa i servizi cluster dai nodi operativi. In pratica, Oracle consiglia di utilizzare una buona densità della memoria sui nodi principali per supportare il sovraccarico di gestione di cluster e servizi. I nodi principali eseguono i servizi Zookeeper, NameNode, JournalNode, Resource Manager, HBase, Spark e Cluster Management (Cloudera Manager e Ambari).
- Forma minima: VM.Standard2.8
- Forma consigliata: VM.Standard2.24
Nodi lavoratore
I nodi di lavoro sono coerenti tra tutte le ISV Hadoop e Apache. Ridimensiona la forma per il nodo del lavoratore in base alle esigenze per soddisfare i requisiti del carico di lavoro. È applicabile sia ai requisiti di computazione che ai requisiti di memoria perché molti clienti cercano la memoria aggregata da usare con carichi di lavoro basati su grafici. La mappa tradizionale/riduzione dei carichi di lavoro offre inoltre vantaggi da un incremento della struttura di memoria sui nodi dei lavoratori.
- Forma minima: VM.Standard2.8
- Forma consigliata: BM.DenseIO2.52
Nodi di supporto
L'infrastruttura di supporto include nodi perimetrali o altri nodi che potrebbero eseguire servizi cluster secondari o codice applicazione personalizzato. I requisiti per questi nodi variano in base alla scala e all'utilizzo delle maiuscole e minuscole. Per i nodi perimetrali, si consiglia una dimensione minima di VM.Standard2.2. Eseguire lo scale up in base al numero di utenti per nodo perimetrale. Si consiglia di utilizzare più nodi perimetrali per HA tra i domini di errore e di creare più percorsi per consentire agli utenti di interagire con il cluster.
Considerazioni sulla rete
Hadoop in genere dipende dalla rete per il traffico in cluster. Pertanto, le forme che si sceglie di distribuire per ogni ruolo nella topologia del cluster influiscono direttamente sulla connettività intracluster.
Quando si utilizzano forme Bare Metal, gli host di computazione possono utilizzare le schede VNIC (Virtual Interface Card) 25-GB complete. Le forme VM vengono scalate in base alle relative dimensioni di computazione.
Quando si utilizzano i volumi a blocchi per la capacità HDFS, ricordare che il traffico di I/O per un volume a blocchi condivide la stessa VNIC del traffico delle applicazioni (per impostazione predefinita). Un modo per ottimizzare tale funzionalità quando si utilizzano forme Bare Metal è quello di creare una VNIC secondaria da utilizzare per la connettività del cluster sulla seconda interfaccia fisica. Ciò consente di riservare la VNIC primaria solo per il traffico a blocchi, ottimizzando in questo modo l'utilizzo della rete.
Il diagramma seguente illustra questo concetto:
Descrizione dell'immagine architecture-vnic.png
Quando si utilizzano i volumi a blocchi, tenere inoltre presente che l'aggregazione di I/O HDFS è correlata direttamente alla quantità e alle dimensioni dei volumi a blocchi associati a ciascun nodo del lavoratore. Per raggiungere la capacità HDFS necessaria, Oracle consiglia di scalare un numero maggiore di volumi per lavoratore anziché un numero ridotto di volumi più grandi.
Considerazioni sulla memorizzazione
Per le distribuzioni Hadoop, è possibile utilizzare due tipi di storage per la capacità HDFS: forme DenseIO con NVMe locale e volumi a blocchi. Per le distribuzioni di MapR, è necessario scegliere un singolo tipo di memorizzazione per i nodi dei lavoratori (omogenei) a meno che non si disponga della licenza per il livellamento dei dati. Altri ISV Hadoop supportano storage eterogeneo (combinazione di volumi NVMe e a blocchi di DenseIO) senza costi in licenza aggiuntivi.
Configurazioni di memorizzazione supportate dal fornitore
Cloudera e Hortonworks supportano tutti i form di storage su Oracle Cloud Infrastructure per l'uso con Hadoop:
- NVMe locale sulle forme DenseIO
- Volumi a blocchi
- Storage degli oggetti (uso della compatibilità S3)
Cloudera supporta la memorizzazione su più livelli di dati (storage eterogeneo) per le distribuzioni composte da NVMe locale e volumi a blocchi per HDFS.
Le distribuzioni di MapR possono utilizzare NVMe locale su forme DenseIO o volumi a blocchi per la distribuzione.
- Storage degli oggetti: fare riferimento a MapR XD Object Tiering.
- MapR non supporta storage eterogeneo senza licenza aggiuntiva.
DenseIO NVMe
DenseIO NVMe è l'opzione di memorizzazione più prestazioni per Hadoop su Oracle Cloud Infrastructure. Le unità NVMe locali che vanno da utilizzare con HDFS sono disponibili sia nelle forme Bare Metal che nelle virtual machine.
Quando si utilizza NVMe locale, Oracle consiglia di impostare la replica DFS su tre repliche per garantire la ridondanza dei dati.
In alternativa, per i cluster Cloudera, è possibile utilizzare la codifica a correzione di cancellazione per aumentare l'efficienza della memorizzazione per tipi di dati specifici.
Volumi a blocchi
I volumi a blocchi su Oracle Cloud Infrastructure sono un'opzione per le prestazioni elevate e forniscono una configurazione flessibile per la capacità HDFS. I volumi a blocchi sono uno storage collegato alla rete e, ad esempio, utilizzano l'ampiezza di banda della VNIC per le operazioni di I/O. I volumi a blocchi si ridimensionano anche in IOPS e MB/s in base alla dimensione configurata (per GB). Il throughput dei singoli volumi a blocchi è di 320 MB/s per 700GB o volumi più grandi.
La tabella seguente mostra la scala di throughput per un singolo nodo lavoratore utilizzando i volumi 700GB:
| Volumi a blocchi | Throughput aggregato (GB/s) |
|---|---|
| 3 | 0.94 |
| 4 | 1.25 |
| 5 | 1.56 |
| 6 | 1.88 |
| 7 | 2.19 |
| 8 | 2.50 |
| 9 | 2.81 |
| 10 | 3.13 |
| 11 | 3.44 |
Oracle ha rilevato che dopo 11 volumi a blocchi, l'aggiunta di ulteriori volumi a blocchi comporta la riduzione degli utili di throughput.
Quando si utilizzano le VM come lavoratori, ricordare che il traffico dei volumi a blocchi condivide la stessa VNIC del traffico Hadoop (applicazione). La tabella riportata di seguito mostra i volumi a blocchi massimi consigliati e la larghezza di banda della VNIC misurata per una selezione di forme Oracle Cloud Infrastructure, in modo da consentire alle istanze una larghezza di banda aggiuntiva sufficiente per supportare il traffico delle applicazioni sull'I/O su disco.
| Forma Oracle Cloud Infrastructure | Ampiezza di banda VNIC | Numero massimo consigliato di volumi a blocchi per HDFS |
|---|---|---|
| BM.DenseIO2.52 | 25Gbps | 11 |
| BM.Standard2.52 | 25Gbps | 11 |
| VM.Standard2.24 | 24.6Gbps | 6 |
| VM.Standard2.16 | 16.4Gbps | 4 |
| VM.Standard2.8 | 8.2Gbps | 3 |
Quando si utilizzano i volumi a blocchi per la capacità HDFS, si consiglia di utilizzare un numero elevato di volumi a blocchi anziché un numero inferiore di volumi a blocchi di grandi dimensioni per lavoratore per ottenere la capacità di destinazione HDFS.
Utilizzando come esempio il minimo di tre nodi lavoratore, con la dimensione del volume a blocchi 700GB per HDFS:
Descrizione dell'immagine block-volume-hdfs-capacity-chart.png
Si noti che i tre volumi a blocchi per lavoratore rappresentano il requisito minimo. Oracle consiglia di ridimensionare la quantità e la dimensione del volume a blocchi per ottimizzare la capacità HDFS richiesta, sapendo che un numero maggiore di volumi a blocchi per lavoratore aumenta la larghezza di banda complessiva di HDFS aggregata disponibile. Ciò è particolarmente importante per i carichi di lavoro di grandi dimensioni con throughput elevato, che richiedono un I/O aggregato più elevato nel cluster.
È importante che i cluster persistenti mantengano sovraccarico aggiuntivo per la crescita o la rifattorizzazione.
Log e dati dell'applicazione
Quando si utilizzano i volumi a blocchi per HDFS, è necessario prenotare alcuni volumi a blocchi per l'uso con i log Hadoop e i dati dell'applicazione (Lotti Cloudera, NameNode e metadati del diario). Sebbene sia possibile espandere il volume del sistema operativo per adattarlo a questi dati, è preferibile utilizzare volumi a blocchi dedicati a tale scopo. I volumi a blocchi garantiscono maggiore portabilità se si desidera modificare il tipo di istanza per i nodi principali e aumentare la flessibilità se sono necessarie più prestazioni di I/O per una posizione di dati particolare. L'aggiunta di un numero maggiore di volumi a blocchi all'istanza, la creazione di un array RAID e la migrazione dei dati esistenti sono più semplici quando si dispone di allegati volume di riserva da utilizzare.
Lo stesso è vero per HDFS. La presenza di un sovraccarico per aggiungere altri volumi a blocchi può essere più semplice rispetto alla disattivazione dei lavoratori, la ricostruzione di tali volumi con dischi più grandi, l'aggiunta di questi al cluster e il ribilanciamento di HDFS. Entrambi gli approcci sono validi. È l'unico indipendentemente dal fatto che il carico di lavoro cluster richieda un completa complemento dei volumi a blocchi per supportare il throughput dei dati. In tal caso, è opportuno cambiare i lavoratori in forme Dense IO Bare Metal con lo storage NVMe più veloce e utilizzando un modello di storage eterogeneo con memorizzazione a più livelli di dati.
Storage degli oggetti
L'integrazione dello storage degli oggetti è possibile con tutti gli ISV Hadoop, compreso Apache Hadoop. Oracle Cloud Infrastructure dispone di un connettore HDFS nativo compatibile con Apache Hadoop. ISV Hadoop (Cloudera, Hortonworks, and MapR) elenca gli endpoint esterni consentiti per l'integrazione dello storage degli oggetti e richiedono l'uso della compatibilità S3 affinché l'integrazione dello storage degli oggetti funzioni correttamente.
Una volta installato, la compatibilità S3 funziona solo con l'area home della tenancy. Ciò significa che per qualsiasi integrazione eseguita con lo storage degli oggetti è necessario distribuire anche i cluster Hadoop nella stessa area (home).
Un'altra avvertenza consiste nel fatto che quando si utilizza lo storage degli oggetti per eseguire il push o il pull dei dati in o dal cluster, HDFS non viene utilizzato come livello di inserimento nella cache. In effetti, il file system del sistema operativo si trova nella posizione in cui i dati vengono inseriti nella cache quando vengono spostati tra lo storage degli oggetti e HDFS. Se un volume elevato di dati passa indietro e indietro tra HDFS del cluster e storage degli oggetti, si consiglia di creare un layer di inserimento del volume a blocchi sul sistema operativo per supportare questo spostamento di dati.
La figura seguente mostra un diagramma di partizione tipico per supportare lo spostamento dei dati S3, insieme ai livelli di dati per i nodi dei lavoratori.
Descrizione dell'immagine object-storageitioning-throughput.png
Scaglione dati
È possibile combinare tutte le opzioni di memorizzazione precedenti quando si utilizza Apache Hadoop, Cloudera o Hortonworks per creare un modello di memorizzazione avanzata dati (eterogeneo). È inoltre possibile utilizzare la gestione del ciclo di vita dei dati per eseguire il push dei dati da un livello di memorizzazione a un altro come pagine dati, in modo da ottimizzare i costi di memorizzazione HDFS.
Descrizione dell'immagine data-lifecycle-tinung.png
Codifica cancellamento
A partire da Hadoop 3.0, la codifica di cancellazione (EC) è supportata sulle distribuzioni HDFS. EC riduce i requisiti di storage per i dati HDFS locali memorizzando i dati con una singola copia incrementata dalle celle di parità. La topologia HDFS può essere contrassegnata come EC, che consente questa funzionalità per qualsiasi dato memorizzato in tale posizione contrassegnata. Ciò riduce il requisito di storage raw per i dati HDFS EC-tagged, consentendo un maggiore livello di efficienza dello storage.
Esistono alcuni caveicoli relativi all'criteri EC:
- Per abilitare EC sono necessari i conteggi minimi dei nodi dei lavoratori.
- La località dei dati viene persa per i dati contrassegnati da EC.
- EC è appropriato per i file di dimensioni medie a cui si accede di rado. È inefficiente per i file di piccole dimensioni e per i file a cui si accede spesso.
- EC aumenta il numero di oggetti blocco presenti in Metadati nodo nome rispetto a dati simili con la replica tradizionale (3x).
- Il recupero dei dati EC richiede il calcolo dal cluster (ricreazione delle parità). Questo tempo di recupero è più lungo dei dati replicati tradizionali (3x).
Monitoraggio delle prestazioni
Il servizio Oracle Cloud Infrastructure Monitoring consente di monitorare in modo attivo e sicuro le risorse cloud utilizzando le funzioni Metriche e Allarmi. L'impostazione degli allarmi per notificare quando si raggiungono le soglie di prestazioni o capacità è un ottimo metodo per utilizzare gli strumenti nativi Oracle Cloud Infrastructure per gestire l'infrastruttura
Architetture di riferimento
Questo argomento fornisce il materiale di riferimento per ogni ISV Hadoop. Le architetture di riferimento e le distinte base riportate di seguito indicano un footprint minimo necessario per la distribuzione Hadoop supportata dal fornitore su Oracle Cloud Infrastructure.
Come progetto open source, la distribuzione Apache Hadoop non dispone di un footprint minimo fornito dal fornitore. Oracle consiglia di utilizzare la distribuzione Hortonworks visualizzata qui come guida ragionevole per una distribuzione Apache minima.
Cloudera
Descrizione dell'immagine architecture-cloudera.png
I requisiti minimi per la distribuzione di Hadoop utilizzando Cloudera sono:
| Ruolo | Quantità | Forma di computazione consigliata |
|---|---|---|
| Edge | 1 | VM.Standard2.4 |
| Cloudera Manager | 1 | VM.Standard2.16 |
| Nodo principale | 2 | VM.Standard2.16 |
| Nodo lavoratore | 3 | BM.DenselO2.52 |
In questa distribuzione minima il nodo Cloudera Manager esegue anche i servizi principali.
È necessario disporre della propria licenza per distribuire Cloudera su Oracle Cloud Infrastructure; tutto il supporto software è su Cloudera.
Hortonworks
Descrizione dell'immagine architecture-hortonworks.png
I requisiti minimi per la distribuzione di Hadoop usando Hortonworks sono:
| Ruolo | Quantità | Forma di computazione consigliata |
|---|---|---|
| Edge | 1 | VM.Standard2.4 |
| Ambari | 1 | VM.Standard2.16 |
| Nodo principale | 2 | VM.Standard2.16 |
| Nodo lavoratore | 3 | BM.DenselO2.52 |
In questa distribuzione minima il nodo Ambari esegue anche i servizi principali.
È necessario disporre della propria licenza per distribuire Hortonworks su Oracle Cloud Infrastructure; tutto il supporto software è tramite Hortonworks.
MapR
Descrizione dell'immagine architecture-mapr.png
I requisiti minimi per la distribuzione di Hadoop utilizzando MapR sono riportati di seguito.
| Ruolo | Quantità | Forma di computazione consigliata |
|---|---|---|
| Edge | 1 | VM.Standard2.4 |
| Nodo dati | 3 | BM.DenselO2.52 |
È necessario disporre della propria licenza per distribuire MapR in Oracle Cloud Infrastructure; tutto il supporto software è tramite MapR.
Distribuzioni Terraform
È possibile trovare modelli Terraform per ogni ISV Hadoop nella sezione Codice scaricamento di questa soluzione.
I repository Cloudera e Hortonworks presentano modelli conformi a Oracle Resource Manager. Si noti che questi sono specifici di Resource Manager. La diramazione base (principale) contiene un modello Terraform standalone. I modelli di Resource Manager per Cloudera e Hortonworks contengono anche uno schema YAML che popola facilmente le variabili Terraform per ogni modello. In questo modo si dispone della selezione dell'interfaccia utente a discesa per le variabili che è possibile personalizzare per i casi d'uso, mediante l'inserimento di informazioni in ogni modello con opzioni di forma consentite e impostazioni di sicurezza/configurazione.