Negli ultimi anni, i feed di notizie sono stati inondati da rapporti su reti di calcolo distribuito di nuovo tipo che emergono letteralmente dal nulla, affrontando (o meglio, tentando di affrontare) le più varie sfide: rendere le città intelligenti, salvare il mondo dai trasgressori dei diritti d'autore o, al contrario, trasmettere segretamente informazioni o risorse, sfuggendo al controllo dello stato in un modo o nell'altro. Indipendentemente dal campo, tutte queste reti hanno una serie di caratteristiche comuni, causate dal fatto che gli algoritmi e le metodologie che hanno alimentato la loro crescita sono emersi di massa durante il recente boom delle criptovalute e delle tecnologie ad esse collegate. Probabilmente, ogni terzo articolo su risorse specializzate conteneva nel titolo la parola “blockchain” — la discussione di nuove soluzioni software e modelli economici è diventato per un certo periodo il trend dominante, sullo sfondo del quale altri ambiti di applicazione dei sistemi di calcolo distribuito sono stati messi in secondo piano.
Allo stesso tempo, visionari e professionisti hanno percepito l'essenza principale del fenomeno: il calcolo distribuito di massa, legato alla costruzione di reti composte da un gran numero di partecipanti disomogenei e disparati, ha raggiunto un nuovo livello di sviluppo. È sufficiente rimuovere dalle menti i temi sensazionalistici e guardare l'argomento da un'altra prospettiva: tutte queste reti, composte da enormi pool che ospitano migliaia di partecipanti isolati e diversi, non sono emerse da sole. Gli entusiasti del movimento crypto sono riusciti a risolvere in una nuova luce complessi problemi di sincronizzazione dei dati e distribuzione di risorse e compiti, il che ha permesso di unire una tale massa di attrezzature e creare un nuovo ecosistema progettato per affrontare un compito specifico.
Naturalmente, questo non è passato inosservato ai team e alle comunità impegnati nello sviluppo del calcolo distribuito aperto, e nuovi progetti non si sono fatti attendere.
Tuttavia, nonostante l'aumento significativo del volume di informazioni disponibili sui progressi nella costruzione di reti e nella gestione delle attrezzature, i creatori di sistemi promettenti dovranno affrontare seri problemi.
Il primo di essi, per quanto strano possa sembrare, è il problema della scelta della direzione
La direzione può essere giusta, può portare a un vicolo cieco — da questo non si può sfuggire, le forniture centralizzate di veggenti nella comunità IT finora sono in ritardo. Ma bisogna fare una scelta, per non cadere nella tradizionale trappola, che consiste nel fatto che il team prende un'area troppo ampia e fin da subito cerca di creare un altro progetto di calcolo distribuito non specializzato. Sembra che l'entità del lavoro non sia così terribile, bisogna per lo più semplicemente applicare le pratiche esistenti: unire i nodi in una rete, adattare gli algoritmi per la determinazione delle topologie, lo scambio di dati e il controllo della loro coerenza, implementare metodologie per il ranking dei nodi e per la ricerca del consenso, e, naturalmente, creare il proprio linguaggio di query e tutto l'ambiente linguistico e di calcolo. L'idea di un meccanismo universale è molto allettante e riemerge continuamente in vari ambiti, ma il risultato finale è ancora uno dei tre: la soluzione creata si rivela essere in realtà un prototipo limitato con un sacco di “ToDo” sospesi nel backlog, diventa un mostro inutilizzabile, pronto ad afferrare chiunque si avvicini in una fetida “palude di Turing”, oppure semplicemente muore tranquillamente a causa del fatto che le forze contrapposte del progetto si scontrano.
Non commettiamo errori stupidi e scegliamo una direzione che abbia un cerchio di compiti chiaro e ben adatta al modello di calcolo distribuito. Si possono capire le persone che cercano di fare tutto e subito — c'è sicuramente da scegliere. E molte cose sembrano estremamente interessanti sia dal punto di vista R&D e sviluppo, sia dal punto di vista economico. Con una rete distribuita si può:
- Addestrare reti neurali
- Elaborare flussi di segnali
- Calcolare la struttura delle proteine
- Eseguire rendering di scene tridimensionali
- Modellare la dinamica dei fluidi
- Testare strategie di trading per borse valori
Per non lasciarsi trasportare nella compilazione di un elenco di cose interessanti che si prestano bene alla parallelizzazione, scegliamo come nostro tema futuro il rendering distribuito.
Il rendering distribuito è, ovviamente, un fenomeno non nuovo. I toolkit di rendering esistenti supportano già da tempo la distribuzione del carico su diverse macchine; senza ciò, vivere nel ventunesimo secolo sarebbe piuttosto triste. Tuttavia, non si deve pensare che l'argomento sia esaurito e che non ci sia nulla da fare: esamineremo un problema specifico e attuale: la creazione di uno strumento per formare una rete di rendering.
La rete di rendering è un insieme di nodi che devono eseguire compiti di rendering, con nodi che dispongono di risorse computazionali disponibili per elaborare il rendering. I proprietari delle risorse collegheranno le loro stazioni alla rete di rendering per ricevere e completare i compiti di rendering utilizzando uno dei motori di rendering supportati dalla rete. I fornitori di compiti lavoreranno con la rete come se fosse un cloud, gestendo autonomamente la distribuzione delle risorse, il controllo della correttezza nell'esecuzione, la gestione del rischio e altri problemi.
Pertanto, esamineremo la creazione di un framework che deve supportare l'integrazione con un insieme di motori di rendering popolari e contenere componenti che forniscono strumenti per organizzare una rete di nodi eterogenei e gestire il flusso dei compiti.
Il modello economico di esistenza di tale rete non ha un'importanza fondamentale, quindi adottiamo come base uno schema simile a quello utilizzato nei calcoli delle reti di criptovalute: i consumatori delle risorse invieranno token ai fornitori che eseguono il lavoro di rendering. È molto più interessante capire quali caratteristiche deve avere il framework, per cui esamineremo lo scenario principale di interazione tra i partecipanti alla rete.
Nella rete esistono tre parti in interazione: il fornitore di risorse, il fornitore di compiti e l'operatore della rete (ossia il centro di controllo, la rete e così via nel testo).
L'operatore di rete fornisce al fornitore di risorse un'applicazione client o un'immagine di sistema operativo con un insieme di software preinstallato, che questi installerà sulla macchina le cui risorse desidera fornire, e un pannello accessibile tramite web che gli consente di impostare i parametri di accesso alle risorse e gestire da remoto il proprio ambiente server: controllare i parametri hardware, eseguire la configurazione remota, riavviare.
Il sistema di gestione della rete, durante la connessione di un nuovo nodo, analizza l'hardware e i parametri di accesso impostati, lo classifica assegnando un determinato punteggio, e lo inserisce nel registro delle risorse. In seguito, ai fini della gestione del rischio, i parametri di attività del nodo verranno analizzati e il punteggio del nodo verrà corretto per garantire la stabilità del funzionamento della rete. A nessuno fa piacere che la propria scena venga inviata a essere renderizzata su schede potenti ma spesso soggette a problemi di surriscaldamento.
L'utente che ha bisogno di renderizzare una certa scena può intraprendere due strade: caricare la scena nel repository della rete tramite un'interfaccia web oppure collegare il proprio pacchetto di modellazione o renderer installato alla rete tramite un plugin. In questo caso, tra l'utente e la rete viene avviato un contratto intelligente, il cui termine standard è la generazione da parte della rete del risultato del calcolo della scena. L'utente può monitorare il processo di esecuzione dell'attività e gestire i suoi parametri tramite l'interfaccia web del proprio pannello personale.
L'attività viene ricevuta su server, dove viene analizzato il volume della scena e la quantità di risorse richieste dall'iniziatore dell'attività, dopo di che viene eseguita la scomposizione del volume totale in parti adattate per il calcolo sulla quantità e sul tipo di risorse allocate dalla rete. L'idea generale è che la visualizzazione può essere suddivisa in numerosi compiti più piccoli. I motori sfruttano questo vantaggio distribuendo questi compiti tra diversi fornitori di risorse. Il modo più semplice è il rendering di piccole parti della scena, chiamate segmenti. Quando ogni segmento è pronto, l'attività locale è considerata completata e la risorsa passa all'esecuzione della successiva tra quelle non ancora risolte.
In questo modo, per il renderer non c'è differenza se i calcoli vengano eseguiti su una singola macchina o su una griglia composta da più stazioni di lavoro distinte. Il rendering distribuito semplicemente aggiunge più core al pool di risorse utilizzate per il compito. Attraverso la rete, riceve tutti i dati necessari per il rendering del segmento, calcola, restituisce questo segmento e passa al compito successivo. Prima di entrare nel pool di rete, ogni segmento riceve un set di meta-informazioni che consente ai nodi esecutori di scegliere i compiti di calcolo più adatti a loro.
I compiti di segmentazione e distribuzione dei calcoli devono essere affrontati non solo dal punto di vista dell'ottimizzazione del tempo di esecuzione, ma anche da quello dell'uso ottimale delle risorse e del risparmio energetico, poiché questo influisce sull'efficienza economica della rete. In caso di una soluzione non ottimale, risulta più conveniente installare un miner o spegnerlo, per evitare rumori e sprechi di elettricità.
Tornando al processo, quando riceve un compito, tra il pool e il nodo viene anche formata una smart contract, che si attiva quando il risultato del compito viene calcolato correttamente. A seguito dell'esecuzione del contratto, il nodo può ricevere una ricompensa in un modo o nell'altro.
Il centro di controllo monitora il processo di esecuzione del compito, raccogliendo i risultati dei calcoli, inviando per una rielaborazione quelli errati e classificando la coda, tracciando il termine normativo per l'esecuzione del compito (per evitare che l'ultimo segmento non venga preso in carico da alcun nodo).
I risultati dei calcoli passano attraverso una fase di composizione, dopodiché l'utente riceve i risultati del rendering e la rete può ricevere una ricompensa.
In questo modo si delinea la composizione funzionale del framework paesaggistico destinato alla realizzazione di sistemi di rendering distribuito:
- Pannelli personali per gli utenti con accesso web
- Pacchetto software per l'installazione sui nodi
- Sistemi di gestione:
- Sottosistema di gestione degli accessi
- Sottosistema di decomposizione dei compiti di rendering
- Sottosistema di distribuzione dei compiti
- Sottosistema di composizione
- Sottosistema di gestione del paesaggio server e della topologia della rete
- Sottosistema di registrazione e auditing
- Sottosistema esperto che apprende
- API Rest o altro interfaccio per sviluppatori esterni
E voi, cosa ne pensate? Quali domande suscita questo argomento e quali risposte vi interessano?
Fonte: habr.com
