Architektur von modernen Datenplattformen

Kapitel 4. Networking

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

In diesem Kapitel geht es darum, wie Clusterdienste wie Spark und Hadoop das Netzwerk nutzen und wie diese Nutzung die Netzwerkarchitektur und -integration beeinflusst. Wir gehen auch auf Implementierungsdetails ein, die für Netzwerkarchitekten und Clusterentwickler relevant sind.

Dienste wie Hadoop sind verteilt, was bedeutet, dass die Vernetzung ein grundlegender und entscheidender Teil der gesamten Systemarchitektur ist. Die Vernetzung wirkt sich nicht nur darauf aus, wie auf einen Cluster von außen zugegriffen wird, sondern hat auch direkte Auswirkungen auf die Leistung, Skalierbarkeit, Sicherheit und Verfügbarkeit eines Clusters und der von ihm angebotenen Dienste.

Wie Dienste ein Netzwerk nutzen

Eine moderne Datenplattform besteht aus einer Reihe von vernetzten Diensten, die selektiv kombiniert werden, um Geschäftsprobleme zu lösen. Jeder Dienst bietet eine einzigartige Fähigkeit, aber im Grunde genommen basieren sie alle auf einem gemeinsamen Satz von Netzwerknutzungsfällen.

Remote Procedure Calls (RPCs)

Einer der häufigsten Anwendungsfälle im Netzwerk ist, wenn Kunden einen entfernten Dienst auffordern, eine Aktion auszuführen. Diese Mechanismen, die als Remote Procedure Calls (RPCs) bekannt sind, bilden eine grundlegende Arbeitseinheit in einem Netzwerk und ermöglichen viele übergeordnete Anwendungsfälle wie Überwachung, Konsens und Datenübertragung.

Alle Plattformdienste sind verteilt und bieten daher per Definition in der einen oder anderen Form RPC-Funktionen. Wie nicht anders zu erwarten, spiegelt die Vielfalt der verfügbaren Remote-Aufrufe die Vielfalt der Dienste selbst wider - RPCs zu einigen Diensten dauern nur Millisekunden und betreffen nur einen einzigen Datensatz, während Aufrufe zu anderen Diensten komplexe Multiserver-Aufträge auslösen, die Petabytes an Informationen bewegen und verarbeiten.

Implementierungen und Architekturen

Die Definition eines RPCs ist weit gefasst und gilt für viele verschiedene Sprachen und Bibliotheken - selbst eine einfache HTTP-Übertragung kann als RPC gelten.

Datenplattform-Dienste sind eine lose zusammenhängende Sammlung von Open-Source-Projekten, die von verschiedenen Autoren geschrieben wurden. Das bedeutet, dass es nur sehr wenig Standardisierung zwischen ihnen gibt, auch bei der Wahl der RPC-Technologie. Einige Dienste verwenden Industriestandardansätze wie REST, andere nutzen Open-Source-Frameworks wie Apache Thrift. Andere, wie Apache Kudu, stellen eigene RPC-Frameworks zur Verfügung, um die gesamte Anwendung von Anfang bis Ende besser kontrollieren zu können.

Die Dienste unterscheiden sich auch stark in ihrer zugrunde liegenden Architektur. Apache Oozie zum Beispiel bietet ein einfaches Client-Server-Modell für das Einreichen und Überwachen von Workflows - Oozie interagiert dann in deinem Namen mit anderen Diensten. Im Gegensatz dazu kombiniert Apache Impala Client-Server-Interaktionen über JDBC mit hochgradig gleichzeitigen Server-Server-Interaktionen, indem es Daten aus HDFS und Kudu liest und Tupel-Daten zwischen Impala-Daemons sendet, um eine verteilte Abfrage auszuführen.

Plattformdienste und ihre RPCs

Tabelle 4-1 zeigt Beispiele für RPCs in den verschiedenen Diensten.

Tabelle 4-1. Dienste und wie sie RPCs verwenden

Service	Client-Server-Interaktionen	Server-zu-Server-Interaktionen
ZooKeeper	Erstellung, Änderung und Löschung von Z-Knoten	Anführerwahl, staatliche Replikation
HDFS	Erstellung, Änderung und Löschung von Dateien und Verzeichnissen	Liveness Reporting, Block Management und Replikation
YARN	Antragstellung und Überwachung, Anträge auf Ressourcenzuteilung	Container-Statusberichte
Bienenstock	Änderungen an Metastore-Metadaten, Abfrageübermittlung über JDBC	Interaktionen mit YARN und Backing RDBMS
Impala	Übermittlung von Abfragen über JDBC	Tupel-Datenaustausch
Kudu	Erstellung, Änderung und Löschung von Zeilen; prädikatsbasierte Suchabfragen	Konsensbasierte Datenreplikation
HBase	Anlegen, Ändern und Löschen von Zellen; Scans und Abrufen von Zellen	Liveness Reporting
Kafka	Veröffentlichung und Abruf von Nachrichten, Abruf von Offsets und Commits	Datenreplikation
Oozie	Workflow-Übermittlung und -Kontrolle	Interaktionen mit anderen Diensten, wie HDFS oder YARN, sowie mit dem RDBMS

Prozesskontrolle

Einige Dienste bieten RPC-Funktionen, mit denen Remote-Prozesse gestartet und gestoppt werden können. Im Fall von YARN werden von den Nutzern eingereichte Anwendungen instanziiert, um verschiedene Workloads wie maschinelles Lernen, Stream Processing oder Batch ETL auszuführen, wobei jede eingereichte Anwendung eigene Prozesse erzeugt.

Verwaltungssoftware wie der Cloudera Manager oder Apache Ambari verwendet ebenfalls RPCs, um Hadoop-Dienste zu installieren, zu konfigurieren und zu verwalten und sie bei Bedarf zu starten und zu stoppen.

Latenz

Jeder Aufruf einer Remote-Prozedur durchläuft denselben langwierigen Prozess: Der Aufruf erzeugt ein Paket, das in einen Frame umgewandelt, gepuffert, an einen Remote-Switch gesendet, innerhalb des Switches erneut gepuffert, an den Zielhost übertragen, innerhalb des Hosts erneut gepuffert, in ein Paket umgewandelt und schließlich an die Zielanwendung übergeben wird.

Die Zeit, die ein RPC braucht, um an sein Ziel zu gelangen, kann beträchtlich sein und liegt oft bei einer Millisekunde. Bei Remote-Aufrufen muss oft eine Antwort an den Client zurückgeschickt werden, was den Abschluss der Interaktion weiter verzögert. Wenn ein Switch stark belastet ist und seine internen Puffer voll sind, kann es sein, dass er einige Frames ganz verwerfen muss, was eine erneute Übertragung verursacht. In diesem Fall kann ein Anruf deutlich länger dauern als gewöhnlich.

Latenz und Clusterdienste

Die Clusterdienste unterscheiden sich darin, inwieweit sie Latenzzeiten tolerieren können. Während HDFS beispielsweise hohe Latenzzeiten beim Senden von Blöcken an Clients tolerieren kann, sind die Interaktionen zwischen dem NameNode und den JournalNodes (die Änderungen im HDFS zuverlässig in einem Quorum-basierten, vorausschauenden Protokoll speichern) empfindlicher. Die Leistung der HDFS-Metadatenoperationen wird dadurch begrenzt, wie schnell die JournalNodes Änderungen speichern können.

ZooKeeper ist besonders empfindlich gegenüber Netzwerklatenz. Er verfolgt, welche Clients aktiv sind, indem er auf Heartbeats - regelmäßigeRPC-Aufrufe - hört. Wenn diese Anrufe verzögert werden oder verloren gehen, geht ZooKeeper davon aus, dass der Client fehlgeschlagen ist, und ergreift entsprechende Maßnahmen, wie z. B. das Beenden von Sitzungen. Wenn du die Timeouts erhöhst, werden die Anwendungen widerstandsfähiger gegen gelegentliche Ausfälle, aber der Nachteil ist, dass es länger dauert, einen fehlgeschlagenen Client zu erkennen.

Auch wenn die Latenzzeit des ZooKeeper-Clients durch eine Reihe von Faktoren wie Speicherbereinigung oder ein langsames Festplattensubsystem verursacht werden kann, kann ein schlecht funktionierendes Netzwerk dennoch zu Sitzungsabbrüchen führen, was zu Unzuverlässigkeit und schlechter Leistung führt.

Datenübertragungen

Datenübertragungen sind ein grundlegender Vorgang in jeder Datenverwaltungsplattform, aber die verteilte Natur von Diensten wie Hadoop bedeutet, dass fast jede Übertragung das Netzwerk einbezieht, unabhängig davon, ob sie für die Speicherung oder die Verarbeitung bestimmt ist.

Wenn ein Cluster wächst, steigt auch die benötigte Netzwerkbandbreite - leicht auf Hunderte von Gigabyte pro Sekunde und mehr. Ein Großteil dieser Bandbreite wird innerhalb des Clusters genutzt, indem die Serverknoten untereinander kommunizieren, anstatt mit externen Systemen und Clients zu kommunizieren - das sogenannte Ost-West-Verkehrsmuster.

Datenübertragungen werden meist mit einigen wenigen Anwendungsfällen in Verbindung gebracht: Ingest und Query, Datenreplikation und Daten-Shuffling.

Replikation

Die Replikation ist eine gängige Strategie, um die Verfügbarkeit und Zuverlässigkeit verteilter Systeme zu erhöhen - wenn ein Server fehlschlägt, stehen andere zur Verfügung, um die Anfrage zu bearbeiten. Bei Systemen, in denen alle Replikate zum Lesen verfügbar sind, kann die Replikation auch die Leistung erhöhen, indem die Clients das nächstgelegene Replikat lesen. Wenn viele Workloads ein bestimmtes Datenelement gleichzeitig benötigen, kann die Möglichkeit, mehrere Replikate zu lesen, die Parallelität erhöhen.

Schauen wir uns an, wie die Replikation in HDFS, Kafka und Kudu gehandhabt wird:

HDFS

HDFS repliziert Daten, indem es Dateien an 128 MB-Grenzen aufteilt und die daraus resultierenden Blöcke repliziert, anstatt Dateien zu replizieren. Dies hat den Vorteil, dass große Dateien unter bestimmten Umständen parallel gelesen werden können, z. B. bei der erneuten Replikation von Daten. Wenn HDFS für Rack Awareness konfiguriert ist, stellt es sicher, dass die Blöcke über mehrere Racks verteilt werden und die Datenverfügbarkeit auch dann erhalten bleibt, wenn ein ganzes Rack oder ein Switch fehlschlägt.

