USB serial multiplexer - #USB2SerialMux

Wieder ein neues Thema - ist bei der Verwendung meines ChinaClusters aufgekommen. Es passiert das die Node2 und Node4 nicht bei Einschaltvorgang starten. Warum ist mir momentan noch unbekannt, dem muss ich noch nachgehen. Wie stellt man das nun aber richtig an?

Jedes der OrangePi PC- und OrangePi One-Systemen besitzen jeweils über einen 3-Pin-Header an dem ein UART-Anschluss (3,3V LVTTL) mit jeweils einer Rx-/Tx und GND-Leitung ausgeführt ist. An diesem Port kann mit einer adäquaten Gegenstelle der Bootprozess des Linuxsystems, sowie den zuvor ausgegebenen Meldungen des Bootloaders etc. empfangen werden. Sollte also an einer Stelle - innerhalb der ersten Sekunden - des Bootvorgangs ein Problem auftreten kann dies dort, zumindest Theoretisch oder auch mit Glück, abgelesen werden.

Nun ist der Aufbau des Clusters aber nicht unbedingt so gestaltet dass man ohne Probleme die Hand hinein stecken kann um ein Kabel auf einen 3-Pin-Header aufstecken zu können.

Es wird also ein Kabel benötigt das dort dauerhaft angebracht bleiben kann. Nun man könnte jeweils umstecken, sollte ein Problem auftreten sein.

Da aber die Probleme nicht wiederholt sondern jeweils nur einmal ausgegeben werden, müsste man nun bei jedem Start je ein Gerät und auch nacheinander und über einen Adapter, vor dem Einschalten der Node anschließen und die BootUp-Meldungen einzeln beobachten.

Da mir persönlich aber solche wiederkehrenden und immer gleichen Aktivitäten furchtbar großen Spaß machen, kam mir die passende Idee.

Ich benötige nicht nur eine Möglichkeit mit der die UART-Verbindungen der Embedded-Systemen einzeln aus dem Cluster-Gehäuse heraus verfügbar zu machen, sondern auch gleich intern automatisch mitloggt und für einen späteren Zeitpunkt zur verfügbar stellt.

Nun soll dabei das zuverlässigste Teil im Cluster der Master sein, welcher im idealen Fall nicht beobachten muss. Das definiere ich mal so, unabhängig davon ob der Cubietruck tatsächlich das stabilste System ist in dem Rechner-Verbund.

Da dieser aber nicht über die benötigten sechs U(S)ART-Eingänge verfügt, muss auch hier noch eine Lösung gefunden werden.

Man könnte nun sechs USB zu UART-Wandler kaufen und diese mittels einem USB-Hub an den Master anschließen was aber leider nur zu noch mehr Kabel im Gehäuse führt und ich absolut vermeiden möchte (man denke an den Platzmangel).

Die nächste Alternative, welche mir sehr schnell in den Sinn gekommen ist, ist eine Art Multiplexer für UART zu benutzen. Also ein Gerät dass in der Lage ist zwischen mehreren U(S)ART-Leitungen umzuschalten oder parallel puffern zu können.

Die Letztere Variante bedeutet jedoch deutlich mehr Aufwand bei der Umsetzung und beide Varianten sind am Markt schlicht nicht verfügbar.

Der nächste Schritt ist es nun also gewesen eine Elektronik zu entwerfen die in der Lage ist den eben genannten ersten Fall umzusetzen. Ein Gerät das in der Lage ist zwischen mehreren U(S)ART-Schnittstellen umzuschalten und am besten gleich noch mit integrierter USB-Schnittstelle, über die das System auch steuerbar ist.

Dabei herausgekommen ist meine USB2SerialMux - Schaltung. Auf diesem befindet sich ein AVR ATMega32U4 Mikrocontroller von ATmel, ein Spannungsregler, diverse Kondensatoren, LEDs und zwei HCT7451 8-Kanal Multiplexer.

Die Multiplexer sind jeweils mit acht Pins einer Pinheader-Reihe verbunden, eine weitere Reihe von 8 Pins ist für den GND-Anschluss vorhanden.

Einer der Muxe ist mit der USART-RX-Leitung des Mikrocontrollers verbunden und der andere Mux mit der TX-Leitung des AVR.

Weiter sind die beiden Multiplexer jeweils parallel mit insgesamt drei Steuerleitung des AVR verbunden. Damit sind die 8 Steuerleitungen der Muxe einzeln auswählbar.

