Überlegungen zu Performance und Form

Wichtige Preis- und Performance-Überlegungen zur Ausführung von Hadoop auf Oracle Cloud Infrastructure. Sie sollten auch berücksichtigen, wie Ihre Anforderungen sich auf Deployment-Formen auswirken.

Vergleichsanalyse

Oracle Cloud Infrastructure bietet sowohl Performance-als auch Kostenvorteile für Unternehmen, die an der Ausführung von Hadoop-Clustern in Oracle Cloud interessiert sind.

TeraSort ist eine allgemeine Benchmark für Hadoop, da sie alle Elemente des Clusters (Compute, Memory, Storage, Network) nutzt, um ein zufälliges Dataset zu generieren, zuzuordnen/zu reduzieren und zu validieren.

Eine vergleichende Analyse mit normalisierten Oracle Cloud Infrastructure-Clustern mit 300 OCPU und verwendeten Block-Volumes für HDFS-Speicher. Die jeweilige Analyse hat festgestellt, dass Oracle Cloud Infrastructure dreimal schneller ausgeführt wurde und mehr als 80% niedrigere Kosten als ein nützliches Deployment in der Cloud des Mitbewerbers liefert.

Im folgenden Diagramm wird die Gesamtperformance verschiedener Oracle Cloud Infrastructure-Leistungseinheiten dargestellt, wenn diese 10TB TeraSort unter der normalisierten Clustergröße ausgeführt wird:

Beschreibung der Abbildung comparison-terasort-phase-cpu.png

Oracle Cloud Infrastructure bietet Bare-Metal-Compute-Standardinstanzen mit Intel - und AMD-CPUs sowie eine spezielle HPC-Option. In dem Diagramm werden die speziellen HPC-Cluster schneller ausgeführt als die Intel - und AMD-Gegenstücke, auch wenn diese Instanzen eine niedrigere Anzahl an Cores aufweisen. Dieses Ergebnis ist vorwiegend aufgetreten, weil dieses Cluster mehr Knoten verwendet, um dieselbe normalisierte OCPU-Anzahl zu erreichen, die sich direkt auf den gesamten HDFS-Aggregatdurchsatz auswirkt und die Performance zu steigern.

Die HPC-Leistungseinheiten profitieren auch von einer 100-GBps-Netzwerkfunktion, die eine schnellere clusterinterne Datenübertragung ermöglicht.

In der folgenden Abbildung wird die Performance von VM-basierten Mitarbeitern mit Block-Volumes und Bare-Metal- NVMe, mit Cloudera ausgeführt und mit 10 Worker-Knoten im Cluster normalisiert:

Beschreibung der Abbildung comparison-terasort-vm-bm-performance.png

Der Gewinn aus einer Verdoppelung der VM-Größe des Mitarbeiters von 8 bis 16 Cores liegt im Hinblick auf eine doppelte Effizienz, was einen Sinn ergibt, weil der VM-Netzwerkdurchsatz ein Bruchteil der zugrunde liegenden physischen NIC ist. Die Vorteile von Bare Metal mit lokaler NVMe sind ebenfalls hervorragend. Das Cluster nutzt die hohe Geschwindigkeit des lokalen NVMe-Speichers zusammen mit der 25-Gbps-Netzwerkschnittstelle.

Entscheiden Sie, welche Leistungseinheiten für die Berechnung in einem Hadoop-Cluster zwischen Hadoop ISVs konsistent sind.

Compute-Instanzauswahl

Dieser Abschnitt enthält Best Practices bei der Auswahl einer Form für jede Knotenrolle.

Masterknoten

Masterknoten sind nur für Cloudera, Hortonworks und Apache Hadoop-Verteilungen anwendbar. Standardmäßig sind MapR keine Cluster-Services von Mitarbeiterknoten getrennt. In der Praxis empfiehlt Oracle die Verwendung einer guten Speicher-Dichte auf Master-Knoten, um die Gemeinkosten von Cluster- und Service-Verwaltung zu unterstützen. Auf den Masterknoten werden Zookeeper-, NameNode-, JournalNode-, Resource Manager-, HBase-, Spark - und Cluster Management-(Cloudera Manager- und Ambari-) Services ausgeführt.

• Mindestform: VM.Standard2.8
• Empfohlene Form: VM.Standard2.24

Worker-Knoten

