Oracle Cloud Infrastructure - Dokumentation

ODH-Cluster planen und verstehen

Bevor Sie Big Data Service-Cluster erstellen, müssen Sie Cluster, Instanztypen und -ausprägungen sowie Clusterprofile planen und verstehen.

Weitere Informationen finden Sie unter:

Clusterlayout, -ausprägung und -speicherung planen

Bevor Sie den Prozess zum Erstellen eines Clusters starten, müssen Sie das Layout des Clusters, die Knotenausprägungen und den Speicher planen.

Clusterlayout

Knoten und Services werden auf verschiedenen Clustern unterschiedlich organisiert, je nachdem, ob das Cluster hochverfügbar (HA) und sicher ist oder nicht.

HA-Cluster verwenden

Verwenden Sie HA-Cluster für Produktionsumgebungen. Sie sind für Resilienz erforderlich und minimieren Ausfallzeiten.

In diesem Release muss ein Cluster hochverfügbar und sicher oder nichts von beidem sein.

Knotentypen

Es gibt folgende Typen von Knoten:

  • Master- oder Utilityknoten enthalten die Services, die für den Betrieb und die Verwaltung des Clusters erforderlich sind. Diese Knoten speichern oder verarbeiten keine Daten.
  • Worker-Knoten speichern und verarbeiten Daten. Der Verlust eines Worker-Knotens wirkt sich nicht auf den Betrieb des Clusters aus, kann aber die Performance beeinträchtigen.
  • Reine Compute-Worker-Knoten verarbeiten Daten. Der Verlust eines reinen Compute-Worker-Knotens wirkt sich nicht auf den Betrieb des Clusters aus, kann aber die Performance beeinträchtigen.
  • Edge-Knoten sind erweiterte Knoten für das Cluster, auf dem nur Clients installiert sind. Sie können zusätzliche Packages installieren und zusätzliche Anwendungen auf diesem Knoten anstelle von Worker-/Compute-/Master-Knoten ausführen, um Classpath-Konflikte und Ressourcenprobleme bei Clusterservices zu vermeiden.

High Availability-(HA-)Clusterlayout

Ein High-Availability-Cluster enthält zwei Masterknoten, zwei Utilityknoten, drei oder mehr Worker-Knoten und null oder mehr reine Compute-Worker-Knoten.

Knotentyp Services auf ODH
Erster Masterknoten
  • Ambari Metrics Monitor
  • HDFS-Client
  • HDFS JournalNode
  • HDFS NameNode
  • HDFS ZKFailoverController
  • Hive-Client
  • Kerberos-Client
  • MapReduce2-Client
  • Spark3-Client
  • Spark3 History Server
  • YARN-Client
  • YARN ResourceManager
  • ZooKeeper-Server
Zweiter Master-Knoten
  • Ambari Metrics Monitor
  • HDFS-Client
  • HDFS JournalNode
  • HDFS NameNode
  • HDFS ZKFailoverController
  • Kerberos-Client
  • MapReduce2-Client
  • MapReduce2 History Server
  • Spark3-Client
  • Tez-Client
  • YARN-Client
  • YARN RegistryDNS
  • YARN ResourceManager
  • YARN Timeline Service V1.5
  • ZooKeeper-Server
Erster Utilityknoten
  • Ambari Metrics Monitor
  • Ambari Server
  • HDFS-Client
  • HDFS JournalNode
  • Hive Metastore
  • HiveServer2
  • Kerberos-Client
  • MapReduce2-Client
  • Oozie Server
  • Spark3-Client
  • Tez-Client
  • YARN-Client
  • ZooKeeper-Client
  • ZooKeeper-Server
Zweiter Utilityknoten
  • Ambari Metrics Collector
  • Ambari Metrics Monitor
  • HDFS-Client
  • Hive-Client
  • Kerberos-Client
  • MapReduce2-Client
  • Spark3-Client
  • YARN-Client
Worker-Knoten (max. 3)
  • Ambari Metrics Monitor
  • HDFS DataNode
  • HDFS-Client
  • Hive-Client
  • Kerberos-Client
  • MapReduce2-Client
  • Oozie-Client
  • Spark3-Client
  • Spark3 Thrift Server
  • Tez-Client
  • YARN-Client
  • YARN NodeManager
  • ZooKeeper-Client
Reine Compute-Worker-Knoten
  • Ambari Metrics Monitor
  • HDFS-Client
  • Hive-Client
  • Kerberos-Client
  • MapReduce2-Client
  • Oozie-Client
  • Spark3-Client
  • Tez-Client
  • YARN-Client
  • YARN NodeManager
  • ZooKeeper-Client
