Hauptseite

Aus Meisterkuehler BOINC Wiki
Wechseln zu: Navigation, Suche

Mk-Header.gif


Eigenbau Cluster mit 200GHz in einem Tower-Gehäuse - günstig und effizient!

Inhaltsverzeichnis

"Wer" oder "Was" ist der EMK2

"Wer" ist dieser EMK2 und "Was" bedeutet EMK2

Revision 1.1 mit 14 Blades und "neuem" Halte-System

Im Endausbau wird der EMK2 aus 14 Mini ITX Systemen (bestückt mit je einem AMD Phenom II X6) bestehen, welche in einem modifizierten ATX-Case untergebracht sind und von nur einem Netzteil versorgt werden. Dabei wird besonders hoher Wert auf Effizienz gelegt.

EMK2 ist der Rechnername, mit dem dieser im BOINC-Netzwerk identifiziert wird und in den Statistiken erscheint. Da bei der Anmeldung des Rechners, wie bei so vielen Eingabe-Masken, nicht alle Zeichen frei gegeben sind, wurde aus E=MK² der EMK2.

E=MK² ist an eine spezielle Relativitätstheorie Einsteins(E=mc²) angelehnt, die das Verständnis von Raum und Zeit revolutionierte. Einsteins Werke führten zu einer Revolution der Physik; die spezielle und die allgemeine Relativitätstheorie gehören bis heute zu den Grundpfeilern der modernen Physik. Für die Auswahl des Rechner-Namens haben wir diesen bewusst an die allgemein bekannte Formel der Relativitätstheorie angelehnt, auch wenn beide wenig gemeinsam haben.

Im Gegensatz zur ursprünglichen Formel steht das „E“ in erster Linie für Effizienz, MK selbsterklärend als Abkürzung für Meisterkühler und das „²“ soll die einzigartige, besondere Community und deren Einsatz, Enthusiasmus und Zielstrebigkeit bei der Umsetzung des Projekts widerspiegeln.

Wie alles begann

Am 18.05.2010 wurde von Jabba ein Thread mit dem Titel: Der Super-Boinc-Rechner-Bastelfred eröffnet. Der Grund für diesen Thread war das Abschneiden und die Teilnahme des Meisterkuehler.de Teams beim von SETI.Germany veranstalteten 1.BOINC-Pentathlon. Vergeblich hatten wir damals um ein Pünktchen bei dem spannenden Race, bei dem wie im antiken Griechenland 5 Disziplinen innerhalb von 2 Wochen, jeweils 5 Tage lang gerechnet wurden, gerungen. Wir haben feststellen müssen, dass uns einiges an CPU Power fehlte, um unserem Ziel ein Stückchen näher zu kommen. Die Idee zum Bau eines Super-BOINC-Rechners war geboren...

Welche Aufgabe hat der EMK2

Der EMK2 steht im Dienste der Wissenschaft und ist ein Teil der BOINC Software-Plattform. Die Berkeley Open Infrastructure for Network Computing (kurz BOINC) ist eine Software-Plattform für verteiltes Rechnen. Sie wird an der Universität Berkeley entwickelt und ermöglicht es, die ungenutzte Rechenleistung von vielen tausend Computern über das Internet oder Intranet verfügbar zu machen. Dies geschieht in Form von Projekten, die meist gemeinnützig arbeiten und von Universitäten oder anderen Institutionen betreut werden. Die derzeit rechenintensivsten Projekte umfassen unter anderem Berechnungen zur Erstellung eines genauen 3D-Modells der Milchstraße, die Suche nach Außerirdischen, Berechnung von Gravitationswellen, Vorhersagen zur Klimaentwicklung, sowie die Simulation von Proteinfaltungen für die Erforschung von neuen Medikamenten.

Wie wird diese Aufgabe gelöst

Der E=mk² ist ein Diskless Computercluster das auf [www.aptosid.de aptosid] basiert. Aptosid bietet von Haus aus die Möglichkeit ein Live-System diskless, also ohne Festplatte nur über das Netzwerk via NBD, zu booten. Aptosid, eine extrem aktuelle Debian Distribution, bringt zusätzlich sehr aktuelle Kernel und Boinc-Software mit.

Um Aptosid für die Clients Cluster-fähig zu machen müssen nur minimale Änderungen an einer Startdatei im Aptosid-Image vorgenommen werden. Die Clients booten ansonsten genau die Live-CD wie man sie direkt von der Aptosid-Webseite herunterladen kann. Dadurch ist ein späteres Update der Software sehr einfach.

Nur auf dem Server, auch Steuerblade genannt, ist die Aptosid-Distribution auf der SSD normal installiert. Für alle Clients wird das abgeänderte Original-Image per DHCP/PXE und NBD zur Verfügung gestellt. Wenn ein Client bootet bekommt er zuerst eine IP-Adresse per DHCP zugewiesen und bootet dann das Image per NBD vom Server. Am Ende des Boot-Vorganges startet auf dem Client ein Skript, dass alle restlichen Einstellungen erledigt und BOINC automatisch startet.

