Berkeley Open Infrastructure for Network Computing

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von BOINC)
Zur Navigation springen Zur Suche springen
BOINC

Das Aktuelle BOINC Logo
Der BOINC-Client für Windows
Der BOINC-Client für macOS
Basisdaten

Entwickler Universität Berkeley
Erscheinungsjahr 10. April 2002
Aktuelle Version 8.0.2[1]
(24. Mai 2024)
Betriebssystem Windows, macOS, Linux, Android
Programmier­sprache C++
Kategorie Verteiltes Rechnen
Lizenz GPL/LGPL (Freie Software)
deutschsprachig ja
boinc.berkeley.edu

Die Berkeley Open Infrastructure for Network Computing (kurz BOINC) ist eine Software-Plattform für verteiltes Rechnen.

Die BOINC-Plattform 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ßerirdischem Leben, Berechnung von Gravitationswellen, Vorhersagen zur Klimaentwicklung sowie die Simulation von Proteinfaltungen für die Erforschung von neuen Medikamenten.

Bei der Entwicklung von BOINC wurden Erfahrungen des Volunteer-Computing-Projekts SETI@home genutzt. Ein Merkmal der Plattform ist die Trennung der Projektverwaltung von den wissenschaftlichen Inhalten.

Anwender dieser Plattform installieren sich ein Clientprogramm und können damit ihre freie Rechenzeit auf ein oder mehrere Projekte verteilen. Dies ist eine wichtige Verbesserung gegenüber an nur ein Projekt gebundenen Clients, da einige Distributed-Computing-Projekte nicht über genügend Arbeit verfügen, um die Ressourcen einer großen Teilnehmerbasis zu nutzen. SETI@home classic umging dieses Problem, indem manche Arbeitspakete bis zu zwölfmal zur Berechnung herausgegeben wurden, obwohl zur Sicherung von akkuraten wissenschaftlich verwertbaren Resultaten nur drei Ergebnisse notwendig wären. Mit einem an mehreren Projekten teilnehmenden BOINC-Client kann die verfügbare Rechenleistung somit effektiver verwendet werden.

Seit dem 18. November 2003 steht BOINC unter der GNU General Public License. Das Ziel der Freigabe des Programmcodes ist eine noch breitere Unterstützung verschiedener Plattformen durch aktive Mithilfe der freien Softwaregemeinde und eine erhöhte Sicherheit.

Ab der Version 6.4.5 wird die CUDA-Technologie von Nvidia unterstützt. Damit ist es möglich, die Rechenleistung von Grafikkarten mit CUDA-Unterstützung zu nutzen. Ab der Version 6.10.x wird die ATI-Stream-Technik unterstützt, welche, ähnlich wie CUDA, die Berechnung auf Grafikkarten des Herstellers ATI Technologies erlaubt.

Derzeit (Stand: Mai 2020) hat die Plattform bei rund 150.000 Teilnehmern[2] und ca. 800.000 aktiven Rechnern[3] eine Rechenleistung von durchschnittlich 32 PetaFLOPS[4], die je nach Tag schwankt. Durch die Unterstützung der Berechnung von Arbeitspaketen mit einer kompatiblen Grafikkarte ist die Rechenleistung in der Vergangenheit stark angestiegen.

Der BOINC-Manager (im Expertenmodus) mit den grafischen Fenstern von Rosetta@home und ClimatePrediction.net

Teilnehmerseitig

[Bearbeiten | Quelltext bearbeiten]
Core-Client
Der Core-Client ist ein auf dem Teilnehmerrechner im Hintergrund laufendes Kommandozeilen-Programm. Er steuert und überwacht die wissenschaftlichen Anwendungen gemäß den Vorgaben des Teilnehmers, puffert Arbeitspakete und kommuniziert mit den Schedulern und Datenservern der Projekte. Der Core-Client kann, neben Windows, theoretisch auch auf jedes Unix-artige Betriebssystem portiert werden, ist für sich allein genommen jedoch recht nutzlos, wenn für die jeweilige Plattform keine wissenschaftlichen Anwendungen zur Verfügung stehen.
BOINC-Manager
Der BOINC-Manager ist eine grafische Oberfläche zur Konfiguration und Überwachung des Core-Clients. Er basiert auf dem wxWidgets-Toolkit und ist damit auf allen Plattformen lauffähig, die von wxWidgets unterstützt werden.
Boinc-Commandline-Interface
das Programm boinc_cmd erlaubt es, den Core-Clienten über die Kommandozeile zu steuern, beispielsweise wenn keine grafische Oberfläche verfügbar ist (wie bei Servern).
Projektanwendungen
Jedes Projekt stellt Anwendungen bereit, die vom Core-Client heruntergeladen und zur Berechnung der Arbeitspakete verwendet werden. Diese werden zur Laufzeit vom Core-Client mittels Shared Memory überwacht. Die Funktionen für diese Überwachung werden in der von BOINC mitgelieferten Programmierschnittstelle (BOINC-API) bereitgestellt.

