Überlegungen zum Deployment von Hadoop auf Oracle Cloud Infrastructure

Deployment

Wenn Sie dieOracle-Infrastruktur als Service (IaaS) abonnieren, können Sie auf alle damit verknüpften Compute-, Speicher- und Netzwerkservices zugreifen. Deployments in Oracle Cloud Infrastructure sind genau wie On-Premise-Deployments, in denen dieselben Versionen und Features für jede Hadoop-Verteilung verfügbar sind.

Teraform und Ressourcenmanager

Oracle Cloud Infrastructure -Teams haben eine Partnerschaft mit jeder Hadoop ISV, um das Deployment zu ermöglichen, das Terraform nutzt. Mit Terraform können Sie Infrastruktur als Code (IaC) bereitstellen. Dazu gehören alle Aspekte eines Hadoop-Ökosystems aus Netzwerken (virtuelle Cloud-Netzwerke, Subnetze, VNICs) und Sicherheits-Access Control-Listen zur Berechnung und Speicherung von Zugriffsberechtigungen. Terraform ist flexibel, hoch skalierbar und ein Standard von vielen Cloud-Providern.

Sie können wählen, ob diese Vorlagen als Framework für das Deployment von Hadoop in Oracle Cloud Infrastructure verwendet werden sollen, oder ob Sie mit einem vorhandenen Deployment Tool arbeiten können, das Sie On Premise verwendet haben. Beide Methoden sind gültig.

Wenn Sie Terraform für das Deployment von Hadoop verwenden möchten, sollten Sie Oracle Resource Manager verwenden. Hauptvorteile von Resource Manager:

Die Terraform-Statusmetadaten bleiben an einem hochverfügbaren Speicherort erhalten.
Der Zugriff auf Resource Manager kann mit demselben Sicherheits- und Audittooling verwaltet werden, das für andere Oracle Cloud Infrastructure-Services enthalten ist.
Resource Manager entfernt die Komplexität, die mit der Konfiguration von Terraform für das Deployment in Oracle Cloud Infrastructure verknüpft ist.

Die Resource Manager-Schnittstelle unterstützt YAML-basierte Schemadateien, die mit erwarteten Werten für Stackvariablen aufgefüllt sind. Auf diese Weise können Sie Formen, Softwareversionen und andere Parameter definieren, die für jede Variable im Stack zulässig sind.

Beschreibung von resource-manager-ui.png folgt

Beschreibung der Abbildung resource-manager-ui.png

Nachdem die Schemadatei aufgefüllt wurde, werden Werte in einer benutzerfreundlichen UI angezeigt. Über die Schemadatei können Sie Dropdown-Listen mit diesen Werten sowie benutzerdefinierte Eingabefelder eingeben oder einfügen.

Felder in der Schemadatei können auch Abhängigkeiten haben. Wenn ein Benutzer einen Wert in einem Feld wählt, werden andere Felder je nach Auswahl angezeigt oder ausgeblendet.

Cluster-Servicetopologie

Beachten Sie beim Deployment von Hadoop die folgende Zuordnung der Cluster-Servicetopologie zu Knotenrollen:

Knotentyp	Hadoop -Rolle	Hadoop -Services
Kante	Benutzerzugriff von Perimiter	Client-Librarys, Oozie
Utility	Cluster-Management	Cloudera Manager, Ambari, Metadaten-Datenbank
Master	Core Cluster-Services	Zookeeper, NameNode, JournalNode, HIVE, HBase Master, Spark History, Job History, Resource Manager, HTTPFS, SOLR
Mitarbeiter	Workload-Ausführung, Datenspeicherung	HDFS, NodeManager, Region Server, Kafka-Broker, Spark Executor, Map/Reduce

Bei der Auswahl der für diese Rollen zu verwendenden Rechenleistungseinheiten werden die Best Practices später in dieser Lösung beschrieben. Beachten Sie außerdem die folgenden Kriterien:

Wie viele gleichzeitige Benutzer verwenden das Cluster?
Achsenknoten müssen je nach Anzahl der gleichzeitigen Benutzer sowohl in der Menge als auch in der OCPU skaliert werden. Zwei gleichzeitige Benutzer pro OCPU sind eine gute Richtlinie, die pro Benutzer einen Thread ermöglicht. Zusätzliche Achsenknoten über Faultdomains hinweg stellen auch Redundanz bereit.
Haben Sie spezielle Speicheranforderungen für Spark - oder HBase-Region Server?
Diese Anforderungen wirken sich direkt auf die Menge und Zusammensetzung von Mitarbeiterknoten aus. Die Skalierung für HBase erfordert ein Verständnis der zugrunde liegenden Anwendung und variiert. Die meisten Kunden kennen bereits ihre Anforderungen für das HBase-Deployment, insbesondere die Anzahl von Regionsservern und die pro Server zugewiesenen Arbeitsspeicherkapazität. Spark -Workloads verfügen ähnlich wie ein Aggregatspeicherziel, das unter Berücksichtigung der Anzahl der Worker-Knoten durch den verfügbaren Speicher pro Mitarbeiter erreicht wird.
Haben Sie eine bestimmte HDFS-Kapazitätsanforderung?
Die meisten Kunden haben diese Anforderung. Bevor Sie jedoch die Breite auf einer großen Anzahl von Bare Metal DenseIO Worker-Knoten skalieren, sollten Sie beachten, dassNVMe-backed HDFS durch Block-Volumes erweitert werden kann, um die erforderliche HDFS-Dichte zu erreichen, wie später in dieser Lösung beschrieben. Oracle empfiehlt, dass Sie die HDFS-Anforderungen verstehen, die Workload-Anforderungen jedoch auch so erfüllen, dass das Cluster eine “richtige Größe” wählen kann, um beide Ziele zu erreichen, während die Kosten minimiert werden.

Migration

Wenn Kunden, die Hadoop ausführen, für Oracle Cloud Infrastructure bereitstellen, sind in der Regel sehr viele Daten für die Migration vorhanden. Die Bulk-Aktion für diese Daten ist in HDFS vorhanden, wobei die Metadaten des unterstützenden Clusters in einer Datenbank unterstützt werden.

Das direkte Kopieren von HDFS-Daten über das Internet kann aus verschiedenen Gründen herausfordern werden:

Das Datenvolumen ist zu groß, oder die verfügbare Bandbreite ist zu eingeschränkt, um die überschüssige Kopie von Daten in einem aussagefähigen Zeitrahmen zu unterstützen.
Daten sind vertraulich, und das Kopieren im Internet ist möglicherweise von Governance- oder gesetzlichen Anforderungen nicht zulässig.
On-Premise-Clusterressourcen sind eingeschränkt, und die Datenkopie würde sich auf die laufende Workload auswirken.

Mehrere Ansätze zur Datenmigration werden unterstützt. Sie werden von dem Typ der zu migrierenden Daten definiert.

HDFS-Datenmigration

Es gibt drei gängige Möglichkeiten, HDFS-Daten in Oracle Cloud Infrastructure zu kopieren:

Kopieren Sie Daten direkt aus einem On-Premise-Cluster in Object Storage in einer Oracle Cloud Infrastructure-Region mit VPN über das Internet oder mit FastConnect. Nach Abschluss dieses Prozesses kann ein Oracle Cloud Infrastructure-Cluster mit den Daten aus Object Storage neu verteilt werden.
Daten direkt aus einem On-Premise-Cluster in ein Oracle Cloud Infrastructure-Cluster über das Internet oder mit FastConnect kopieren.
Kopieren Sie Daten in eine Data Transfer Appliance, die im Kundendatencenter bereitgestellt, mit Daten gefüllt und dann an Oracle geliefert und in Object Storage hochgeladen wird. Ein Oracle Cloud Infrastructure-Cluster kann dann mit diesen Daten erneut getestet werden.

Technische Details zu jeder dieser Methoden werden später in dieser Lösung erläutert.

Metadatenmigration

Clustermetadaten sind im Allgemeinen wesentlich kleiner als HDFS-Daten und sind in einer Datenbank in einem lokalen Cluster vorhanden.

Die Migration von Clustermetadaten hängt von zwei Faktoren ab: der Hadoop-Verteilung im Quell-Cluster und der Datenbank, in der Metadaten gespeichert werden. Der Transfer dieser Daten ist einfach und für jede Hadoop-Verteilung spezifisch.

Für jede Hadoop-Verteilung werden später in dieser Lösung Besonderheiten gestellt.

Sicherheit