Auf der ersten Version der Platine ergaben sich trotz der einfachen Schaltung ein paar grobe Fehler welche vermieden hätten werden können. So hatte ich schlichtweg den ISP-Header nicht eingeplant, die Ground-Leitungen des AVR gar-nicht erst verbunden und an dern Multiplexern einen weiteren Spannungs-definierenden Eingang mit VCC statt GND verbunden.

Diese Fehler waren jedoch schnell korrigiert, das Ergebnis kann sich trotzdem sehen lassen.

Auf dem neuen Layout der Platine sind diese Fehler natürlich allesamt behoben. Weiter habe ich diverse optionale Widerstände verschiedene Leitungen eingeführt um die Multiplexer ggfls. etwas schützen zu können.

Die Software des Mikrocontrollers besteht im wesentlichen aus einem LUFA Dual VirtualSerial Demo-Programm, welches ich so angepasst habe dass man auf dem einen virtuellen seriellen Port die empfangenen Daten meiner Nodes sehen kann, und auf einem zweiten seriellen Port mittels Steuerkommandos den Multiplexer-Kanal auswählen und die benötigte Baudrate festlegen kann.

Da die Bedienung per Terminal-Programm und der Verwendung eines binären Kommunikationsprotokolls - welches ich dazu implementiert habe - jedoch nicht ganz komfortabel ist, habe ich zudem ein Python-Script geschrieben mit dem die Einstellungen problemlos per Kommandozeile vorgenommen werden können.

Der findige Windows-Anwender kann sich die entsprechenden Script-Aufrufe natürlich auch in verschiedenen Batch-Files per Klick verfügbar machen. Hier die Ausgabe der verfügbaren Parameter:

Wie im vorhergegangenen Screenshot zu sehen ist kann mittels diesem Script die Baudrate der Verbindung zu den angeschlossenen Systemen verändert werden, sowie die aktuell zu verbindende Multiplexer-"Leitung" gesetzt und jeweils ausgelesen werden. Damit sind auch unterschiedliche Baudraten möglich, indem man vor dem umschalten bereits die Baudrate auf die benötigte umstellt.

Für den Cluster bedeutet dies nun das lediglich die sechs 3-Pin-Header mit der USB2SerialMux - Platine verbunden werden müssen und diese dann mit dem Cluster-Master. Und dieser kann dann mit Hilfe von verschiedenen Tools - zeit-gesteuert ab dem Zeitpunkt des Einschaltens der ersten Node - durch die einzelnen Kanäle des Multiplexers schalten und die empfangenen Daten entsprechend für die spätere Verwendung loggen. Auch hierzu existiert bereits ein kleines Shellscript welches ebenfalls im Tools-Ordner im Repository liegt. 

Das Projekt ist wie gewohnt auf git.okoyono.de verfügbar. Ebenfalls ist die aktuelle Version des benötigten des Bootloaders verfügbar und diverse Screenshots wie die Fuses des AVR über den ISP-Header gesetzt werden müssen, NACHDEM der neue Bootloader per ISP auf den AVR übertragen worden ist.

Die Platinen können direkt von OSHPark bestellt werden. Eine Liste der benötigten Bauteile kann dem Schaltplan (KiCAD) entnommen werden.

Hier noch ein Bild der fertigen Platine in der ersten Version, mit den oben genannten Korrekturen...

Und hier noch eine 3D-Darstellung der aktuellen Version v0.2, welche bei OSHPark bestellt werden kann.

Eine fertig aufgebaute Version inklusive aller Bauteile und deren Aufbau und Test kann ich aus zeitlichen Gründen leider nicht anbieten.

#ChinaCluster impressions

Die neue Frontplatte im schlichten Aluminium-Lochblech, mit dem 2.2" TFT, drei Tastern und zwei USB- und einem HDMI-Anschluss. Das lila Leuchte ist eine Kombination der roten Power-LEDs und der ultra-hellen blauen LED des eingebauten USB-Hubs.

Hier nochmal deutlich heller aufgenommen.

In der Rückwand sind zwei Ethernet-Anschlüsse eingebettet. Einer führt auf den Cubietruck und der zweite direkt auf den internen Netzwerk-Switch.

In meinem vorherigen Post habe ich  über die Strommessung geschrieben. Der neu montierte OrangePi One (mit der rot leuchtenden LED) fungiert als Datenbank-Server.

Hier eine Übersicht über alle Messdaten die per Grafana dargestellt werden, damit entgeht einem keine Auffälligkeit.