Alle Clients booten dabei ein und das selbe Image. Da alle Clients das Image Read-Only booten werden auf der SSD für das Betriebssystem aller 13 Blades nur ca. 600MB verbraucht. Insgesamt also incl. Server werden nur etwa 2 GB benötigt. Aller restlicher Platz auf der SSD wird den Clients, ebenfalls per NBD, für Boinc-Anwendungen und Boinc-Zwischenergebnisse zur Verfügung gestellt.

Die Temperaturen und die Auslastung der Clients werden mit collectd vom Server überwacht. Boinc-Einstellungen kann man im laufenden Betrieb sowohl per boincmgr oder boincphpgui ändern.

Um die Clients per Web-Interface Ein- und Ausschalten zu können wird ein USB-I/O-Modul verwendet, dass mit dem Power-Switch- und Power-LED-Pfostenstecker der Client-Mainborads verbunden ist.

Text-Passagen in 1.1 und 1.3 aus: wikipedia.org

"Welche" und "Warum" ausgerechnet diese Hardware

Stromversorgung

Der Reihe nach von der Steckdose aus:

EM600 & Webcam

PSU

Der gesamte Cluster hängt an einer Steckdosen-Leiste, die man per Web-Browser fern steuern kann. Auf diese Weise lässt sich der Cluster im Worst-Case komplett ausschalten und wieder neu starten. Das Managment-Blade wurde dazu im BIOS auf "ON after Power-Fail" gestellt.

Strommessgerät (mit "Webserver")

In das Netzkabel ist ein Strommessgerät, EM600 Expert II von ELV, eingeschleift, auf dessen Display eine Webcam gerichtet ist. Da die Webcam per USB am Steuerblade hängt kann man jederzeit den aktuellen Strom-Verbrauch auf den Webseiten des Steuerblades sehen. Das ist insbesondere für Takt- und Spannungs-Optimierungen von großem Vorteil.

ATX-Netzteil

Corsair NT & Switche
Effizienz vom AX1200

Als Netzteil wurde das Corsair AX 1200 ausgewählt, weil es zu der Zeit eines der wenigen 80+ Gold zertifizierten Netzteile mit vollständig abnehmbaren Anschlüssen war.

An 230 Volt bei ca. 800 Watt hat es einen Wirkungsgrad von annähernd 92%.

Das Netzteil wurde "überbrückt" (siehe Stecker links unten im Bild), es ist daher immer eingeschaltet wenn man es an der Rückseite des Gehäuses mit dem Wipp-Schalter einschaltet, und stellt so den Strom für alle anderen Teile des Server bereit. An den Anschlüssen in den oberen beiden Reihen (siehe Bild) stehen auf der linken Seite 32 mal 12 Volt und Masse sowie auf der rechten Seite eine Mischung aus 12 Volt, 5 Volt und 3,3 Volt zur Verfügung.

PICO an ATX NT

PICO am ATX

Für die Picos haben wir das original Kabel-Management zerlegt. Das Netzteil selbst ist (bis auf einen Lüfter-immer-Max-Drehzahl-Mod) noch original. Am Netzteil siehst man oben links 8 Stecker mit je 4*Masse und 4*12Volt. An je einem dieser Stecker sind 4 PICOs, winzig kleine ATX-Netzteile mit 12 Volt Eingang, angeschlossen. Die mit dem Netzteil gelieferten Kabel wurden an der PICO-Seite abgeschnitten und die PICOs mit je einer Sicherung direkt an das Kabel gelötet.

Brücke ATX-P4

PICO zum Mainboard

Die PICOs haben zwar einen P4 Stecker, der wurde aber nicht verwendet. Um die Anzahl der Kabel und Stecker im Gehäuse minimal zu halten wurde eine Brücke direkt auf die Main-Board-Rückseite vom ATX-Anschluss zur P4-Buchse gelötet.

Fazit

Vorteil: Es wird nur ein einziges ATX-Netzteil benötigt. Dadurch wird eine so große Anzahl von Blades in einem so kleinen Gehäuse überhaupt erst möglich. Ferner arbeitet das Netzteil so mit optimaler Auslastung und damit sehr Effizient. Da zu jedem Blade nur zwei Kabel, 12Volt und Masse, verlaufen wird die Anzahl der Stromkabel minimiert. Nachteil: Das ganze Blade darf nicht (viel) über 6 Ampere an Strom verbrauchen (=72 Watt), damit bewegt man sich eben gerade so unterhalb der Belastbarkeitsgrenze der Molex-Steck-Kontakte am Netzteil und am Übergang von den PICOs zu den Blades. Die PICOs selbst könnte man bei entsprechender Kühlung sogar noch etwas stärker belasten. Kurzzeitig, z.B. beim Booten bis die Strom-Spar-Maßnahmen greifen, darf ein Blade jedoch bis zu 120 Watt verbrauchen. Innerhalb des Gesamtkonzeptes relativiert sich diese Einschränkung jedoch, weil bei 14 Blades an einem 1,2-kW-Netzteil, abzüglich der Lüfter, Switche etc., ohnehin nur ca. 75 Watt pro Blade zur Verfügung stehen. Als Ziel wird ein Gesamt-Verbrauch von ca. 800-900 Watt angestrebt. Tatsächlich verbraucht jedes der verwendeten Blades unter BOINC-Voll-Last, bei im BIOS deaktivierter Grafik, leicht gedrosseltem Takt und abgesenkter Core-Spannung, nur etwas über 50 Watt.