Blöcke werden sowohl beim ersten Schreiben der Datei als auch während des laufenden Clusterbetriebs repliziert. HDFS stellt die Datenintegrität sicher, indem beschädigte oder fehlende Blöcke repliziert werden. Blöcke werden auch während des Rebalancings repliziert, sodass Server, die einem bestehenden HDFS-Cluster hinzugefügt werden, sofort an der Datenverwaltung teilnehmen können, indem sie einen Teil des bestehenden Datenbestands übernehmen.

Beim ersten Schreiben einer Datei sendet der Kunde nur eine Kopie. Die Datenknoten bilden eine Pipeline, die den neu erstellten Block entlang der Kette sendet, bis er erfolgreich geschrieben wurde.

Obwohl die Replikationsanforderungen einer einzelnen Datei bescheiden sind, kann die Gesamtarbeitslast, die eine verteilte Anwendung auf HDFS ausübt, immens sein. Anwendungen wie Spark und MapReduce können leicht Tausende von gleichzeitigen Aufgaben ausführen, von denen jede gleichzeitig aus dem HDFS liest oder in das HDFS schreibt. Obwohl diese Anwendungsframeworks versuchen, Lesevorgänge im HDFS so weit wie möglich zu minimieren, müssen Schreibvorgänge fast immer repliziert werden.

Kafka

Der Replikationspfad, den die Nachrichten in Kafka nehmen, ist relativ statisch, anders als in HDFS, wo der Pfad für jeden Block anders ist. Die Daten fließen von den Produzenten zu den Leadern, aber von dort werden sie von allen Followern unabhängig voneinander gelesen - eine Fan-Out-Architektur und keine Pipeline. Kafka-Topics haben einen festen Replikationsfaktor, der bei der Erstellung des Topics festgelegt wird, anders als in HDFS, wo jede Datei einen anderen Replikationsfaktor haben kann. Wie nicht anders zu erwarten, repliziert Kafka Nachrichten beim Ingest.

Nachrichten an Kafka können auch in Bezug auf ihre Haltbarkeit variieren. Produzenten können Nachrichten asynchron per Fire-and-Forget senden oder synchron schreiben und auf eine Bestätigung warten, wobei sie Leistung gegen Haltbarkeit tauschen. Der Produzent kann auch wählen, ob die Bestätigung nur für den Leader oder für alle Replikate gilt, die gerade synchronisiert sind.

Die Replikation findet auch statt, wenn ein neuer Broker gebootet wird oder wenn ein bestehender Broker wieder online geht und die neuesten Nachrichten einholt. Anders als bei HDFS wird die Partition eines Brokers, der offline geht, nicht automatisch auf einen anderen Broker repliziert, sondern dies kann manuell erfolgen.

Kudu

Ein Kudu-Cluster speichert Tabellen im relationalen Stil, die jedem Datenbankentwickler vertraut sind. Durch die Verwendung von Primärschlüsseln ermöglicht er den Zugriff auf einzelne Zeilen mit niedriger Latenz im Millisekundenbereich und speichert gleichzeitig Datensätze in einem spaltenförmigen Speicherformat, was tiefe analytische Scans effizient macht.

Anstatt Daten direkt zu replizieren, repliziert Kudu Datenänderungsoperationen wie Einfügungen und Löschungen. Es verwendet den Raft-Konsensalgorithmus, um sicherzustellen, dass Datenoperationen zuverlässig auf mindestens zwei Servern in Write-Ahead-Logs gespeichert werden, bevor eine Antwort an den Kunden zurückgegeben wird.

Shuffles

Die Datenanalyse lebt von Vergleichen. Egal, ob du die Finanzergebnisse des laufenden Jahres mit denen des Vorjahres vergleichst oder die Gesundheitswerte eines Neugeborenen mit den erwarteten Normen vergleichst, Vergleiche sind allgegenwärtig. Auch Datenverarbeitungsvorgänge wie Aggregationen und Joins nutzen Vergleiche, um übereinstimmende Datensätze zu finden.

Um Datensätze vergleichen zu können, müssen sie zunächst im Speicher eines einzelnen Prozesses zusammengefasst werden. Das bedeutet, dass das Netzwerk für die Datenübertragung als erster Schritt einer Verarbeitungspipeline genutzt wird. Frameworks wie Spark und MapReduce integrieren diese groß angelegten Datenaustauschphasen, die als Shuffles bezeichnet werden, bereits im Voraus und ermöglichen es den Nutzern, Anwendungen zu schreiben, die Terabytes an Informationen massiv parallel sortieren, gruppieren und zusammenführen.

Während eines Shuffles überträgt jeder teilnehmende Server gleichzeitig Daten an alle anderen, wodurch Shuffles die mit Abstand bandbreitenintensivste Netzwerkaktivität sind. Bei den meisten Einsätzen entscheidet der potenzielle Bandbreitenbedarf von Shuffles über die Eignung einer Netzwerkarchitektur.

Shuffles und das Netzwerk

Bei großen Arbeitslasten kann es durch Shuffles zu Datenübertragungen zwischen jedem Serverpaar in einem Cluster kommen. Da es nicht praktikabel ist, alle Server in einem vollständigen Netz miteinander zu verbinden, werden Netzwerk-Switches als Vermittler zwischen den Servern eingesetzt, wodurch die Anzahl der physischen Verbindungen erheblich reduziert wird.

In gewisser Weise moduliert das physische Netzwerk die idealen Shuffle-Transferströme, indem es die Konnektivität und die Bandbreite einschränkt. Diese Idee wird in den Abbildungen 4-1 und4-2 veranschaulicht, wo wir sehen, dass die logischen Ströme, die direkt zwischen den Servern bestehen, durch die verfügbare Konnektivität physisch eingeschränkt werden.

Abbildung 4-1. Logische und physische Shuffle-Flows

Wenn derselbe logische Cluster in einer anderen Netzwerkarchitektur eingesetzt wird, ergeben sich daraus unterschiedliche physische Flüsse. Abbildung 4-2 zeigt, wie sich das Hinzufügen eines zweiten Switches zu unserem vorherigen Beispiel auswirkt.

Obwohl diese Architektur mehr Switches enthält, schneidet sie deutlich schlechter ab als die Single-Switch-Architektur. Im Durchschnitt müssen 50 % des gesamten Netzwerkverkehrs zwischen den Switches übertragen werden, was zu Staus auf der Verbindung zwischen den Switches führt.

Abbildung 4-2. Flows über zwei miteinander verbundene Switches

Überwachung

Unternehmenstaugliche Systeme erfordern Anwendungsfälle wie die Durchsetzung der Sicherheit durch Audits und Aktivitätsüberwachung, die Sicherstellung der Systemverfügbarkeit und -leistung durch proaktive Gesundheitsprüfungen und Metriken sowie die Ermöglichung von Ferndiagnosen durch Protokollierung und Telefonfunktionen.

Alle diese Anwendungsfälle fallen unter den Begriff der Überwachung und erfordern alle das Netzwerk. Es gibt auch Überschneidungen zwischen ihnen. Zum Beispiel können Protokolle zur Aktivitätsüberwachung sowohl für die Gewährleistung der Sicherheit durch Audits als auch für die historische Analyse der Auftragsleistung verwendet werden - beides ist nur eine andere Perspektive auf dieselben Daten. Überwachungsinformationen in einem Hadoop-Cluster werden in Form von Audit-Ereignissen, Metriken, Protokollen und Alarmen erfasst.

Backup

Zur Gewährleistung der allgemeinen Systemstabilität in einem unternehmensgerechten System gehört auch, dass die Systeme im Falle eines katastrophalen Ausfalls wieder online gebracht und wiederhergestellt werden können. Wie in Kapitel 13 gezeigt wird, sind diese traditionellen Unternehmensbelange für moderne Datenarchitekturen immer noch von großer Bedeutung. In den meisten IT-Umgebungen wird die Datensicherung über das Netzwerk durchgeführt, da dies einfacher und effizienter ist als der physische Besuch von entfernten Standorten.

Für eine moderne Cluster-Architektur, die Hunderte von Servern umfasst, ist diese Nutzung des Netzwerks für Backups unerlässlich. Der daraus resultierende Netzwerkverkehr kann beträchtlich sein, aber nicht alle Server müssen vollständig gesichert werden. Gespeicherte Daten werden oft bereits repliziert, und die Build-Automatisierung kann die erforderliche Systemsoftware häufig neu installieren. Achte in jedem Fall darauf, dass die Backup-Prozesse den Cluster-Betrieb nicht beeinträchtigen, weder auf Netzwerkebene noch anderweitig.

Konsens

Stell dir einen Client vor, der einen RPC ausführt, aber keine Antwort erhält. Ohne weitere Informationen ist es unmöglich zu wissen, ob die Anfrage erfolgreich empfangen wurde. Wenn die Anfrage wichtig genug war, um den Zustand des Zielsystems zu verändern, wissen wir nicht, ob das System tatsächlich verändert wurde.

Leider ist das nicht nur ein akademisches Problem. Die Realität sieht so aus, dass kein Netzwerk oder System jemals völlig zuverlässig sein kann. Pakete gehen verloren, Stromversorgungen schlagen fehl, Plattenköpfe stürzen ab. Ein System so zu entwickeln, dass es mit diesen Ausfällen umgehen kann, bedeutet zu verstehen, dass Ausfälle keine außergewöhnlichen Ereignisse sind, und dementsprechend Software zu schreiben, die diese Ausfälle berücksichtigt und ausgleicht.

Eine Möglichkeit, die Zuverlässigkeit bei Ausfällen zu erhöhen, ist der Einsatz mehrerer Prozesse, die einzelne Ausfallpunkte (Single Points of Failure, SPOFs) ersetzen. Dies setzt jedoch voraus, dass die Prozesse zusammenarbeiten und Informationen über ihren eigenen Zustand austauschen, um sich über den Zustand des Systems als Ganzes zu einigen. Wenn sich die Mehrheit der Prozesse über diesen Zustand einig ist, spricht man von einem Quorum, das die zukünftige Entwicklung des Systemzustands kontrolliert.

Der Konsens wird in vielen Clusterdiensten verwendet, um Korrektheit zu erreichen:

• HDFS verwendet ein Quorum-basiertes Mehrheitswahlsystem, um Dateisystemänderungen zuverlässig auf drei verschiedenen JournalNodes zu speichern, die idealerweise über mehrere Racks in unabhängigen Ausfalldomänen verteilt sind.

