Considerazioni sulla distribuzione di Hadoop su Oracle Cloud Infrastructure

Distribuzione

Quando si esegue la sottoscrizione all'infrastruttura di Oracle come servizio (IaaS), si ha accesso a tutti i servizi di calcolo, storage e rete associati. Le distribuzioni in Oracle Cloud Infrastructure sono simili alle distribuzioni locali, in quanto le stesse versioni e funzioni sono disponibili per ogni distribuzione Hadoop.

Teraform e Resource Manager

I team di progettazione di Oracle Cloud Infrastructure hanno presentato la partnership con ogni ISV Hadoop per consentire la distribuzione che usa Terraform. Terraform consente di distribuire l'infrastruttura come codice (IaC) e include tutti gli aspetti di un ecosistema Hadoop, dalla rete (reti cloud virtuali, subnet, VNIC) e dalle liste di controllo dell'accesso alla sicurezza, per calcolare e eseguire il provisioning della memoria. Terraform è flessibile, altamente scalabile e standard tra molti provider cloud.

È possibile scegliere di utilizzare questi modelli come framework per la distribuzione di Hadoop su Oracle Cloud Infrastructure oppure se è possibile conservare gli strumenti di distribuzione esistenti utilizzati in locale. Entrambi i metodi sono validi.

Se si desidera usare Terraform per distribuire Hadoop, si consiglia di utilizzare Oracle Resource Manager. Considerare i vantaggi principali derivanti dall'uso di Resource Manager:

I metadati di stato Terraform vengono conservati in una posizione ad alta disponibilità.
L'accesso a Resource Manager può essere gestito con gli stessi strumenti di sicurezza e audit inclusi per altri servizi Oracle Cloud Infrastructure.
Resource Manager rimuove la complessità associata alla configurazione di Terraform per la distribuzione su Oracle Cloud Infrastructure.

L'interfaccia Resource Manager supporta i file di schema basati su YAML- contenenti i valori previsti per le variabili stack. Ciò consente di definire le forme, le versioni software e altri parametri consentiti per ciascuna variabile nello stack.

Descrizione dell'immagine resource-manager-ui.png

Dopo l'inserimento dei dati nel file dello schema, i valori vengono visualizzati in un'interfaccia utente di facile utilizzo. Il file di schema consente di disporre di elenchi a discesa con questi valori, nonché di campi di immissione personalizzati in cui gli utenti possono digitare o incollare l'input.

I campi del file di schema possono inoltre avere dipendenze, in modo che se un utente sceglie un valore in un campo, gli altri campi vengono visualizzati o nascosti in base a tale scelta.

Topologia servizio cluster

Durante la distribuzione di Hadoop, prendere in considerazione il seguente mapping della topologia del servizio cluster ai ruoli del nodo:

Tipo di nodo	Ruolo Hadoop	Servizi Hadoop
Edge	Accesso utente da perimiter	Librerie client, Oozie
Utility	Gestione cluster	Cloudera Manager, Ambari, database dei metadati
Principale	Servizi cluster di base	Zookeeper, NameNode, JournalNode, HIVE, HBase Master, Spark History, Job History, Resource Manager, HTTPFS, SOLR
Lavoratore	Esecuzione del carico di lavoro, Memorizzazione dati	HDFS, NodeManager, Server area, Broker Kafka, Executor Spark, Mappa/Riduci

Quando si sceglie le forme di calcolo da utilizzare per questi ruoli, le procedure ottimali sono descritte più avanti in questa soluzione. Considerare inoltre i seguenti criteri:

Quanti utenti simultanei utilizzeranno il cluster?
I nodi perimetrali devono essere scalati sia in quantità che in OCPU in base al numero di utenti concorrenti. Due utenti concorrenti per OCPU costituiscono una buona linea guida, consentendo un solo thread per utente. I nodi perimetrali aggiuntivi nei domini di errore forniscono anche ridondanza.
Si dispone di requisiti di memoria specifici per Spark o per il server dell'area HBase?
Questi requisiti influiscono direttamente sulla quantità e sulla composizione dei nodi dei lavoratori. Il dimensionamento per HBase richiede una comprensione dell'applicazione di base e varia. Molti clienti conoscono già i requisiti per la distribuzione di HBase, in particolare il numero di server delle aree e di memoria allocata per server. I carichi di lavoro Spark hanno una destinazione di memoria aggregata ottenuta via via via via factoring il numero di nodi dei lavoratori moltiplicati per la memoria disponibile per ogni lavoratore.
Si dispone di uno specifico requisito per la capacità HDFS?
La maggior parte dei clienti ha questo requisito. Ma prima di applicare la scalabilità su un'ampia gamma di nodi di lavoro DenseIO Bare Metal, tenere presente che HDFS di cui è stato eseguito il backup NVMe può essere incrementato dai volumi a blocchi per ottenere la densità HDFS richiesta, come descritto più avanti in questa soluzione. Oracle consiglia di comprendere i requisiti HDFS, ma anche di definire i requisiti del carico di lavoro in modo da poter “garantire la dimensione giusta” per il cluster, accedere a entrambe le destinazioni e ridurre al minimo i costi.