Ein-/Ausschalten

Das Management-Board kann man nur am Gehäuse ein- und ausschalten. Alle andern Blades werden über die normalen Stift-Leisten auf dem Blade, die über ein Flachbandkabel an einem USB-I/O am Management-Board hängen, per Software ein- und ausgeschaltet. Wie oben beschrieben werden alle Eingänge der PICOs immer mit Strom vom ATX-Netzteil versorgt und schalten die Blades genau so wie das auch normale ATX-Netzteile in einem normalen PC mit Power-Taste machen würden.

Blades

Einer der vielen Entwürfe der Rev. 1.1
Revision 1.1 mit 8 Blades und "neuem" Halte-System
Revision 1.0, hier noch mit 6 Blades und "altem" Halte-System


Um mehrere Blades waagerecht in ein Standard-ATX-Gehäuse einbauen zu können müssen die Mainboards Mini-ITX-Format haben, dürfen also nur 17cm x 17cm groß sein. Zum Vergleich ein 5 1/4" Laufwerkseinschub ist etwa 13cm breit. Da wir ein etwas großzügigeres Tower-Gehäuse gewählt haben verbleibt neben den Blades sogar noch 1-2 cm Platz bis zur Seitenwand das Gehäuses.

Zu Zeit der ersten Planungen waren nur wenige ITX-Mainboards mit AM3 Sockel verfügbar. Die gewählten Mainboards von Sapphire akzeptieren zudem Standard-DDR3-RAM, diese sind günstiger als SO-DIM, und die RAM-Riegel verlaufen im 90-Grad Winkel zur ATX-Blende und damit in Gehäuse-Längs-Richtung, was vermutlich den Luftstrom zur CPU weniger hemmt. Die Einbaulage der ITX-Boards, mit der ATX-Blende zur Gehäuse-Rückseite, wurde so gewählt um genügend Platz für die Netztwerk-Kabel mit Stecker zu haben und die PICOs, die mini ATX-Netzteile, optimal im Luftstrom kühlen zu können. Die Sapphire ITX sind vom Hersteller für den professionellen Einsatz gemacht, im Unterschied zu Heim-PCs werden etwas hochwertigere Komponenten, dickere Kupfer-Leiterbahnen etc. verbaut. Durch diese Tatsachen verlängert sich hoffentlich die Laufzeit (bzw. die MTBF) im 24 Stunden-Betrieb. Ein Nachteil der Industrie-Mainboards sind jedoch die üblicherweise nur sehr spärlichen BIOS-Einstell-Möglichkeiten. Glücklicherweise kann man aber viele der Einstellungen, z.B. CPU-Takt und CPU-Spannung, auch nach dem Booten mit Software nochmals ändern.

Während der Planung der Gehäuses-Aufteilung wurde neben einem optimalen Luftstrom stets darauf geachtet, dass die Blades einzeln ausgewechselt werden können. Um das zu gewährleisten wurden die Anzahl der Kabel und Stecker zu den Blades auf ein Minimum reduziert. Jedes Blades wird nur mit drei Steckkontakten verbunden, diese sind je ein Netztwerkkabel, ein 12 Volt-Stromkabel und ein kleines Flachbandkabel, das mit einem Pfostenstecker, genauer den Kontakten zum Ein-/Ausschalten des Blades, verbunden wird.

Als CPU-Kühler wurde der Prolimatech Samuel 17 ausgewählt, weil er bei sehr geringer Höhe, Heat-Pipes und geeigneten Kühlrippen, bzgl. der Luftstrom-Richtung und Abstand zwischen den Kühlrippen, optimale Kühlung auf kleinstem Raum verspricht.

Die Mainboards mussten mit einer aktuelleren BIOS-Version geflasht werden, damit die gewählte AMD Phenom II X6 CPU vom Mainboard erkannt und vollständig unterstützt wird. Für diese CPU sprach einerseits der günstige Preis aber andererseits auch das hohe UV-Potential, also die Möglichkeit unter bestimmten Rahmenbedingungen die CPU-Core-Spannung absenken zu können um die Performance pro Watt erheblich zu steigern. Zu diesen Rahmenbedingungen gehören einerseits sehr geringe CPU-Temperaturen (40-45°C), was auch den verhältnismäßig hohen Preis der Samuel Kühler und Gehäuse-Lüfter rechtfertigt, und andererseits ein leichtes absenken des maximalen CPU-Taktes. Durch diese Maßnahmen lässt sich die Leistungsaufnahme pro BOINC-Credit praktisch halbieren! Damit ist man dann bei sehr günstigem Preis für Mainboard und CPU in etwa gleich auf mit der Konkurrenz von Intel.

