Hadoop Rack Considerations - Dummies

Ein Kernprinzip von Hadoop besteht darin, mit zusätzlichen Slave-Knoten zu skalieren, um die steigenden Anforderungen bei Datenspeicherung und -verarbeitung zu erfüllen. In einem Scale-Out-Modell müssen Sie das Cluster-Design sorgfältig berücksichtigen, da Dutzende und sogar Hunderte von Slave-Knoten letztendlich gestapelt, mit Strom versorgt, vernetzt und gekühlt werden müssen.

Serverformfaktoren

Eine der ersten Entscheidungen, mit denen IT-Architekten beim Entwerfen eines Hadoop-Clusters konfrontiert werden, ist die Verwendung der folgenden beiden Formfaktoren für Hadoop-Knoten:

• Blade-Server: Für maximale Dichte konzipiert, können Sie so viele dieser Babys wie möglich in ein Rack stecken. Blade-Server passen in Blade-Gehäuse, die viele Standard-Server-Komponenten wie dedizierten Speicher, Netzwerk, Strom und Kühlung haben. Diese Komponenten werden von den Blade-Servern gemeinsam genutzt, was bedeutet, dass jeder einzelne Blade-Server viel kleiner sein kann.

  Blade-Server sind an der Oberfläche eine attraktive Wahl, da Sie ein Standard-Rack verwenden und zwischen 40 und 50 dieser Blade-Server bereitstellen können. Das Problem bei der Verwendung von Blades für Hadoop-Bereitstellungen besteht darin, dass sie sich auf bestimmte gemeinsam genutzte Komponenten stützen, was nicht mit der Shared-Nothing-Architektur von Hadoop übereinstimmt, in der jeder der Slave-Knoten eigenständig ist und über eigene dedizierte Ressourcen verfügt.

  Noch wichtiger ist, dass die Blätter nur wenig Platz für die lokale Aufbewahrung bieten und oft nicht mehr als zwei oder drei Laufwerksschächte haben. Dies ist ein Nicht-Starter für Hadoop, da Slave-Knoten viel mehr dedizierte Speicherkapazität benötigen.

• Rack-Server: Komplette Server ohne gemeinsame Komponenten und Platz für die Hardwareerweiterung. Rack-Server sind die richtige Wahl für Hadoop, da sie sehr gut in sich abgeschlossen sind. Ein Rack-Server, der als Hadoop-Slave-Knoten konfiguriert ist, belegt in der Regel zwei RUs, sodass Sie 20 davon in ein Standard-Rack einbauen können.

Cost of Ownership

Bei der Auswahl und dem Design eines Slave-Knotens sind Ihre wichtigsten Überlegungen in der Regel die anfänglichen Beschaffungskosten und das Speichervolumen. Die Betriebskosten sind jedoch ebenfalls wichtig. Es ist jedoch ein feiner Balanceakt, da Entscheidungen, die sich auf Beschaffungskosten, Stromverbrauch, Kühlung, Hardwareleistung und Dichte auswirken, häufig in Opposition stehen. Um Ihnen eine gute Wahl zu ermöglichen, folgen Sie hier einem (ganz bestimmten) Ratschlag:

• Reservieren Sie redundante Stromversorgungen für die Master-Knoten. Wenn redundante Stromversorgungen für Slave-Knoten vorhanden sind, ist dies ein Overkill - ein Stromversorgungsfehler in einem Slave-Knoten würde den Cluster nicht stark beeinträchtigen.Wenn jedoch redundante Stromversorgungen an allen Slave-Knoten vorhanden sind, würde dies den Energieverbrauch erhöhen und mehr Wärme erzeugen.

• Wählen Sie mittlere Taktraten für Slave Knoten-CPUs. CPUs mit höheren Taktraten kosten nicht nur mehr, sondern verbrauchen auch mehr Strom und erzeugen deutlich mehr Wärme.

• Wählen Sie Rack-Server aus, die für Hadoop entwickelt wurden. Mit der steigenden Beliebtheit von Hadoop bieten jetzt alle großen Hardware-Anbieter Rack-Server an, die ideale Slave-Knoten sind, mit 12 bis 20 Laufwerkseinschüben für lokal angeschlossenen Speicher.

  Rack-Server, die als Hadoop-Slave-Knoten arbeiten, sind in der Regel zu groß, um in einen Formfaktor von einer RU zu passen. Werden jedoch zwei RUs belegt, kann dies zu verschwendetem Speicherplatz führen. Für die effizientere Nutzung von Speicherplatz haben bestimmte Hardware-Hersteller Rack-Server freigegeben, die mehrere Slave-Knoten in einem einzigen Gehäuse unterbringen.

  Beispielsweise kann ein Standard-Rack in dieser komprimierten Form bis zu 27 Slave-Knoten haben (sogar mit Netzwerk-Switches), wobei jeder Slave-Knoten Platz für 15 Festplattenlaufwerke für HDFS hat. Das Ergebnis dieser Anordnung ist eine viel höhere Dichte und eine bessere Raumnutzung im Rechenzentrum.