migrazione

Quando i clienti che eseguono Hadoop decide di distribuire in Oracle Cloud Infrastructure, in genere dispongono di una grande quantità di dati di cui eseguire la migrazione. Il blocco di questi dati è presente in HDFS, con i metadati del cluster di supporto presenti in un database.

La copia diretta dei dati HDFS su Internet può risultare difficile per diversi motivi.

Il volume dei dati è troppo grande oppure la larghezza di banda disponibile è troppo limitata per supportare la copia dei dati in formato finale in qualsiasi intervallo di tempo significativo.
I dati fanno distinzione tra maiuscole e minuscole e la relativa copia su Internet potrebbe non essere consentita dalla gestione del controllo o dai requisiti normativi.
Le risorse cluster on premise sono vincolate e la copia dei dati influisce sul carico di lavoro in corso.

Sono supportati diversi approcci alla migrazione dei dati. Vengono definiti dal tipo di dati di cui viene eseguita la migrazione.

Migrazione dati HDFS

Esistono tre modi comuni per copiare i dati HDFS in Oracle Cloud Infrastructure:

Copiare i dati direttamente da un cluster on premise allo storage degli oggetti in un'area Oracle Cloud Infrastructure utilizzando una VPN su Internet o con FastConnect. Al termine di questo processo, è possibile eseguire nuovamente la valutazione di un cluster Oracle Cloud Infrastructure con i dati dello storage degli oggetti.
Copiare i dati direttamente da un cluster on premise a un cluster Oracle Cloud Infrastructure tramite Internet o utilizzando FastConnect.
Copia i dati in un'istanza Data Transfer Appliance, distribuita nel data center del cliente, contenente i dati e quindi spediti a Oracle e caricati nello storage degli oggetti. Un cluster Oracle Cloud Infrastructure può quindi essere reidratato con questi dati.

I dettagli tecnici su ciascuno di questi metodi vengono descritti più avanti in questa soluzione.

Migrazione metadati

I metadati del cluster sono generalmente più piccoli dei dati HDFS ed esistono in un database del cluster on premise.

La migrazione dei metadati del cluster dipende da due fattori: la distribuzione Hadoop nel cluster di origine e il database utilizzato per memorizzare i metadati. Il trasferimento di questi dati è diretto e specifico per ogni distribuzione Hadoop.

In questa soluzione, in seguito vengono presentati specifiche su ogni distribuzione Hadoop.

Sicurezza

La sicurezza nel cloud è particolarmente importante per Hadoop e ci sono numerosi modi per garantire la sicurezza della distribuzione su Oracle Cloud Infrastructure.

In primo luogo, considerare i controlli di sicurezza specifici di Oracle Cloud Infrastructure:

Utilizza la funzionalità IAM (Identity and Access Management) per controllare chi ha accesso alle risorse cloud, il tipo di accesso di un gruppo di utenti dispone e per individuare le risorse specifiche. Questa architettura può fornire i seguenti risultati:
- Isolare in modo sicuro le risorse cloud in base alla struttura organizzativa.
- Autentica gli utenti ad accedere ai servizi cloud tramite un'interfaccia browser, un'API REST, un SDK o un'interfaccia CLI
- Autorizzare i gruppi di utenti a eseguire azioni sulle risorse cloud appropriate
- Federazione con provider di identità esistenti
- Abilitare un provider di servizi gestito (MSP) o un integratore di sistemi (SI) per gestire gli asset dell'infrastruttura pur continuando ad accedere alle risorse
- Autorizzare le istanze di applicazione per effettuare chiamate API ai servizi cloud
Esegue l'audit delle liste di sicurezza per tutte le reti nella rete cloud virtuale (VCN, Virtual Cloud Network). Rendere possibile queste regole limitatamente e consentire solo il traffico sicuro nelle subnet rivolte su Internet.
Abilitare i firewall host sugli host su cui si trova tramite rete e consentire solo il traffico necessario.
Si consiglia di utilizzare regolarmente la funzione di audit della sicurezza.

La cifratura è anche una buona opzione per i dati in archivio e i dati in movimento. Considerare le seguenti risorse:

Meccanismo di cifratura Cloudera
Hortonworks
- Cifratura HDFS in archivio
- Cifratura in formato finale
Cifratura MapR

Altre considerazioni sulla sicurezza specifiche di Hadoop includono:

Distribuire i cluster nelle subnet con indirizzi IP privati che espongono solo le API o le interfacce utente necessarie alle subnet attraverso attraverso attraverso Internet.
Esegui Hadoop usando la sicurezza cluster
Utilizzare i nodi perimetrali per accedere ai servizi del cluster mediante il tunneling SSH. Questa operazione è ancora più semplice su Mac o Linux.
Sfrutta Apache Knox per proteggere gli endpoint API.
Sfrutta il Navigator di Apache Sentry o Cloudera per l'accesso basato sui ruoli ai dati e ai metadati del cluster.

Sicurezza della rete

A causa della natura aperta di Hadoop e delle considerazioni sulla sicurezza, la maggior parte dei clienti preferisce distribuire il proprio cluster Hadoop in una subnet privata. L'accesso ai servizi cluster è quindi disponibile solo utilizzando nodi perimetrali, l'accesso di bilanciamento del carico alle interfacce utente, le interfacce API e i dashboard dei servizi oppure mediante l'accesso diretto mediante il tunneling VPN o SSH FastConnect mediante un proxy perimetrale.

Le subnet pubbliche aumentano la distribuzione del cluster per i nodi perimetrali e i nodi della utility, che eseguono servizi internet-facing (come Cloudera Manager o Ambari). Si tratta di un'operazione completamente facoltativa. È possibile scegliere di utilizzare FastConnect VPN ed eseguire l'intera distribuzione come estensione della topologia di rete on premise. Che richiede solo un segmento IP privato instradabile dal cliente, associato a livello di VCN, quindi suddiviso in subnet appropriate in Oracle Cloud Infrastructure. L'accesso è controllato mediante liste di sicurezza che si applicano a livello di subnet. La procedura ottimale consiste nel raggruppare risorse con requisiti di accesso simili nelle stesse subnet.

Topologia subnet

La VCN copre un singolo blocco CIDR IPv4 contiguo di tua scelta. All'interno della VCN è possibile distribuire singole subnet IPv4 per gli host del cluster. L'accesso a ogni subnet è controllato dalle liste di sicurezza. La sicurezza aggiuntiva viene controllata a livello di host dai firewall.

La miglior prassi consiste nel separare le risorse cluster Hadoop in una subnet privata non direttamente accessibile da Internet. L'accesso al cluster deve essere controllato attraverso host aggiuntivi nelle subnet rivolte alla rete pubblica e protetto mediante regole di lista di sicurezza appropriate per gestire il traffico tra i segmenti di rete pubblici e privati. Questo modello fornisce la migliore sicurezza per il cluster Hadoop.

Le subnet pubbliche possono essere utilizzate per i nodi perimetrali (accesso utente) e per qualsiasi servizio che deve esporre un'interfaccia utente o interfaccia API (ad esempio, Cloudera Manager o Ambari) per l'accesso esterno.
Le subnet private devono essere utilizzate per gli host del cluster (master, worker) e non sono direttamente accessibili da Internet. Ma richiedono un host intermedio in una subnet pubblica per l'accesso, un load balancer o l'accesso diretto da VPN, FastConnect o proxy SSH.

Liste di sicurezza

Le liste di sicurezza controllano il traffico in entrata e in uscita a livello di subnet. Per Hadoop, è preferibile disporre di un accesso bidirezionale illimitato completo tra le subnet con host cluster sia per il traffico TCP che per il traffico UDP. Le subnet pubbliche devono avere elenchi di sicurezza molto restrittivi per consentire l'accesso alle API e alle interfacce utente solo alle porte sicure (e anche agli indirizzi IP di origine).

Alta disponibilità

Hadoop dispone di metodi incorporati per l'alta disponibilità (HA) e non sono coperti qui. Di seguito sono riportate le procedure ottimali per utilizzare Oracle Cloud Infrastructure for Hadoop per ottenere HA.

Selezione area

Ogni area di Oracle Cloud Infrastructure è costituita da uno a tre domini di disponibilità. Ogni dominio di disponibilità è costituito anche da tre domini di errore. Scegliere un'area home che sia vicina all'utente corrente e alle risorse aziendali (ad esempio, il data center). La composizione dell'area scelta determina se è possibile utilizzare la distribuzione a singolo dominio o di più disponibilità.

Distribuzione dominio con disponibilità singola

Oracle consiglia la distribuzione a singolo dominio per le distribuzioni Hadoop in Oracle Cloud Infrastructure. Per le distribuzioni di MapR, questa architettura è l'unica supportata. Questo modello di distribuzione è il più prestazioni da una prospettiva di rete in quanto il traffico intracluster è contenuto in segmenti di rete locali, che mantengono bassa latenza e throughput elevato. Le risorse nel dominio di disponibilità vengono striping tra i domini di errore per ottenere l'HA dell'infrastruttura fisica.

