Hallo, Community von Habr! Vor kurzem habe ich über unser erstes Cluster-Board der Version geschrieben []. Heute möchte ich euch erzählen, wie wir an der Version gearbeitet haben dem Arbeitsspeicher auszuführen.
Wir sind begeistert von Mini-Servern, die sowohl für die lokale Entwicklung als auch für das Hosting vor Ort verwendet werden können. Im Gegensatz zu Desktop-Computern oder Laptops sind unsere Server dafür ausgelegt, 24/7 zu arbeiten. Sie lassen sich schnell zu einem Cluster verbinden; beispielsweise hatten wir vier Prozessoren im Cluster, und nach fünf Minuten waren es bereits 16 Prozessoren (ohne zusätzliches Netzwerk-Equipment) – und das alles im kompakten Formfaktor, lautlos und energieeffizient.
Das Grundprinzip unserer Serverarchitektur ist der Clustermodus, d.h. wir erstellen Cluster-Boards, die mehrere Recheneinheiten (Prozessoren) über ein Ethernet-Netzwerk auf der Platine verbinden. Zur Vereinfachung verwenden wir vorerst keine eigenen Recheneinheiten, sondern nutzen Raspberry Pi Compute Modules und hatten große Hoffnungen auf das neue CM4-Modul. Doch die Dinge liefen anders als geplant, mit ihrem neuen Formfaktor, und ich denke, viele sind enttäuscht.
Im Folgenden erläutern wir, wie wir von V1 zu V2 gelangt sind und wie wir mit dem neuen Formfaktor des Raspberry Pi CM4 umgegangen sind.
Also, nach der Erstellung eines Clusters mit 7 Knoten stellt sich die Frage: Wie geht es weiter? Wie steigern wir den Wert des Produkts? 8, 10 oder 16 Knoten? Welche Modulhersteller? Bei der Betrachtung des Produkts insgesamt haben wir erkannt, dass es nicht hauptsächlich um die Anzahl der Knoten oder die Hersteller geht, sondern um das Wesen von Clustern als grundlegenden Baustein. Wir müssen nach dem minimalen Baustein suchen, der
Erstens, ein Cluster darstellt und gleichzeitig die Möglichkeit bietet, Festplatten und Erweiterungskarten anzuschließen. Der Clusterblock sollte ein autarkes Basismodul sein und umfangreiche Erweiterungsmöglichkeiten bieten.
Zweitens, damit die minimalen Clusterblöcke miteinander verbunden werden können, um Cluster größerer Größe zu bilden, und dies sollte sowohl budgetär als auch in Bezug auf die Skalierungseffizienz effektiv sein. Die Skalierungsgeschwindigkeit sollte schneller sein als die von herkömmlichen Computern in einem Netzwerk und viel günstiger als Serverhardware.
Drittens, die minimalen Clusterblöcke sollten ausreichend kompakt, mobil, energieeffizient, kosteneffektiv und nicht anspruchsvoll in Bezug auf die Betriebsbedingungen sein. Dies ist eines der Hauptmerkmale, das sie von Server-Racks und allem, was damit zusammenhängt, unterscheidet.
Wir haben mit der Festlegung der Anzahl der Nodes begonnen.
Anzahl der Nodes
Durch einfache logische Überlegungen haben wir festgestellt, dass 4 Nodes die beste Option für das minimale Cluster-Setup sind. 1 Node ist kein Cluster, 2 Nodes sind zu wenig (1 Master, 1 Worker, keine Skalierungsmöglichkeiten innerhalb des Blocks, insbesondere bei heterogenen Varianten), 3 Nodes sieht gut aus, ist aber nicht ein Vielfaches von 2 und hat limitierte Skalierungsmöglichkeiten innerhalb des Blocks. 6 Nodes kosten fast so viel wie 7 Nodes (aus unserer Erfahrung ist das bereits eine hohe Kostenstruktur), 8 Nodes sind zu viel, passen nicht in den Mini-ITX-Formfaktor und sind eine noch teurere Lösung für den Proof of Concept.
Vier Nodes pro Block betrachten wir als goldene Mitte:
- weniger Material für die Clusterplatine, somit geringere Produktionskosten
- fünfmal 4, insgesamt 4 Blöcke ergeben 16 physische Prozessoren
- stabile Konfiguration mit 1 Master und 3 Workern
- mehr heterogene Varianten, General-Compute + Accelerated-Compute-Module
- Mini-ITX-Formfaktor mit SSD-Laufwerken und Erweiterungsplatinen
Rechenmodule
Die zweite Version basiert auf dem CM4, wir dachten, dass sie im SODIMM-Formfaktor veröffentlicht würde. Aber…
Wir haben beschlossen, eine Tochterplatine im SODIMM-Format zu erstellen und das CM4 direkt in Module einzubauen, damit die Nutzer sich nicht um das CM4 kümmern müssen.
Turing Pi Compute-Modul mit Unterstützung für Raspberry Pi CM4
Bei der Suche nach Modulen wurde ein ganzer Markt für Rechenmodule entdeckt, von kleinen Modulen mit 128 MB RAM bis hin zu 8 GB RAM. Module mit 16 GB RAM und mehr stehen bereits in Aussicht. Für Edge-Hosting von cloud-nativen Anwendungen ist 1 GB RAM bereits zu wenig, während die kürzlich vorgestellten Module mit 2, 4 und sogar 8 GB RAM viel Spielraum für Wachstum bieten. Sogar Optionen mit FPGA-Modulen für Maschinenlern-Anwendungen wurden in Betracht gezogen, jedoch ist deren Unterstützung verschoben, da das Software-Ökosystem noch nicht entwickelt ist. Während der Marktuntersuchung von Modulen kamen wir auf die Idee, eine universelle Schnittstelle für Module zu schaffen, und in V2 beginnen wir mit der Vereinheitlichung der Schnittstelle für Rechenmodule. Dies ermöglicht es den Besitzern der Version V2, Module anderer Hersteller anzuschließen und sie für spezifische Aufgaben zu kombinieren.
V2 unterstützt die gesamte Produktreihe des Raspberry Pi 4 Compute Modules (CM4), einschließlich Lite-Versionen und Modulen mit 8 GB RAM
Peripherie
Nachdem wir den Anbieter der Module und die Anzahl der Knoten bestimmt hatten, kamen wir zur PCI-Bus, an dem sich die Peripheriegeräte befinden. Der PCI-Bus ist der Standard für Peripheriegeräte und ist in fast allen Recheneinheiten vorhanden. Wir haben mehrere Knoten, und idealerweise sollte jeder Knoten PCI-Geräte im Wettrufmodus gemeinsam nutzen können. Wenn es sich beispielsweise um eine an den Bus angeschlossene Festplatte handelt, ist diese für alle Knoten verfügbar. Wir begannen mit der Suche nach PCI-Switches, die Multi-Host-Unterstützung bieten, und entdeckten, dass keiner von ihnen unseren Anforderungen entsprach. Alle diese Lösungen waren im Wesentlichen auf 1 Host oder Multi-Hosts beschränkt, jedoch ohne Wettrufmodus für Endpunkte. Ein weiteres Problem war der hohe Preis ab $50 und mehr pro Chip. In V2 beschlossen wir, die Experimente mit PCI-Switches zu verschieben (wir werden später darauf zurückkommen, wenn sich die Situation entwickelt) und gingen den Weg, jeder Knoten eine Rolle zuzuweisen: Die ersten beiden Knoten verfügen über einen mini PCI-Express-Anschluss pro Knoten, der dritte Knoten bietet einen 2-Port 6 Gbps SATA-Controller. Um auf die Festplatten von anderen Knoten zuzugreifen, kann ein Netzwerkdateisystem innerhalb des Clusters verwendet werden. Warum nicht?
Sneakpeek
Wir haben uns entschieden, einige Skizzen zu teilen, wie sich der minimalistische Clusterblock im Laufe der Zeit während der Diskussion und Überlegung entwickelt hat.
Infolgedessen sind wir zu einem Clusterblock mit 4 Knoten, 260-pin, 2 Mini PCIe (Gen 2) Ports und 2 SATA (Gen 3) Ports gekommen. Auf der Platine befindet sich ein Layer-2 Managed Switch mit VLAN-Unterstützung. Vom ersten Knoten führt ein Mini PCIe Port, in den eine Netzwerkkarte installiert werden kann, um einen zusätzlichen Ethernet Port oder ein 5G Modem bereitzustellen und den ersten Knoten zu einem Router für das Cluster- und Ethernet-Netzwerk zu machen.
Der Clusterbus bietet weitere Funktionen, einschließlich der Möglichkeit, Module direkt über alle Slots zu flashen, sowie FAN-Anschlüsse an jedem Knoten mit Geschwindigkeitsregelung.
Anwendung
Edge-Infrastruktur für selbstgehostete Anwendungen & Dienste
Wir haben V2 so konzipiert, dass sie als grundlegender Baustein für Verbraucher- und kommerzielle Edge-Infrastrukturen dient. Mit V2 können Sie kostengünstig einen Proof of Concept starten und skalieren, während Sie schrittweise Anwendungen migrieren, die wirtschaftlich und praktisch sinnvoller im Edge gehostet werden. Clusterblöcke lassen sich zusammen verbinden, um größere Cluster zu erstellen. Dies kann schrittweise und ohne riskante Auswirkungen auf etablierte Prozesse erfolgen.
Bereits heute gibt es eine Vielzahl von Anwendungen für Unternehmen, .
ARM Workstation
Mit bis zu 32 GB RAM pro Cluster kann die erste Node für die Desktop-Version des Betriebssystems (z. B. Ubuntu Desktop 20.04 LTS) verwendet werden, während die restlichen 3 Nodes für Aufgaben wie Kompilierung, Testing, Debugging und die Entwicklung cloud-nativer Lösungen für ARM-Cluster genutzt werden. Diese fungieren als Nodes für CI/CD in der ARM-Produktionsinfrastruktur.
Der Turing V2 Cluster mit CM4-Modulen ist architektonisch nahezu identisch mit (unterschiedliche Minor-Versionen von ARMv8) dem Cluster auf Basis von AWS Graviton Instanzen. Im CM4-Modul-Prozessor wird die ARMv8-Architektur verwendet, sodass Sie Images und Anwendungen für AWS Graviton 1 und 2 Instanzen erstellen können, die bekanntermaßen deutlich günstiger sind als x86-Instanzen.
Quelle: habr.com