• ZooKeeper verwendet ein Quorum-basiertes Konsenssystem, um Funktionen wie Leaderwahl, verteiltes Sperren und Warteschlangenbildung für andere Clusterdienste und -prozesse, einschließlich HDFS, Hive und HBase, bereitzustellen.

• Kafka verwendet Konsens, wenn es darum geht, welche Nachrichten für einen Verbraucher sichtbar sein sollen. Wenn ein Leader Schreibvorgänge akzeptiert, aber die erforderliche Anzahl von Replikaten noch nicht synchronisiert ist, werden diese Nachrichten den Konsumenten vorenthalten, bis sie ausreichend repliziert sind.

• Kudu verwendet für die Replikation den Raft-Konsensalgorithmus, der sicherstellt, dass Einfügungen, Aktualisierungen und Löschungen auf mindestens zwei Knoten persistiert werden, bevor der Kunde eine Antwort erhält.

Netzwerkarchitekturen

Die Vernetzung bestimmt einige der wichtigsten architektonischen Eigenschaften eines verteilten Systems, darunter Zuverlässigkeit, Leistung und Sicherheit. In diesem Abschnitt beschreiben wir eine Reihe von Netzwerkdesigns, die sich für alle Arten von Systemen eignen, von der Einzelplatzinstallation bis zum Giganten mit Tausenden von Servern.

Kleine Cluster-Architekturen

Die erste Cluster-Netzwerkarchitektur, die wir in Betracht ziehen, ist die eines einzelnen Switches.

Einzelner Schalter

Obwohl fast zu einfach ist, um als Architektur zu gelten, ist der Ansatz dennoch für viele Anwendungsfälle geeignet. Abbildung 4-3 veranschaulicht die Architektur.

Abbildung 4-3. Eine Single-Switch-Architektur

Aus Sicht der Leistung stellt dieses Design nur wenige Herausforderungen dar. Fast alle modernen Switches sind non-blocking (d.h. alle Ports können bei voller Auslastung gleichzeitig genutzt werden), so dass der interne Datenverkehr von Shuffles und Replikation mühelos bewältigt werden sollte.

Obwohl diese Netzwerkarchitektur einfach und leistungsfähig ist, leidet sie unter einem Mangel an Skalierbarkeit - sobald ein Switch keine Ports mehr hat, kann ein Cluster nicht weiter wachsen. Da die Switch-Ports häufig sowohl für die Upstream-Verbindung als auch für lokale Server genutzt werden, kann das Wachstum kleiner Cluster mit hohen Ingest-Anforderungen weiter eingeschränkt werden.

Ein weiterer Nachteil dieser Architektur ist, dass der Switch ein SPOF ist - wenn er fehlschlägt, fällt der Cluster gleich mit. Nicht alle Cluster müssen immer verfügbar sein, aber für die, die es sind, besteht die einzige Lösung darin, ein ausfallsicheres Netzwerk mit mehreren Switches aufzubauen.

Cluster-Netzwerke widerstandsfähig machen

Mehrere physische Verbindungen können mit dem Link Aggregation Control Protocol (LACP) zu einer einzigen logischen Verbindung zusammengeschlossen werden, aber das erhöht nur die Ausfallsicherheit einer Verbindung.Wenn der Switch selbst fehlschlägt, hilft auch eine ausfallsichere Verbindung nicht.

Um wirklich ausfallsicher zu sein, muss ein Server mit zwei Switches gleichzeitig verbunden sein. Wenn einer der beiden Switches fehlschlägt, versorgt der andere Switch weiterhin alle angeschlossenen Geräte. Anstatt sich mit mehreren unabhängigen Netzwerken zu verbinden, muss eine einzige logische Verbindung mehrere Switches überbrücken können.

MitMulti-Chassis Link Aggregation (MC-LAG) kann ein ausfallsicheres Netzwerk aufgebaut werden, indem der Top-of-Rack-Switch durch ein Switch-Paar ersetzt wird, das wie ein einziger logischer Switch funktioniert. Netzwerkgeräte verbinden sich mit beiden Switches über LACP und verhalten sich so, als wären sie mit einem einzigen Gerät verbunden.

Die Skalierbarkeit bleibt jedoch auf die Größe eines einzelnen Switches beschränkt, und auch die vorgelagerten Verbindungen müssen auf die gleiche Weise widerstandsfähig gemacht werden. Andernfalls könnte die externe Verbindung zu einem weiteren Single Point of Failure werden. Abbildung 4-4 zeigt die daraus resultierende Architektur.

Abbildung 4-4. Ein belastbarer Switch-Paar-Cluster

Eine Reihe von proprietären Technologien, darunter die unter "Network Fabrics" beschriebenen , bieten dieselbe Funktionalität und sind in Unternehmen weit verbreitet. MC-LAG und die meisten dieser Alternativen können entweder in einer aktiv-passiven oder aktiv-aktiven Konfiguration eingesetzt werden. Obwohl beide die Ausfallsicherheit verbessern, erhöht aktiv-aktiv auch die verfügbare Bandbreite (und damit die Clusterleistung).

In der Praxis setzen die meisten Unternehmen LACP im Failover-Modus (aktiv-passiv) ein, anstatt Round-Robin- oder Balance-Konfigurationen (aktiv-aktiv) zu verwenden, da die Aggregationsgruppen in der Regel für jedes Switch-Paar einzeln erstellt werden müssen, was einen erheblichen Verwaltungsaufwand bedeutet. Auch aus Sicht des Ressourcenmanagements ist dies sinnvoll, da ein einfaches Failover nicht zu einer Verringerung der verfügbaren Bandbreite für einen Server führt.

Umsetzung

Bei einer Single-Switch-Architektur gibt es aufgrund der inhärenten Einfachheit des Designs sehr wenig Auswahl bei der Implementierung. Der Switch hostet eine einzelne Layer-2-Broadcast-Domäne innerhalb eines physischen LANs oder eines einzelnen virtuellen LANs (VLAN), und alle Hosts befinden sich im selben Layer-3-Subnetz.

Mittlere Cluster-Architekturen

Für den Aufbau von Clustern, die sich über mehrere Racks erstrecken, empfehlen wir dringend die Architekturen , die unter "Große Cluster-Architekturen" beschrieben werden , da sie das höchste Maß an Skalierbarkeit und Leistung bieten. Da jedoch nicht alle Cluster so hohe Kapazitäten benötigen, können auch kleinere Cluster eine der in diesem Abschnitt beschriebenen alternativen Architekturen verwenden.

Netzwerk Überzeichnung

Immer wenn ein Clusternetzwerk mit mehreren Switches aufgebaut wird, besteht die Möglichkeit, dass auf eine Überbelegungstößt - einLeistungsengpass, der durch das physische Netzwerkdesign verursacht wird. Der Begriff stammt aus der Telefonie, wo in einer altmodischen Telefonzentrale mehr lokale Teilnehmer als Fernleitungen zur Verfügung stehen, was dazu führt, dass Fernverbindungen zu Stoßzeiten vorübergehend nicht verfügbar sind.

Netzwerk-Switches, die eine große Anzahl lokaler Geräte mit einer kleinen Anzahl von Remote-Switches verbinden, können ebenfalls überlastet werden, wenn die Uplink-Bandbreite nicht ausreicht. Die Nachfrage nach Bandbreite ist dann größer als die Kapazität, was zu Konflikten führt und die Datenübertragung verlangsamt.

Der Grad der Überzeichnung ist einfach das Verhältnis zwischen der Bandbreitennachfrage und der Kapazität. Ein Switch mit 24 x 1 Gb/s-Ports könnte zum Beispiel insgesamt 24 Gb/s nachfragen. Wenn diese Nachfrage ausschließlich für entfernte Systeme über einen Uplink von 4 Gbit/s besteht, ergibt sich eine Überzeichnung von 24:4, also 6:1.

Gestapelte Netzwerke

Einige Netzwerkhersteller bieten Switches an, die mit proprietären Kabeln mit hoher Bandbreite zusammengeschaltet werden können, so dass sie wie ein einziger Switch funktionieren. Dies ist eine kostengünstige und unkomplizierte Option, um über einen einzelnen Switch hinaus zu wachsen. Abbildung 4-5 zeigt ein Beispiel für ein gestapeltes Netzwerk.

Abbildung 4-5. Ein gestapeltes Netzwerk mit drei Switches

Obwohl stapelbare Switches ähnlich klingen wie ein hochverfügbares Switch-Paar (das auch als einzelner logischer Switch fungieren kann), sind sie in Wirklichkeit ganz anders. Stapelbare Switches nutzen ihre proprietären Interconnects, um große Mengen an Benutzerdaten zu übertragen, während ein hochverfügbares Switch-Paar (HA) die Interconnects nur zur Verwaltung des Switch-Status nutzt. Stacking ist auch nicht auf ein Switch-Paar beschränkt; viele Implementierungen können bis zu sieben Switches in einem einzigen Ring miteinander verbinden (wie wir noch sehen werden, hat dies jedoch große Auswirkungen auf die Überbelegung und beeinträchtigt die Netzwerkleistung erheblich).

Resilienz

Stapelbare Switches verbinden sich über eine bidirektionale Ringtopologie. Jeder Teilnehmer hat also immer zwei Verbindungen: im Uhrzeigersinn und gegen den Uhrzeigersinn. Das macht das System widerstandsfähig gegen den Ausfall von Ringverbindungen - wenn die Verbindung im Uhrzeigersinn fehlschlägt, kann der Verkehr stattdessen über die Verbindung gegen den Uhrzeigersinn fließen, auch wenn die Gesamtbandbreite des Netzwerks möglicherweise reduziert wird.

Wenn ein Switch im Ring ausfällt, funktionieren die anderen Switches weiter und übernehmen bei Bedarf die Führung des Rings (da ein Teilnehmer der Master ist). Alle Geräte, die nur mit einem einzigen Ring-Switch verbunden sind, verlieren den Netzwerkdienst.

Einige stapelbare Switches unterstützen Multi-Chassis Link Aggregation (siehe "Cluster-Netzwerke ausfallsicher machen" auf Seite 115). Dadurch können die Geräte auch dann noch Netzwerkdienste empfangen, wenn einer der Switches im Ring fehlschlägt, solange die Geräte mit einem Paar der Switches im Stack verbunden sind. Mit dieser Konfiguration lassen sich belastbare Stack-Netzwerke erstellen (siehe Abbildung 4-6 für ein Beispiel).

Abbildung 4-6. Ein belastbares gestapeltes Netzwerk aus drei Switches