Im BIOS der Blades wurden alle unnötigen Komponenten wie Grafik, USB, Soundkarte, etc. deaktiviert und das booten via Netzwerk aktiviert.

Welche Software kommt zum Einsatz

Software

Software-Installation auf Server

SSD partitionieren

Weil die SATA-SSD insgesamt nur 15 Partitionen haben darf wird die SSD wie folgt aufgeteilt:

sda1    Betriebssystem (incl. Boinc Daten vom Management-Blade)
sda2-3  NBD für Blade 01 und 02
(sda4)  (extended)
sda5-15 NBD für Blades 03 bis 13

Die Partitionen sind alle auf 2 MiB aligned. (512 KiB hätten vermutlich auch gereicht)

# fdisk -lu
Disk /dev/sda: 115.0 GB, 115033153536 bytes
255 heads, 63 sectors/track, 13985 cylinders, total 224674128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00001849
  Device Boot      Start         End      Blocks   Id  System
/dev/sda1            4096    67112959    33554432   83  Linux
/dev/sda2        75501568    83890175     4194304   83  Linux
/dev/sda3        67112960    75501567     4194304   83  Linux
/dev/sda4        83890176   224673791    70391808    5  Extended
/dev/sda5        83894272    92282879     4194304   83  Linux
/dev/sda6        92286976   100675583     4194304   83  Linux
/dev/sda7       100679680   109068287     4194304   83  Linux
/dev/sda8       109072384   117460991     4194304   83  Linux
/dev/sda9       117465088   125853695     4194304   83  Linux
/dev/sda10      125857792   134246399     4194304   83  Linux
/dev/sda11      134250496   142639103     4194304   83  Linux
/dev/sda12      142643200   151031807     4194304   83  Linux
/dev/sda13      151035904   159424511     4194304   83  Linux
/dev/sda14      159428608   167817215     4194304   83  Linux
/dev/sda15      167821312   176209919     4194304   83  Linux

Grundinstallation

Aptosid XFCE-Image von CD installieren. Das XFCE-Image ist das kleinste und da ohnehin weder auf dem Server noch auf den Clients die graphische Oberfläche startet ist die Art der Oberfläche egal. Das Image gibt es z.B. hier: XFCE-Image

SSD Trim aktivieren

# vi /etc/fstab
UUID=blablabla  / ext4 defaults,noatime,discard,errors=remount-ro           0    1

Aptosid aktualisieren

# init 1
# apt-get install
# apt-get dist-upgrade

Grub-Config für Server-Boot auf Textmode only ändern

Durch die Änderung an der /etc/grub.d/10_linux wird in das Grub-Bootmenue automatisch eine zusätzliche Textmode-Version init 2 eingefügt.

linux_entry "${OS}" "${version}" false \
"${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
# ULV: insert an additional Textmode-Version
linux_entry "${OS}" "${version}" false \
"2 ${GRUB_CMDLINE_LINUX}"

Zusätzliche ist eine Änderung in /etc/default/grub nötig, damit der neue Eintrag der Standard Standard-Eintrag von Grub wird.

#GRUB_DEFAULT=0
GRUB_DEFAULT=1

aktivieren mit

# update-grub

Die Integration in die Skripte von Grub ist zwar etwas aufwendiger sorgt aber dafür, dass der Server auch nach einen eventuellen Remote-Update des Kernels auf jeden Fall wieder ordentlich bootet. Diese Art Vorsichts-Maßnahmen sind bei Servern, die evtl. weit entfernt vom Systemadministrator stehen sehr zu empfehlen.

OpenVPN zur Fernsteuerung

openVPN installieren mit

# apt-get install openvpn

danach die Preshared-Keys und nötige Config nach /etc/openvpn kopieren.

Details kann man hier nachlesen: OpenVPN HOWTO Ein VPN hat für den Administrator den Vorteil, dass man völlig unabhängig davon wo der Server physikalisch steht und wie der Server ans Internet angebunden ist den Server an seiner immer gleichen VPN-Tunnel-IP administrieren kann. Wenn der Server mal den Standort wechselt muss weder auf dem Server noch beim Administrator eine einzige Konfigurationsdatei geändert werden. Auch die Firewall-Regeln auf dem Server werden dadurch einfacher und übersichtlicher.

Webserver installieren

# apt-get install apache2
# apt-get install libapache2-mod-php5
# apt-get install php5-cgi

Danach die Webseiten nach /var/www und die CGIs nach /usr/lib/cgi-bin kopieren.

# apache2ctl restart

Zugriffsbeschränkung mit htaccess etc.

in /etc/apache2/sites-enabled/000-default wird die Beschränkung für alle Verzeichnisse eingefügt. Dazu noch die Dateien /etc/htacess_passwords* erstellen bzw. kopieren. Details kann man hier nachlesen: Authentication, Authorization and Access Control HOWTO