Mitarbeiterknoten sind zwischen allen Hadoop ISVs und Apache konsistent. Skalieren Sie die Form für den Worker-Knoten entsprechend, um die Workload-Anforderungen zu erfüllen. Dies gilt sowohl für Compute-als auch für Speicheranforderungen, da viele Kunden nach Aggregatspeicher suchen, der mitSpark-basierten Workloads verwendet werden kann. Herkömmliche Karten-/Abnutzung von Workloads profitieren auch von erhöhtem Speicher-Footprint auf Worker-Knoten.

• Mindestform: VM.Standard2.8
• Empfohlene Form: BM.DenseIO2.52

Unterstützende Knoten

Die unterstützende Infrastruktur umfasst Achsenknoten oder andere Knoten, die zusätzliche Cluster-Services oder benutzerdefinierten Anwendungscode ausführen können. Die Anforderungen für diese Knoten variieren je nach Skalierung und Anwendungsfall. Für Achsenknoten wird eine Mindestgröße von VM.Standard2.2. empfohlen Je nach Anzahl der Benutzer pro Achsenelement vertikal skalieren. Es wird empfohlen, mehrere Achsenknoten für HA zwischen Faultdomains zu empfehlen und mehrere Wege zu erstellen, damit Benutzer mit dem Cluster interagieren können.

Netzwerkaspekte

Hadoop ist stark vom Netzwerk für clusterinternen Datenverkehr abhängig. Daher haben die Leistungseinheiten, die Sie für jede Rolle in der Cluster-Topologie bereitstellen möchten, direkte Auswirkungen auf die clusterinterne Konnektivität.

Bei der Verwendung von Bare Metal-Leistungseinheiten können Compute-Hosts vollständige virtuelle 25-GB-Netzwerkkarten (VNICs) verwenden. VM-Leistungseinheiten werden relativ zu ihrer Compute-Größe skaliert.

Wenn Sie Block-Volumes für die HDFS-Kapazität verwenden, müssen Sie sich beachten, dass der I/O-Datenverkehr für ein Block-Volume dieselbe VNIC wie der Anwendungsdatenverkehr (standardmäßig) gemeinsam verwendet. Eine Möglichkeit zur Optimierung, wenn Sie Bare Metal-Leistungseinheiten verwenden, besteht darin, eine sekundäre VNIC für die Clusterkonnektivität auf der zweiten physikalischen Schnittstelle zu erstellen. Dadurch wird die primäre VNIC nur für Blockdatenträgerverkehr reserviert, sodass die Netzwerkauslastung optimiert wird.

Das folgende Diagramm zeigt dieses Konzept:

Beschreibung der Abbildung architecture-vnic.png

Beachten Sie bei der Verwendung von Block-Volumes außerdem, dass die Aggregation von HDFS-I/O direkt auf die Menge und Größe der Block-Volumes bezieht, die mit jedem Worker-Knoten verknüpft sind. Um die erforderliche HDFS-Kapazität zu erreichen, empfiehlt Oracle, dass Sie eine größere Anzahl von Datenträgern pro Mitarbeiter und nicht eine geringere Anzahl an größeren Datenträgern skalieren.

Speicheraspekte

Bei Hadoop-Deployments können zwei Speichertypen für die HDFS-Kapazität verwendet werden: DenseIO-Leistungseinheiten mit lokalen NVMe - und Block-Volumes. Bei MapR-Deployments muss ein einziger Speichertyp für Worker-Knoten (homoge) gewählt werden, es sei denn, Sie haben eine Lizenzierung für den Daten-Tiering. Sonstige Hadoop ISVs unterstützen heterogenen Speicher (Mischung von DenseIO NVMe - und Block-Volumes) ohne zusätzliche Lizenzkosten.

Vom Hersteller unterstützte Speicherkonfigurationen

Cloudera und Hortonworks unterstützen alle Speicherformulare in Oracle Cloud Infrastructure zur Verwendung mit Hadoop:

• Lokales NVMe auf DenseIO-Leistungseinheiten
• Block-Volumes
• Object Storage (S3-Kompatibilität verwenden)

Cloudera unterstützt das Daten-Tiering (heterogener Speicher) für Deployments, die aus lokalen NVMe - und Block-Volumes für HDFS bestehen.

MapR -Deployments können entweder lokale NVMe auf DenseIO-Leistungseinheiten oder Block-Volumes zum Deployment nutzen.

• Object Storage: Siehe MapR XD Object Tiering.
• MapR unterstützt nicht heterogenen Speicher ohne zusätzliche Lizenz.