Im dunkeln entfaltet sich dann ein ganz andere Atmosphäre.

Da Aaron mit ja ein schickes Gehäuse für den Cluster baut, benötige ich einige Adapterplatinen. Unter anderem habe ich einen um den HDMI-Anschluss des Cubietrucks nach außen an der Gehäuse zu führen. Leider ergaben sich dabei kleinere Störungen die ich aber mit ein klein wenig Aluminiumfolie beheben konnte.

Cubietruck GPIO with python und SWIG

Um für meinen ChinaCluster diverse externe Hardware steuern und auslösen zu können benötigte ich vor einiger Zeit eine Möglichkeit auf das GPIO-Subsystem des Cubitrucks zugreifen zu können. Dieser ist das Master-System im Cluster.

Für die Implementierung von Software in C/C++ sind die beiden folgenden Quellen die grundlegenden Informationen zum Ziel. Das allgemeine Cubietruck Tutorial und das Cubieboard GPIO tutorial. Ich jedoch würde gerne per Python - und das ohne möglichst alles neu implementieren zu müssen - auf das GPIO-System zugreifen.

Theoretisch gibt es bereits ein WiringCB-Projekt, welches theoretisch ein GPIO-Interface für Cubieboards bereitstellen sollte, in meinem Fall funktionierte dies jedenfalls in keinem meiner Tests.

Was tun also wenn es keine adäquate Lösung gibt? Selbst umsetzen. Daher habe ich hier bereits ein Repository eingerichtet mit dem per Python auf das GPIO-Subsystem - zumindeste meines Cubitrucks - zugegriffen werden kann.

Letztendlich basiert diese Lösung darauf das ich um die C-Implementierung von Stefan Mavrodiev einen Python-Wrapper gelegt habe. Der gängige Weg ist dabei wohl diesen mittels SWIG, unter Zuhilfename eines .i-Files in dem alle zu exportieren Elemente aus der ursprünglichen Library aufgelistet bzw. definiert werden, den Wrapper automatisch generieren und kompilieren zu lassen. Wichtig ist hierbei ein Setup-File manuell erzeugt zu haben in dem die Eigenschaften der neuen GPIO-Library definiert sind. Das Repository beinhaltet eine sehr übersichtliche Umsetzung und kann so ggfls. theoretisch als Beispiel dienen.

Spezielle Software-Pakete habe ich auf dem Armbian des Cubitrucks nicht installiert. Lediglich Python, pypy swig und make und der gcc sollten installiert sein.

Meine Software kann simpel mittels make durchgeführt werden. Achtung, es wird jeweils die Python und pypy-Version der Library kompiliert. Benötigt man beispielsweise die Python-Version kann man diese Zeile einfach im Makefile auskommentieren. Hat man make als normaler User ausgeführt und bereits ausreichend Rechte auf das GPIO-Subsystem wird zudem der automatisch ausgeführte Library-Test ohne Fehlermeldungen ausgeführt. Ansonsten bleibt einem nur der Weg über den User root.

Fazit zum ChinaCluster und OpenMPI

ChinaCluster-Fazit

Meine Erfahrungen der letzten Wochen beim Aufbau der Konfiguration und dem Ärgern über meinen ChinaCluster möchte ich hier niemandem vorenthalten.

Ich war ehrlich gesagt zunächst etwas skeptisch was die Qualität der Produkte aus China angeht. Die Kosten derer waren sehr viel geringer - um nicht zu sagen sogar drastisch. Die Verarbeitung wirkte an der einen oder anderen Stelle - im Vergleich zu teureren Produkten die aus dem europäischen Markt verfügbar sind - etwas weniger robust und hochwertig. Was meine Erfahrung mit den Teilen angeht habe ich jedoch noch keine wirklichen Nachteile gefunden, außer einem: Die 2,50€ Micro SD-Karten sind sehr empfindlich. Trennt man von einem der Embedded Systems die Spannung während gerade ein Zugriff auf eine der Karten erfolgte kann es durchaus sein das weite Teile der Speicherbereiche irreparabel beschädigt werden. Also nicht so dass ein Einfaches zurückspielen des Journals Abhilfe   schaffen würde, nein der Speicher ist komplett defekt. Ich werde an dieser Stelle noch ein paar Tests machen ob ich das Problem zuverlässig reproduzieren kann.

Für die Zukunft werde ich vorsichtshalber jedoch auf Markenprodukte (zumindest bei SD-Karten)  setzten - und auch mal hier prüfen ob sich diese ähnlich leicht in meinen Cluster-Nodes zerstören lassen.