Edge-Knoten
  • Ambari Metrics Monitor
  • HDFS-Client
  • Hive-Client
  • Kerberos-Client
  • MapReduce2-Client
  • Oozie-Client
  • Spark3-Client
  • Tez-Client
  • YARN-Client
  • ZooKeeper-Client

Minimales Clusterlayout (nonHA)

Ein Nicht-High-Availability-Cluster enthält einen Masterknoten, einen Utilityknoten, drei oder mehr Worker-Knoten und null oder mehr reine Compute-Worker-Knoten.

Knotentyp Services auf ODH
Masterknoten
  • Ambari Metrics Monitor
  • HDFS-Client
  • HDFS NameNode
  • Hive-Client
  • MapReduce2-Client
  • Spark3-Client
  • Spark3 History Server
  • YARN-Client
  • YARN RegistryDNS
  • YARN ResourceManager
  • ZooKeeper-Server
Utilityknoten
  • Ambari Metrics Collector
  • Ambari Metrics Monitor
  • Ambari Server
  • HDFS-Client
  • HDFS Secondary NameNode
  • Hive Metastore
  • HiveServer2
  • MapReduce2-Client
  • MapReduce2 History Server
  • Oozie Server
  • Spark3-Client
  • Tez-Client
  • YARN-Client
  • YARN Timeline Service V1.5
  • ZooKeeper-Client
  • ZooKeeper-Server
Worker-Knoten
  • Ambari Metrics Monitor
  • HDFS DataNode
  • HDFS-Client
  • Hive-Client
  • MapReduce2-Client
  • Oozie-Client
  • Spark3-Client
  • Spark3 Thrift Server
  • Tez-Client
  • YARN-Client
  • YARN NodeManager
  • ZooKeeper-Client
  • ZooKeeper-Server
Reine Compute-Worker-Knoten
  • Ambari Metrics Monitor
  • HDFS-Client
  • Hive-Client
  • MapReduce2-Client
  • Oozie-Client
  • Spark3-Client
  • Tez-Client
  • YARN-Client
  • YARN NodeManager
  • ZooKeeper-Client
Edge-Knoten
  • HDFS-Client
  • Hive-Client
  • MapReduce2-Client
  • Oozie-Client
  • Spark3-Client
  • Tez-Client
  • YARN-Client
  • ZooKeeper-Client
Unterstützte Knotenausprägungen

Die Knotenausprägung beschreibt die Compute-Ressourcen, die dem Knoten zugewiesen werden.

Die für Master-/Utilityknoten und Worker-Knoten verwendeten Ausprägungen können unterschiedlich sein. Es müssen jedoch alle Master-/Utilityknoten dieselbe Ausprägung und alle Worker-Knoten dieselbe Ausprägung aufweisen.

Die folgende Tabelle zeigt, welche Ausprägungen für die verschiedenen Knotentypen verwendet werden können. Weitere Informationen finden Sie unter Compute-Ausprägungen.

Eine Liste der von den einzelnen Ausprägungen bereitgestellten Ressourcen finden Sie unter:

Knotenart Verfügbare Ausprägungen Erforderliche Anzahl virtuelle Netzwerkkarten (VNICs)
Master oder Utility

VM.Standard2.4

VM. Standard2.8

VM. Standard2.16

VM.Standard2.24

VM.Standard.E5. Flexibel

VM.Standard.E4. FlexFeld *

VM.Standard3. FlexFeld*

VM.Optimized3. FlexFeld*

VM.DenseIO.E4. Flexibel*

VM.DenseIO.E5. Flex*

VM.DenseIO2.8

VM.DenseIO2.16

VM.DenseIO2.24

BM.Standard2.52

BM.DenseIO2.52

BM.HPC2.36

BM.Standard3.64*

BM.Optimized3.36*

BM.DenseIO.E4.128*

BM.Standard.E4.128*

 mindestens 3

Wird für das Clustersubnetz, das Subnetz für den DP-Zugriff und das Subnetz des Kunden verwendet

* Sie müssen mindestens 3 OCPUs und 32 GB Speicher angeben.
Worker

VM.Standard2.1*

VM.Standard2.2*

VM. Standard2.4

VM. Standard2.8

VM. Standard2.16

VM.Standard2.24

VM.Standard.E5. Flexibel

VM.Standard.E4. FlexFeld *