<VirtualHost *:80>
ServerAdmin webmaster@localhost

DocumentRoot /var/www
<Directory />
Options FollowSymLinks
AllowOverride None
##############################
AuthType Basic
AuthName "By Invitation Only"
AuthUserFile /etc/htacess_passwords
AuthGroupFile /etc/htacess_passwords_groups
Require valid-user
###############################
</Directory>
# apache2ctl restart

Collectd (Server Config) + collection3_cgi-bin

Mit Hilfe des collectd kann man sehr elegant den Server und auch gleich alle Blades überwachen. Es sind sehr viele fertige Module sowohl für die Hardware-Überwachung als auch für Standard-Software verfügbar, die entweder gar keine oder nur minimale Konfiguration erfordern. Gesammelt werden alle üblichen Informationen wie Temperatur, Speicher- und CPU-Auslastung. Mit den collection3 cgi-skripten werden all diese Informationen automatisch und übersichtlich auf dem Webserver sichtbar. Neben der Auswahl der gewünschten Module (oben in der Konfig) sind Einträge für das Sammeln der Blade-Daten über das Netzwerk interessant:

# apt-get install collectd
# apt-get install librrds-perl
# apt-get install libhtml-entities-numbered-perl
# apt-get install libhtml-parser-perl
# apt-get install libconfig-general-perl
# apt-get install libregexp-common-perl

Konfiguration des Servers in /etc/collectd/collectd.conf:

LoadPlugin apache
LoadPlugin cpu
LoadPlugin cpufreq
LoadPlugin df
LoadPlugin disk
LoadPlugin entropy
LoadPlugin interface
LoadPlugin irq
LoadPlugin load
LoadPlugin memory
LoadPlugin network
LoadPlugin processes
LoadPlugin rrdtool
LoadPlugin sensors
LoadPlugin thermal
LoadPlugin users
...
<Plugin network>
<Listen "10.0.0.1" "25826">
Interface "eth0"
</Listen>
</Plugin>
...

Da die Daten ja nur innerhalb des Gehäuses übertragen werden ist eine mögliche Verschlüsselung und Authentifizierung der Blades gegenüber dem Server nicht nötig. Details kann man hier nachlesen: http://collectd.org/

boincphpgui

Um die Boinc-Clients der Blades bequem im Browswer überwachen und fernsteuern zu können gibt es das bereits etwas ältere boincphpgui. Es stellt die aktuellen WUs im Webserver dar. Die funktionalität von boincphpgui in Hinblick auf Diskless-Blades wird stark in Erwägung gezogen, bzw. ist schon in Arbeit. Details kann man hier nachlesen: BoincPHP5-GUI

Netzwerk

Das Server-Blade hat zwei Netzwerkanschlüsse. Einen in Richtung Internet, dort holt sich der Server via DHCP seine Internet-Verbindung so wie es bei den meisten PCs heute üblich ist. Am zweiten NIC ist der Switch, bzw. die Switche angeschlossen. Wir verwenden zwei Switche, weil es leider keinen stromsparenden 16 Port-Switch mit kleinen Abmaßen gegeben hat. Der NIC in Richtung Switch, also auch in Richtung Blades, die alle ebenfalls an den Switchen hängen, ist ein privates Netz (hier 10.0.0.0/24) in dem der Server fest die Adresse 10.0.0.1 hält und den Blades auf Anforderung via DHCP-Server Adressen aus diesem Netz, z.B. dem ersten Blade die Adresse 10.0.0.101 zuweist. An dieser Stelle muss auf dem Server nur das zweite private Netz eingerichtet werden die weiteren Einstellungen für die Blades stehen weiter unten, weil sie nicht in der selben Konfig-Datei des Servers eingetragen werden - siehe "PXE-Bootkram für Blades"

In /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth1
iface eth1 inet dhcp

auto eth0
iface eth0 inet static
address 10.0.0.1
broadcast 10.0.0.255
netmask 255.255.255.0
network 10.0.0.0

Routing

# echo 1 > /proc/sys/net/ipv4/ip_forward

Dadurch wird der Server angewiesen TCP-Pakete zwischen dem Internet und den Blades zu routen. Ohne diese Einstellung kämen die Blades niemals ins Internet.

Damit das dann auch so bleibt noch der Eintrag in /etc/sysctl.conf

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

NAT für die Blades

# iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
# iptables-save > /etc/firewall.conf
# echo '#!/bin/sh' > /etc/network/if-up.d/iptables
# echo "iptables-restore < /etc/firewall.conf" >> /etc/network/if-up.d/iptables
# chmod +x /etc/network/if-up.d/iptables

Da die Blades private Ip-Adressen haben könne sie ohne NAT (Network Address Translation) zwar mit dem Server reden aber kommen nicht ins Internet. Durch das NAT am Server können sich die Blades auch mit den Boinc-Projekten zu verbinden, WUs holen und wieder abzuliefern. Details kann man hier nachlesen: NAT HOWTO und Debian Administration

Firewall