Un dominio di errore è un raggruppamento di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità contiene tre domini di errore. I domini di errore consentono di distribuire le istanze in modo che non si trovino sullo stesso hardware fisico all'interno di un singolo dominio di disponibilità. Un errore hardware o una gestione dell'hardware di calcolo che interessa un dominio di errore non ha effetto sulle istanze in altri domini di errore.

Distribuzione di più domini

Le distribuzioni con più domini (spanning di dominio di disponibilità) sono supportate solo da Cloudera e Hortonworks, ma sono anche possibili utilizzando Apache Hadoop.

Considerare tuttavia le seguenti avvertenze per lo spanning di dominio di disponibilità:

La connettività intracluster deve analizzare i segmenti WAN, che aumenta la latenza e riduce il throughput ottimale. Ciò ha un impatto significativo sulle prestazioni, soprattutto con i nodi dei lavoratori Bare Metal. Per i nodi lavoratore VM più piccoli, l'impatto sulle prestazioni è meno evidente.
Non tutte le aree di Oracle Cloud Infrastructure supportano questo modello.

Il diagramma riportato di seguito mostra l'impatto sulle prestazioni misurato quando si utilizza 10-TB TeraSort in un singolo dominio di disponibilità anziché un dominio di disponibilità che si estende con un cluster costituito da cinque nodi dei lavoratori e tre nodi principali.

Segue una descrizione di comparison-availability-domain-spanning.png

Descrizione dell'immagine comparison-availability-domain-spanning.png

Lo spanning di dominio di disponibilità fornisce ridondanza aggiuntiva dei servizi cluster in una singola area. Le risorse del cluster possono inoltre utilizzare i domini di errore in ogni dominio di disponibilità per una “topologia del rack” logica aggiuntiva. Ogni dominio di errore viene considerato "rack” per la consapevolezza del rack. Questi vantaggi vengono illustrati dal diagramma riportato di seguito.

Descrizione dell'immagine architecture-multiple-availability-domains.png

Disaster recovery

Il recupero da errori irreversibili in Oracle Cloud Infrastructure dipende direttamente dai requisiti RPO (Recovery Point Objective) e RTO (Recovery Time Objective).

Se RPO o RTO è vicino a tempo reale, l'unica opzione di Hadoop è creare un cluster DR in un altro dominio o area di disponibilità, quindi replicare i dati tra i cluster di produzione e DR. Se i requisiti RPO e RTO sono più flessibili, si consiglia di utilizzare lo storage degli oggetti come destinazione di backup per i metadati HDFS e cluster. Pianificare il processo di copia con la frequenza richiesta per soddisfare la destinazione RPO, eseguendo il PUSH dei dati nello storage degli oggetti utilizzando uno strumento quale DistCp (copia distribuita). È inoltre possibile eseguire il backup dei database (Oracle, MySQL) nei bucket di storage degli oggetti oppure eseguire la replica per ulteriori istanze di database in altri domini o aree di disponibilità.

Se i requisiti DR specificano la ridondanza geografica per i dati che non possono essere forniti da una singola area, è possibile copiare i dati nello storage degli oggetti tra aree. Se si verifica una situazione di emergenza, si consiglia di utilizzare Terraform per eseguire rapidamente il provisioning delle risorse in un altro dominio di disponibilità (nella stessa area o in un'area differente) e di reidratare il cluster DR dai dati nello storage degli oggetti.

Cost Management

Come descritto nel resto di questa soluzione, esistono diversi modi per “le dimensioni a destra” rispetto ai requisiti di storage in modo da ridurre i costi dell'infrastruttura. Oracle Cloud Infrastructure dispone di strumenti aggiuntivi che consentono di gestire il costo associato a una distribuzione Hadoop:

È possibile sfruttare l'applicazione di tag alle distribuzioni per semplificare il tracciamento del consumo.
Puoi impostare le quote a livello di compartimento in modo da limitare il consumo in base a settori di attività diversi. È possibile utilizzare più compartimenti per gestire gli ambienti di produzione, QA e sviluppo e limitare le quote in base alle esigenze.

Inoltre, l'utilizzo della natura dinamica del cloud è ideale per ambienti che potrebbero non essere persistenti. Se si utilizza lo storage degli oggetti come backup (o Connessione dati) per i dati, è facile creare gli ambienti quando necessari utilizzando Terraform, eseguire nuovamente la valutazione di HDFS con i dati dallo storage degli oggetti ed eliminare l'ambiente quando non è più necessario.

È inoltre possibile sospendere gli ambienti VM con volumi a blocchi per interrompere la fatturazione della computazione e l'utente viene addebitato solo per il consumo della memoria.