Bei den Netzwerkkabeln hatte ich damals bewusst die kürzesten und billigsten bestellt gehabt - diese sind blau. Und ich vermute mal dass diese - aufgrund der fehlenden Schirmung - nicht für professionelle Zwecke genutzt werden sollten. In meinem Fall habe ich die 50 cm langen Kabel noch weiter gekürzt, so dass diese nun insgesamt nicht mehr als Länge von jeweils 15-20 cm haben. Damit sollten sich die Probleme welche durch die fehlende Schirmung entstehen weiter minimieren. Bei meinem Performance-Test des Netzwerks sind mir jedenfalls keine Probleme oder  Geschwindigkeits-Einbußen aufgefallen. Die 100MBit - Verbindung ist stabil. Auch der 13€ 10/100 MBit Netzwerk-Switch arbeitet problemlos.

Was das 2,2" TFT Display angeht ist mir aufgefallen das sich nach einiger Zeit der Klebstoff löst welcher die Frontscheibe am Gehäuse festhält. Damit steht diese Scheibe etwas ab was dazu führt das viel Licht der Hintergrundbeleuchtung an den Seiten heraus leuchtet. Nichts was man jedoch nicht mit einem Tropfen Klebstoff oder einem Klebestreifen reparieren kann. Zudem ist dieses Problem mit der Verarbeitung obsolete sobald das Display in ein Gehäuse eingebaut wird.

Auch die OrangePi PCs sind durchaus zuverlässig. Deren Leistung mit den 4 CPU-Cores welche permanent auf 1,5 GHz laufen ist ordentlich. Das RAM mit einem Gigabyte ist jedoch etwas knapp bemessen, im Vergleich dazu hat mein Cluster-Master - ein Cubietruck - bereits 2 GB RAM. Was definitiv zu bemängeln ist das der Support und die Community für diese Plattform nicht sonderlich groß ist. So das Kernel-Updates quasi nicht stattfinden, und viele Features welche man sich wünschen würde für die Hardwareunterstützung nicht umgesetzt sind. Die letzten offiziellen Updates der Installations-Images fand beispielsweise Mitte 2015 statt, was zum Zeitpunkt zu dem ich diesen Artikel schreibe etwa 10 Monate her ist. Nichtsdestotrotz ist, vom Kernel und dessen Features abgesehen, die restliche Software welche aus den Debian/Ubuntu Paket-Quellen kommt aktuell und zuverlässig. Was dazu führt das die OrangePi PCs dennoch brauchbar sind, sie können recht performant Probleme abarbeiten.

OpenMPI

Schon interessanter war es eine aktuelle Version von OpenMPI.org zu installieren bzw. zu  kompilieren und auch verwenden zu können. Die Tutorials im WorldWideWeb beschreiben nur den Standard-Fall - wenn man zuvor Unmengen an Libraries installiert hat und die Software direkt in das Root-Filesystem hinein installiert. Klar dann muss man keine PATH-Variable oder den LD_LIBRARY_PATH anpassen und auch sonst nichts im System verbiegen. Die Alternative welche  die Debian-Paketen bieten sind - wie auch anders zu erwarten leider veraltet - wodurch diese ausscheiden.

Meine Lösung ist das ich OpenMPI direkt unter /opt installiere, die System-Variablen anpasse und damit auch bei einem Versions-Wechsel simpel einfach alle Inhalte überschreiben kann. Auf der Master- und den Slave-Nodes wird jeweils das identische Software-Paket verwendet, so dass hier keine Inkompatibilitäten entstehen. Konfiguriert wird OpenMPI mit der Option „--prefix=/opt“. Wobei ich bereits DistCC zum kompilieren verwende, was jedoch auch dazu führt das zukünftig auch alle per mpicc kompilierten Projekte per DistCC verteilt kompiliert werden - ein netter Seiteneffekt. Das Konfigurieren per configure-Script und das kompilieren/installieren gestaltet sich simpel - nämlich durch warten das es fertig ist.

Spannend wird es erst bei der Konfiguration der Cluster-Nodes und des Masters. Das Problem ist das die PATH-Variable angepasst werden muss um auch direkt Programme aus /opt/ bin ausführen zu können, ohne den kompletten Dateipfad angeben zu müssen. Wer per „ssh user@host“ jedoch eine Software ausführen möchte stellt recht schnell fest das Kommandos einfach nicht gefunden werden.
Das liegt daran das SSH nur eine „abgespeckte“ Variante der Umgebungsvariablen in diesem Fall zur Verfügung stellt.