Momentan läuft der Server selbst hinter einem NATting-Router. Dieser schützt den Server momentan ausreichend.

EINSCHUB

Vor den weiteren Konfigurations-Schritten für die Blades ein kleiner Einschub: Der Bootvorgang bei Linux läuft in mehreren Schritten ab.

Durch die von der initrd eingefügten Änderungen startet jetzt als ganz normaler Teil des Bootprozesses ein zusätzliches Skript, dass sich um alles weitere kümmert. Dazu gehört das mounten des Boinc-Verzeichnisses, das auf der SSD liegt, genauso wie die Installation der Boinc-Software. Bei der Gelegenheit wird auch der ssh Zugang, CPU-Takt und -Spannugs-Änderungen sowie Monitoring via collectd auf dem Blade aktiv.

Image für Blades

PXE-Bootkram für Blades

dnsmask (DHCP+TFTP-Server) installieren und neue Konfig-Datei in /etc/dnsmasq.d anlegen Zitat:

# IP-Bereich aus dem Adressen vergeben werden
dhcp-range=10.0.0.100,10.0.0.200,1h
# MAC-Adressen der Blades -> IP-Adressen und Hostname
dhcp-host=00:23:54:fa:76:17,10.0.0.101,boinc101
dhcp-host=00:23:54:fa:77:2a,10.0.0.102,boinc102
dhcp-host=00:23:54:fa:74:b9,10.0.0.103,boinc103
dhcp-host=00:23:54:fa:77:26,10.0.0.104,boinc104
dhcp-host=00:23:54:fa:fd:9b,10.0.0.105,boinc105
dhcp-host=70:71:bc:13:9f:bf,10.0.0.106,boinc106
# PXE-Boot-Kram
dhcp-boot=pxelinux.0
pxe-service=x86PC, "boot linux", pxelinux
enable-tftp
# Verzeichnis vom Tftp-Server
tftp-root=/srv/tftp
tftp-secure
#Nummern der Optionen siehe "dnsmasq --help dhcp"
#3=Default-Route der Blades
dhcp-option=3,10.0.0.1
#6=DNS-Server der Blades
dhcp-option=6,192.168.1.1

tftp-Verzeichnis für PXE-anlegen

Dateien aus dem iso-Image/boot/isolinux in das tftp-Verzeichnis kopieren Boot-Konfiguration in tftp/pxelinux.cfg/defaut ändern in: Das ist fast der Aptosid-Standard-Eintrag für NDB + die 2 für Textmode (Init 2)

default /boot/vmlinuz0.amd lang=de_DE tz=Europe/Berlin initrd=/boot/initrd0.amd fromhd=/dev/nbd0 root=/dev/nbd0 nbdroot=10.0.0.1,9040 nonetwork boot=fll 2

An der Stelle mal ein großes Lob für die Aptosid-Entwickler! Der Großteil der Konfiguration ist direkt aus dem Aptosid-Image.

NDB-Server installieren

Die Version des Aptosid nbd-servers (1:2.9.23-4) macht immer noch Probleme, bzw. liest das config file gar nicht. Daher downgrade auf: Debian-Stable

# wget http://ftp.de.debian.org/debian/pool/main/n/nbd/nbd-server_2.9.16-8_amd64.deb
# dpkg --install nbd-server_2.9.16-8_amd64.deb
# echo nbd-server hold | dpkg --set-selections (sonst wird es beim nächsten Update wieder überschrieben)

In /etc/nbd-server zwei neue Konfigurationsdateien. Damit die Blades sich mit dem ndb-Server verbinden dürfen eine /etc/nbd-server/allow Datei:

10.0.0.0/24

Und die /etc/nbd-server/config Datei:

[generic]
authfile = /etc/nbd-server/allow
listenaddr = 0.0.0.0
[aptosid-ext2]
exportname = /srv/nbd/aptosid-2010-02-keres-xfce-amd64-201009132215.ext2
readonly = true
port = 9040
[aptosid-ulv]
exportname = /srv/nbd/blades/%s
readonly = false
port = 9041

Der mittlere Teil ist für das OS der Blades (read-only) und der unterste für die BOINC-Daten der Blades (read-write). Das "%s" ersetzt der nbd-Server automatisch durch die IP-Adresse des Blades daher muss man nicht für jedes Blade eine eigene Zeile schreiben. (Das aptosid-2010-02-keres hat da leider einen Bug. Ich musste den nbd-server deshalb downgraden.)

Datenpartition für jedes Blade

So sehen die Boinc-Partitionen der Blades aus. Das sind "normale" Dateien, die ein ext4-Datei-System enthalten. Kommt ein neues Blade dazu kopiert man das Template und ändert innen drin nur noch den Hostnamen. (Noch schöner wäre vermutlich eine Lösung mit LVM.)