VM.Standard3. FlexFeld*

VM.Optimized3. FlexFeld*

VM.DenseIO.E4. Flexibel*

VM.DenseIO.E5. Flex*

VM.DenseIO2.8

VM.DenseIO2.16

VM.DenseIO2.24

BM.Standard2.52

BM.DenseI2.52

BM.HPC2.36

BM.Standard3.64*

BM.Optimized3.36*

BM.DenseIO.E4.128*

BM.Standard.E4.128*

 Mindestens 2

Wird für das Clustersubnetz und das Subnetz verwendet
Reiner Compute Worker

VM.Standard2.1*

VM.Standard2.2*

VM. Standard2.4

VM. Standard2.8

VM. Standard2.16

VM.Standard2.24

VM.Standard.E5. Flexibel

VM.Standard.E4. FlexFeld *

VM.Standard3. FlexFeld*

VM.Optimized3. FlexFeld*

VM.DenseIO.E4. Flexibel*

VM.DenseIO.E5. Flex*

VM.DenseIO2.8

VM.DenseIO2.16

VM.DenseIO2.24

BM.Standard2.52

BM.DenseI2.52

BM.HPC2.36

BM.Standard3.64*

BM.Optimized3.36*

BM.DenseIO.E4.128*

BM.Standard.E4.128*

 Mindestens 2

Wird für das Clustersubnetz und das Subnetz verwendet
Rand

VM.Standard2.1*

VM.Standard2.2*

VM. Standard2.4

VM. Standard2.8

VM. Standard2.16

VM.Standard2.24

VM.Standard.E5. Flexibel

VM.Standard.E4. FlexFeld *

VM.Standard3. FlexFeld*

VM.Optimized3. FlexFeld*

VM.DenseIO.E4. Flexibel*

VM.DenseIO.E5. Flex*

VM.DenseIO2.8

VM.DenseIO2.16

VM.DenseIO2.24

BM.Standard2.52

BM.DenseI2.52

BM.HPC2.36

BM.Standard3.64*

BM.Optimized3.36*

BM.DenseIO.E4.128*

BM.Standard.E4.128*

Mindestens 2

Wird für das Clustersubnetz und das Subnetz des Kunden verwendet

Hinweis: Da der Edge-Knoten spezifisch für Clientanwendungsfälle ist, wählen Sie die Ausprägung nach Bedarf für die Anwendung aus.

* Beachten Sie, dass VM.Standard2.1 und VM.Standard2.2 kleine Ausprägungen sind, die keine großen Workloads unterstützen. Für VM.Standard.E4. Flex, VM.Standard3. Flex, VM.Standard.E5. Flex und VM.Optimized3. Sie müssen mindestens 1 OCPU und 16 GB Arbeitsspeicher angeben.

Nicht alle Ausprägungen sind standardmäßig verfügbar. Informationen dazu, welche Ausprägungen standardmäßig über die Cloud-Konsole verfügbar sind, finden Sie unter Mandantenlimits suchen. Informationen dazu, wie Sie eine Erhöhung der Servicelimits beantragen, finden Sie unter Erhöhung des Servicelimits beantragen.

Blockspeicherknotenausprägungen

Knoten, die auf Standard-VM-Ausprägungen basieren, verwenden einen netzgebundenen Blockspeicher.

Hinweis

Blockspeicher wird für auf DenseIO- und HPC-Ausprägungen basierende Knoten nicht unterstützt.

Alle Knoten weisen ein Boot-Volume mit 150 GB auf.

Option Limits/Richtlinien
Minimaler anfänglicher Blockspeicher 150 GB
Standardmäßiger anfänglicher Blockspeicher * 150 GB
Minimaler zusätzlicher Blockspeicher 150 GB
Standardmäßiger zusätzlicher Blockspeicher * 1 TB
Erhöhungsschritt für (anfänglichen und zusätzlichen) Blockspeicher 50 GB
Maximaler Blockspeicher für einen einzelnen Knoten

48 TB

Die Gesamtgröße von 48 TB ergibt sich aus 12 Volumes mit jeweils 4 TB.

Wenn Sie Blockspeicher mehrmals hinzufügen, bleibt das Maximum bei 48 TB. Es kann jedoch über mehr als 12 Volumes verteilt werden.
Maximale Block-Volume-Größe

4 TB

Wenn Sie die maximalen 48 TB angeben, werden 12 Laufwerke mit jeweils 4 TB erstellt.