Im Normalbetrieb bedeutet die bidirektionale Natur der Ringverbindungen, dass es zwei unabhängige Ringe gibt. Bei einem Ausfall einer Verbindung oder eines Switches erkennen die verbleibenden Switches den Ausfall und kappen die Enden, sodass eine hufeisenförmige, unidirektionale Schleife entsteht.

Leistung

Die Stacking-Verbindungen bieten eine sehr hohe Bandbreite zwischen den Switches, aber jeder Link bietet immer noch weniger Bandbreite als die Summe der Ports, was zwangsläufig zu einer Überbelegung des Netzwerks führt.

Bei nur zwei Switches in einem Ring gibt es zwei mögliche Wege zu einem Ziel-Switch - im und gegen den Uhrzeigersinn. In jeder Richtung ist der Ziel-Switch direkt verbunden. Bei drei Switches in einem Ring bedeutet die Topologie, dass es immer noch nur zwei mögliche Richtungen gibt, aber jetzt ist ein Ziel-Switch nur in einer Richtung direkt verbunden. In der anderen Richtung befindet sich ein Zwischenschalter zwischen der Quelle und dem Ziel.

Da der Datenverkehr zwischen den Switches übertragen werden muss, steigt die Überzeichnung, wenn wir dem Ring weitere Switches hinzufügen. Unter normalen Umständen hat jeder Switch im Ring die Wahl, den Datenverkehr im oder gegen den Uhrzeigersinn zu senden, was sich ebenfalls auf die Netzwerkleistung auswirken kann.

Bestimmung der Überzeichnung in gestapelten Netzwerken

Innerhalb eines gestapelten Netzwerks gibt es nun zwei potenzielle Pfade zwischen einem Quell- und einem Zielgerät, was die Bestimmung der Überzeichnung komplizierter macht, aber konzeptionell ist der Prozess unverändert.

In diesem ersten Szenario betrachten wir die Überzeichnung zwischen einem Paar gestapelter Switches, von denen jeder über 48 10 GbE-Ports und bidirektionale Stacking-Links mit 120 Gb/s verfügt (das Flussdiagramm ist in Abbildung 4-7 zu sehen). Jeder Switch ist über zwei Pfade direkt mit dem anderen verbunden, so dass sich eine Gesamtkapazität von 240 Gb/s für den ausgehenden Datenfluss ergibt. Da von den Ports potenziell 480 Gbit/s ankommen, ergibt sich ein Überbelegungsverhältnis von 480:240, also 2:1.

Abbildung 4-7. Netzwerkflüsse zwischen einem Paar gestapelter Switches

Mit drei Switches im Ring ist jeder Switch immer noch direkt mit jedem anderen verbunden, aber die abgehende Bandbreite von 240 Gbit/s wird nun zwischen den beiden Nachbarn geteilt. Abbildung 4-8 zeigt die Netzwerkflüsse, die auftreten, wenn wir davon ausgehen, dass der Verkehr perfekt ausgeglichen ist und die Switches perfekte Entscheidungen über die Pfadwahl treffen (und sicherstellen, dass kein Verkehr über einen dazwischenliegenden Switch gesendet wird). In diesem Szenario erhält jeder Nachbar 120 Gbit/s und die gesamte ausgehende Bandbreite beträgt 240 Gbit/s, sodass das Überbezugsverhältnis 2:1 beträgt.

Abbildung 4-8. Best-Case-Netzwerkflüsse zwischen drei gestapelten Switches

Wenn die Stacked Switches die schlechtestmögliche Pfadauswahl treffen würden (indem sie den gesamten Datenverkehr über den längeren Pfad senden, wie in Abbildung 4-9 gezeigt), würde die effektive Bandbreite reduziert, da jeder ausgehende Link nun zwei Flows statt einem übertragen würde. Durch die erhöhte Konkurrenzsituation würde die pro Datenfluss verfügbare Bandbreite auf nur 60 Gb/s sinken, wodurch das Überbelegungsverhältnis 480:120 oder 4:1 beträgt.

Abbildung 4-9. Worst-Case-Netzwerkflüsse zwischen drei gestapelten Switches

Auch wenn dies ein pathologisches Beispiel ist, zeigt es doch deutlich die Idee eines lastabhängigen Überbelegungsverhältnisses. Ein realer Stack mit drei Switches würde mit ziemlicher Sicherheit viel näher am besten als am schlechtesten Fall liegen, und selbst ein Überbelegungsverhältnis von 4:1 ist in jedem Fall ein vernünftiger Vorschlag für einen Hadoop-Cluster.

Mit nur zwei Switches im Stack war der Verkehr auf den Verbindungsstrecken immer direkt. Mit drei Switches ist der Verkehr immer noch größtenteils direkt, mit der Möglichkeit eines indirekten Verkehrs bei hoher Last.

Wenn der Ring vier oder mehr Switches hat, ist indirekter Verkehr selbst unter perfekten Bedingungen unvermeidlich. Je mehr Switches zu einem Stack hinzugefügt werden, desto mehr dominiert der indirekte Verkehr die Arbeitslast, sodass eine Überzeichnung zu problematisch wird. Alternative Architekturen sind dann besser geeignet.

Überlegungen zur Verkabelung von gestapelten Netzwerken

Die proprietären Stacking-Kabel, die für den Ring verwendet werden, sind sehr kurz - in der Regel nur einen Meter oder so - und wurden für das Stapeln von Switches im wahrsten Sinne des Wortes entwickelt. Es ist möglich, Stacking-Switches in benachbarten Racks zu platzieren, aber in der Regel ist es am besten, dies zu vermeiden, da nicht alle Racks den Durchgang von Kabeln zwischen ihnen erlauben.

Eine Möglichkeit, die Längenbeschränkung der Ringverkabelung zu umgehen, besteht darin, den gesamten Switch-Stack in einem einzigen Rack unterzubringen und längere Kabel zwischen den Switches und Servern zu verwenden. Dies hat jedoch den Nachteil, dass alle Switches an eine einzige Stromverteilungseinheit (PDU) angeschlossen werden und somit ein Single Point of Failure entsteht. Wenn du die Racks aus Platzgründen in verschiedenen Gängen aufstellen musst, ist Stacking nicht das Richtige für dich.

Umsetzung

Bei einer Stacked-Switch-Architektur gibt es zwei Implementierungsoptionen: ein Subnetz pro Switch oder ein einzelnes Subnetz für den gesamten Ring.

Der Einsatz eines Subnetzes pro Switch ist am besten geeignet, wenn die Server nur mit einem einzigen Switch verbunden sind. So bleibt der Broadcast-Verkehr auf jeden Switch im Ring beschränkt. In Szenarien, in denen Server über MC-LAG mit mehreren Stack-Switches verbunden sind, ist es sinnvoller, ein einzelnes Subnetz für den gesamten Ring einzurichten.

In beiden Szenarien ist ein physisches LAN oder ein einzelnes VLAN pro Subnetz angemessen.

Fat-Tree-Netzwerke

Netzwerke wie das Fat-Tree-Netzwerk werden durch aufgebaut, indem mehrere Switches in einer hierarchischen Struktur verbunden werden. Ein Single-Core-Switch verbindet sich über Schichten von Aggregations-Switches mit Access-Switches, die wiederum mit Servern verbunden sind.

Diese Architektur wird als Fat-Tree bezeichnet, weil die Links, die dem Core-Switch am nächsten sind, eine höhere Bandbreite haben und der Baum daher "dicker" wird, je näher man der Wurzel kommt. Abbildung 4-10 zeigt ein Beispiel für ein Fat-Tree-Netzwerk.

Abbildung 4-10. Die Fat-Tree-Netzwerkarchitektur

Da viele kleine Cluster mit einem einzigen Switch beginnen, kann ein Fat-Tree-Netzwerk als natürlicher Upgrade-Pfad betrachtet werden, wenn eine Netzwerkerweiterung in Betracht gezogen wird. Dupliziere einfach das ursprüngliche Single-Switch-Design, füge einen Core-Switch hinzu und verbinde alles miteinander.

Skalierbarkeit

Die Leistung eines Fat-Tree-Netzwerks lässt sich anhand des Grads der Überzeichnung des Netzwerks bestimmen. Betrachte das Beispiel in Abbildung 4-11.

Abbildung 4-11. Ein Beispiel für ein Fat-Tree-Netzwerk

Die Access-Switches haben jeweils 48 10-GbE-Ports, die mit den Servern verbunden sind, und 2 40-GbE-Ports, die mit dem Core-Switch verbunden sind. Daraus ergibt sich ein Überbelegungsverhältnis von 480:80, also 6:1, das deutlich höher ist als für Hadoop-Workloads empfohlen. Dies kann verbessert werden, indem entweder die Anzahl der Server pro Access-Switch reduziert oder die Bandbreite zwischen den Access-Switches und dem Core-Switch durch Link Aggregation erhöht wird.

Diese Architektur lässt sich durch Hinzufügen von Access Switches erweitern - jeder zusätzliche Switch erhöht die Gesamtzahl der Ports um 48. Dies kann wiederholt werden, bis die Port-Kapazität des Core-Switches erreicht ist. Dann kann eine größere Skalierung nur durch einen größeren Core-Switch oder eine andere Architektur erreicht werden.

Überzeichnung als schlimmster Fall

Abbildung 4-11 zeigt einen Zugangsswitch mit 480 Gb/s eingehend und 80 Gb/s ausgehend, wodurch das Überbelegungsverhältnis 6:1 beträgt. Mit anderen Worten: Wenn alle Server beschließen würden, Datenverkehr über den Uplink an nicht-lokale Ziele zu senden, könnte jeder nur etwa 1/6 seiner Kapazität senden - etwa 1,7 Gb/s.

Die Überzeichnung gilt nur für den Datenverkehr, der den Switch über Uplinks verlässt, nicht für den lokal gerouteten Datenverkehr. Während eines Shuffle überträgt jeder Server Daten an jeden anderen, aber das schließt auch lokale Server ein. Bei zwei Access Switches sendet ein Server im Durchschnitt etwa 50 % an lokale und 50 % an nicht-lokale Server, wenn man davon ausgeht, dass der Shuffle selbst gleichmäßig auf die Server verteilt ist. Das senkt die effektive Überzeichnung, da von der potenziellen Nachfrage von 480 Gb/s nur 240 Gb/s den Uplink benötigen. Wenn die 240 Gbit/s auf 80 Gbit/s reduziert werden, ergibt sich ein effektives Überbelegungsverhältnis von 240:80, also 3:1.

