In den letzten Jahren sind Nachrichten über neuartige verteilte Rechennetzwerke, die scheinbar aus dem Nichts auftauchen, in den Nachrichten zu einem ständigen Thema geworden. Diese Netzwerke versuchen, verschiedene Aufgaben zu lösen – sei es, eine Stadt intelligent zu machen, die Welt vor Urheberrechtsverletzungen zu retten oder umgekehrt, Informationen oder Ressourcen heimlich zu übermitteln und der Kontrolle des Staates in verschiedenen Bereichen zu entkommen. Unabhängig von der Branche weisen sie eine Reihe von gemeinsamen Merkmalen auf, da ihre Entwicklung von Algorithmen und Methoden angetrieben wird, die während des jüngsten Booms von Kryptowährungen und verwandten Technologien populär wurden. Wahrscheinlich enthielt jeder dritte Artikel auf Fachseiten damals das Wort „Blockchain“ – die Diskussion über neue Softwarelösungen und Wirtschaftsmodelle wurde zeitweise zum dominierenden Trend, während andere Anwendungsbereiche verteilter Rechensysteme in den Hintergrund gedrängt wurden.
Gleichzeitig erkannten Visionäre und Experten das Wesentliche des Phänomens: Massively Distributed Computing, das mit dem Aufbau von Netzwerken aus einer großen Zahl von verstreuten und heterogenen Teilnehmern verbunden ist, hat ein neues Entwicklungsniveau erreicht. Es genügt, die hypegetriebenen Themen beiseite zu lassen und die Sache aus einem anderen Blickwinkel zu betrachten: All diese Netzwerke, die aus riesigen Pools bestehen, in denen sich Tausende isolierter, heterogener Teilnehmer befinden, sind nicht von selbst entstanden. Die Enthusiasten der Krypto-Bewegung haben es geschafft, komplexe Probleme der Datensynchronisation sowie der Ressourcenzuteilung und -verteilung auf innovative Weise zu lösen, was die Zusammenführung einer derart großen Menge an Hardware und die Schaffung eines neuen Ökosystems ermöglicht hat, das für die Lösung einer spezifischen Aufgabe konzipiert ist.
Natürlich blieb dies den Teams und Gemeinschaften, die sich mit der Entwicklung freier verteilter Rechensysteme beschäftigen, nicht verborgen, und neue Projekte ließen nicht lange auf sich warten.
Doch trotz des erheblichen Anstiegs des verfügbaren Wissens über Entwicklungen im Bereich Netzaufbau und Equipment-Nutzung werden die Schöpfer zukunftsweisender Systeme ernsthafte Herausforderungen bewältigen müssen.
Das erste, und auch wenn es seltsam klingt, ist das Problem der Richtungsauswahl.
Der Kurs kann richtig sein oder ins Leere führen – dem bleibt man nicht entkommen, und die zentralisierten Angebote von Hellsehern in der IT-Community hinken momentan hinterher. Eine Entscheidung muss jedoch getroffen werden, um nicht in die traditionelle Falle zu tappen, in der das Team ein zu weites Feld abdeckt und gleich zu Beginn versucht, ein weiteres, unspezialisiertes Projekt für breite verteilte Berechnungen zu schaffen. Der Umfang der Arbeiten scheint nicht allzu bedrohlich zu sein; es gilt vor allem, bestehende Entwicklungen zu nutzen: Knoten zu einem Netzwerk zusammenzuführen, Algorithmen für die Topologieerkennung, den Datenaustausch und die Konsistenzkontrolle anzupassen, Methoden zur Bewertung von Knoten und Konsensfindung einzuführen und natürlich einfach eine eigene Abfragesprache und die gesamte sprachliche und rechnerische Umgebung zu schaffen. Die Idee eines universellen Mechanismus ist äußerst verlockend und taucht immer wieder in verschiedenen Bereichen auf, doch das Ergebnis bleibt eines von dreien: Die geschaffene Lösung entpuppt sich entweder als tatsächlich begrenzter Prototyp mit einer Menge offener „ToDos“ im Backlog, wird zu einem unbenutzbaren Monster, das jeden, der es berührt, in den üblen „Turing-Sumpf“ ziehen kann, oder stirbt einfach, weil die die Richtung unklar ziehenden „Schwan, Krebs und Hecht“ sich ganz trivial überanstrengt haben.
Lassen Sie uns keine dummen Fehler wiederholen und eine Richtung wählen, die einen klaren Aufgabenbereich hat und gut zu einem modellierten verteilten Rechnen passt. Man kann die Menschen verstehen, die versuchen, alles auf einmal zu erledigen – schließlich gibt es eine breite Auswahl. Und vieles sieht sowohl aus der Perspektive von F&E als auch aus wirtschaftlicher Sicht äußerst interessant aus. Mit einem verteilten Netzwerk kann man:
- Neuronale Netze trainieren
- Signalströme verarbeiten
- Die Struktur von Proteinen berechnen
- 3D-Szenen rendern
- Hydrodynamik modellieren
- Handelsstrategien für Börsen testen
Um uns nicht mit einer Liste interessanter Dinge, die sich gut parallelisieren lassen, zu verlieren, wählen wir für unser weiteres Thema das verteilte Rendering.
Verteiltes Rendering ist an sich natürlich kein neues Phänomen. Existierende Rendering-Toolkits unterstützen seit langem die Lastverteilung auf verschiedene Maschinen; ohne dies wäre das Leben im einundzwanzigsten Jahrhundert ziemlich trist. Es ist jedoch nicht angebracht zu glauben, dass das Thema bereits umfassend behandelt wurde und es nichts mehr zu entdecken gibt – wir werden ein spezielles aktuelles Problem untersuchen: die Entwicklung eines Tools zur Bildung eines Render-Netzwerks.
Unser Rendering-Netzwerk ist eine Vereinigung von Knoten, die Rendering-Aufgaben ausführen müssen, und Knoten, die über freie Rechenressourcen für die Bearbeitung des Renderings verfügen. Ressourcenbesitzer werden ihre Stationen mit dem Rendering-Netzwerk verbinden, um Rendering-Aufträge zu empfangen und auszuführen, indem sie eine der von dem Netzwerk unterstützten Rendering-Engines nutzen. Auftragsanbieter werden dabei mit dem Netzwerk wie mit einer Cloud arbeiten, die selbständig die Ressourcenverteilung, die Einhaltung der Auftragsausführung, das Risikomanagement und andere Probleme übernimmt.
Wir werden ein Framework betrachten, das die Integration mit einer Reihe beliebter Render-Engines unterstützen soll und Komponenten enthält, die Werkzeuge zur Organisation eines Netzwerks aus heterogenen Knoten und zur Verwaltung von Aufgabenströmen bereitstellen.
Das wirtschaftliche Modell für die Existenz eines solchen Netzwerks ist nicht von grundlegender Bedeutung. Daher nehmen wir als Ausgangsbasis ein Schema, das dem in Kryptowährungsnetzwerken verwendeten ähnelt – die Ressourcennutzer senden Token an die Anbieter, die die Render-Arbeiten ausführen. Viel interessanter ist es zu verstehen, welche Eigenschaften das Framework haben sollte. Dafür betrachten wir das Hauptszenario der Interaktion zwischen den Teilnehmern des Netzwerks.
Im Netzwerk gibt es drei Interaktionsparteien: den Ressourcenanbieter, den Aufgabenanbieter und den Netzwerkbetreiber (auch als Steuerzentrum, Netzwerk usw. im Text bezeichnet).
Der Netzwerkbetreiber stellt dem Ressourcenanbieter eine Client-Anwendung oder ein Betriebssystem-Image mit einer kompletten Software-Sammlung zur Verfügung, die er auf die Maschine installieren kann, deren Ressourcen er bereitstellen möchte. Über ein webbasiertes Benutzer-Dashboard hat er die Möglichkeit, Zugriffsparameter für die Ressource festzulegen und seine Serverlandschaft aus der Ferne zu verwalten: Hardwareparameter zu überwachen, Remote-Konfigurationen durchzuführen und Neustarts auszulösen.
Das Netzwerkmanagementsystem analysiert beim Anschluss eines neuen Knotens die Hardware und die festgelegten Zugriffsparameter, bewertet diese und ordnet ihm eine bestimmte Einstufung zu, um sie in das Ressourcenregister aufzunehmen. Zur Risikoverwaltung werden in der Folge die Aktivitätsparameter des Knotens analysiert und die Einstufung des Knotens angepasst, um die Stabilität des Netzbetriebs zu gewährleisten. Niemand möchte schließlich, dass seine Aufgaben auf leistungsstarken, aber oft überhitzten Grafikkarten gerendert werden.
Ein Benutzer, der eine Szene rendern möchte, hat zwei Möglichkeiten: entweder lädt er die Szene über das Web-Interface in das Netzwerk-Repository hoch oder verbindet über ein Plug-in sein Modellierungspaket oder den installierten Renderer mit dem Netzwerk. In diesem Fall wird ein Smart Contract zwischen dem Benutzer und dem Netzwerk initiiert, dessen Standardbedingung die Generierung des Berechnungsergebnisses der Szene durch das Netzwerk ist. Der Benutzer kann den Fortschritt der Aufgabe überwachen und ihre Parameter über das Web-Interface seines persönlichen Dashboards steuern.
Die Aufgabe wird an der Server, wo das Volumen der Szene und die Anzahl der von der aufrufenden Aufgabe angeforderten Ressourcen analysiert werden. Anschließend wird das Gesamtvolumen in Teile zerlegt, die an die verfügbare Anzahl und Art von Ressourcen in einem dedizierten Netzwerk angepasst sind. Die Hauptidee besteht darin, dass die Visualisierung in viele kleine Aufgaben unterteilt werden kann. Engines nutzen diesen Vorteil, indem sie diese Aufgaben auf viele Ressourcenanbieter verteilen. Der einfachste Weg besteht darin, kleine Teile der Szene zu rendern, die als Segmente bezeichnet werden. Wenn jedes Segment fertiggestellt ist, wird die lokale Aufgabe als abgeschlossen angesehen und die Ressource kann zur Ausführung der nächsten ungeklärten Aufgabe übergehen.
Für den Renderer spielt es keine Rolle, ob die Berechnungen auf einem einzigen Rechner oder in einem Netzwerk von vielen separaten Arbeitsstationen durchgeführt werden. Verteiltes Rendering fügt einfach mehr Kerne in den Pool der zur Aufgabe verfügbaren Ressourcen hinzu. Über das Netzwerk erhält es alle Daten, die für das Rendering des Segments erforderlich sind, berechnet dieses, sendet es zurück und geht zur nächsten Aufgabe über. Vor dem Eintritt in den gemeinsamen Netzwerkpool erhält jedes Segment einen Satz von Metainformationen, die es den ausführenden Knoten ermöglichen, die am besten passenden Berechnungsaufgaben auszuwählen.
Die Aufgaben der Segmentierung und Verteilung der Berechnungen müssen dabei nicht nur aus der Perspektive der Optimierung der Ausführungszeit betrachtet werden, sondern auch hinsichtlich der optimalen Ressourcennutzung und Energieeinsparung, da dies die wirtschaftliche Effizienz des Netzwerks beeinflusst. Im Falle einer suboptimalen Lösung wäre es sinnvoller, einen Miner an den Knoten zu setzen oder diesen abzuschalten, um kein Geräusch zu verursachen und keinen Strom zu verbrauchen.
Kehren wir jedoch zum Prozess zurück. Bei der Aufgabenerstellung wird zwischen dem Pool und dem Knoten auch ein Smart Contract erstellt, der ausgeführt wird, wenn das Ergebnis der Aufgabe korrekt berechnet wird. Nach Abschluss des Vertrags kann der Knoten eine Belohnung in irgendeiner Form erhalten.
Das Kontrollzentrum überwacht den Prozess der Aufgabenausführung, sammelt die Berechnungsergebnisse, sendet inkorrekte Ergebnisse zur erneuten Verarbeitung zurück und bewertet die Warteschlange, wobei es die reguläre Bearbeitungszeit der Aufgabe verfolgt (um sicherzustellen, dass das letzte Segment von keinem Knoten bearbeitet wird).
Die Berechnungsergebnisse durchlaufen eine Kompositionsstufe, nach der der Benutzer die Renderingergebnisse erhält, und das Netzwerk kann eine Belohnung erhalten.
So ergibt sich die funktionale Struktur des Landschaftsframeworks, das für den Aufbau von verteilten Rendering-Systemen vorgesehen ist:
- Benutzer-Dashboards mit Webzugang
- Softwarepaket für die Installation auf Knoten
- Verwaltungssysteme:
- Zugriffsverwaltungssystem
- Subsystem zur Zerlegung von Rendering-Aufgaben
- Subsystem zur Aufgabenverteilung
- Subsystem zur Komposition
- Subsystem zur Verwaltung von Serverlandschaften und Netzwerktopologien
- Subsystem für Logging und Auditing
- Lernende Expertensubsystem
- REST API oder eine andere Schnittstelle für externe Entwickler
Was denken Sie dazu? Welche Fragen wirft das Thema auf und welche Antworten interessieren Sie?
Quelle: habr.com
