In den letzten Jahren wurden Newsfeeds mit Nachrichten über eine neue Art von verteilten Computernetzwerken überflutet, die die unterschiedlichsten Aufgaben lösen (oder vielmehr zu lösen versuchen) - die Stadt intelligent machen, die Welt vor Urheberrechtsverletzern retten oder umgekehrt, Informationen oder Ressourcen heimlich übertragen, entkommen - unter der Kontrolle des Staates in einem bestimmten Gebiet. Unabhängig von der Sphäre haben sie alle eine Reihe gemeinsamer Merkmale, da der Treibstoff für ihr Wachstum Algorithmen und Techniken waren, die während des jüngsten Booms von Kryptowährungen und verwandten Technologien an die Massen gingen. Wahrscheinlich hatte jeder dritte Artikel über spezialisierte Ressourcen zu dieser Zeit im Titel das Wort „Blockchain“ - die Diskussion über neue Softwarelösungen und Wirtschaftsmodelle wurde für einige Zeit zum vorherrschenden Trend, vor dem andere Anwendungsbereiche verteilter Computersysteme in den Hintergrund traten.
Gleichzeitig erkannten Visionäre und Fachleute die Hauptessenz des Phänomens: Massenverteiltes Computing, das mit dem Aufbau von Netzwerken einer großen Anzahl unterschiedlicher und heterogener Teilnehmer verbunden ist, erreichte einen neuen Entwicklungsstand. Es reicht aus, Hype-Themen aus dem Kopf zu werfen und das Thema von der anderen Seite zu betrachten: Alle diese Netzwerke, die aus riesigen Pools zusammengesetzt sind, die aus Tausenden von verschiedenen heterogenen Teilnehmern bestehen, sind nicht für sich allein aufgetaucht. Krypto-Bewegungsbegeisterte konnten die komplexen Probleme der Datensynchronisation und der Zuweisung von Ressourcen und Aufgaben auf neue Weise lösen, wodurch wir eine ähnliche Masse an Geräten zusammenstellen und ein neues Ökosystem schaffen konnten, das ein eng zielgerichtetes Problem lösen sollte.
Dies ging natürlich nicht an den Teams und Communities vorbei, die an der Entwicklung von Free Distributed Computing beteiligt waren, und neue Projekte ließen nicht lange auf sich warten.
Trotz eines ernsthaften Anstiegs der verfügbaren Informationen über Entwicklungen auf dem Gebiet der Vernetzung und Ausrüstung müssen die Entwickler vielversprechender Systeme ernsthafte Probleme lösen.
Der erste von ihnen, so seltsam es auch klingen mag, ist das Problem der Wahl einer Richtung
Die Richtung kann richtig sein, es kann zu einer Sackgasse führen - Sie können sich nicht davon lösen, zentralisierte Lieferungen von Hellsehern an die IT-Community sind immer noch verspätet. Es sollte jedoch die Wahl getroffen werden, nicht in die traditionelle Falle zu tappen, dass das Team ein zu weites Feld einnimmt und von Anfang an versucht, ein weiteres nicht spezialisiertes Projekt für verteiltes Rechnen mit einem breiten Profil zu erstellen. Es scheint, dass die Front der Arbeit nicht so schrecklich ist. Zum größten Teil müssen Sie nur die vorhandenen Entwicklungen anwenden: Vereinigen Sie die Knoten zu einem Netzwerk, passen Sie die Algorithmen zur Bestimmung von Topologien an, tauschen Sie Daten aus und kontrollieren Sie ihre Konsistenz, führen Sie Methoden zur Rangfolge von Knoten und zur Konsensfindung ein und natürlich nur Erstellen Sie Ihre eigene Abfragesprache und die gesamte Sprach- und Computerumgebung. Die Idee eines universellen Mechanismus ist sehr verlockend und taucht ständig in der einen oder anderen Sphäre auf, aber die Ausgabe stellt sich immer noch als eine von drei heraus: Die erstellte Lösung stellt sich entweder als begrenzter Prototyp mit einer Reihe von suspendierten „ToDo“ im Backlog heraus oder sie wird zu einem unüberschaubaren Monster, das zum Ziehen bereit ist Jeder, der den übelriechenden „Turing-Sumpf“ berührt oder einfach sicher daran stirbt, dass der Schwan, die Krabbe und der Hecht, die in eine unverständliche Richtung ziehen, in Stücke gerissen werden.
Wir werden keine dummen Fehler wiederholen und eine Richtung wählen, die einen verständlichen Aufgabenbereich hat und für das verteilte Rechenmodell gut geeignet ist. Sie können Leute verstehen, die versuchen, alles auf einmal zu tun - natürlich gibt es eine große Auswahl. Und vieles sieht sowohl aus Sicht von F & E und Entwicklung als auch aus wirtschaftlicher Sicht äußerst interessant aus. Mit einem verteilten Netzwerk können Sie:
- Trainiere neuronale Netze
- Signalströme verarbeiten
- Berechnen Sie die Proteinstruktur
- 3D-Szenen rendern
- Hydrodynamik simulieren
- Testen Sie Handelsstrategien für Börsen
Um nicht von der Zusammenstellung einer Liste interessanter Dinge, die gut parallel sind, mitgerissen zu werden, wählen wir verteiltes Rendering als weiteres Thema.
Verteiltes Rendern an sich ist natürlich nie ein neues Phänomen. Bestehende Render-Toolkits unterstützen seit langem die Lastverteilung auf verschiedene Maschinen, ohne die es ziemlich traurig wäre, im 21. Jahrhundert zu leben. Sie sollten jedoch nicht glauben, dass das Thema auf und ab getrieben wurde, und es gibt dort nichts zu tun - wir werden ein separates dringendes Problem betrachten: das Erstellen eines Tools zum Erstellen eines Render-Netzwerks.
Das Rendering-Netzwerk mit uns ist die Vereinigung von Knoten, die Rendering-Aufgaben ausführen müssen, mit Knoten, die über freie Rechenressourcen für das Rendering verfügen. Ressourcenbesitzer verbinden ihre Stationen mit dem Rendering-Netzwerk, um Rendering-Jobs mit einer der netzwerkunterstützten Rendering-Engines zu empfangen und auszuführen. Gleichzeitig arbeiten Task-Provider mit dem Netzwerk als Cloud, die Ressourcen unabhängig verteilt, die Richtigkeit der Ausführung überprüft und Risiken und andere Probleme verwaltet.
Daher werden wir die Schaffung eines Frameworks in Betracht ziehen, das die Integration in eine Reihe gängiger Rendering-Engines unterstützen und Komponenten enthalten soll, die Tools zum Organisieren eines Netzwerks heterogener Knoten und zum Steuern des Aufgabenflusses bereitstellen.
Das Wirtschaftsmodell der Existenz eines solchen Netzwerks ist nicht von grundlegender Bedeutung, daher werden wir für das erste ein ähnliches Schema wie bei Berechnungen in Kryptowährungsnetzwerken verwenden - Ressourcenkonsumenten senden Token an Lieferanten, die die Rendering-Arbeiten ausführen. Es ist viel interessanter zu verstehen, welche Eigenschaften ein Framework haben sollte, für die wir das Hauptszenario für die Interaktion von Netzwerkteilnehmern betrachten werden.
Es gibt drei Aspekte der Interaktion in einem Netzwerk: einen Ressourcenanbieter, einen Aufgabenanbieter und einen Netzwerkbetreiber (im gesamten Text als Kontrollzentrum, Netzwerk usw. bezeichnet).
Der Netzbetreiber stellt dem Ressourcenanbieter eine Clientanwendung oder ein Betriebssystemabbild mit einer umfassenden Software zur Verfügung, die er auf dem Computer installiert, dessen Ressourcen er bereitstellen möchte, sowie einem persönlichen Konto, auf das über die Weboberfläche zugegriffen werden kann, sodass er Zugriffsparameter für die Ressource festlegen und seinen Server fernsteuern kann Landschaft: Steuern Sie die Parameter von Eisen, führen Sie eine Remote-Konfiguration durch und starten Sie den Computer neu.
Beim Verbinden eines neuen Knotens analysiert das Netzwerkverwaltungssystem das Gerät und die angegebenen Zugriffsparameter, ordnet es, weist eine bestimmte Bewertung zu und legt es im Ressourcenregister ab. 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 sich freuen, wenn seine Szene auf mächtigen, aber oft überhitzten Karten gerendert wird?
Ein Benutzer, der eine Szene rendern muss, hat zwei Möglichkeiten: Laden Sie die Szene über die Weboberfläche in das Netzwerk-Repository hoch oder verbinden Sie sein Simulationspaket oder den installierten Renderer über das Plug-In mit dem Netzwerk. In diesem Fall wird ein intelligenter Vertrag zwischen dem Benutzer und dem Netzwerk initiiert, dessen Standardbedingung die Erzeugung des Szenenberechnungsergebnisses durch das Netzwerk ist. Der Benutzer kann den Fortschritt der Aufgabe überwachen und ihre Parameter über die Weboberfläche seines persönlichen Kontos verwalten.
Die Aufgabe kommt auf dem Server an, wo das Szenenvolumen und die Anzahl der vom Aufgabeninitiator angeforderten Ressourcen analysiert werden. Anschließend wird das Gesamtvolumen in Teile zerlegt, die zur Berechnung der Anzahl und Art der vom Netzwerk zugewiesenen Ressourcen angepasst sind. Die allgemeine Idee ist, dass die Visualisierung in viele kleine Aufgaben unterteilt werden kann. Engines nutzen dies, indem sie diese Aufgaben auf mehrere Ressourcenanbieter verteilen. Am einfachsten ist es, kleine Teile einer Szene zu rendern, die als Segmente bezeichnet werden. Wenn jedes Segment bereit ist, gilt die lokale Aufgabe als erledigt, und die Ressource fährt mit der nächsten ungelösten fort.
Somit gibt es für den Renderer als solchen keinen Unterschied, ob die Berechnungen auf einer Maschine oder auf einem Gitter von vielen getrennten Rechenstationen durchgeführt werden. Durch verteiltes Rendern werden dem für die Aufgabe verwendeten Ressourcenpool einfach mehr Kerne hinzugefügt. Über das Netzwerk empfängt er alle zum Rendern eines Segments erforderlichen Daten, berechnet sie, sendet dieses Segment zurück und fährt mit der nächsten Aufgabe fort. Vor dem Eintritt in den allgemeinen Pool des Netzwerks erhält jedes Segment eine Reihe von Metainformationen, mit denen die ausführenden Knoten die für sie am besten geeigneten Rechenaufgaben auswählen können.
Die Aufgaben der Segmentierung und Verteilung von Berechnungen sollten nicht nur unter dem Gesichtspunkt der Optimierung der Ausführungszeit, sondern auch unter dem Gesichtspunkt der optimalen Nutzung der Ressourcen und der Energieeinsparung gelöst werden, da die Wirtschaftlichkeit des Netzwerks davon abhängt. Im Falle einer erfolglosen Entscheidung ist es zweckmäßiger, den Bergmann ein- oder auszuschalten, damit er keinen Lärm macht und keinen Strom verschwendet.
Aber zurück zum Prozess. Wenn eine Aufgabe zwischen dem Pool und dem Knoten empfangen wird, wird auch ein intelligenter Vertrag gebildet, der ausgeführt wird, wenn das Aufgabenergebnis korrekt berechnet wird. Basierend auf den Ergebnissen des Vertrags kann der Knoten eine Belohnung in der einen oder anderen Form erhalten.
Das Kontrollzentrum überwacht den Prozess des Abschlusses der Aufgabe, sammelt die Ergebnisse der Berechnungen, sendet die falschen zur Wiederaufbereitung und Rangfolge der Warteschlange und verfolgt den normativen Begriff der Aufgabe (damit es nicht vorkommt, dass das letzte Segment von keinem Knoten in Betrieb genommen wird).
Die Berechnungsergebnisse durchlaufen die Compositing-Phase. Danach erhält der Benutzer die Rendering-Ergebnisse und das Netzwerk kann eine Belohnung erhalten.
So ergibt sich die funktionale Zusammensetzung des Landschaftsrahmens, mit dem verteilte Rendering-Systeme erstellt werden sollen:
- Web-Dashboards
- Eine Reihe von Software zur Installation auf Knoten
- Nach Managementsystem:
- Subsystem für die Zugriffskontrolle
- Das Zerlegungssubsystem für Rendering-Aufgaben
- Taskverteilungs-Subsystem
- Compositing-Subsystem
- Subsystem zur Verwaltung der Serverlandschaft und der Netzwerktopologie
- Protokollierungs- und Überwachungssubsystem
- Learning Expert Subsystem
- Rest API oder andere Schnittstelle für externe Entwickler
Was denkst du? Welche Fragen wirft das Thema auf und welche Antworten interessieren Sie?