Sicherheit in der Cloud ist besonders für Hadoop wichtig. Es gibt verschiedene Möglichkeiten, sicherzustellen, dass das Deployment auf Oracle Cloud Infrastructure sicher bleibt.

Beachten Sie zunächst einige Oracle Cloud Infrastructure-spezifische Sicherheitskontrollen:

Nutzen Sie Identity and Access Management (IAM), um zu kontrollieren, wer Zugriff auf Cloud-Ressourcen hat, welcher Zugriffstyp auf eine Benutzergruppe hat und auf welche Ressourcen sie zugreifen kann. Diese Architektur kann folgende Ergebnisse liefern:
- Cloud-Ressourcen sicher auf Basis der Organisationsstruktur isolieren
- Authentifizieren Sie Benutzer, um über eine Browseroberfläche, eine REST-API, ein SDK oder eine CLI auf Cloud-Services zuzugreifen
- Benutzergruppen autorisieren, Aktionen mit den entsprechenden Cloud-Ressourcen auszuführen
- Federation mit vorhandenen Identitätsprovidern
- Aktivieren Sie einen verwalteten Serviceanbieter (MSP) oder Systemintegrator (SI) zur Verwaltung von Infrastrukturanlagen, während Ihre Operatoren den Zugriff auf Ressourcen ermöglichen
- Anwendungsinstanzen autorisieren, um API-Aufrufe mit Cloud-Services vorzunehmen
Prüfen Sie Sicherheitslisten für alle Netzwerke im virtuellen Cloud-Netzwerk (VCN). Setzen Sie diese Regeln so restriktiv wie möglich, und lassen Sie nur vertrauenswürdigen Datenverkehr in Internet-fähige Subnetze zu.
Aktivieren Sie Host-Firewalls auf Internet-Hosts, und ermöglichen Sie nur den erforderlichen Verkehr.
Sie sollten Sicherheits-Auditing regelmäßig verwenden.

Die Verschlüsselung ist auch eine gute Option für Daten im Ruhezustand und Daten im Motion. Beachten Sie die folgenden Ressourcen:

Cloudera-Verschlüsselungsverfahren
Hortonworks
- HDFS-Verschlüsselung im Ruhezustand
- Wire-Verschlüsselung
MapR -Verschlüsselung

Zu weiterenHadoop-spezifischen Sicherheitsaspekten zählen:

Stellen Sie Cluster in Subnetzen mit privaten IP-Adressen bereit, die nur erforderliche APIs oder UIs für internetseitige Subnetze bereitstellen.
Hadoop mit Cluster-Sicherheit ausführen
Verwenden Sie Achsenknoten, um über SSH-Tunneling auf Clusterservices zuzugreifen. Dies ist noch einfacher auf Mac oder Linux.
Profitieren Sie von Apache Knox, um API-Endpunkte zu sichern.
Nutzen Sie Apache Sentry oder Cloudera Navigator für rollenbasierten Zugriff auf Clusterdaten und Metadaten.

Netzwerksicherheit

Aufgrund der offenen Art von Hadoop und Sicherheitsbetrachtungen können die meisten Kunden ihr Hadoop-Cluster in einem privaten Subnetz bereitstellen. Der Zugriff auf Cluster-Services ist dann nur über Edge-Knoten, Load Balancing-Zugriff auf UIs, APIs und Service-Dashboards oder durch direkten Zugriff über FastConnect-VPN oder SSH-Tunneling über einen Edge-Proxy verfügbar.

Öffentliche Subnetze erweitern das Cluster-Deployment für Achsenknoten und Utilityknoten, die intern verwendete Services ausführen (wie Cloudera Manager oder Ambari). Dies ist ganz optional. Sie können FastConnect VPN nutzen und das gesamte Deployment als Erweiterung Ihrer On-Premise-Netzwerktopologie ausführen. Dies erfordert nur ein kundenroutbares privates IP-Segment, das auf VCN-Ebene verknüpft ist und dann in entsprechende Subnetze in Oracle Cloud Infrastructure aufgeteilt wird. Der Zugriff wird über Sicherheitslisten gesteuert, die auf Subnetzebene angewendet werden. Als Best Practice sollten Ressourcen, die ähnliche Zugriffsanforderungen haben, in denselben Subnetzen gruppiert werden.

Subnetz-Topologie

