In den letzten Jahren wurden Newsfeeds mit Meldungen über eine neue Art von verteilten Computernetzwerken überschwemmt, die buchstäblich aus dem Nichts auftauchten und eine Vielzahl von Problemen lösten (oder vielmehr zu lösen versuchten): eine Stadt intelligent machen und die Welt vor dem Urheberrecht retten Rechtsverletzer oder umgekehrt, heimliche Weitergabe von Informationen oder Ressourcen, Flucht vor staatlicher Kontrolle in dem einen oder anderen Bereich. Unabhängig vom Fachgebiet weisen sie alle eine Reihe gemeinsamer Merkmale auf, da der Treibstoff für ihr Wachstum die Algorithmen und Techniken waren, die während des jüngsten Booms der Kryptowährungen und verwandter Technologien an die Öffentlichkeit gelangten. Vermutlich jeder dritte Artikel zu spezialisierten Ressourcen hatte damals das Wort „Blockchain“ im Titel – die Diskussion neuer Softwarelösungen und Wirtschaftsmodelle wurde für einige Zeit zum dominierenden Trend, vor dem Hintergrund anderer Einsatzgebiete verteilter Rechensysteme in den Hintergrund gedrängt.
Gleichzeitig erkannten Visionäre und Fachleute den Kern des Phänomens: Massive Distributed Computing, verbunden mit dem Aufbau von Netzwerken aus einer großen Anzahl unterschiedlicher und heterogener Teilnehmer, hat ein neues Entwicklungsniveau erreicht. Es genügt, die Hype-Themen aus dem Kopf zu werfen und das Thema von der anderen Seite zu betrachten: All diese Netzwerke, zusammengesetzt aus riesigen Pools, die aus Tausenden isolierter heterogener Teilnehmer bestehen, sind nicht von alleine entstanden. Enthusiasten der Krypto-Bewegung konnten komplexe Probleme der Datensynchronisierung und Verteilung von Ressourcen und Aufgaben auf eine neue Art und Weise lösen, was es ermöglichte, eine ähnliche Masse an Ausrüstung zusammenzustellen und ein neues Ökosystem zu schaffen, das auf die Lösung eines eng fokussierten Problems ausgelegt war.
Dies ging natürlich nicht an den Teams und Communities vorbei, die an der Entwicklung des freien verteilten Rechnens beteiligt waren, und neue Projekte ließen nicht lange auf sich warten.
Doch trotz der deutlichen Zunahme der verfügbaren Informationen über Entwicklungen im Bereich Netzwerkaufbau und Gerätearbeit müssen die Entwickler vielversprechender Systeme gravierende Probleme lösen.
Das erste davon, so seltsam es auch klingen mag, ist das Problem der Richtungswahl.
Die Richtung kann richtig sein oder in eine Sackgasse führen – daraus gibt es kein Entrinnen; die zentralisierte Versorgung der IT-Community mit Hellseherinnen und Hellsehern kommt immer noch zu spät. Aber die Wahl muss so getroffen werden, dass man nicht in die traditionelle Falle tappt, dass das Team einen zu weiten Bereich einnimmt und von Anfang an versucht, ein weiteres, nicht spezialisiertes, allgemeines verteiltes Computerprojekt zu erstellen. Es scheint, dass der Arbeitsumfang nicht so beängstigend ist, zum größten Teil müssen wir nur bestehende Entwicklungen anwenden: Knoten zu einem Netzwerk zusammenfassen, Algorithmen zur Bestimmung von Topologien anpassen, Daten austauschen und ihre Konsistenz überwachen, Methoden zum Ranking und Finden von Knoten einführen Konsens, und natürlich erstellen Sie einfach Ihre eigene Abfragesprache und die gesamte Sprach- und Computerumgebung. Die Idee eines universellen Mechanismus ist sehr verlockend und taucht ständig in dem einen oder anderen Bereich auf, aber das Endergebnis ist immer noch eines von drei Dingen: Die erstellte Lösung stellt sich entweder als limitierter Prototyp mit einer Menge schwebender „ToDos“ heraus ” im Rückstand, oder es wird zu einem unbrauchbaren Monster, das bereit ist, jeden wegzuziehen, der den stinkenden „Turing-Sumpf“ berührt, oder es stirbt einfach sicher daran, dass der Schwan, die Krebse und der Hecht, die das Projekt in eine unverständliche Richtung zogen, einfach überfordert.
Wiederholen wir keine dummen Fehler und wählen wir eine Richtung, die einen klaren Aufgabenbereich hat und gut zum verteilten Rechenmodell passt. Man kann Leute verstehen, die versuchen, alles auf einmal zu machen – die Auswahl ist natürlich groß. Und vieles sieht sowohl aus Sicht der Forschung und Entwicklung als auch aus wirtschaftlicher Sicht äußerst interessant aus. Mit einem verteilten Netzwerk können Sie:
- Trainieren Sie neuronale Netze
- Signalströme verarbeiten
- Berechnen Sie die Proteinstruktur
- Rendern Sie XNUMXD-Szenen
- Hydrodynamik simulieren
- Testen Sie Handelsstrategien für Börsen
Um uns nicht mit der Zusammenstellung einer Liste interessanter Dinge, die gut parallelisiert sind, zu langweilen, wählen wir als weiteres Thema verteiltes Rendering.
Verteiltes Rendering an sich ist natürlich nichts Neues. Vorhandene Render-Toolkits unterstützen seit langem die Lastverteilung auf verschiedene Maschinen; ohne diese wäre das Leben im XNUMX. Jahrhundert ziemlich traurig. Sie sollten jedoch nicht glauben, dass das Thema bereits umfassend behandelt wurde und es nichts zu tun gibt. Wir werden uns mit einem separaten dringenden Problem befassen: der Erstellung eines Tools zum Erstellen eines Render-Netzwerks.
Unser Rendering-Netzwerk ist eine Kombination aus Knoten, die Rendering-Aufgaben ausführen müssen, und Knoten, die über freie Rechenressourcen zur Verarbeitung des Renderings verfügen. Ressourceneigentümer verbinden ihre Stationen mit dem Rendernetzwerk, um Renderaufträge mithilfe einer der vom Netzwerk unterstützten Render-Engines zu empfangen und auszuführen. In diesem Fall arbeiten Aufgabenanbieter mit dem Netzwerk als Cloud, verteilen unabhängig Ressourcen und überwachen die korrekte Ausführung, das Risikomanagement und andere Probleme.
Daher werden wir die Schaffung eines Frameworks in Betracht ziehen, das die Integration mit einer Reihe gängiger Render-Engines unterstützen und Komponenten enthalten sollte, die Tools zum Organisieren eines Netzwerks heterogener Knoten und zum Verwalten des Aufgabenflusses bereitstellen.
Das wirtschaftliche Modell der Existenz eines solchen Netzwerks ist nicht von grundlegender Bedeutung, daher werden wir als Ausgangsschema ein Schema verwenden, das dem ähnelt, das bei Berechnungen in Kryptowährungsnetzwerken verwendet wird – Verbraucher der Ressource senden Token an Lieferanten, die die Rendering-Arbeit durchführen. Viel interessanter ist es zu verstehen, welche Eigenschaften ein Framework haben sollte, für das wir das Hauptszenario der Interaktion zwischen Netzwerkteilnehmern betrachten.
Es gibt drei Seiten der Interaktion im Netzwerk: Ressourcenanbieter, Aufgabenanbieter und Netzwerkbetreiber (im Text auch als Kontrollzentrum, Netzwerk usw. bezeichnet).
Der Netzwerkbetreiber stellt dem Ressourcenanbieter eine Client-Anwendung oder ein Betriebssystem-Image mit einem bereitgestellten Softwaresatz zur Verfügung, den er auf dem Computer installiert, dessen Ressourcen er bereitstellen möchte, sowie ein persönliches Konto, auf das er über die Webschnittstelle zugreifen kann Zugriffsparameter auf die Ressource festlegen und seine Serverlandschaft aus der Ferne verwalten: Hardwareparameter steuern, Fernkonfiguration durchführen, Neustart durchführen.
Wenn ein neuer Knoten angeschlossen wird, analysiert das Netzwerkmanagementsystem die Ausrüstung und die angegebenen Zugangsparameter, ordnet sie ein, weist eine bestimmte Bewertung zu und trägt sie in das Ressourcenregister ein. Um das Risiko zu managen, werden in Zukunft die Aktivitätsparameter des Knotens analysiert und die Bewertung des Knotens angepasst, um die Stabilität des Netzwerks sicherzustellen. Niemand wird erfreut sein, wenn seine Szene zum Rendern auf leistungsstarke Karten geschickt wird, die oft aufgrund von Überhitzung einfrieren?
Ein Benutzer, der eine Szene rendern muss, hat zwei Möglichkeiten: Er lädt die Szene über die Webschnittstelle in ein Netzwerk-Repository hoch oder verwendet ein Plugin, um sein Modellierungspaket oder seinen installierten Renderer mit dem Netzwerk zu verbinden. In diesem Fall wird zwischen dem Nutzer und dem Netzwerk ein Smart Contract initiiert, dessen Standardbedingung die Generierung des Ergebnisses der Szenenberechnung durch das Netzwerk ist. Der Benutzer kann den Prozess der Erledigung einer Aufgabe überwachen und ihre Parameter über die Weboberfläche seines persönlichen Kontos verwalten.
Die Aufgabe wird an den Server gesendet, wo das Volumen der Szene und die Anzahl der vom Aufgabeninitiator angeforderten Ressourcen analysiert werden. Anschließend wird das Gesamtvolumen in Teile zerlegt, die für die Berechnung der Anzahl und Art der vom Netzwerk zugewiesenen Ressourcen angepasst sind . Die allgemeine Idee ist, dass Visualisierung in viele kleine Aufgaben unterteilt werden kann. Engines machen sich dies zunutze, indem sie diese Aufgaben auf mehrere Ressourcenanbieter verteilen. Der einfachste Weg besteht darin, kleine Teile der Szene, sogenannte Segmente, zu rendern. Wenn jedes Segment bereit ist, gilt die lokale Aufgabe als abgeschlossen und die Ressource geht zur nächsten ausstehenden Aufgabe über.
Somit macht es für den Renderer grundsätzlich keinen Unterschied, ob die Berechnungen auf einer einzelnen Maschine oder auf einem Raster aus vielen einzelnen Rechenstationen durchgeführt werden. Beim verteilten Rendering werden einfach mehr Kerne zum Ressourcenpool hinzugefügt, der für eine Aufgabe verwendet wird. Über das Netzwerk empfängt es alle zum Rendern eines Segments erforderlichen Daten, berechnet sie, sendet das Segment zurück und fährt mit der nächsten Aufgabe fort. Vor dem Eintritt in den allgemeinen Netzwerkpool erhält jedes Segment eine Reihe von Metainformationen, die es den ausführenden Knoten ermöglichen, die für sie am besten geeigneten Rechenaufgaben auszuwählen.
Die Probleme der Segmentierung und Verteilung von Berechnungen müssen nicht nur unter dem Gesichtspunkt der Optimierung der Ausführungszeit, sondern auch unter dem Gesichtspunkt der optimalen Ressourcennutzung und Energieeinsparung gelöst werden, da davon die Wirtschaftlichkeit des Netzwerks abhängt . Sollte die Lösung keinen Erfolg haben, wäre es ratsamer, einen Miner auf dem Knoten zu installieren oder ihn abzuschalten, damit er keinen Lärm macht und keinen Strom verschwendet.
Kommen wir jedoch zurück zum Prozess. Beim Empfang einer Aufgabe wird außerdem ein Smart Contract zwischen dem Pool und dem Node gebildet, der bei korrekter Berechnung des Aufgabenergebnisses ausgeführt wird. Basierend auf den Ergebnissen der Vertragserfüllung kann der Knoten eine Belohnung in der einen oder anderen Form erhalten.
Das Kontrollzentrum steuert den Prozess der Aufgabenausführung, sammelt Berechnungsergebnisse, sendet falsche zur erneuten Verarbeitung und ordnet die Warteschlange und überwacht die Standardfrist für die Erledigung der Aufgabe (damit es nicht passiert, dass das letzte Segment nicht belegt wird). beliebiger Knoten).
Die Ergebnisse der Berechnungen durchlaufen die Compositing-Phase. Anschließend erhält der Benutzer die Rendering-Ergebnisse und das Netzwerk kann eine Belohnung erhalten.
Somit ergibt sich die funktionale Zusammensetzung eines Landschaftsrahmens, der für den Aufbau verteilter Rendering-Systeme konzipiert ist:
- Persönliche Benutzerkonten mit Webzugriff
- Software-Kit zur Installation auf Knoten
- Nach Kontrollsystem:
- Subsystem für die Zugangskontrolle
- Subsystem zur Zerlegung von Rendering-Aufgaben
- Subsystem zur Aufgabenverteilung
- Compositing-Subsystem
- Subsystem für die Verwaltung von Serverlandschaften und Netzwerktopologien
- Protokollierungs- und Audit-Subsystem
- Lernexperten-Subsystem
- Rest-API oder andere Schnittstelle für externe Entwickler
Was denken Sie? Welche Fragen wirft das Thema auf und welche Antworten interessieren Sie?
Source: habr.com