ls -lah /srv/nbd/blades
-rw-r--r-- 1 root root 4,0G 25. Jul 13:39 10.0.0.101
-rw-r--r-- 1 root root 4,0G 25. Jul 13:39 10.0.0.102
-rw-r--r-- 1 root root 4,0G 25. Jul 13:39 10.0.0.103
-rw-r--r-- 1 root root 4,0G 25. Jul 13:39 10.0.0.104
-rw-r--r-- 1 root root 4,0G 25. Jul 13:39 10.0.0.105
-rw-r--r-- 1 root root 4,0G 25. Jul 13:39 10.0.0.106
-rw-r--r-- 1 root root 4,0G 26. Apr 12:40 10.0.0.template

Das Web-Interface

...befindet sich zur Zeit noch im Aufbau und wird nach Fertig-Stellung mit allen möglichen Informationen zu den gerechneten BOINC-Projekten aufwarten und weiterhin die Möglichkeit der Überwachung und Steuerung bieten. Hier schon mal ein kleiner Vorgeschmack...

Der EMK2 im Internet

ToDo...

su2279001b9-5a10-2-1.png su2279001b9-5a10-2-4.png

"Was" leistet der EMK2 und "Wie" hoch ist der Verbrauch

Eckdaten

Zitat von Boinc-Benchmarks Phenom II X6 @ 2,2 GHz / 0,925 Volt

Number of CPUs: 6
1693 floating point MIPS (Whetstone) per CPU

Jedes der Blades rechnet damit laut Boinc-Benchmark ca. 10,2 Giga-Flops.

Der Boinc-Benchmark scheint ein Single-Thread Programm zu sein, dass die Möglichkeiten des Sechs-Kerners nicht voll auslastet und daher zu einem Ergebnis von nur 10,2 GFlops/Kern kommt. Dieser Wert stimmt in etwa mit dem in der c't (2010/23/S.142) angegebenen Single-Thread-Linpack-Werten überein. Wenn man die Angaben aus dem c't auf 2,2 GHz umrechnet dann würden sich 7,9 GFlops (bei Single Thread) ergeben. Die verbleibenden Unterschiede ergeben sich vermutlich aus der Ungenauigkeit des Boinc-Benchmark und der sicherlich nicht ganz linearen Skalierung mit dem CPU-Tackt.

Im c't (2011/18/S.169) ist eine Liste mit theoretischen GFlops vom Phenom II X6 1100T@3,3GHz => 79 GFlops / CPU umgerechnet auf 2,2 GHz wären das theoretische 52 GFlops. Im Text steht dort weiterhin, dass bis zu ca. 80% des theoretischen Maximums bei optimierter Software möglich sind. Unsere Phenom II X6@2,2GHz könnten demnach real bis zu 42 GFlops machen.

In der c't (2011/23/S.142) ist ein Linpack-Benchmark Vergleich von mehreren CPUs und dort wird der Phenom II X6 @ 3,3 GHz mit 54,2 GFlops angegeben. Wenn man diese Werte zu Grunde legt müsste ein Blade dieses Clusters @ 2,2 GHz bis zu 36,1 Linpack-GFlops bei ca. 50 Watt Strom-Verbrauch erzielen.

Wie exakt diese Hochrechnung ist muss die geplante Messung mit dem Linpack-Benchmark erst noch ergeben, weil diese Hochrechnung z.B. die Einbußen durch die Vernetzung der Blades mit GigaBit-Ethernet nicht berücksichtigt. Ferner ist auch der genaue Stromverbrauch während dem Linpack-Lauf noch nicht bekannt.

Diese Einschränkungen betreffen jedoch nur den Vergleich mit den Linpack basierten Listen. Die MegaFlops/Watt unter BOINC werden sich dadurch nicht verändern!

Flops/Watt

Das sind ca. 722 Mega-Flops/Watt oder 1,4 Watt/Giga-Flop. Momentan läge der Cluster damit auf Platz 10 der aktuellen Green500 Liste! (Liste der effizientesten Supercomputer Stand 06/2011) Der Cluster ist damit einer der effizientesten Non-GPU-Cluster überhaupt.

Im Vergleich zu einem IBM BladeCenter HS22 mit 6-Kern Xeon wäre dieser Cluster etwa 3,5 mal so schnell und das bei etwa einem Zehntel der Kosten! (Stand Oktober 2011)

Leider gibt es nur von sehr wenigen Clustern dazu Daten Nur 0,5 und 1,5 MFlops/Watt bei Intel Itanium II (Stand 2006).

Flops/Euro bzw. Flops/Dollar

Wir gehen davon aus, dass der Cluster mit ca. 108 MFlops/Euro oder 74 MFlops/Dollar momentan die MFlops/Dollar-Liste für CPU basierte Cluster anführt. Der Vollständigkeit halber auch hier noch die Kehrwerte zum einfacheren vergleichen: 0,01 Euro/MFlop bzw. 0,016 Dollar/MFlop. Einige Daten über andere Eigenbau-Cluster findet man hier: Hauptseite#Weblinks

Flops/Tower-Gehäuse