Wenn die Anzahl der Access Switches steigt, erhöht sich auch der Prozentsatz der entfernten Server, was die Auswirkungen der Überzeichnung verstärkt. Bei vier Access Switches sind 75 % der Server dezentral, was zu einem effektiven Überbelegungsgrad von 4,5:1 führt. Bei acht Access Switches sind 87,5 % der Server remote, was das effektive Verhältnis auf 5,25:1 erhöht. Wenn 100 % des Datenverkehrs für nicht-lokale Ziele bestimmt sind, beträgt das Überbuchungsverhältnis 6:1, wie ursprünglich berechnet.

Die am Zugangsswitch berechnete Überbelegungsquote stellt daher den schlimmstmöglichen Fall dar, bei dem davon ausgegangen wird, dass der gesamte Verkehr Upstream-Bandbreite benötigt.

Resilienz

Bei einer Implementierung ohne redundante Switches ist die Zuverlässigkeit dieser Architektur aufgrund der vielen SPOFs begrenzt. Der Ausfall eines Access-Switches würde einen großen Teil des Clusters betreffen, und der Ausfall des Core-Switches wäre katastrophal.

Das Entfernen der SPOFs durch Ersetzen einzelner Switches durch Switch-Paare verbessert die Ausfallsicherheit erheblich. Abbildung 4-12 zeigt ein Fat-Tree-Netzwerk, das mit Multichassis Link Aggregation aufgebaut wurde.

Abbildung 4-12. Ein widerstandsfähiges Fat-Tree-Netzwerk

Umsetzung

Ein hierarchisches Netzwerk kann entweder mit einem einzigen Subnetz für den gesamten Baum oder mit einem Subnetz pro Switch aufgebaut werden. Die erste Option ist am einfachsten zu implementieren, bedeutet aber, dass der Broadcast-Verkehr über Links jenseits der Zugangsebene läuft. Die zweite Option lässt sich besser skalieren, ist aber komplexer zu implementieren und erfordert, dass Netzwerkadministratoren das Routing verwalten - ein Prozess, der fehleranfällig sein kann.

Große Cluster-Architekturen

Alle bisher besprochenen Architekturen sind in Bezug auf Skalierung oder Skalierbarkeit begrenzt: Einzelne Switches haben schnell keine Ports mehr, gestapelte Netzwerke sind auf einige wenige Switches pro Stapel beschränkt und Fat-Tree-Netzwerke können nur so lange skaliert werden, wie der Core-Switch genügend Ports hat.

In diesem Abschnitt werden Netzwerkdesigns erörtert, die größere und/oder skalierbarere Cluster unterstützen können.

Modulare Schalter

Im Allgemeinen gibt es nur zwei Möglichkeiten, ein Netzwerk zu skalieren: durch größere Switches oder durch mehr Switches. Sowohl die Fat-Tree- als auch die Stacked-Netzwerkarchitekturen werden durch das Hinzufügen von Switches erweitert. Bevor es modulare Switches gab, bedeutete die vertikale Skalierung eines Switches einfach, ihn durch eine größere Variante mit einer höheren Portkapazität zu ersetzen - eine störende und kostspielige Option.

Mit modularen Switches wurde die Idee eines erweiterbaren Gehäuses eingeführt, das mit mehreren Switch-Modulen bestückt werden kann. Da ein modularer Switch auch dann funktioniert, wenn er nur teilweise mit Modulen bestückt ist, kann die Netzwerkkapazität durch den Einbau zusätzlicher Module erweitert werden, solange das Gehäuse Platz bietet.

In vielerlei Hinsicht kann man sich einen modularen Switch als eine vergrößerte Version eines einzelnen Switches vorstellen; daher kann er in einer Vielzahl von Architekturen eingesetzt werden. Ein modularer Switch eignet sich zum Beispiel gut als Core-Switch in einem Fat-Tree oder als zentraler Switch in einer Single-Switch-Architektur. Im letzteren Fall spricht man von einer End-of-Row-Architektur, da der modulare Switch buchstäblich am physischen Ende einer Rechenzentrumsreihe eingesetzt wird und mit den Servern der vielen Racks in der Reihe verbunden ist.

Modulare Switches, wie z. B. Cisco 7000, werden oft paarweise eingesetzt, um die Ausfallsicherheit der Architektur zu gewährleisten, in der sie verwendet werden.

Wirbelsäulennetzwerke

Für eine echte Skalierbarkeit auf Clusterebene ist eine Netzwerkarchitektur erforderlich, die über die Grenzen eines einzelnen Switches hinauswachsen kann - selbst wenn es sich um ein monströses modulares Ungetüm handelt.

Als wir uns die Architektur eines Fat-Tree-Netzwerks angeschaut haben, haben wir gesehen, dass die Skalierbarkeit letztendlich durch die Kapazität des Core-Switches an der Wurzel des Baums begrenzt ist. Solange die Überzeichnung an den Leaf- und Intermediate-Switches auf einem vernünftigen Niveau gehalten wird, können wir den Fat-Tree durch Hinzufügen weiterer Switches so lange ausbauen, bis der Core-Switch keine Kapazität mehr hat.

Diese Grenze kann durch die Vergrößerung des Core-Switches auf ein größeres Modell (oder das Hinzufügen eines Moduls zu einem modularen Switch) angehoben werden, aber Abbildung 4-13 zeigt einen interessanten alternativen Ansatz, nämlich einfach einen weiteren Root-Switch hinzuzufügen.

Abbildung 4-13. Ein Wirbelsäulen-Blatt-Netzwerk

Da es keinen einzigen Root-Switch gibt, handelt es sich nicht um ein hierarchisches Netzwerk. In Bezug auf die Topologie wird das Design als partielles Mesh bezeichnet,da die Leaf-Switches nur mit den Core-Switches und die Core-Switches nur mit den Leaf-Switches verbunden sind.

Die Core-Switches fungieren als Backbone des Netzwerks und werden als Spine-Switches bezeichnet, daher der Name Spine Leaf.

Skalierbarkeit

Der wichtigste Vorteil der Spine-Leaf-Architektur ist die lineare Skalierbarkeit: Wenn mehr Kapazität benötigt wird, können wir das Netzwerk durch das Hinzufügen von Spine- und Leaf-Switches erweitern, indem wir nach außen skalieren, anstatt nach oben zu skalieren. Dadurch kann das Netzwerk horizontal skaliert werden, genau wie die Cluster-Software, die es unterstützt.

Da jeder Spine-Switch mit jedem Leaf-Switch verbunden ist, wird die Skalierbarkeit durch die Anzahl der verfügbaren Ports an einem einzelnen Spine-Switch bestimmt. Wenn ein Spine-Switch 32 Ports mit jeweils 40 Gbit/s hat und jeder Leaf-Switch 160 Gbit/s benötigt, um ein vernünftiges Überbelegungs-Verhältnis aufrechtzuerhalten, können wir höchstens 8 Leaf-Switches haben.

Nord-Süd- vs. Ost-West-Verkehrsmuster

Die Netzwerkskalierbarkeit der Spine-Leaf-Architektur ist besonders geeignet, um die Bandbreitenanforderungen moderner Datenplattformen zu bewältigen, denn das vorherrschende Verkehrsmuster ist Server-zu-Server. Dieser netzwerkinterne Verkehr zwischen Clusterservern (der oft durch Shuffles oder Replikation entsteht) wird auch als Ost-West-Verkehr bezeichnet, da die Datenströme meist zwischen Serverpaaren auf gleicher Höhe innerhalb der Netzwerkhierarchie verlaufen.

Im Gegensatz dazu wird der herkömmliche Client-Server-Verkehr über externe Netze geleitet und gelangt über ein Kernnetz durch die Spine- und Leaf-Layer nach unten. Diese Art von Datenfluss wird oft als Nord-Süd-Verkehr bezeichnet. Bedenke, dass bei einer Plattform wie HDFS der Client-Server-Verkehr eher in Ost-West-Richtung als in Nord-Süd-Richtung verläuft, da Plattformen wie Spark hochgradig parallele Aktivitäten im Cluster erzeugen.

Widerstandsfähige Wirbelsäulennetzwerke

Um Netzwerke widerstandsfähig zu machen, werden in erster Linie redundante Switches und MC-LAG eingesetzt. Bislang war dies für alle Switches in einer Architektur erforderlich, da jeder Switch ohne einen redundanten Partner zu einem SPOF werden würde.

Mit der Spine-Leaf-Architektur ist das nicht mehr der Fall. Definitionsgemäß verfügt ein Spine-Leaf-Netzwerk bereits über mehrere Spine-Switches, sodass die Spine-Schicht bereits von vornherein widerstandsfähig ist. Die Leaf-Ebene lässt sich ausfallsicher machen, indem jeder Leaf-Switch durch ein Switch-Paar ersetzt wird, wie in Abbildung 4-14 dargestellt. Diese beiden Switches stellen dann eine Verbindung zur Spine-Schicht her, um Daten zu übertragen, und verbinden sich gegenseitig für das Statusmanagement.

Abbildung 4-14. Ein belastbares Wirbelsäulen-Blatt-Netzwerk

Umsetzung

Da eine Spine-Leaf-Architektur Schleifen enthält, ist die Implementierungsoption, alle Geräte in dieselbe Broadcast-Domäne zu setzen, nicht mehr gültig. Broadcast-Frames würden einfach um die Schleifen herumfließen und einen Broadcast-Sturm verursachen, zumindest bis das Spanning Tree Protocol (STP) einige Verbindungen deaktiviert.

Die Option, ein Subnetz (Broadcast Domain) pro Leaf-Switch zu haben, bleibt bestehen und ist eine skalierbare Lösung, da der Broadcast-Verkehr dann auf die Leaf-Switches beschränkt wäre. Auch bei dieser Implementierungsoption müssen die Netzwerkadministratoren das Routing verwalten, was fehleranfällig sein kann.

Eine interessante alternative Implementierungsmöglichkeit ist der Einsatz eines Spine-Leaf-Netzwerks, das eine Netzwerkstruktur verwendet, anstatt Routing auf der IP-Schicht zu nutzen.

Netzwerk Fabrics

Layer 2 bietet überzeugende Funktionen wie Null-Konfiguration und hohe Switching-Leistung, aber das fehlende Frame-Routing beeinträchtigt die Skalierbarkeit und die fehlende Time-to-Live führt zu Broadcast-Stürmen. Layer 3 entschärft diese Probleme, indem es Routing und Time-to-Live auf IP-Paketebene hinzufügt, aber das bedeutet immer noch, dass größere Netzwerke nur aus mehreren miteinander verbundenen Layer-2-Netzwerken aufgebaut werden können.

