Mittwoch, 13. April 2016

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.

UpConverter fixed

Vor einiger Zeit berichtete ich darüber das mein Versuch einen UpConverter für mein rad1o zu bauen leider fehlgeschlagen ist. Es lag an der...