Im Voll-Ausbau mit 14 Blades rechnet das Cluster 0,5 Terra-Flops und man bräuchte etwa 86 mal 14 Blades um in die aktuelle (06/2011) Top500 Liste aller Super-Computer zu kommen. Na ja, ist ja auch nur eine kleine Kiste. Vor 8 Jahren wäre das noch einer der schnellsten 500 Computer der Welt gewesen.

PS: Takt und Spannung sind noch nicht zu Ende optimiert - da geht evtl. auch noch etwas.

Statistik in den BOINC Projekten des EMK2

Statistiken bei BOINCstats.com

Statistiken bei allprojektstats.com

Preiskalkulation (Anschaffung und Laufende Kosten)

Überschlägt man alle Komponenten die im Rechner eingebaut sind, kommt man auf eine Summe von ~ 5100€. Auf Grund von Planungsänderungen(Haltesystem der Blades und optimierung der Kühlung) und daraus resultierendem technischen und mechanischen Neubau(Gehäuse, Lüfter), sowie zusätzlicher Kleinteile(Sleeve, Feinsicherungen, Schrumpfschlauch usw.) ist man schnell bei einem Betrag von ca. 6000€ angelangt.

Link-Sammlung (Hard- und Software)

Blades

Teil Name Geizhals-Preisvergleich Hersteller
Mainboard Sapphire IPC-AM3DD785G Link Link
CPU AMD Phenom II X6 Link Link
RAM DDR3 4GB Low-Profile (1,875 cm) Link Link
Kühler Prolimatech Samuel 17 Link Link
mini ATX-Netzteile PICOPSU-160-XT Link Link

Gehäuse, Netzteil, Lüfter, Switche etc.

Teil Name Geizhals-Preisvergleich Hersteller
Gehäuse Sharkoon Rebel12 Economy Link Link
Netzteil Corsair AX 1200W ATX 2.3 Link Link
Lüfter SmartCooler LFM1512HP Link Link
Lüftersteuerung Dimmer für LEDs mit PWM (gemoddet) - Link
Switche D-Link DGS-1008D Green Ethernet Link Link
Netzwerkkabel CAT 5e, super flache Sorte Link Link
SSD Wechselrahmen DeLOCK 47189, 2.5" SATA II Link Link
SSD OCZ Agility II Link Link
USB-I/O BMC Messsysteme - USB-PIO - Link
2. Netzwerkkarte super low Profile GBit-NIC von Inline Link Link

Software

Name Link
Aptosid http://www.aptosid.de/

Wer ist an dem Projekt beteiligt

Hier sind alle Meisterkühler aufgeführt die an diesem Projekt mit gearbeitet, sich als Sponsor von Hardware eingebracht, verschiedene Software und Programmier-Lösungen aus gearbeitet haben oder in einer anderen Weise in das Projekt eingebunden sind.

Wir danken :

   ulv
   Jabba
   littledevil
   Wiaf
   samotronta05
   topperharly
   Super-Kermit
   Renovatio
   isch
   Gillian
   Sc0rp
   Zaperwood
   Konfetti
   Audiodude
   Kaboom
   zero cool
   phil68

"Wo" oder "Wie" kann ich das Projekt unterstützen

Wir möchten betonen, dass eine Spende vollkommen freiwillig ist und keinerlei Zwang unterliegt. Über die eingehenden Spenden werden wir in einer Art "Spenden-Report" berichten und den aktuellen Kontostand offenlegen. Die Spenden werden ausschließlich für Unterhalt und Hardware dieses Projektes verwendet, die den Betrieb des EMK2 sicherstellen.

Hinweis: Eine Spende ist eine freiwillige Unterstützung zum Unterhalt des EMK2 und keine "Beteiligung". Die Hardware wird nach Auflösung des Projektes dem jeweiligen Spender zugeführt und bleibt dessen Eigentum.


Spenden.gif


Hinweis: Bei der Nutzung von PayPal entstehen dem Empfänger der Zahlung Gebühren, sodass nicht der volle Beitrag der Spende auf dem Konto gut geschrieben wird. Z.Z belaufen sich diese beim Empfangen von Geld aus Deutschland oder anderen EU-Ländern auf 1,9 % + 0,35 Euro pro Überweisung. Bei einer Spende von 10€ erscheinen so nur 9,46€ auf dem Konto.

Foren-Links der Meisterkuehler

BOINC@Meisterkuehler.de

Weblinks

Andere Eigenbau Cluster mit ausführlicher Dokumentation

(4x Micro-ATX MSI K9N6PGM-F mit AMD Athlon 64 X2 3800+ = 8 Cores => 16 GHz)

(6x Mini-ITX VIA CN10000 mit VIA C7 1 GHz = 6 Cores => 6 GHz)

(12x Mini-ITX VIA EPIA V8000, 800 MHz => 9,6 GHz)

Sonstiges

Software


Mk-Header.gif



Hilfe zur Benutzung und Konfiguration der Wiki-Software findest du im Benutzerhandbuch.

Starthilfen

Meine Werkzeuge
Namensräume
Varianten
Aktionen
Navigation
Sonstiges
Werkzeuge