Erst im Fall eines direkten User-Logins wird beispielsweise die bash das Environment anhand der bashrc usw. einrichten. Damit jedoch das Problem behoben wird kann man - simpel - eine Konfigurationsdatei von SSH verwenden, die /etc/environment. In diese trägt man einfach die benötigten Variablen ein die man gerne gesetzt haben möchte. Das ganze wird zeilenweise untereinander geschrieben, wie im folgenden Beispiel:

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/opt/bin:/opt/hadoop/bin:/opt/hadoop/sbin:/mnt/cluster/bin"

Hier können auch andere Variablen hinein, wie z.B. JAVA_HOME, HADOOP_INSTALL, usw.

Für den Master sind noch die folgenden Einstellungen für die bashrc notwendig:

export C_INCLUDE_PATH=/opt/include
export CPATH=/opt/include
export CPLUS_INCLUDE_PATH=/opt/include

In der /etc/ld.so.conf.d/openmpi.conf ist dann noch der Pfad zu den Shared-Libraries einzutragen, sonst wird das Linken der Software nicht funktionieren:

/opt/lib

Mit diesen Einstellungen ist dann auch das fehlerfreie kompilieren von C/C++ Software möglich die OpenMPI verwenden.

Wie in den umherkursierenden Tutorials ersichtlich ist greifen die Tools für die Verwendung von OpenMPI per SSH auf die anderen Nodes zu. Damit ist es notwendig dass ein Login per SSH ohne Passwort - also per authorized_key - möglich ist. Verwendet man dazu mpirun oder mpiexec kann man per -H - Option einfach user@host angeben. Gleiches ist jedoch auch in der mpihosts möglich. Hier können nicht nur Hosts und deren verfügbaren Slots angegeben werden - sondern auch der User mit dem in das System eingeloggt werden soll. Also wie folgt:

mpi@Node01 slots=4
mpi@Node02 slots=4
mpi@Node03 slots=4
mpi@Node04 slots=4
mpi@Node05 slots=4

Damit ist die Installation und Konfiguration von MPI bereits abgeschlossen, so dass dieses direkt verwendet werden kann. Jedenfalls aus C/C++ - Code heraus. Möchte man beispielsweise - wie ich - Python verwenden muss man noch die Hürde nehmen und sich MPI4PY - am besten in der neuesten Version (aktuell 2.0.0) installieren. Dies geschieht indem man lediglich „python setup.py build; python setup.py install“ eingibt. Über die Examples und Demos kann man daraufhin prüfen ob die Installation, wie auch bei OpenMPI, funktioniert. Wenn jemand ein Python-Derivat wie pypy verwenden möchte ersetzt man lediglich beim Aufruf des setup.py - Scripts den Interpreter.

An dieser Stelle möchte ich noch deutlicher darauf hinweisen das dieser Post nicht dazu da ist eine detaillierte Installationsanleitung für OpenMPI abzubilden, diese gibt es wie Sand am Meer im Internet zu finden. Ich möchte hier nur auch die speziellen Details hinweisen welche mir persönlich die Installation der Software erschwert hatte.

ChinaCluster - Aufbau der Hardware

Mit dem ChinaCluster bin ich in den letzten Tagen recht gut vorangekommen. Der Aaron hat mir seine überragend gute Arbeit zugesendet. Und zwar einen Sockel mit bereits darauf aufgebauten Halterungen für die OrangePi - Nodes, das Netzteil, den Netzwerk-Switch, das Relais-Board und die Platinen zur Verteilung der Spannung des Netzteils zur Stromversorgung aller Komponenten.

Ich bin sehr begeistert von der Optik, der Verarbeitung und den vielen Details die Aaron eingearbeitet hat - sogar einen Dummy um die Abmessungen des Cubietruck nachzubilden hat er für den Aufbau hergestellt.

ChinaCluster

Hier ein paar Bilder von den Details.

Der Cubietruck-Dummy

Die Stromverteiler-Platine

Relais-Board

Netzteil

Die Halterungen für die Nodes

Netzwerk-Switch

Da Aaron bereits alle Komponenten fertig aufgebaut hatte konnte ich direkt mit der Verkabelung starten und die Position des Cubietruck - der noch zwei Zusatzplatinen aufgesteckt hat - festzulegen und einzurichten.