Wenn Sie eine niedrigere Zahl angeben, werden ausreichend 4-TB-Geräte für diese Menge erstellt, und beim Hinzufügen von Speicher werden weitere Geräte erstellt.

Sie können Master- oder Utilityknoten keinen weiteren Blockspeicher hinzufügen. Daher zeigen die folgenden Zahlen nur Anfangsgrößen.

Option Limits/Richtlinien
Minimaler anfänglicher Blockspeicher 150 GB
Standardmäßiger anfänglicher Blockspeicher 1 TB
Minimaler zusätzlicher Blockspeicher 150 GB
Standardmäßiger zusätzlicher Blockspeicher 1 TB
Erhöhungsschritt für (anfänglichen und zusätzlichen) Blockspeicher 50 GB
Maximaler Blockspeicher für einen einzelnen Knoten 32 TB
Maximale Block-Volume-Größe 32 TB
MySQL Platzierung Verschieben Sie für Utilityknoten /var/lib/mysql in /u01, und erstellen Sie einen symbolischen Link. Dadurch wird verhindert, dass das Boot-Volume gefüllt wird.
Option Richtlinien
Standardmäßiger anfänglicher Blockspeicher 2 TB
Minimaler anfänglicher Blockspeicher 150 GB

Abfrageserverspeicher wird für Temporary Tablespace verwendet, um umfangreiche JOIN- und GROUP BY-Vorgänge auszuführen. 2 TB werden für die typische Verarbeitung empfohlen. Bei kleinen Umgebungen, beispielsweise Entwicklung, kann dieser Wert nach unten angepasst werden.

Berücksichtigen Sie die folgenden Faktoren, um eine optimale Performance zu erzielen:

  • I/O-Durchsatz
  • Networking zwischen Compute-Gerät und Blockspeichergerät.

Informationen hierzu finden Sie in der Oracle Cloud Infrastructure-Dokumentation unter Block-Volume-Perfomance.

In der folgenden Tabelle wird beschrieben, wie Big Data Service Block Volume-Speicher für Knoten mit verschiedenen Größen zuweist.

Überblick Menge
Anfängliche Volume-Zuweisung für Masterknoten und Utilityknoten 1 großes Volume
Volume-Zuweisung für zusätzlichen Blockspeicher für Masterknoten und Utilityknoten 1 großes Volume
Anfängliche Volume-Zuweisung für Worker-Knoten.

  • Speicher: Weniger als 12 TB.

    Volume-Größe: 1 TB Das letzte Volume kann kleiner als 1 TB sein.

  • Speicher: 12 TB bis 48 TB.

    Volume-Größe: Gleichmäßige Aufteilung auf 12 Volumes mit jeweils mindestens 1 TB.

  • Speicher: Mehr als 48 TB.

    Volume-Größe: Nicht zulässig.
Volume-Zuweisung für zusätzlichen Blockspeicher für Worker-Knoten