Netzwerkanbieter und Normungsgremien entwickeln seit einiger Zeit hybride Layer-2/3-Architekturen, was zu zwei konkurrierenden Standards geführt hat: Transparent Interconnection of Lots of Links (TRILL) und Shortest Path Bridging (SPB). Diese beiden Technologien (und ihre proprietären Varianten wie Cisco FabricPath) kombinieren die Vorteile der Schichten 2 und 3.

TRILL ist ein völlig neues Layer-2-Protokoll, das den normalen Layer-2-Ethernet-Verkehr kapselt. TRILL-Frames enthalten ein Time-to-Live-Feld sowie Quell- und Ziel-Switch-Kennungen. Die Switch-Adressen werden automatisch zugewiesen und die Routing-Tabellen der Switches werden automatisch gepflegt, so dass die Frames ohne Switch-Konfiguration geroutet werden können.

Die Server verwenden weiterhin Standard-Ethernet-Frames, wenn sie Daten senden, aber diese werden dann von den Fabric Switches in TRILL-Frames umgewandelt, wenn sie in das TRILL-Netzwerk gelangen. Die Rahmen werden über einen optimalen Pfad zum Ziel-Switch übertragen und wieder in einen Standard-Ethernet-Rahmen umgewandelt, bevor sie schließlich an das Zielgerät weitergeleitet werden. Die Nutzung von TRILL ist völlig transparent.

Obwohl Hadoop nicht direkt von einem flachen Layer-2-Netzwerk profitiert, kann die betriebliche Einfachheit dieses Ansatzes für viele Unternehmen überzeugend sein.

Netzwerk-Integration

Ein Cluster ist eine große Investition, die eine umfangreiche Vernetzung erfordert. Deshalb ist es sinnvoll, die Architektur eines Clusternetzwerks isoliert zu betrachten. Sobald jedoch die Netzwerkarchitektur des Clusters feststeht, muss als Nächstes festgelegt werden, wie der Cluster mit der Welt verbunden wird.

Es gibt eine Reihe von Möglichkeiten, einen Cluster in ein größeres Netzwerk zu integrieren. In diesem Abschnitt werden die verfügbaren Optionen beschrieben und ihre Vor- und Nachteile dargelegt.

Ein bestehendes Netzwerk wiederverwenden

Der erste Ansatz - der nur bei kleinen Clustern wirklich möglich ist - besteht darin, den Cluster zu einem bereits bestehenden Subnetz hinzuzufügen. Dies ist der einfachste Ansatz, da er die geringsten Änderungen an der bestehenden Infrastruktur erfordert. Abbildung 4-15 zeigt, dass dieser Integrationspfad auf logischer Ebene trivial ist, da wir nur neue Clusterserver hinzufügen.

Abbildung 4-15. Logische Ansicht einer Integration in ein bestehendes Netzwerk

Physikalisch gesehen könnte dies durch die Wiederverwendung bestehender Switches realisiert werden, aber wenn nicht alle Knotenpunkte am selben Switch liegen, könnte dies leicht zu Überbelegungsproblemen führen. Viele Netzwerke sind eher für den Zugang als für den Durchsatz ausgelegt.

Ein besserer Implementierungsplan ist die Einführung zusätzlicher Switches, die nur für den Cluster bestimmt sind, wie in Abbildung 4-16 dargestellt. Dies ist besser für die Isolierung und die Leistung, da der interne Datenverkehr des Clusters auf dem Switch verbleiben kann, anstatt über ein bestehendes Netzwerk geleitet zu werden.

Abbildung 4-16. Physikalische Ansicht der möglichen Integrationen in ein bestehendes Netzwerk

Ein zusätzliches Netzwerk erstellen

Die Alternative ist die Einrichtung zusätzlicher Subnetze, um den neuen Cluster zu hosten. Dazu muss die bestehende Netzwerkinfrastruktur sowohl in Bezug auf die physische Konnektivität als auch auf die Konfiguration geändert werden. Abbildung 4-17 zeigt, dass die Architektur aus logischer Sicht immer noch einfach ist: Wir fügen das Subnetz des Clusters hinzu und verbinden es mit dem Hauptnetzwerk.

Abbildung 4-17. Logische Ansicht der Integration über ein zusätzliches Netzwerk

Aus der Sicherheitsperspektive ist dieser Ansatz vorzuziehen, da die zusätzliche Isolierung den Broadcast-Verkehr vom Hauptnetzwerk fernhält. Wenn wir den Router durch eine Firewall ersetzen, können wir das Clusternetzwerk vollständig abtrennen und genau kontrollieren, welche Server und Dienste für das Hauptnetzwerk sichtbar sind.

Kanten-verbundene Netzwerke

Edge Nodes sind in der Regel Clusterserver, die den Zugang zu den Clusterdiensten ermöglichen, indem sie SSH-Zugang bieten, Web-UIs hosten oder JDBC-Endpunkte für vorgelagerte Middleware-Systeme bereitstellen. Sie bilden die Grenze oder den Rand der Softwaredienste, die von einem Cluster bereitgestellt werden.

Abbildung 4-18 zeigt, wie ein Cluster nicht über einen Router oder eine Firewall verbunden wird, sondern wie die Kantenknoten eine externe Netzwerkverbindung zum Cluster herstellen können.

Abbildung 4-18. Logische Ansicht der Integration über einen Kanten-Knoten

Wenn sie auf diese Weise verbunden sind, bilden die Edge Nodes buchstäblich die physischen Kanten des Clusters und fungieren als Gateway, über das die gesamte Kommunikation abgewickelt wird. Der Nachteil dieses Ansatzes ist, dass die Kanten-Knoten mehrfach angebunden sind, was im Allgemeinen nicht empfehlenswert ist.

Upstream-Konnektivität

Der Bedarf an Leistung und Ausfallsicherheit ist ein wichtiger Faktor für die Netzwerkarchitektur innerhalb eines Clusters, aber das Gleiche gilt (wenn auch in geringerem Maße) für die Upstream-Konnektivität. In vielen Clustern sind die Bandbreitenanforderungen für Ingest und Reporting im Vergleich zum internen Datenverkehr bescheiden, außer in einem Fall - der Replikation in einen anderen Cluster.

Obwohl fast alle Clusterdienste für hohe Verfügbarkeit ausgelegt sind, besteht immer die Möglichkeit, dass ein ganzes Rechenzentrum einen katastrophalen Ausfall erleidet. Mehrere Racks und Stromverteilungseinheiten können helfen, einige SPOFs abzumildern, aber es bleibt die Tatsache, dass ein einzelnes Rechenzentrum immer nur an einem einzigen Standort existieren wird - um dies zu verhindern, müssen mehrere Standorte genutzt werden, was bedeutet, dass Daten zwischen ihnen repliziert werden müssen.

Cluster-Dienste stellen oft Software-Tools zur Verfügung, um die Datenreplikation zwischen geografischen Standorten zu ermöglichen. Im Fall von Hadoop kann ein Tool namens Distributed Copy (DistCp) verwendet werden, um Daten zwischen HDFS-Instanzen zu kopieren. Da HDFS eine riesige Datenmenge speichern kann, wurde DistCp entwickelt, um Daten parallel zu kopieren. Daher kann es eine erhebliche Netzwerklast verursachen. Apache HBase und Apache Kafka bieten ähnliche Tools, um Daten auf andere Installationen zu replizieren.

Überlegungen zur Netzwerkgestaltung

In diesem Abschnitt werden Empfehlungen und Überlegungen zum Netzwerkdesign vorgestellt, die auf Referenzarchitekturen, bewährten Methoden und den Erfahrungen der Autoren basieren. Ziel ist es, einige Implementierungsrichtlinien bereitzustellen, um einen erfolgreichen Einsatz zu gewährleisten.

Empfehlungen für Schicht 1

Die folgenden Empfehlungen betreffen Aspekte der Schicht 1, der so genannten physikalischen Schicht. Hier trifft der Gummi auf die Straße und überbrückt die Kluft zwischen der logischen Welt der Software und der physischen Welt der Elektronik und der Übertragungssysteme.

Spezielle Schalter verwenden

Auch wenn es möglich ist, die bestehende Netzwerkinfrastruktur für einen neuen Cluster zu nutzen, empfehlen wir nach Möglichkeit die Einrichtung von dedizierten Switches und Uplinks für Hadoop. Dies hat mehrere Vorteile, darunter Isolierung und Sicherheit, Wachstumskapazität des Clusters und eine bessere Garantie, dass der Datenverkehr von Hadoop und Spark die bestehenden Netzwerkverbindungen nicht überlastet.

Betrachte einen Cluster als eine Appliance

Dies hängt mit dem vorherigen Punkt zusammen, aber es ist hilfreich, einen Cluster als Ganzes zu betrachten und nicht als eine Ansammlung von Servern, die zu deinem Netzwerk hinzugefügt werden.

Wenn Unternehmen einen Cluster als Appliance kaufen, wird die Installation zu einer relativ einfachen Angelegenheit, bei der es um die Bereitstellung von Platz, Netzwerkanbindung, Kühlung und Stromversorgung geht - die interne Konnektivität ist in der Regel kein Thema. Wenn du deinen eigenen Cluster entwickelst und baust, musst du dich zwangsläufig mit den internen Details befassen, aber die Appliance-Mentalität - den Cluster als eine Einheit zu betrachten - ist immer noch angebracht.

Überzeichnung bewältigen

Die Leistung eines Clusternetzwerks wird vollständig durch den Grad der Überzeichnung an den Switches bestimmt. Cluster-Software wie Hadoop und Spark kann ein Netzwerk an seine Kapazitätsgrenzen bringen, daher sollte das Netzwerk so konzipiert sein, dass die Überzeichnung möglichst gering ist. Cluster-Software funktioniert am besten, wenn die Überzeichnung bei etwa 3:1 oder besser liegt.

InfiniBand sorgfältig prüfen

Hadoop-Cluster können mit InfiniBand (IB) als Layer-1-Technologie eingesetzt werden, aber das ist außerhalb von Hadoop-Appliances eher unüblich.

Zum Zeitpunkt der Erstellung dieses Artikels wird InfiniBand von Diensten wie Hadoop und Spark nicht nativ unterstützt. Funktionen wie Remote Direct Memory Access (RDMA) bleiben daher ungenutzt und machen die Verwendung von IP over InfiniBand (IPoIB) unumgänglich. Das hat zur Folge, dass die Leistung von InfiniBand erheblich reduziert wird und die höheren Geschwindigkeiten von InfiniBand weniger relevant sind.