Aufgrund der enormen Abmessungen sitzt der Cubietruck doch an einer anderen Stelle als zuvor, wo er jedoch aufgrund der zusätzlich an diesen befestigten Platinen weniger Platz benötigt.

Neue Position vom Cubietruck

Die Verkabelung war insgesamt weniger spektakulär. Die Netz-Leitungen wurden mit entsprechend isoliertem flexiblen Kabel gelegt, dabei habe ich Kabelschuhe verwendet um den Netzschalter - in den auch gleich die Kaltgerätebuchse und eine 1A Sicherung integriert ist - an das Netzteil anzuschließen.

Kabel am Netzschalter/der Kaltgerätebuchse

Verkabelung am Netzteil

Die Platinen zum versorgen einzelner Komponenten sind mit jeweils zwei Adern an das Netzteil angeschlossen, die Verbindung wird auch hierbei über Schraubklemmen bewerkstelligt.

Stromverteiler-Platinen mit Verkabelung

Der Cubietruck und der Netzwerk-Switch sind direkt mit dem Netzteil verbunden.

Die OrangePis, der Cubietruck sowie der Netzwerk-Switch werden jeweils über DC-Stecker mit Spannung/Strom versorgt und erhielten jeweils einen Ground-Leitung. Die 5V führenden Zuleitungen werden für die OrangePis über das Relais-Board gesteuert. Die Steuerleitungen des Relais-Boards laufen von der Platine direkt auf eine der Erweiterungs-Platinen am Cubietruck. Nicht jedoch die Spannungsversorgung der Relais-Platine. Diese ist gesondert an 5V und GND angeschlossen.

Relais-Board mit Verkabelung

Der wohl am unhandlichste Teil der Verkabelung sind aktuell noch die Netzwerkkabel. Diese sind mit ihren 50cm drastisch zu lang. Auch ein aufrollen und wickeln hilft nicht darüber weg das diese übermäßig über die definierten Dimensionen des Innenlebens herausragen. Hier muss noch eine Lösung geschaffen werden, am einfachsten kürzt man die Kabel und Crimpt diese auf einer Seite neu.

Die maximale Länge welche noch zu verlegen wäre, aber nicht stören würde liegt bei etwa 15-20cm.

Netzwerkkabel-Größe

Auch das TFT-Display und das MX-Board haben bereits einen Anschluss gefunden und sind bereit um später, sobald die Wände des Gehäuses und der Deckel das Cluster fertiggestellt sind, eingebaut zu werden. Die Aktuelle provisorische Position sieht man im folgenden Bild.

MX-Board und TFT-Display

Zum Status der Software kann ich die folgenden Punkte nennen:

• Alle Nodes verfügen über eine 8GB SD-Karte von denen das darauf installierte Linux gestartet werden kann (armbian basierend).
• Der Cubietruck bootet ebenfalls von einer 8GB SD-Karte ein Linux (armbian).
• Die ChinaCluster Management Software läuft auf dem TFT-Display und ist mit den Tastern auf dem MX-Board bedienbar.
• Die ChinaCluster Management Software kann die Nodes und den Cubietruck steuern (reboot shutdown reset), teils per SSH oder über das Relais-Board.
• Die ChinaCluster Management Softwareüberwacht den Zustand der Nodes per ICMP-Ping.
• Die Cluster-Nodes erhalten per DHCP-Server eine Cluster-Interne IP-Adresse (gesondertes Netzwerk).
• Der Cubietruck ist Firewall und Router für die Cluster-Nodes, welche per NAT auf das externe Netzwerk zugreifen können.
• Der Cubietruck stellt per NFSD für das Clustering spezifische Software (z.B. OpenMPI) für alle Nodes bereit.
• Beim Systemstart des Cubietruck wird eine Sequenz gestartet welche nach und nach die Nodes einschaltet und booten lässt.
• Die Netzwerkverbindung des Cubietruck in mein Intranet wird gerade über WLAN hergestellt. Mit dem ChinaCluster Manager ist es jedoch möglich auf die zweite LAN - Schnittstelle umzuschalten. Diese wird über einen USB zu LAN - Adapter bewerkstelligt da die Cubietruck-eigene bereits für das interne Netzwerk verwendet.

Aktuell arbeite ich daran mein Management-Tool - welches die Cluster-Nodes automatisch auf meine Anforderungen konfigurieren und aktuell halten soll. Ich werde bei Gelegenheit und nach entsprechendem Fortschritt darüber berichten.

Das aktuelle Gesamtsystem