Alle Speicherformulare in Oracle Cloud Infrastructure stehen für die Verwendung mit Apache Hadoop zur Verfügung, einschließlich Object Storage, die den HDFS-Connector nutzen.

DenseIO NVMe

DenseIO NVMe ist die leistungsstarkste Speicheroption für Hadoop auf Oracle Cloud Infrastructure. Lokale NVMe-Laufwerke mit hoher Geschwindigkeit zur Verwendung mit HDFS sind in Bare-Metal- und Virtual-Machine-Leistungseinheiten verfügbar.

Bei der Verwendung von lokaler NVMe empfiehlt Oracle, die DFS-Replikation auf drei Replikate zu setzen, um die Datenredundanz zu gewährleisten.

Alternativ können Sie bei Cloudera Clustern die Löschcodierung verwenden, um die Speicherungseffizienz für bestimmte Datentypen zu erhöhen.

Block-Volumes

Block-Volumes in Oracle Cloud Infrastructure sind eine hervorragende Performanceoption und bieten eine flexible Konfiguration für die HDFS-Kapazität. Block-Volumes sind ein netzwerkangeschlossener Speicher. Beispiel: Sie verwenden die VNIC-Bandbreite für I/O. Block-Volumes können auch in IOPS und MB/s je nach konfigurierter Größe (pro GB) skaliert werden. Individueller Block-Volume-Durchsatz überschreitet 320 MB/s für 700GB oder größere Datenträger.

Die folgende Tabelle zeigt die Durchsatzskalierung für einen einzelnen Worker-Knoten mit 700GB Volumes:

Block-Volumes	Aggregatdurchsatz (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 hat festgestellt, dass das Hinzufügen von zusätzlichen Block-Volumes nach 11 Block-Volumes zu reduzierten Durchsatzgewinn geführt hat.

Wenn Sie VMs als Mitarbeiter verwenden, beachten Sie, dass der Block-Volume-Verkehr denselben VNIC-Datenverkehr wie der Hadoop - (Anwendungs-) Verkehr gemeinsam verwendet. In der folgenden Tabelle sind die empfohlenen maximalen Block-Volumes und die gemessene VNIC-Bandbreite für eine Auswahl von Oracle Cloud Infrastructure-Leistungseinheiten aufgeführt. Instanzen können über die zusätzliche Bandbreite verfügen, um den Anwendungsdatenverkehr am Anfang der Datenträger-I/O zu unterstützen:

Oracle Cloud Infrastructure -Maschine	VNIC-Bandbreite	Vorgeschlagene maximale Block-Volumes für HDFS
BM.DenseIO2.52	25Gbit/s	11
BM.Standard2.52	25Gbit/s	11
VM.Standard2.24	24.6Gbps	6
VM.Standard2.16	16.4Gbps	4
VM.Standard2.8	8.2Gbps	3

Wenn Sie Block-Volumes für die HDFS-Kapazität verwenden, wird empfohlen, anstelle einer kleineren Anzahl an großen Block-Volumes pro Mitarbeiter eine größere Anzahl an kleinen Block-Volumes zu verwenden, um die HDFS-Zielkapazität zu erreichen.

Verwenden Sie mindestens drei Worker-Knoten als Beispiel mit 700GB Block-Volume-Größe für HDFS:

Beschreibung der Abbildung block-volume-hdfs-capacity-chart.png

Beachten Sie, dass drei Block-Volumes pro Mitarbeiter die Mindestanforderung darstellen. Oracle empfiehlt die Skalierung der Block-Volume-Menge und -Größe, um die erforderliche HDFS-Kapazität zu optimieren. Weitere Block-Volumes pro Mitarbeiter erhöhen die insgesamt verfügbare HDFS-Bandbreite. Dies ist besonders bei großen Workloads mit hohem Durchsatz wichtig, die mehr aggregierte I/O in dem Cluster erfordern.

Es ist außerdem wichtig, dass persistente Cluster zusätzliche Gemeinkosten für Wachstum oder Refactoring beibehalten.

Logging- und Anwendungsdaten

Wenn Sie Block-Volumes für HDFS verwenden, müssen Sie einige Block-Volumes zur Verwendung mit Hadoop-Logs und Anwendungsdaten reservieren (Cloudera Parcels, NameNode und Journal metadata). Auch wenn BS-Datenträger für diese Daten eingeblendet werden kann, sollten Sie dedizierte Block-Volumes aus diesem Zweck besser verwenden. Block-Volumes bieten Ihnen mehr Portierbarkeit, wenn Sie den Instanztyp für Ihre Masterknoten ändern möchten. Wenn Sie mehr I/O-Performance für einen bestimmten Datenspeicherort benötigen. Das Hinzufügen mehrerer Block-Volumes zur Instanz, das Erstellen eines RAID-Arrays und das Migrieren der vorhandenen Daten ist einfacher, wenn Sie über zu verwendende Ersatzdatenträgeranhänge verfügen.

Dasselbe gilt für HDFS. Wenn Sie mehr Block-Volumes hinzufügen möchten, ist es einfacher, Mitarbeiter außer Betrieb zu nehmen, sie mit größeren Platten neu zu generieren, sie wieder dem Cluster hinzuzufügen und HDFS neu zu Rebalancing. Beide Ansätze sind gültig. Es ist gleichgültig, ob die Cluster-Workload eine vollständige Ergänzung der Block-Volumes für die Unterstützung des Datendurchsatzes erfordert. In diesem Fall sollten Sie die Mitarbeiter mit schneller NVMe-Speicherung in Bare Metal Dense IO-Leistungseinheiten wechseln und ein heterogenes Speichermodell mit Daten-Tiers verwenden.

Object Storage

Object Storage-Integration ist mit allen Hadoop-IISVs, einschließlich Apache Hadoop möglich. Oracle Cloud Infrastructure verfügt über einen nativen HDFS-Connector, der mit Apache Hadoop kompatibel ist. Für Hadoop ISVs (Cloudera, Hortonworks und MapR) sind externe Endpunkte für Object Storage-Integration zulässig. Außerdem muss die S3-Kompatibilität verwendet werden, damit die Object Storage-Integration ordnungsgemäß funktioniert.

Ein Caveat besteht darin, dass die S3-Kompatibilität nur mit der Region des Mandanten-Homes funktioniert. Das bedeutet, dass für alle mit Object Storage durchgeführten Integrationen auch Hadoop-Cluster in derselben (Home-) Region bereitgestellt werden müssen.

Ein weiterer Nachteil ist, dass HDFS nicht als Caching-Layer verwendet wird, wenn Sie mit Object Storage Daten in das oder aus dem Cluster pushen oder abrufen. Bei der Tatsache werden im Betriebssystem Daten während der Übertragung zwischen Object Storage und HDFS gecacht. Wenn ein großes Datenvolumen zwischen dem Cluster HDFS und dem Objektspeicher verschoben wird, wird empfohlen, eine Block-Volume-Caching-Schicht im Betriebssystem zu erstellen, um diese Datenverschiebung zu unterstützen.

Die folgende Abbildung zeigt ein typisches Partitionsdiagramm zur Unterstützung der S3-Datenverschiebung zusammen mit Data Tiers für Mitarbeiterknoten.

Beschreibung der Abbildung object-storage-partitioning-throughput.png

Datenverschlüsselung

Sie können alle davor liegenden Speicherungsoptionen kombinieren, wenn Sie Apache Hadoop, Cloudera oder Hortonworks verwenden, um ein robustes Daten-Tier-(heterogenes) Speichermodell zu erstellen. Sie können auch die Verwaltung des Datenlebenszyklus verwenden, um Daten von einer Speicherebene in andere als Daten zu übertragen, um die HDFS-Speicherkosten zu optimieren.

Beschreibung der Abbildung data-lifecycle-tiering.png

Erasure Coding

Ab Hadoop 3.0 wird die Delur-Codierung (EC) in HDFS-Deployments unterstützt. EC reduziert die Speicheranforderungen für lokale HDFS-Daten, indem Daten mit einer einzigen Kopie gespeichert werden, die durch Paritätszellen erweitert wird. HDFS-Topologie kann als EC gekennzeichnet werden, wodurch diese Funktionalität für alle in diesem getaggten Speicherort gespeicherten Daten aktiviert wird. Dadurch wird die Raw-Speicherplatzanforderung für EC-taggte HDFS-Daten effektiv reduziert, sodass eine erhöhte Speicherungseffizienz gewährleistet wird.

Es gibt einige Hinweise zu EC:

• Zur Aktivierung von EC sind die Mindestanzahl der Mitarbeiterknoten erforderlich.
• Der Datenlokalität geht bei mit EC gekennzeichneten Daten verloren.
• EC ist für Dateien mit mittlerer Größe geeignet, auf die selten zugegriffen wird. Sie ist für kleine Dateien nicht geeignet und für Dateien, auf die häufig zugegriffen wird.
• EC erhöht die Anzahl der in den Namensknotenmetadaten vorhandenen Blockobjekte im Vergleich zu ähnlichen Daten mit der herkömmlichen (3x) Replikation.
• Das Recovery von EC-Daten erfordert die Berechnung aus dem Cluster (Paritätsneuerstellung). Diese Recovery-Zeit ist länger als herkömmliche (3x) replizierte Daten.

Performance überwachen

Mit dem Oracle Cloud Infrastructure Monitoring-Service können Sie Ihre Cloud-Ressourcen aktiv und passiver überwachen, indem Sie die Features "Metriken" und "Alarme" verwenden. Die Festlegung von Alarmen, die benachrichtigt werden, wenn Sie die Performance- oder Kapazitätsschwellenwerte testen, ist eine hervorragende Möglichkeit, Oracle Cloud Infrastructure native Tools zur Verwaltung Ihrer Infrastruktur zu nutzen

Referenzarchitekturen

Dieses Thema enthält Referenzmaterial für jeden Hadoop-IV. Die folgenden Referenzarchitekturen und Rechnungen von Materialien geben einen minimal erforderlichen Footprint für das vom Anbieter unterstützte Deployment von Hadoop auf Oracle Cloud Infrastructure an.

Als Open-Source-Projekt verfügt das Apache Hadoop-Deployment nicht über einen vom Hersteller bereitgestellten Mindestzeitraum. Oracle empfiehlt, dass Sie das hier gezeigte Hortonwork-Deployment als vernünftiges Handbuch für ein minimales Apache-Deployment verwenden.

Cloudera

Beschreibung der Abbildung architecture-cloudera.png

Die Mindestanforderungen für das Deployment von Hadoop mit Cloudera sind:

Rolle	Menge	Empfohlene Rechenleistungseinheit
Kante	1	VM.Standard2.4
Cloudera Manager	1	VM.Standard2.16
Masterknoten	2	VM.Standard2.16
Worker-Knoten	3	BM.DenselO2.52

In dieser minimalen Bereitstellung führt der Cloudera Manager-Knoten auch Master-Dienste aus.

Sie müssen Ihre eigene Lizenz verwenden, um Cloudera auf Oracle Cloud Infrastructure bereitzustellen; die gesamte Softwareunterstützung erfolgt über Cloudera.

Hortonworks

Beschreibung der Abbildung Architect-hortonworks.png

Die Mindestanforderungen für das Deployment von Hadoop mit Hortonworks sind:

Rolle	Menge	Empfohlene Rechenleistungseinheit
Kante	1	VM.Standard2.4
Ambari	1	VM.Standard2.16
Masterknoten	2	VM.Standard2.16
Worker-Knoten	3	BM.DenselO2.52

Bei dieser Mindestbereitstellung führt der Knoten "Ambari" auch Master-Dienste aus.

Sie müssen Ihre eigene Lizenz für das Deployment von Hortonworks auf Oracle Cloud Infrastructure verwenden. Alle Softwareunterstützung umfasst Hortonworks.

MapR

Beschreibung der Abbildung architect-mapr.png

Die Mindestanforderungen für das Deployment von Hadoop mit MapR sind:

Rolle	Menge	Empfohlene Rechenleistungseinheit
Kante	1	VM.Standard2.4
Datenknoten	3	BM.DenselO2.52

Sie müssen eine eigene Lizenz für das Deployment von MapR auf Oracle Cloud Infrastructure verwenden. Alle Softwareunterstützung umfasst MapR.

Terraform -Deployments

Sie finden Terraform-Vorlagen für jedes Hadoop ISV im Abschnitt "Downloadcode" dieser Lösung.

Cloudera und Hortonworks Repositorys verfügen über mit Oracle Resource Manager kompatible Vorlagen. Beachten Sie, dass diese spezifisch für Resource Manager sind. Die Basis-(Master-) Verzweigung enthält eine Standalone-Terraform-Vorlage. Resource Manager-Vorlagen für Cloudera und Hortonworks enthalten außerdem ein YAML-Schema, das die Terraform-Variablen für jede Vorlage einfach auffüllt. Dadurch wird eine Dropdown-UI-Auswahl für Variablen bereitgestellt, die Sie für Ihre Anwendungsfälle anpassen können. Im Wesentlichen werden jede Vorlage mit zulässigen Formoptionen und Sicherheits-/Konfigurationseinstellungen gefüllt.