VCN deckt einen einzelnen, zusammenhängenden IPv4 CIDR-Block Ihrer Wahl ab. In VCN können einzelne IPv4-Subnetze für Clusterhosts bereitgestellt werden. Der Zugriff auf jedes Subnetz wird durch Sicherheitslisten gesteuert. Zusätzliche Sicherheit wird auf Host-Ebene durch Firewalls kontrolliert.

Als Best Practice wird empfohlen, Hadoop-Clusterressourcen in ein privates Subnetz zu trennen, auf das nicht direkt über das Internet zugegriffen werden kann. Der Zugriff auf das Cluster muss über zusätzliche Hosts in öffentlichen Subnetzen gesteuert und mit den entsprechenden Sicherheitslistenregeln gesichert werden, um den Datenverkehr zwischen öffentlichen und privaten Netzwerksegmenten zu bestimmen. Dieses Modell bietet die beste Sicherheit für Ihr Hadoop-Cluster.

Öffentliche Subnetze können für Achsenknoten (Benutzerzugriff) und Services verwendet werden, die eine UI oder API (wie Cloudera Manager oder Ambari) für den externen Zugriff zur Verfügung stellen müssen.
Private Subnetze müssen für Clusterhosts (Master, Worker) verwendet werden und können nicht direkt über das Internet aufgerufen werden. Stattdessen benötigen diese einen Zwischenhost in einem öffentlichen Subnetz für den Zugriff, einen Load Balancer oder direkten Zugriff durch VPN, FastConnect oder SSH-Proxy.

Sicherheitslisten

Sicherheitslisten kontrollieren den Ingress- und Egress-Traffic auf Subnetzebene. Für Hadoop sollten Sie vollen uneingeschränkten bidirektionalen Zugriff zwischen Subnetzen mit Clusterhosts für TCP- und UDP-Verkehr haben. Für öffentliche Subnetze müssen sehr restriktive Sicherheitslisten vorhanden sein, damit nur vertrauenswürdige Ports (und sogar Quell-IP-Adressen) auf APIs und Benutzeroberflächen zugreifen können.

High Availability

Hadoop verfügt über integrierte Methoden für High Availability (HA). Diese werden hier nicht behandelt. Als Nächstes folgen die Best Practices, mit denen Oracle Cloud Infrastructure für Hadoop verwendet wird, um HA zu erreichen.

Regionsauswahl

Jede Region in Oracle Cloud Infrastructure besteht aus einer bis drei Availability-Domains. Jede Availability-Domain besteht auch aus drei Faultdomains. Wählen Sie einen Home-Bereich, der nahe bei Ihnen liegt, und Ihre Unternehmensressourcen (wie Ihr Data Center). Die Zusammensetzung des ausgewählten Bereichs bestimmt, ob Sie ein Deployment mit einer Einzelverfügbarkeits-Domain oder ein Deployment mit mehreren Optionen verwenden können.

Deployment einer Single-Availability-Domain

Oracle empfiehlt ein Single-availability-domain-Deployment für Hadoop-Deployments in Oracle Cloud Infrastructure. Bei MapR-Deployments ist diese Architektur die einzige unterstützte Architektur. Dieses Deployment-Modell ist der wichtigste Nutzen aus einer Netzwerkperspektive, weil ein clusterübergreifender Datenverkehr in lokalen Netzwerksegmenten enthalten ist, die geringe Latenz und einen hohen Durchsatz aufrecht erhalten. Ressourcen in der Availability-Domain werden zwischen Faultdomains verteilt, um HA der physischen Infrastruktur zu erreichen.

Eine Faultdomain ist eine Gruppierung von Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain enthält drei Faultdomains. Mit Faultdomains können Sie Ihre Instanzen verteilen, sodass sie nicht in derselben physischen Hardware innerhalb einer einzelnen Availability-Domain enthalten sind. Ein Hardwarefehler oder Berechnen der Hardwarewartung, die sich auf eine Faultdomain auswirkt, wirkt sich nicht auf Instanzen in anderen Faultdomains aus.

Deployment mit mehreren Funktionen

Multiple-availability-domain Deployments (Availability-Domain spanning) werden nur von Cloudera und Hortonworks unterstützt, sie sind aber auch mit Apache Hadoop möglich.

Beachten Sie jedoch die folgenden Hinweise zu Availability-Domains:

Intraclusterkonnektivität besteht aus WAN-Segmenten, wodurch die Latenz erhöht und der optimale Durchsatz verringert wird. Dies hat messbare Auswirkungen auf die Performance, insbesondere auf Bare-Metal-Worker-Knoten. Für kleinere VM-Mitarbeiterknoten ist die Performanceauswirkung weniger bemerkbar.
Dieses Modell wird nicht von allen Oracle Cloud Infrastructure-Regionen unterstützt.

Das folgende Diagramm zeigt die gemessenen Performanceauswirkungen bei der Verwendung von 10-TB TeraSort in einer einzelnen Availability-Domain im Vergleich zur Verfügbarkeit der Domain über ein Cluster, das aus fünf Worker-Knoten und drei Master-Knoten besteht:

Beschreibung von comparison-availability-domain-spanning.png folgt

Beschreibung der Abbildung comparison-availability-domain-spanning.png

Die Availability-Domain spanning bietet zusätzliche Redundanz von Clusterservices in einer einzelnen Region. Clusterressourcen können auch Faultdomains in jeder Availability-Domain für eine zusätzliche logische “Rack-Topologie” nutzen. Jede Faultdomain wird als "Rack” für Rack-Freutungen betrachtet. Diese Vorteile werden durch das folgende Diagramm dargestellt.

Beschreibung von Architect - ultiple-availability-domains.png folgt

Beschreibung der Abbildung Architect - ultiple-availability-domains.png

Disaster Recovery

Disaster Recovery (DR) in Oracle Cloud Infrastructure hängt direkt von den Anforderungen des Recovery Point Objective (RPO) und des Recovery Time Objective (RTO) ab.

Wenn der RPO oder RTO nahezu in Echtzeit liegt, können Sie nur ein DR-Cluster in einer anderen Availability-Domain oder Region erstellen und dann Daten zwischen dem Produktions- und dem DR-Cluster replizieren. Wenn die Anforderungen für RPO und RTO flexibler sind, wird empfohlen, Object Storage als Backupziel für HDFS- und Clustermetadaten zu verwenden. Planen Sie den Kopiervorgang so oft wie erforderlich, um Ihr RPO-Ziel zu erfüllen, und pushen Sie Daten mit einem Tool wie DistCp (verteilte Kopie) in Object Storage. Sie können Datenbanken (Oracle, MySQL) auch in Object Storage-Buckets sichern oder zusätzliche Datenbankinstanzen in anderen Availability-Domains oder Regionen replizieren.

Wenn Ihre DR-Anforderungen Geodundanz für Daten angeben, die eine einzelne Region nicht bereitstellen kann, können Sie auch Daten in Object Storage zwischen Regionen kopieren. Wenn ein Disaster auftritt, sollten Sie Terraform verwenden, um Ressourcen schnell in einer anderen Availability-Domain bereitzustellen (entweder in derselben Region oder in einer anderen Region) und das DR-Cluster aus Daten in Object Storage neu zu entfernen.

Kostenmanagement

Genau wie im Rest dieser Lösung gibt es mehrere Möglichkeiten, die Compute- und Speicheranforderungen zu “rechte Größe”, um Ihre Infrastrukturkosten zu reduzieren. Oracle Cloud Infrastructure bietet zusätzliche Tools, mit denen Sie die mit einem Hadoop-Deployment verknüpften Kosten verwalten können:

Sie können das Tagging für Ihre Deployments nutzen, um die Nutzung einfacher zu verfolgen.
Sie können Quoten auf Compartment-Ebene festlegen, um den Verbrauch durch verschiedene Geschäftsbereiche zu begrenzen. Sie sollten mehrere Compartments zur Verwaltung von Produktions-, QA- und Entwicklungsumgebungen verwenden und die Quotas nach Bedarf einschränken.

Wenn Sie die dynamische Art von Cloud nutzen, ist dies für Umgebungen geeignet, die möglicherweise nicht persistent sein müssen. Wenn Sie Object Storage als Backup (oder Data lake) für Ihre Daten verwenden, können Sie einfach Umgebungen erstellen, wenn Sie diese mit Terraform benötigen, HDFS mit Daten aus Object Storage erneut entwickeln und die Umgebung löschen, wenn Sie sie nicht mehr benötigen.

VM-Umgebungen mit Block-Volumes können auch unterbrochen werden, um die Compute-Fakturierung anzuhalten, und nur für die Speicherbelegung.