InfiniBand führt auch eine sekundäre Netzwerkschnittstelle zu den Clusterservern ein, wodurch sie multihomed werden. Wie in den "Layer 3 Empfehlungen" beschrieben, sollte dies vermieden werden. Schließlich erschweren die relative Knappheit an InfiniBand-Kenntnissen auf dem Markt und die Kosten im Vergleich zu Ethernet die Einführung und Wartung der Technologie.

Hochgeschwindigkeitskabel verwenden

Cluster werden in der Regel mit Kupferkabeln verkabelt. Diese sind in einer Reihe von Standards, den sogenannten Kategorien, erhältlich, die die maximale Kabellänge und die maximale Geschwindigkeit festlegen, mit der ein Kabel verwendet werden kann.

Da der Kostenanstieg zwischen den verschiedenen Kabeltypen im Vergleich zu Servern und Switches vernachlässigbar ist, ist es sinnvoll, das Kabel mit der höchstmöglichen Leistung zu wählen. Zum Zeitpunkt der Erstellung dieses Artikels wird empfohlen, Kabel der Kategorie 7a zu verwenden, die Geschwindigkeiten von bis zu 40 Gb/s bei einer maximalen Entfernung von 100 Metern (für Vollkernkabel; 55 Meter für Litzenkabel) bieten.

Glasfaserkabel bieten im Vergleich zu Kupferkabeln eine bessere Leistung in Bezug auf Bandbreite und Entfernung, allerdings zu höheren Kosten. Sie können für die Verkabelung von Servern verwendet werden, werden aber häufiger für Verbindungen über größere Entfernungen eingesetzt, die Switches in verschiedenen Racks verbinden. Derzeit wird empfohlen, OM3-Glasfaserkabel oder besser zu verwenden, die Geschwindigkeiten von bis zu 100 Gb/s ermöglichen.

Hochgeschwindigkeitsnetzwerke nutzen

Die Zeiten, in denen Cluster-Server mit 1 Gb/s verbunden wurden, sind längst vorbei. Heutzutage sollten fast alle Cluster die Server mit 10 Gbit/s oder mehr verbinden. Bei größeren Clustern, die mehrere Switches verwenden, sollten 40 Gbit/s als Mindestgeschwindigkeit für die Verbindungen zwischen den Switches gelten. Selbst bei einer Geschwindigkeit von 40 Gbit/s ist wahrscheinlich eine Link-Aggregation erforderlich, um ein akzeptables Maß an Überzeichnung zu erreichen.

Platzierung der Hardware berücksichtigen

Wir empfehlen, die Server an vorhersehbaren Stellen im Rack zu platzieren, z. B. die Master-Knoten immer ganz oben im Rack oder die Server in aufsteigender Name/IP-Reihenfolge zu platzieren. Diese Strategie kann dazu beitragen, die Wahrscheinlichkeit zu verringern, dass ein Server bei der Wartung des Clusters falsch identifiziert wird. Noch besser ist es, Etiketten zu verwenden und die Dokumentation auf dem neuesten Stand zu halten.

Achte darauf, dass die Racks zusammen aufgestellt werden, wenn du gestapelte Netzwerke in Betracht ziehst, da die Stapelkabel kurz sind. Erinnere dich daran, dass die Netzwerkkabel der Server in diesem Fall möglicherweise zwischen den Racks verlegt werden müssen.

Achte darauf, dass die Racks nicht mehr als 100 Meter voneinander entfernt sind, wenn du die optische Verkabelung verlegst.

Verbinden Sie die Cluster nicht mit dem Internet

Anwendungsfälle, bei denen ein Cluster direkt im öffentlichen Internet ansprechbar sein muss, sind selten. Da sie oft wertvolle, sensible Informationen enthalten, sollten die meisten Cluster in gesicherten internen Netzwerken eingesetzt werden, fernab von neugierigen Blicken. Eine gute Informationssicherheitspolitik besagt, dass die Angriffsfläche eines jeden Systems minimiert werden sollte, und Cluster wie Hadoop bilden da keine Ausnahme.

Wenn es unbedingt erforderlich ist, sollten Cluster mit Internetzugang über Firewalls bereitgestellt und mit Kerberos, Transport Layer Security (TLS) und Verschlüsselung gesichert werden.

Empfehlungen für Schicht 2

Die folgenden Empfehlungen betreffen Aspekte der Schicht 2, der so genannten Datenverbindungsschicht, die für das Senden und Empfangen von Frames zwischen Geräten in einem lokalen Netzwerk zuständig ist. Jeder Rahmen enthält die physikalischen Hardwareadressen der Quelle und des Ziels sowie einige andere Felder.

Vermeiden Sie überdimensionierte Layer-2-Netzwerke

Während IP-Adressen vollständig durch die Netzwerkkonfiguration bestimmt werden, sind MAC-Adressen praktisch zufällig (mit Ausnahme des Herstellerpräfixes). Um die zu einer IP-Adresse gehörende MAC-Adresse zu ermitteln, wird das Address Resolution Protocol (ARP) verwendet, das eine Adressermittlung durchführt, indem es eine Adressanfrage an alle Server in der gleichen Broadcast-Domäne sendet.

Die Verwendung von Broadcasts für die Adressermittlung bedeutet, dass Layer-2-Netzwerke in ihrer Skalierbarkeit eingeschränkt sind. Eine allgemeine Regel besagt, dass eine einzelne Broadcast-Domäne nicht mehr als etwa 500 Server beherbergen sollte.

VLAN-Nutzung minimieren

Virtuelle LANs wurden ursprünglich entwickelt, um die Deaktivierung von Verbindungen durch das Spanning Tree Protocol weniger kostspielig zu machen, indem Switches und Links gleichzeitig mehrere unabhängige LANs übertragen können, von denen jedes einen eigenen Spanning Tree hat. Die Absicht war, die Auswirkungen der Verbindungsdeaktivierung zu verringern, indem eine physische Verbindung in einem VLAN deaktiviert werden kann, während sie in anderen weiterhin aktiv bleibt.

In der Praxis werden VLANs fast nie nur verwendet, um die Auswirkungen von STP zu begrenzen; die isolierende Natur von VLANs ist oft viel nützlicher, um die Sichtbarkeit von Diensten zu verwalten und die Sicherheit zu erhöhen, indem der Broadcast-Bereich eingeschränkt wird.

VLANs sind für Clusternetzwerke nicht erforderlich - physische LANs sind vollkommen ausreichend, da ein Cluster in den meisten Fällen ohnehin über dedizierte Switches verfügt. Wenn VLANs eingesetzt werden, sollte ihre Verwendung auf höchstens ein VLAN pro Cluster oder ein VLAN pro Rack bei Clustern, die mit Layer-3-Routing aufgebaut wurden, beschränkt werden. Die Verwendung von mehreren VLANs pro Server ist Multihoming, was im Allgemeinen nicht empfohlen wird.

Jumbo-Frames in Betracht ziehen

Netzwerke können so konfiguriert werden, dass sie größere Rahmen (sogenannte Jumbo-Frames) senden, indem die maximale Übertragungseinheit (MTU) von 1.500 auf 9.000 Byte erhöht wird. Dadurch wird die Effizienz großer Übertragungen erhöht, da viel weniger Rahmen benötigt werden, um dieselben Daten zu senden. Cluster-Workloads wie Hadoop und Spark sind in hohem Maße von großen Übertragungen abhängig, so dass die Effizienz von Jumbo-Frames sie zu einer offensichtlichen Design-Entscheidung macht, wenn sie unterstützt werden.

In der Praxis können Jumbo Frames problematisch sein, weil sie von allen beteiligten Switches und Servern (einschließlich externer Dienste wie Active Directory) unterstützt werden müssen. Andernfalls kann die Fragmentierung zu Problemen mit der Zuverlässigkeit führen.

Berücksichtige die Ausfallsicherheit des Netzwerks

Wie bereits erwähnt, ist ein Ansatz, um ein Netzwerk ausfallsicher zu machen, die Multi-Chassis Link Aggregation. Diese baut auf den Fähigkeiten der Link Aggregation (LAG) auf, indem sie es Servern ermöglicht, sich gleichzeitig mit zwei Switches zu verbinden und dabei nur eine einzige logische Verbindung zu nutzen. Wenn also einer der Links oder Switches fehlschlägt, funktioniert das Netzwerk weiter.

Zusätzlich zu ihren Upstream-Verbindungen müssen die redundanten Switches des Paares direkt miteinander verbunden werden. Diese Verbindungen sind proprietär (mit herstellerspezifischen Bezeichnungen und Implementierungen), was bedeutet, dass Switches verschiedener Hersteller (sogar verschiedene Modelle desselben Herstellers) nicht kompatibel sind. Die proprietären Verbindungen unterscheiden sich darin, ob sie zusätzlich zu den erforderlichen Switch-Kontrolldaten auch den Cluster-Verkehr übertragen.

In Unternehmensumgebungen gibt es fast immer gemanagte Switches, die LACP nutzen können, daher ist es sinnvoll, diese Fähigkeit zu nutzen, wo immer es möglich ist. LACP handelt automatisch die Aggregationseinstellungen zwischen dem Server und einem Switch aus, weshalb dies für die meisten Einsätze empfohlen wird.

Empfehlungen für Schicht 3

Die folgenden Empfehlungen betreffen Aspekte der Schicht 3, der so genannten Netzwerkschicht. Diese Schicht verbindet mehrere Layer-2-Netzwerke miteinander, indem sie logische Adressierungs- und Routing-Funktionen hinzufügt.

Dedizierte Subnetze verwenden

Wir empfehlen, den Netzwerkverkehr auf mindestens ein eigenes Subnetz (und damit eine Broadcast-Domäne) pro Cluster zu beschränken. Dies ist nützlich, um die Ausbreitung des Broadcast-Verkehrs zu steuern und kann auch zur Sicherheit des Clusters beitragen (durch Netzwerksegmentierung und den Einsatz von Firewalls). Ein Subnetzbereich der Größe /22 ist für diesen Zweck in der Regel ausreichend, da er 1.024 Adressen bietet - die meisten Cluster sind kleiner als dieser Bereich.

