Hallo Community von Habr! Kürzlich habe ich über unser Cluster-Board der ersten Version geschrieben []. Heute möchte ich erzählen, wie wir an der Version gearbeitet haben dem Arbeitsspeicher ausgeführt zu werden.
Wir sind begeistert von Mini-Servern, die sowohl für die lokale Entwicklung als auch für das lokale Hosting verwendet werden können. Im Gegensatz zu Desktop-Computern oder Laptops sind unsere Server für den 24/7-Betrieb konzipiert und können schnell zu einer Föderation verbunden werden. Zum Beispiel gab es 4 Prozessoren im Cluster, und nach 5 Minuten waren es 16 Prozessoren (ohne zusätzliches Netzwerkgerät), und das alles in einem kompakten Formfaktor, geräuschlos und energieeffizient.
Die Grundlage der Architektur unserer Server ist das Cluster-Prinzip, d.h. wir erstellen Cluster-Boards, die mehrere Rechenmodule (Prozessoren) über das Ethernet-Netzwerk auf dem Board verbinden. Zur Vereinfachung stellen wir derzeit keine eigenen Rechenmodule her, sondern verwenden Raspberry Pi Compute Modules und haben sehr auf das neue Modul CM4 gehofft. Aber alles verlief nicht wie 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 umgehen mussten.
Nachdem wir ein Cluster mit 7 Knoten erstellt haben, stellt sich die Frage: Was als Nächstes? Wie erhöhen wir den Wert des Produkts? 8, 10 oder 16 Knoten? Welche Modulhersteller gibt es? Bei der Betrachtung des Produkts als Ganzes wurde uns klar, dass die Menge der Knoten oder der Hersteller nicht entscheidend ist, sondern die Essenz der Cluster als Baustein. Wir müssen den minimalen Baustein suchen, der
Erstens, ein Cluster darstellt und gleichzeitig die Möglichkeit bietet, Festplatten und Erweiterungs-Boards anzuschließen. Der Clusterblock muss ein eigenständiger Basisknoten sein und umfassende Erweiterungsmöglichkeiten bieten.
Zweitens, damit die minimalen Clusterblöcke miteinander verbunden werden können, um Cluster größerer Größe zu bilden, und um dies kosten- und geschwindigkeitseffizient zu gestalten. Die Skalierungsgeschwindigkeit muss höher sein als bei der Verbindung von gewöhnlichen Computern zu einem Netzwerk und viel günstiger als bei Serverhardware.
Drittens, die minimalen Clusterblöcke sollten kompakt, mobil, energieeffizient, kostengünstig und unkompliziert in der Nutzung sein. Das ist eines der Hauptmerkmale, die sie von Server-Racks und allem, was damit zu tun hat, unterscheiden.
Wir haben mit der Bestimmung der Anzahl der Nodes begonnen.
Anzahl der Nodes
Durch einfache logische Überlegungen haben wir festgestellt, dass 4 Nodes die beste Option für ein minimales Cluster-Setup sind. 1 Node ist kein Cluster, 2 Nodes sind zu wenig (1 Master und 1 Worker, es gibt keine Skalierungsmöglichkeiten innerhalb des Blocks, insbesondere für heterogene Varianten), 3 Nodes sehen gut aus, sind aber nicht potenziert mit den Zweien und das Scaling innerhalb des Blocks ist limitiert, 6 Nodes kosten fast so viel wie 7 Nodes (aus unserer Erfahrung ist das bereits ein hoher Preis), 8 ist zu viel, passt nicht in den Mini ITX Formfaktor und ist eine noch teurere Lösung für PoC.
Vier Nodes pro Block halten wir für die goldene Mitte:
- weniger Materialien für die Clusterplatine, daher günstigere Produktion
- kumulativ 4, insgesamt 4 Blöcke ergeben 16 physische Prozessoren
- stabile Konfiguration mit 1 Master und 3 Workern
- mehr heterogene Variationen, General-Compute + Accelerated-Compute Module
- Mini ITX Formfaktor mit SSDs und Erweiterungsplatinen
Rechenmodule
Die zweite Version basiert auf CM4; wir dachten, dass sie im SODIMM-Formfaktor veröffentlicht wird. Aber...
Wir haben beschlossen, eine SODIMM-Tochterplatine zu erstellen und CM4 direkt in Module zu integrieren, damit die Benutzer nicht über CM4 nachdenken müssen.
Turing Pi Compute Module mit Unterstützung für Raspberry Pi CM4
In der Tat wurde auf der Suche nach Modulen ein ganzer Markt für Rechenmodule entdeckt, von kleinen Modulen mit 128 MB RAM bis hin zu solchen mit 8 GB RAM. Zukünftig werden Module mit 16 GB RAM und mehr erwartet. Für Edge-Hosting-Anwendungen, die auf cloud-native Technologien basieren, sind 1 GB RAM bereits zu wenig, und das kürzliche Erscheinen von Modulen mit 2, 4 und sogar 8 GB RAM bietet guten Spielraum für das Wachstum. Wir haben sogar Optionen mit FPGA-Modulen für Anwendungen des maschinellen Lernens in Betracht gezogen, aber ihre Unterstützung wurde zurückgestellt, da das Software-Ökosystem noch nicht entwickelt ist. Während der Marktanalyse sind wir auf die Idee gekommen, eine universelle Schnittstelle für Module zu schaffen, und in V2 beginnen wir mit der Vereinheitlichung der Schnittstellen von Rechenmodulen. Dies ermöglicht es den Besitzern der V2-Version, Module anderer Hersteller anzuschließen und sie für spezifische Aufgaben zu mixen.
V2 unterstützt die gesamte Palette von Raspberry Pi 4 Compute Module (CM4), einschließlich der Lite-Versionen und Module mit 8 GB RAM.
Peripherie
Nach der Auswahl der Modulanbieter und der Anzahl der Knoten sind wir an den PCI-Bus gelangt, an dem sich die Peripheriegeräte befinden. Der PCI-Bus ist der Standard für Peripheriegeräte und kommt in fast allen Rechenmodulen vor. Wir haben mehrere Knoten und idealerweise sollte jeder Knoten PCI-Geräte im Modus konkurrierender Anfragen teilen können. Zum Beispiel, wenn es sich um eine Festplatte handelt, die an den Bus angeschlossen ist, dann ist sie für alle Knoten zugänglich. Wir haben mit der Suche nach PCI-Switches begonnen, die Multi-Host unterstützen, und festgestellt, dass keiner von ihnen unseren Anforderungen entsprach. All diese Lösungen waren hauptsächlich auf 1 Host oder Multi-Hosts begrenzt, jedoch ohne den Modus konkurrierender Anfragen an Endpunkte. Ein weiteres Problem ist die hohe Kosten von 50 $ und mehr pro Chip. In V2 haben wir entschieden, die Experimente mit PCI-Switches aufzuschieben (wir werden später darauf zurückkommen, während sich alles weiterentwickelt) und sind den Weg gegangen, jede Knotenrolle zuzuweisen: die ersten beiden Knoten haben einen mini PCI-Express-Port pro Knoten bereitgestellt, der dritte Knoten hat einen 2-Port 6 Gbps SATA-Controller bereitgestellt. Um auf die Festplatten von anderen Knoten zuzugreifen, kann ein Netzwerkdateisystem im Rahmen des Clusters verwendet werden. Warum nicht?
Vorschau
Wir haben uns entschieden, einige Skizzen zu teilen, wie sich der minimale 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. Von der ersten Knoten ist ein mini PCIe-Port abgeleitet, in den eine Netzwerkkarte installiert werden kann, um einen weiteren Ethernet-Port oder ein 5G-Modem zu erhalten und aus der ersten Knoten einen Router für das Netzwerk im Cluster und die Ethernet-Ports zu machen.
Der Clusterbus bietet mehr Funktionen, einschließlich der Möglichkeit, Module direkt über alle Slots zu flashen, sowie natürlich FAN-Anschlüsse an jedem Knoten mit Geschwindigkeitskontrolle.
Anwendung
Edge-Infrastruktur für selbstgehostete Anwendungen & Dienste
Wir haben V2 mit dem Ziel entwickelt, sie als minimalen Baustein für consumer-/commercial-grade Edge-Infrastruktur zu nutzen. Mit V2 ist es günstig, das Konzept zu testen und mit dem Wachstum zu skalieren, indem wir schrittweise Anwendungen verschieben, die wirtschaftlich und praktisch sinnvoller in der Edge gehostet werden. Clusterblöcke können zusammengefügt werden, um größere Cluster zu bauen. Dies kann schrittweise ohne nennenswerte Risiken für etablierte Strukturen erfolgen.
Bereits heute gibt es eine enorme Anzahl von Anwendungen für Unternehmen, .
ARM Workstation
Mit bis zu 32 GB RAM pro Cluster kann der erste Knoten für die Desktop-Version des OS (z. B. Ubuntu Desktop 20.04 LTS) verwendet werden, während die verbleibenden 3 Knoten für Aufgaben wie Kompilierung, Tests und Debugging sowie für die Entwicklung von Cloud-nativen Lösungen für ARM-Cluster genutzt werden. Als Knoten für CI/CD in einer produktiven Umgebung.
Der Turing V2-Cluster mit CM4-Modulen ist architektonisch nahezu identisch (mit Ausnahme kleiner Unterschiede in den Minor-Versionen von ARMv8) mit einem Cluster auf Basis von AWS Graviton-Instanzen. Im Prozessor der CM4-Module wird die ARMv8-Architektur verwendet, sodass Sie Images und Anwendungen für AWS Graviton 1 und 2-Instanzen erstellen können, die bekanntermaßen viel günstiger sind als x86-Instanzen.
Quelle: habr.com