Die Mindestanzahl an Volumes, die die Speichergröße aufnehmen können, mit einer maximalen Volume-Größe von 4 TB pro Volume. (Das letzte Volume kann kleiner als 4 TB sein.

Es wird empfohlen, Edge-Knoten für das Staging zu verwenden.

Instanztypen und Ausprägungen

Big Data Service-Clusterknoten werden in Oracle Cloud Infrastructure-Compute-Instanzen (Servern) ausgeführt.

Beim Erstellen eines Clusters wählen Sie einen Instanztyp aus, der bestimmt, ob die Instanz direkt auf der Bare-Metal-Instanz der Hardware oder in einer virtuellen Umgebung ausgeführt wird. Sie wählen auch eine Ausprägung aus, mit der die der Instanz zugewiesenen Ressourcen konfiguriert werden.

Informationen zu Instanztypen

  • Bare Metal: Eine Bare Metal Compute-Instanz verwendet einen dedizierten physischen Server für den Knoten, um die beste Performance und starke Isolation zu gewährleisten.

  • Virtual Machine (VM): Durch Virtualisierung kann eine VM-Compute-Instanz mehrere isolierte Knoten hosten, die auf einem einzelnen physischen Bare-Metal-Rechner ausgeführt werden. VM-Instanzen sind weniger aufwendig als Bare-Metal-Instanzen und eignen sich zum Erstellen weniger anspruchsvoller Cluster, die nicht die Performance und Ressourcen (CPU, Arbeitsspeicher, Netzwerkbandbreite, Speicher) eines gesamten physischen Rechners für jeden Knoten erfordern.

VM-Instanzen werden auf derselben Hardware wie Bare-Metal-Instanzen mit derselben Firmware, demselben Softwarestack und derselben Netzwerkinfrastruktur ausgeführt.

Weitere Informationen zu Compute-Instanzen finden Sie unter Überblick über Compute.

Informationen zu Ausprägungen

Die Ausprägung bestimmt die Anzahl der CPUs, den Arbeitsspeicher und andere Ressourcen, die der Compute-Instanz zugewiesen sind, die den Clusterknoten hostet. Die verfügbaren Ausprägungen finden Sie in der Oracle Cloud Infrastructure-Dokumentation unter Clusterlayout, Ausprägung und Speicher planen.

Die Ausprägungen der Big Data Service-Masterknoten und der Worker-Knoten müssen nicht übereinstimmen. Die Ausprägungen aller Masterknoten müssen jedoch miteinander übereinstimmen, und die Ausprägungen aller Worker-Knoten müssen miteinander übereinstimmen.

Clusterprofile verstehen

Mit Clusterprofilen können Sie optimale Cluster für eine bestimmte Workload oder Technologie erstellen. Nachdem Sie ein Cluster mit einem bestimmten Clusterprofil erstellt haben, können dem Cluster weitere Hadoop-Services hinzugefügt werden.

Clusterprofiltypen

Mit Oracle Big Data Service können Sie Cluster für zahlreiche Clusterprofiltypen erstellen.

Clusterprofil Komponenten (sicher und hoch verfügbar) Komponenten
HADOOP_EXTENDED1 Hive, Spark, HDFS, Garn, ZooKeeper, MapReduce2, Ambari-Metriken, Ranger, Hue, Oozie, Tez Hive, Spark, HDFS, Garn, ZooKeeper, MapReduce2, Ambari-Metriken, Farbton, Oozie, Tez
HADOOP HDFS, Garn, ZooKeeper, MapReduce2, Ambari-Metriken, Ranger, Farbton HDFS, Garn, ZooKeeper, MapReduce2, Ambari-Metriken, Farbton
NIVEAU Hive, HDFS, Garn, ZooKeeper, MapReduce2, Ambari-Metriken, Ranger, Farbton, Tez Hive, HDFS, Garn, ZooKeeper, MapReduce2, Ambari-Metriken, Farbton, Tez
SPARK Spark, Hive2, HDFS, Garn, ZooKeeper, MapReduce2, Ambari-Metriken, Ranger, Farbton Spark, Hive2, HDFS, Garn, ZooKeeper, MapReduce2, Ambari-Metriken, Farbton 2
HBASE HBase, HDFS, Garn, ZooKeeper, MapReduce2, Ambari-Metriken, Ranger, Farbton HBase, HDFS, Garn, ZooKeeper, MapReduce2, Ambari-Metriken, Farbton
TRINO Trino, Hive3, HDFS, ZooKeeper, Ambari-Metriken, Ranger, Farbton Trino, Hive3, HDFS, ZooKeeper, Ambari-Metriken, Farbton
KAFKA Kafka Broker, HDFS, ZooKeeper, Ambari Metrics, Ranger, Hue Kafka Broker, HDFS, ZooKeeper, Ambari-Metriken, Hue

1 HADOOP_EXTENDED besteht aus Komponenten, die Sie erstellt haben, bevor Clusterprofile verfügbar waren.

2Die Hive-Metastore-Komponente aus dem Hive-Service wird zur Verwaltung der Metadaten in Spark verwendet.

3Die Hive-Metastore-Komponente aus dem Hive-Service wird zur Verwaltung der Hive-Metadatenentitys im Trino verwendet.

Apache Hadoop-Versionen in Clusterprofilen

In der folgenden Tabelle sind die Hadoop-Komponentenversionen aufgeführt, die in Clusterprofilen enthalten sind, die der ODH-Version entsprechen.

Rechtes Auge - 1.x

Clusterprofil Version
HADOOP_EXTENDED HDFS 3.1, Hive 3.1, Spark 3.0.2
HADOOP HDFS 3.1
NIVEAU Hive 3.1
SPARK Spark 3.0.2
HBASE HBase 2.2
TRINO Trino 360
KAFKA Kafka 2.1.0

Rechtes Auge - 2.x

Clusterprofil Version
HADOOP_EXTENDED HDFS 3.3, Hive 3.1, Spark 3.2
HADOOP HDFS 3.3
NIVEAU Hive 3.1
SPARK Spark 3.2
HBASE HBase 2.2
TRINO Trino 389