In den letzten Jahren haben Nachrichtenfeeds über neue, verteilte Rechennetzwerke, die buchstäblich aus dem Nichts auftauchen, berichtet, die versuchen, die unterschiedlichsten Aufgaben zu lösen – eine Stadt smarter zu machen, die Welt vor Urheberrechtsverletzern zu retten oder umgekehrt heimlich Informationen oder Ressourcen zu übertragen und aus der Kontrolle des Staates in einem bestimmten Bereich zu entkommen. Unabhängig vom Bereich haben sie alle einige gemeinsame Merkmale, die dadurch bedingt sind, dass die Algorithmen und Methoden, die während des jüngsten Booms von Kryptowährungen und den damit verbundenen Technologien in den breiten Massen verbreitet wurden, das Treibstoff für ihr Wachstum waren. Wahrscheinlich trug jede dritte Artikel auf spezialisierten Plattformen damals im Titel das Wort „Blockchain“ – die Diskussion über neue Softwarelösungen und Wirtschaftsmodelle wurde für eine Weile zum dominierenden Trend, im Schatten dessen andere Anwendungsbereiche verteilter Rechenverfahren in den Hintergrund gedrängt wurden.
Gleichzeitig erkannten Visionäre und Fachleute das Wesentliche dieses Phänomens: Die massiven verteilten Berechnungen, die mit dem Aufbau von Netzwerken aus einer großen Anzahl von disparaten und heterogenen Teilnehmern verbunden sind, haben ein neues Entwicklungsniveau erreicht. Es reicht aus, die Hype-Themen aus dem Kopf zu werfen und das Thema aus einem anderen Blickwinkel zu betrachten: All diese Netzwerke, die aus riesigen Pools bestehen, in denen Tausende von getrennten heterogenen Teilnehmern zu finden sind, sind nicht von selbst entstanden. Enthusiasten der Krypto-Bewegung konnten komplexe Probleme der Datensynchronisation und der Verteilung von Ressourcen und Aufgaben auf neue Weise lösen, was es ermöglicht hat, eine solche Masse von Geräten zusammenzuführen und ein neues Ökosystem zu schaffen, das zur Lösung einer eng fokussierten Aufgabe bestimmt ist.
Selbstverständlich blieb dies den Teams und Gemeinschaften, die sich mit der Entwicklung freier verteilter Berechnungen beschäftigen, nicht verborgen, und neue Projekte ließen nicht lange auf sich warten.
Doch trotz des erheblichen Anstiegs der verfügbaren Informationen über Entwicklungen im Bereich des Netzaufbaus und der Arbeit mit Hardware müssen die Entwickler vielversprechender Systeme ernsthafte Probleme lösen.
Das erste Problem, so seltsam es auch klingen mag, ist die Auswahl der Richtung.
Die Richtung kann richtig sein, kann aber auch in eine Sackgasse führen – dem lässt sich nicht entkommen, die zentralisierten Lieferungen von Hellsehern in die IT-Community verzögern sich bisher. Aber es ist wichtig, eine Wahl zu treffen, um nicht in die traditionelle Falle zu tappen, die darin besteht, dass das Team ein zu breites Feld abdeckt und von Anfang an versucht, ein weiteres nicht spezialisiertes Projekt für verteiltes Rechnen zu schaffen. Es scheint, als wäre der Arbeitsaufwand nicht so beängstigend, man muss größtenteils nur bestehende Entwicklungen anwenden: Knoten in ein Netzwerk integrieren, Algorithmen zur Bestimmung von Topologien, Datenaustausch und Kontrolle ihrer Konsistenz anpassen, Methoden zur Bewertung von Knoten und zur Konsensfindung einführen, und natürlich einfach eine eigene Abfragesprache und die gesamte sprachliche und rechentechnische Umgebung schaffen. Die Idee eines universellen Mechanismus ist sehr verlockend und taucht immer wieder in einem oder anderen Bereich auf, aber am Ende resultiert es nach wie vor in einem von drei Ergebnissen: Die geschaffene Lösung erweist sich entweder als tatsächlich eingeschränktes Prototyp mit einer Menge fälliger „ToDo“-Punkte im Backlog, oder sie wird zu einem unbrauchbaren Monster, das jeden, der mit ihm in Berührung kommt, in einen übelriechenden „Turing-Sumpf“ zieht, oder sie stirbt einfach friedlich, weil die involvierten Stakeholder in eine unklare Richtung gezerrt wurden und letztlich überfordert sind.
Lass uns keine dummen Fehler wiederholen und eine Richtung wählen, die einen klaren Aufgabenbereich hat und gut zum Modell des verteilten Rechnens passt. Man kann die Menschen verstehen, die versuchen, alles auf einmal zu machen – es gibt natürlich viel auszuwählen. Und vieles sieht sowohl aus der R&D- als auch aus der wirtschaftlichen Perspektive extrem interessant aus. Mit einem verteilten Netzwerk kann man:
- Neuronale Netzwerke trainieren
- Signalströme verarbeiten
- Die Struktur von Proteinen berechnen
- 3D-Szenen rendern
- Hydrodynamik modellieren
- Handelsstrategien für Aktienmärkte testen
Um nicht in die Versuchung zu geraten, eine Liste von interessanten Dingen zu erstellen, die gut parallelisiert werden können, wählen wir als unser zukünftiges Thema verteiltes Rendering.
Verteiltes Rendering an sich ist natürlich kein neues Phänomen. Die bestehenden Render-Toolkits unterstützen schon lange die Lastverteilung auf verschiedene Maschinen; ohne das wäre das Leben im einundzwanzigsten Jahrhundert ziemlich traurig. Es ist jedoch nicht so, dass das Thema bis ins kleinste Detail behandelt wurde und es dort nichts mehr zu tun gibt – wir werden ein spezifisches aktuelles Problem untersuchen: die Schaffung eines Werkzeugs zur Bildung eines Render-Netzwerks.
Unser Rendering-Netzwerk ist eine Vereinigung von Knoten, die Aufgaben des Renderns ausführen müssen, und Knoten, die über freie Rechenressourcen zur Verarbeitung des Renderns verfügen. Die Eigentümer der Ressourcen werden ihre Stationen mit dem Rendering-Netzwerk verbinden, um Renderaufträge zu erhalten und auszuführen, wobei einer der unterstützten Render-Engines des Netzwerks verwendet wird. Die Auftragsanbieter hingegen werden mit dem Netzwerk wie mit einer Cloud arbeiten, die selbstständig die Ressourcenverteilung, die Überwachung der ordnungsgemäßen Ausführung, das Risikomanagement und andere Probleme übernimmt.
Wir werden also die Schaffung eines Frameworks betrachten, das die Integration mit einer Reihe von beliebten Render-Engines unterstützen soll und Komponenten enthalten muss, die Werkzeuge zur Organisation eines Netzwerks aus heterogenen Knoten und zur Verwaltung des Aufgabenflusses bereitstellen.
Das wirtschaftliche Modell für das Bestehen eines solchen Netzwerks ist nicht von grundlegender Bedeutung, daher nehmen wir als Ausgangspunkt ein Schema, das dem in Kryptowährungsnetzwerken verwendeten ähnelt – die Verbraucher der Ressource senden Tokens an die Anbieter, die die Renderarbeiten ausführen. Weitaus interessanter ist es zu verstehen, über welche Eigenschaften das Framework verfügen sollte, weshalb wir das Hauptszenario der Interaktion der Netzwerkteilnehmer betrachten wollen.
Im Netzwerk gibt es drei Parteien der Interaktion: den Ressourcenanbieter, den Aufgabenanbieter und den Netzwerkoperator (auch Kontrollzentrum, Netzwerk usw. im Text).
Der Netzwerkbetreiber stellt dem Ressourcenanbieter eine Client-Anwendung oder ein Betriebssystem-Image mit einem erweiterten Softwarepaket zur Verfügung, das dieser auf dem Computer installieren wird, dessen Ressourcen er bereitstellen möchte. Über das Webinterface seines persönlichen Kontos kann er die Zugangseinstellungen zur Ressource festlegen und seine Serverlandschaft aus der Ferne verwalten: Hardwareparameter überwachen, Remote-Settings durchführen und neu starten.
Das Netzwerkmanagementsystem analysiert bei der Verbindung eines neuen Knotens die Hardware und die festgelegten Zugangsdaten, rangiert sie und weist eine bestimmte Bewertung zu, bevor sie in das Ressourcenregister eingetragen wird. Im weiteren Verlauf werden die Aktivitätsparameter des Knotens analysiert, um das Risiko zu steuern, und die Bewertung des Knotens wird angepasst, um die Stabilität des Netzwerks zu gewährleisten. Es ist schließlich niemandem angenehm, wenn seine Szene zum Rendern an leistungsstarke, aber häufig überhitzende Karten gesendet wird.
Ein Benutzer, der eine Szene rendern muss, kann zwei Wege gehen: Er kann die Szene über das Webinterface in das Netzwerk-Repository hochladen oder seinen Modeller-Paket oder installierten Renderer über ein Plugin mit dem Netzwerk verbinden. Zwischen dem Benutzer und dem Netzwerk wird dabei ein Smart Contract initiiert, dessen reguläre Bedingung für den Abschluss die Generierung des Berechnungsergebnisses der Szene durch das Netzwerk ist. Der Benutzer kann den Fortschritt der Aufgabenerfüllung und die Parameter darüber über das Webinterface seines persönlichen Kontos verwalten.
Die Aufgabe gelangt zu Server, wo das Volumen der Szene und die Anzahl der vom Aufgabenauslöser angeforderten Ressourcen analysiert werden. Danach wird das Gesamtvolumen in Teile zerlegt, die an die von dem Netzwerk bereitgestellte Menge und Art von Ressourcen angepasst sind. Die allgemeine Idee besteht darin, dass die Visualisierung in viele kleine Aufgaben unterteilt werden kann. Die Engines nutzen diesen Vorteil, indem sie diese Aufgaben unter mehreren Ressourcenanbietern verteilen. Der einfachste Weg ist das Rendern kleiner Teile der Szene, die Segmente genannt werden. Wenn jedes Segment fertig ist, wird die lokale Aufgabe als abgeschlossen betrachtet, und die Ressource wechselt zur Ausführung der nächsten noch ungelösten.
Somit gibt es für den Renderer keinen wirklichen Unterschied, ob die Berechnungen auf einem einzelnen Rechner oder auf einem Gitter aus mehreren einzelnen Rechenstationen durchgeführt werden. Verteiltes Rendering fügt einfach mehr Kerne in den Pool der Ressourcen ein, die für die Aufgabe verwendet werden. Über das Netzwerk erhält er alle Daten, die für das Rendering des Segments erforderlich sind, berechnet es, sendet dieses Segment zurück und wechselt zur nächsten Aufgabe. Bevor ein Segment in den gemeinsamen Pool des Netzwerks gelangt, erhält es einen Satz von Metainformationen, die es den ausführenden Knoten ermöglichen, die am besten geeigneten Berechnungsaufgaben auszuwählen.
Die Aufgaben der Segmentierung und Verteilung der Berechnungen müssen dabei nicht nur aus der Sicht der Optimierung der Ausführungszeit, sondern auch aus der Sicht einer optimalen Ressourcennutzung und Energieeinsparung gelöst werden, da die wirtschaftliche Effizienz des Netzwerks davon abhängt. Im Falle einer suboptimalen Entscheidung wäre es sinnvoller, den Knoten als Miner zu verwenden oder ihn auszuschalten, um Lärm und Stromverbrauch zu vermeiden.
Kehren wir jedoch zum Prozess zurück. Bei der Entgegennahme einer Aufgabe wird zwischen dem Pool und dem Knoten auch ein Smart Contract erstellt, der bei korrekter Berechnung des Aufgabenresultats ausgeführt wird. Nach Ausführung des Vertrags kann der Knoten eine Belohnung in irgendeiner Form erhalten.
Das Kontrollzentrum überwacht den Ablauf der Aufgabe, indem es die Ergebnisse der Berechnungen sammelt, fehlerhafte Ergebnisse zur erneuten Bearbeitung zurücksendet und die Warteschlange rangiert, wobei es den normativen Zeitrahmen für die Ausführung der Aufgabe verfolgt (damit es nicht zu einem Fall kommt, dass das letzte Segment von keinem Knoten bearbeitet wird).
Die Ergebnisse der Berechnungen durchlaufen eine Komposition, nach der der Benutzer die Rendering-Ergebnisse erhält und das Netzwerk eine Belohnung erhalten kann.
Somit ergibt sich die funktionale Zusammensetzung eines landschaftlichen Frameworks, das für den Aufbau von Systemen für verteiltes Rendering vorgesehen ist:
- Persönliche Konten der Benutzer mit Webzugang
- Softwarepaket zur Installation auf Knoten
- Verwaltungssysteme:
- Zugriffskontrollunterstützungssystem
- Unterstützungssystem zur Dekomposition von Rendering-Aufgaben
- Aufgabenverteilungssystem
- Kompositionsunterstützungssystem
- Verwaltungssystem für den Server-Landschaft und die Netzwerktopologie
- Logging- und Auditsystem
- Lernendes Expertensystem
- REST API oder eine andere Schnittstelle für externe Entwickler
Was denken Sie darüber? Welche Fragen wirft das Thema auf und welche Antworten interessieren Sie?
Quelle: habr.com
