Pianificazione e comprensione dei cluster ODH
Prima di creare i cluster Big Data Service, è necessario pianificare e comprendere i cluster, i tipi e le forme di istanza e i profili cluster.
Per ulteriori informazioni, vedere quanto segue:
Pianificazione del layout, della forma e dello storage del cluster
Prima di avviare il processo di creazione di un cluster, è necessario pianificare il layout del cluster, le forme del nodo e lo storage.
I nodi e i servizi sono organizzati in modo diverso nei cluster, in base all'elevata disponibilità (HA) e alla sicurezza o meno del cluster.
Informazioni sull'uso dei cluster HA
Utilizzare i cluster HA per gli ambienti di produzione. Sono necessari per la resilienza e per ridurre al minimo i tempi di inattività.
In questa release, un cluster deve essere HA e sicuro oppure nessuno dei due.
Tipi di nodi
Di seguito sono riportati i tipi di nodi.
- I nodi principali o di utility includono i servizi necessari per il funzionamento e la gestione del cluster. Questi nodi non memorizzano o elaborano i dati.
- I nodi lavoratore memorizzano ed elaborano i dati. La perdita di un nodo di lavoro non influisce sul funzionamento del cluster, anche se può influire sulle prestazioni.
- I nodi di lavoro solo calcolo elaborano i dati. La perdita di un nodo di lavoro di solo calcolo non influisce sull'operazione del cluster, sebbene possa influire sulle prestazioni.
- I nodi edge sono nodi estesi al cluster in cui sono installati solo i client. È possibile installare package aggiuntivi ed eseguire applicazioni aggiuntive in questo nodo anziché nodi di lavoro/computazione/master per evitare conflitti di classpath e problemi di risorse con i servizi cluster.
Layout cluster High Availability (HA)
Un cluster High Availability dispone di due nodi principali, due nodi di utility, tre o più nodi di lavoro e zero o più nodi di lavoro di calcolo.
| Tipo di nodo | Servizi su ODH |
|---|---|
| Primo nodo principale |
|
| Secondo nodo principale |
|
| Primo nodo dell'utility |
|
| Secondo nodo di utility |
|
| Nodi di lavoro (minimo 3) |
|
| Nodi di lavoro di solo calcolo |
|
| Nodi perimetrali |
|
Layout cluster minimo (nonHA)
Un cluster non High Availability ha un nodo principale, un nodo di utility, tre o più nodi di lavoro e zero o più nodi di lavoro di calcolo.
| Tipo di nodo | Servizi su ODH |
|---|---|
| nodo principale |
|
| Nodo utility |
|
| nodi di lavoro |
|
| Nodi di lavoro di solo calcolo |
|
| Nodi perimetrali |
|
La forma del nodo descrive le risorse di calcolo allocate al nodo.
Le forme utilizzate per i nodi master/utility e i nodi di lavoro possono essere diverse. Tutti i nodi master/utility devono tuttavia avere la stessa forma e tutti i nodi di lavoro devono avere la stessa forma.
Nella tabella seguente vengono indicate le forme che è possibile utilizzare per i diversi tipi di nodo. Per informazioni più dettagliate, consulta forme di computazione.
Per un elenco delle risorse fornite da ciascuna forma, vedere:
| Tipo di nodo | Forme disponibili | Numero richiesto di schede di interfaccia di rete virtuali (VNIC) |
|---|---|---|
| Master o utility |
VM.Standard2.4 VM. Standard2.8 VM. Standard2.16 VM.Standard2.24 VM.Standard.E5. Flexfield VM.Standard.E4. Flex * VM.Standard3. Flessibile* VM.Optimized3. Flessibile* VM.DenseIO.E4. Flessibile* VM.DenseIO.E5. Flessibile* VM.DenseIO2.8 VM.DenseIO2.16 VM.DenseIO2.24 BM.Standard2.52 BM.DenseIO2.52 BMHPC2.36 BM.Standard3.64* BM.Ottimizzato3.36* BM.DenseIO.E4.128* BM.Standard.E4.128* |
3 minimo Utilizzato per la subnet cluster, la subnet di accesso DP e la subnet del cliente *È necessario specificare almeno 3 OCPU e 32 GB di memoria. |
| Fase processo operativo |
VM.Standard2.1* VM.Standard2.2* VM. Standard2.4 VM. Standard2.8 VM. Standard2.16 VM.Standard2.24 VM.Standard.E5. Flexfield VM.Standard.E4. Flex * VM.Standard3. Flessibile* VM.Optimized3. Flessibile* VM.DenseIO.E4. Flessibile* VM.DenseIO.E5. Flessibile* VM.DenseIO2.8 VM.DenseIO2.16 VM.DenseIO2.24 BM.Standard2.52 BM.DenseI2.52 BMHPC2.36 BM.Standard3.64* BM.Ottimizzato3.36* BM.DenseIO.E4.128* BM.Standard.E4.128* |
2 minimo Utilizzato per la subnet cluster e la subnet |
| Lavoratore solo calcolo |
VM.Standard2.1* VM.Standard2.2* VM. Standard2.4 VM. Standard2.8 VM. Standard2.16 VM.Standard2.24 VM.Standard.E5. Flexfield VM.Standard.E4. Flex * VM.Standard3. Flessibile* VM.Optimized3. Flessibile* VM.DenseIO.E4. Flessibile* VM.DenseIO.E5. Flessibile* VM.DenseIO2.8 VM.DenseIO2.16 VM.DenseIO2.24 BM.Standard2.52 BM.DenseI2.52 BMHPC2.36 BM.Standard3.64* BM.Ottimizzato3.36* BM.DenseIO.E4.128* BM.Standard.E4.128* |
2 minimo Utilizzato per la subnet cluster e la subnet |
| Asse |
VM.Standard2.1* VM.Standard2.2* VM. Standard2.4 VM. Standard2.8 VM. Standard2.16 VM.Standard2.24 VM.Standard.E5. Flexfield VM.Standard.E4. Flex * VM.Standard3. Flessibile* VM.Optimized3. Flessibile* VM.DenseIO.E4. Flessibile* VM.DenseIO.E5. Flessibile* VM.DenseIO2.8 VM.DenseIO2.16 VM.DenseIO2.24 BM.Standard2.52 BM.DenseI2.52 BMHPC2.36 BM.Standard3.64* BM.Ottimizzato3.36* BM.DenseIO.E4.128* BM.Standard.E4.128* |
2 minimo Utilizzato per la subnet cluster e la subnet del cliente Nota: poiché il nodo Edge è specifico per i casi d'uso dell'applicazione client, scegliere la forma come richiesto dall'applicazione. |
* Tenere presente che VM.Standard2.1 e VM.Standard2.2 sono forme di piccole dimensioni e non supportano l'esecuzione di carichi di lavoro di grandi dimensioni. Per VM.Standard.E4. Flexfield, VM.Standard3. Flexfield, VM.Standard.E5. Flex e VM.Optimized3. Flex è necessario specificare almeno 1 OCPU e 16 GB di memoria.
Non tutte le forme sono disponibili per impostazione predefinita. Per visualizzare le forme disponibili per impostazione predefinita tramite la console cloud, vedere Ricerca dei limiti della tenancy. Per inviare una richiesta di aumento dei limiti del servizio, vedere Richiesta di un aumento del limite del servizio.
I nodi basati su forme VM standard utilizzano lo storage a blocchi collegato alla rete.
Lo storage a blocchi non è supportato per i nodi basati su forme DenseIO e HPC.
Tutti i nodi hanno un volume di avvio di 150 GB.
| Opzione | Limiti/Linee guida |
|---|---|
| Storage a blocchi iniziale minimo | 150 GB |
| Memoria a blocchi iniziale predefinita * | 150 GB |
| Storage a blocchi aggiuntivo minimo | 150 GB |
| Memoria a blocchi aggiuntiva predefinita * | 1 TB |
| Passo incrementale per lo storage a blocchi (iniziale e aggiuntivo) | 50 GB |
| Storage a blocchi massimo per un singolo nodo |
48 TB I 48 TB risultati totali da 12 volumi di 4 TB ciascuno. Se aggiungi più volte lo storage a blocchi, il massimo rimane di 48 TB, ma potrebbe essere distribuito su più di 12 volumi. |
| Dimensione massima volume a blocchi |
4 TB Se si specifica il numero massimo di 48 TB, vengono create 12 unità da 4 TB ciascuna. Se si specifica un numero inferiore, vengono creati un numero sufficiente di dispositivi da 4 TB per tale quantità e vengono creati più dispositivi durante l'aggiunta di ulteriore storage. |
Impossibile aggiungere altro storage a blocchi ai nodi master o utility. Pertanto, le seguenti figure mostrano solo le dimensioni iniziali.
| Opzione | Limiti/Linee guida |
|---|---|
| Storage a blocchi iniziale minimo | 150 GB |
| Memoria a blocchi iniziale predefinita | 1 TB |
| Storage a blocchi aggiuntivo minimo | 150 GB |
| Storage a blocchi aggiuntivo predefinito | 1 TB |
| Passo incrementale per lo storage a blocchi (iniziale e aggiuntivo) | 50 GB |
| Storage a blocchi massimo per un singolo nodo | 32 TB |
| Dimensione massima volume a blocchi | 32 TB |
| Posizionamento MySQL | Per i nodi di utility spostare /var/lib/mysql in /u01 e creare un collegamento simbolico. Ciò impedisce il riempimento del volume di avvio. |
| Opzione | Istruzioni |
|---|---|
| Memoria a blocchi iniziale predefinita | 2 TB |
| Storage a blocchi iniziale minimo | 150 GB |
Lo storage del server di query viene utilizzato per lo spazio tabella temporaneo per eseguire operazioni JOIN e GROUP BY pesanti. 2 TB sono consigliati per l'elaborazione tipica. Per gli ambienti di piccole dimensioni, ad esempio lo sviluppo, questo numero può essere regolato.
Per ottenere prestazioni ottimali, considerare i seguenti fattori:
- Throughput di I/O
- Rete tra il dispositivo di calcolo e il dispositivo di memorizzazione a blocchi.
Consulta la sezione relativa alle prestazioni dei volumi a blocchi nella documentazione di Oracle Cloud Infrastructure.
Nella tabella riportata di seguito viene descritto come Big Data Service alloca lo storage dei volumi a blocchi per nodi di dimensioni diverse.
| Cosa | Numero |
|---|---|
| Allocazione iniziale del volume per nodi principali e nodi utility | 1 grande volume |
| Allocazione dei volumi per lo storage a blocchi aggiuntivo per i nodi master e i nodi delle utility | 1 grande volume |
| Allocazione iniziale del volume per i nodi di lavoro. |
|
| Allocazione dei volumi per lo storage a blocchi aggiuntivo per i nodi di lavoro |
Numero minimo di volumi in grado di soddisfare le dimensioni dello storage, con una dimensione massima di 4 TB per volume. (L'ultimo volume potrebbe essere inferiore a 4 TB.) |
Si consiglia di utilizzare i nodi edge per l'area intermedia.
Descrizione dei tipi e delle forme di istanza
I nodi cluster Big Data Service vengono eseguiti nelle istanze di computazione (server) di Oracle Cloud Infrastructure.
Quando crei un cluster, scegli un tipo di istanza che determina se l'istanza viene eseguita direttamente sull'istanza Bare Metal dell'hardware o in un ambiente virtualizzato. È inoltre possibile scegliere una forma che configura le risorse assegnate all'istanza.
-
Bare Metal: un'istanza di calcolo bare metal utilizza un server fisico dedicato per il nodo, per le prestazioni più elevate e l'isolamento più efficace.
-
Virtual Machine (VM): tramite la virtualizzazione, un'istanza di computazione VM può ospitare più nodi isolati eseguiti su un singolo computer Bare Metal fisico. Le istanze VM sono meno costose delle istanze Bare Metal e sono utili per creare cluster meno impegnativi che non richiedono le prestazioni e le risorse (CPU, memoria, larghezza di banda di rete, storage) di un'intera macchina fisica per ogni nodo.
Le istanze VM vengono eseguite sullo stesso hardware delle istanze Bare Metal, con la stessa infrastruttura di firmware, stack software e networking.
Per ulteriori informazioni sulle istanze di computazione, vedere Panoramica di Compute.
La forma determina il numero di CPU, la quantità di memoria e altre risorse allocate all'istanza di computazione che ospita il nodo cluster. Per informazioni sulle forme disponibili, vedere Pianificazione del layout, della forma e dello storage del cluster nella documentazione di Oracle Cloud Infrastructure.
Non è necessario che le forme dei nodi principali di Big Data Service e dei nodi di lavoro corrispondano. Tuttavia, le forme di tutti i nodi principali devono corrispondere tra loro e le forme di tutti i nodi di lavoro devono corrispondere tra loro.
Informazioni sui profili cluster
I profili cluster consentono di creare cluster ottimali per un carico di lavoro o una tecnologia specifica. Dopo aver creato un cluster con un profilo cluster specifico, è possibile aggiungere altri servizi Hadoop al cluster.
Tipi di profilo cluster
Oracle Big Data Service consente di creare cluster per numerosi tipi di profilo cluster.
| Profilo cluster | Componenti (sicuri e altamente disponibili) | Componenti |
|---|---|---|
| HADOOP_EXTENDED1 | Hive, Spark, HDFS, Filato, ZooKeeper, MapReduce2, Metriche Ambari, Ranger, Tonalità, Oozie, Tez | Hive, Spark, HDFS, Filato, ZooKeeper, MapReduce2, Metriche Ambari, Tonalità, Oozie, Tez |
| HADOOP | HDFS, filato, ZooKeeper, MapReduce2, metriche Ambari, ranger, tonalità | HDFS, filato, ZooKeeper, MapReduce2, metriche Ambari, tonalità |
| CINQUE | Hive, HDFS, Filato, ZooKeeper, MapReduce2, Metriche Ambari, Ranger, Tonalità, Tez | Hive, HDFS, filato, ZooKeeper, MapReduce2, metriche Ambari, tonalità, Tez |
| PISCINA | Spark, Hive2, HDFS, Filato, ZooKeeper, MapReduce2, Metriche Ambari, Ranger, Tonalità | Spark, Hive2, HDFS, filati, ZooKeeper, MapReduce2, metriche Ambari, tonalità 2 |
| HBASE | HBase, HDFS, Filato, ZooKeeper, MapReduce2, Metriche Ambari, Ranger, Tonalità | HBase, HDFS, filato, ZooKeeper, MapReduce2, metriche Ambari, tonalità |
| TRINO | Trino, Hive3, HDFS, ZooKeeper, Metriche Ambari, Ranger, Hue | Trino, Hive3, HDFS, ZooKeeper, Metriche Ambari, Tonalità |
| KAFKA | Broker Kafka, HDFS, ZooKeeper, Metriche Ambari, Ranger, Hue | Broker Kafka, HDFS, ZooKeeper, Metriche Ambari, Tonalità |
1 HADOOP_EXTENDED è costituito dai componenti creati dai cluster prima che i profili cluster fossero disponibili.
2Il componente del metastore Hive dal servizio Hive viene utilizzato per gestire i metadati in Spark.
3Il componente del metastore Hive del servizio Hive viene utilizzato per gestire le entità dei metadati Hive in Trino.
Versioni di Apache Hadoop nei profili cluster
La tabella seguente elenca le versioni dei componenti Hadoop incluse nei profili cluster corrispondenti alla versione ODH.
ODH 1.x
| Profilo cluster | Versione |
|---|---|
| HADOOP_EXTENDED | HDFS 3.1, Hive 3.1, Spark 3.0.2 |
| HADOOP | HDFS 3.1 |
| CINQUE | Hive 3.1 |
| PISCINA | Spark 3.0.2 |
| HBASE | HBase 2.2 |
| TRINO | Trino 360 |
| KAFKA | Kafka 2.1.0 |
ODH 2.x
| Profilo cluster | Versione |
|---|---|
| HADOOP_EXTENDED | HDFS 3.3, Hive 3.1, Spark 3.2 |
| HADOOP | HDFS 3.3 |
| CINQUE | Hive 3.1 |
| PISCINA | Spark 3.2 |
| HBASE | HBase 2.2 |
| TRINO | Trino 389 |