Bei größeren Clustern, die kein Fabric-basiertes Switching verwenden, ermöglicht ein dediziertes Subnetz pro Rack den Switches, den Datenverkehr auf Layer 3 zu routen, anstatt nur Frames zu vermitteln. Das bedeutet, dass die Cluster-Switches mit mehreren Links verbunden werden können, ohne dass es zu Problemen durch STP kommt. Ein Subnetzbereich der Größe /26 ist ausreichend, da er 64 Adressen pro Rack bereitstellt - die meisten Racks haben weniger Server als das.

Jedem Cluster sollte ein eindeutiges Subnetz innerhalb deiner gesamten Netzwerkzuordnung zugewiesen werden. Dadurch wird sichergestellt, dass alle Serverpaare miteinander kommunizieren können, falls Daten zwischen den Clustern kopiert werden müssen.

IP-Adressen statisch zuweisen

Wir empfehlen dringend, den Clusterservern während der Erstellungs- und Konfigurationsphase des Betriebssystems statische IP-Adressen zuzuweisen, anstatt DHCP bei jedem Systemstart dynamisch zu verwenden. Die meisten Clusterdienste erwarten, dass die IP-Adressen im Laufe der Zeit statisch bleiben. Außerdem sind Dienste wie Spark und Hadoop in Java geschrieben, wo DNS-Einträge standardmäßig für immer zwischengespeichert werden, wenn ein Sicherheitsmanager installiert ist.

Wenn du DHCP verwendest, solltest du sicherstellen, dass die IP-Adressenzuweisung im Laufe der Zeit stabil ist, indem du eine feste Zuordnung von MAC-Adressen zu IP-Adressen verwendest - auf diese Weise erhält der Server immer dieselbe IP-Adresse, wenn er hochfährt.

Private IP-Adressbereiche verwenden

In den meisten Fällen sollten interne Netzwerke innerhalb einer Organisation so konfiguriert werden, dass sie IP-Adressen aus den privaten IP-Adressbereichen verwenden. Diese Bereiche sind speziell für die Nutzung durch interne Netzwerke vorgesehen - Switches im Internet lassen alle Pakete zu oder von privaten Adressen fallen.

Die mehreren verfügbaren privaten IP-Bereiche können in Subnetze unterteilt werden. Tabelle 4-2 zeigt die Bereiche.

Tabelle 4-2. Private IP-Adressbereiche

IP-Adresse Bereich	Anzahl der IP-Adressen	Beschreibung
10.0.0.0–10.255.255.255	16,777,216	Einfaches Klasse-A-Netz
172.16.0.0–172.31.255.255	1,048,576	16 zusammenhängende Klasse-B-Netze
192.168.0.0–192.168.255.255	65,536	256 zusammenhängende Klasse-C-Netze

Bei Clustern wie Hadoop empfehlen wir dringend die Verwendung eines privaten Netzwerks. Achte bei der Einrichtung eines Clusters jedoch darauf, dass ein privater Netzwerkbereich innerhalb einer Organisation nur einmal verwendet wird - zwei Cluster, deren IP-Adressen sich widersprechen, können nicht miteinander kommunizieren.

DNS gegenüber /etc/hosts bevorzugen

Auf Cluster-Server wird fast immer über Hostnamen und nicht über IP-Adressen zugegriffen. Abgesehen davon, dass man sich Hostnamen leichter merken kann, sind sie insbesondere bei der Verwendung von Sicherheitstechnologien wie TLS und Kerberos erforderlich. Die Auflösung eines Hostnamens in eine IP-Adresse erfolgt entweder über das Domain Name System (DNS) oder die lokale Konfigurationsdatei /etc/hosts.

Die lokale Konfigurationsdatei (in der Einträge statisch definiert werden können) hat einige Vorteile gegenüber DNS:

Vorrang

Lokale Einträge haben Vorrang vor DNS, so dass Administratoren bestimmte Einträge außer Kraft setzen können.

Verfügbarkeit

Als Netzwerkdienst ist DNS anfällig für Service- und Netzwerkausfälle, aber /etc/hosts ist immer verfügbar.

Leistung

DNS-Suchvorgänge erfordern mindestens einen Round Trip über das Netzwerk, aber Suchvorgänge über die lokale Datei erfolgen sofort.

Trotz dieser Vorteile empfehlen wir nachdrücklich, DNS zu verwenden. Änderungen im DNS werden nur einmal vorgenommen und sind sofort verfügbar. Da /etc/hosts eine lokale Datei ist, die auf allen Geräten vorhanden ist, müssen alle Änderungen an allen Kopien vorgenommen werden. Zumindest erfordert dies eine Automatisierung der Bereitstellung, um die Korrektheit zu gewährleisten, aber wenn der Cluster Kerberos verwendet, müssen die Änderungen sogar auf den Clients vorgenommen werden. An diesem Punkt ist DNS die weitaus bessere Option.

Die Verfügbarkeits- und Leistungsprobleme von DNS-Lookups können durch Dienste wie den Name Service Caching Daemon (NSCD) entschärft werden.

Unabhängig von allen anderen Überlegungen werden alle Cluster mit externen Systemen interagieren. DNS ist daher unerlässlich, sowohl für den eingehenden als auch für den ausgehenden Datenverkehr.

Bereitstellung von Forward- und Reverse-DNS-Einträgen

Neben der Verwendung von DNS für Forward-Lookups, die einen Hostnamen in eine IP-Adresse umwandeln, sind auch Reverse-DNS-Einträge erforderlich, die Lookups zur Umwandlung einer IP-Adresse in einen Hostnamen ermöglichen.

Reverse-DNS-Einträge sind vor allem für Kerberos wichtig, das sie verwendet, um die Identität des Servers zu überprüfen, mit dem sich ein Client verbindet.

Löse niemals einen Hostnamen nach 127.0.0.1 auf

Es muss unbedingt sichergestellt werden, dass jeder Clusterserver seinen eigenen Hostnamen in eine routingfähige IP-Adresse auflöst und niemals in die IP-Adresse des localhost 127.0.0.1 - eine häufige Fehlkonfiguration der lokalen Datei /etc/hosts.

Dies ist ein Problem, weil viele Clusterdienste ihre IP-Adresse als Teil der normalen RPC-Interaktionen an entfernte Systeme weitergeben. Wenn die localhost-Adresse übergeben wird, versucht das entfernte System später fälschlicherweise, sich mit sich selbst zu verbinden.

IPv6 meiden

Es gibt zwei Arten von IP-Adressen, die heute verwendet werden: IPv4 und IPv6. IPv4 wurde in den 1970er Jahren entwickelt, wobei die Adressen 4 Byte groß waren. Damals hielt man 4.294.967.296 Adressen für die absehbare Zukunft für ausreichend, aber das schnelle Wachstum des Internets in den 1990er Jahren führte zur Entwicklung von IPv6, das die Größe der Adressen auf 16 Byte erhöhte.

Die Akzeptanz von IPv6 ist immer noch gering - einem Bericht aus dem Jahr 2014 zufolge nutzen nur 3 % der Google-Nutzer/innen die Website über IPv6. Das liegt zum Teil an den erforderlichen Infrastrukturänderungen und daran, dass Umgehungslösungen wie Network Address Translation (NAT) und Proxys in vielen Fällen gut genug funktionieren.

Zum Zeitpunkt der Erstellung dieses Artikels haben die Autoren noch kein Kundennetzwerk - egal ob Cluster oder nicht - gesehen, das IPv6 nutzt. Die privaten Netzwerke bieten weit über 16 Millionen Adressen, so dass IPv6 ein Problem löst, das im Unternehmensbereich nicht existiert.

Wenn sich IPv6 im Verbraucher-Internet weiter durchsetzt, könnte es einen Anstoß geben, Unternehmensnetzwerke so zu standardisieren, dass sie denselben Stack verwenden. Wenn das passiert, werden Datenplattformen IPv6 stärker wahrnehmen und regelmäßiger darauf getestet werden. Im Moment ist es sinnvoller, IPv6 ganz zu vermeiden.

Vermeide Multihoming

Unter Multihoming versteht man die Anbindung eines Servers an mehrere Netzwerke, in der Regel mit der Absicht, einige oder alle Netzwerkdienste von mehreren Subnetzen aus zugänglich zu machen.

Wenn Multihoming mit einem Hostname-per-Interface-Ansatz implementiert wird, kann ein einziger DNS-Server verwendet werden, um die verschiedenen Hostnameneinträge an einem einzigen Ort zu speichern. Dieser Ansatz funktioniert jedoch nicht gut mit Hadoop, wenn es mit Kerberos gesichert ist, da Dienste nur für die Verwendung eines einzigen Service Principal Name (SPN) konfiguriert werden können und ein SPN den voll qualifizierten Hostnamen eines Dienstes enthält.

Wenn Multihoming mit dem Hostname-per-Server-Ansatz implementiert wird, ist ein einzelner DNS-Server nicht mehr ausreichend. Die IP-Adresse, die ein Client benötigt, hängt nun davon ab, in welchem Netzwerk sich der Client befindet. Die Lösung dieses Problems macht die Netzwerkkonfiguration sehr komplex und erfordert normalerweise eine Kombination aus DNS und /etc/hosts. Dieser Ansatz erhöht auch die Komplexität, wenn es um die Kerberos-Sicherheit geht, denn es ist wichtig, dass Forward- und Reverse-DNS-Lookups in allen Zugangsszenarien exakt übereinstimmen.

Multihoming kommt am häufigsten bei Kanten-Knoten vor, wie in " Edge-connected networks" beschrieben , wo Kanten-Dienste an mehreren Schnittstellen auf eingehende Anfragen warten. Multihomed-Cluster-Knoten sollten aus folgenden Gründen möglichst vermieden werden:

• Zum Zeitpunkt der Erstellung dieses Artikels unterstützen noch nicht alle Clusterdienste Multihoming.

• Multihoming ist in der Nutzergemeinschaft nicht so weit verbreitet, sodass Probleme nicht so schnell gefunden werden.

• Open-Source-Entwickler entwickeln und testen nicht oft mit Multihomed-Konfigurationen.

Zusammenfassung

In diesem Kapitel haben wir erörtert, wie Cluster-Dienste wie Spark und HDFS Netzwerke nutzen, wie sie ein Höchstmaß an Leistung und Verfügbarkeit verlangen und wie diese Anforderungen letztlich die erforderliche Netzwerkarchitektur und Integrationsmuster bestimmen.

Mit diesem Wissen sollten Netzwerk- und Systemarchitekten in der Lage sein, sicherzustellen, dass das Netzwerkdesign robust genug ist, um einen Cluster heute zu unterstützen, und flexibel genug, um dies auch weiterhin zu tun, wenn ein Cluster wächst.