Bei älteren Programmversionen ist der Core-Client sowohl in den grafischen BOINC-Manager als auch in das Kommandozeilen-Interface integriert. Bei aktuellen Versionen kommuniziert der separate Core-Client über Shared Memory mit den Steuerungsprogrammen.

Das vom jeweiligen Projekt zur Verfügung gestellte Backend basiert auf einem Webserver, PHP als Skriptsprache und einer MySQL-Datenbank. Bei großen Projekten können die Backend-Dienste auf mehrere Server verteilt sein. Einige Projekte verwenden Perl oder ASP anstelle von PHP für das Backend, dies sind Eigenentwicklungen der Projekte, die das von Berkeley vorgegebene Kommunikationsprotokoll nachbilden.

Scheduler
Der Scheduler ist ein CGI-Programm auf dem Webserver des Projekts. Er teilt den Teilnehmer-Clients ihre Arbeitspakete zu und nimmt nach getaner Arbeit eine kurze Meldung über Erfolg/Misserfolg entgegen. Über alle Aktivitäten führt er in der Datenbank Buch.
Datenserver
Ein einfacher HTTP-Server, von dem die Clients ihre vom Scheduler zugeteilten Arbeitspakete herunterladen und die Ergebnisdateien hochladen.
Validator
Der Validator (ein für jedes Projekt unterschiedliches Programm) prüft die von den Clients zurückgelieferten Ergebnisdateien auf Korrektheit. Meist geschieht dies dadurch, dass ein Arbeitspaket von mehreren Teilnehmern redundant bearbeitet wird. Der Validator vergleicht dann die Ergebnisse. Idealerweise sind sie identisch.
Assimilator
Ein projektspezifisches Programm. Nimmt validierte Ergebnisdateien und bereitet sie zur weitergehenden wissenschaftlichen Analyse auf. Dazu können die Ergebnisse beispielsweise in eine weitere Datenbank archiviert werden.
File-Deleter
Nachdem die Ergebnisse „assimiliert“ wurden, sind die Input- und Output-Dateien der Clients unnötiger Ballast für den Datenserver, die durch ihre Anzahl auch seine Performance beeinträchtigen können. Mit dem File-Deleter werden nicht mehr benötigte Dateien vom Server gelöscht.
Transitioner
Der Transitioner überwacht den Fortschritt der Arbeitspakete entlang einer gedachten Pipeline. So stößt er beispielsweise den Validator an, wenn er feststellt, dass zu einem Arbeitspaket genügend redundante Ergebnisse vorliegen, so dass mit der Validierung begonnen werden kann.

Das Verhalten des BOINC-Frameworks kann an die Bedürfnisse verschiedener Projekte angepasst werden. Zu den Funktionen, die nur von einigen Projekten genutzt werden, gehören:

Homogene Redundanz
Einige wissenschaftliche Anwendungen reagieren empfindlich auf numerische Differenzen, die sich auf unterschiedlichen Teilnehmerrechnern ergeben können. Die Ursachen dafür können in den Betriebssystemen, den Prozessoren oder den verwendeten Compilern liegen. Kleine Unterschiede in der Rundung oder Gleitkomma-Implementation können dabei zu völlig unterschiedlichen Ergebnissen führen. Im Falle von Predictor@home stellte man beispielsweise fest, dass Intel- und AMD-Prozessoren häufig unterschiedliche Proteinfaltungen errechneten. Keiner der Prozessoren hatte dabei „falsch“ gerechnet, da man Proteinstrukturen ohnehin nur statistisch annähern kann, aber die Unterschiede waren signifikant genug, um den Validator aus dem Tritt zu bringen. LHC@Home hat das Problem für sich durch eine neue plattformunabhängige Mathematik-Bibliothek lösen können. BOINC-seitig besteht die Möglichkeit, ein Arbeitspaket jeweils nur identischen Plattformen zuzuteilen. Ein Arbeitspaket für „Windows/AMD“ wird dann nur von Rechnern mit dieser Ausstattung bearbeitet.
Locality Scheduling
Bei einigen Projekten sind die Input-Dateien der Arbeitspakete sehr groß. Das belastet die Netzwerkanbindung des Projekts. Manche Projekte haben jedoch den Vorteil, dass für viele Arbeitspakete die gleichen Input-Dateien benötigt werden. Dann kann durch Locality Scheduling der Netzwerkverkehr reduziert werden. Ein Client bekommt in diesem Fall bevorzugt Arbeitspakete zugeteilt, zu denen er angibt, dass er die benötigten Input-Dateien bereits vorliegen hat. Diese Technik wird derzeit vor allem von Einstein@home verwendet.
Trickles
(engl. für Tröpfchen) sind kleine XML-Dateien, mit denen die Projektanwendung den Scheduler über den Fortschritt von sehr lange laufenden Berechnungen unterrichten kann. ClimatePrediction.net benutzt zum Beispiel Arbeitspakete, deren Fertigstellung Wochen oder sogar Monate dauern kann. So lange möchten die Benutzer aber nicht auf Creditpunkte warten. Durch diese Trickles unterrichtet der Core-Client den Scheduler über den Arbeitsfortschritt, so dass bereits Creditpunkte vergeben werden können, während das Paket noch in Arbeit ist.
Datenarchivierung
Bis zu einer vom Teilnehmer festlegbaren Grenze können Projekte die Festplatte des Teilnehmerrechners zur Archivierung alter Input- oder Output-Daten verwenden. Das Projekt kommt an die Daten jedoch nicht ohne Kooperation des Teilnehmers heran. Diese Möglichkeit wurde zeitweise von ClimatePrediction.net verwendet, es handelte sich um Datenmengen im Bereich von einigen 100 MB. Inzwischen gibt es Projektkonzepte, die sich ausschließlich mit der verteilten Archivierung mit BOINC befassen, bisher ist aber kein derartiges Projekt öffentlich verfügbar.

Sicherheit des Clients

[Bearbeiten | Quelltext bearbeiten]

Der BOINC-Client kann so konfiguriert werden, dass ein sogenannter Protected Mode verwendet wird. Dabei läuft die BOINC-Instanz in einem Sandbox-Modus. Dazu wird ein mit geringsten Rechten ausgestattetes Benutzerkonto verwendet.[5]

Für erfolgreich berechnete und innerhalb der Gültigkeitsdauer zurückgemeldete Arbeitspakete werden sogenannte Credits vergeben. Diese virtuellen Punkte ermöglichen den Vergleich der investierten Berechnungszeiten zwischen den Teilnehmern und den Teams. Die Höhe der Credits kann zum einen vom Projekt vorgegeben werden (fixed credits) oder zum anderen anhand der Berechnungszeit sowie der Geschwindigkeit des berechnenden Computers ermittelt werden.[6]

Auf dem Rechner muss lediglich die BOINC-Software installiert werden. Nach der Registrierung bei einem oder mehreren der Projekte lädt BOINC sich selbständig die benötigte Projektsoftware herunter und beginnt den eigentlichen Rechenprozess. Inzwischen steht eine breite Auswahl an Projekten zur Verfügung, laufend werden neue entwickelt.

Commons: Berkeley Open Infrastructure for Network Computing – Album mit Bildern, Videos und Audiodateien

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. github.com. 24. Mai 2024.
  2. Active-User-Übersicht auf boincstats.com
  3. Active-Host-Übersicht auf boincstats.com
  4. Übersicht BOINC-Leistung auf boincstats.com
  5. Sicherheit von BOINC auf der Projektseite
  6. Erklärung zu Credits auf der BOINC-Projektseite