Negli ultimi anni, i feed di notizie sono stati invasi da racconti su reti di calcolo distribuito di nuovo tipo, che emergono letteralmente dal nulla, cercando di affrontare (o meglio, tentando di affrontare) una varietà di compiti: rendere le città intelligenti, salvare il mondo dai violatori dei diritti d'autore o, al contrario, trasmettere segretamente informazioni o risorse, sfuggendo al controllo statale in vari settori. Indipendentemente dall'ambito, esse condividono tutte alcune caratteristiche comuni, dovute al fatto che il motore della loro crescita è stato costituito da algoritmi e metodologie diffuse durante il recente boom delle criptovalute e delle tecnologie correlate. Probabilmente, ogni terzo articolo su risorse specializzate conteneva nel titolo la parola 'blockchain' — la discussione di nuove soluzioni software e modelli economici è diventata una tendenza dominante, relegando in secondo piano altri ambiti di applicazione dei sistemi di calcolo distribuito.
Nel frattempo, visionari e professionisti hanno colto l'essenza fondamentale del fenomeno: il calcolo distribuito su larga scala, legato alla costruzione di reti composte da un gran numero di partecipanti eterogenei e sparsi, ha raggiunto un nuovo livello di sviluppo. Basta abbandonare le tematiche hype e guardare la questione da un'altra prospettiva: tutte queste reti, raccolte da enormi pool che comprendono migliaia di partecipanti anonimi e diversi, non sono emerse spontaneame. Gli appassionati del movimento crypto sono riusciti a risolvere in modo innovativo complesse sfide di sincronizzazione dei dati e distribuzione delle risorse e dei compiti, il che ha permesso di unire una massa così imponente di attrezzature e creare un nuovo ecosistema dedicato alla risoluzione di un compito specifico.
Naturalmente, ciò non è passato inosservato ai team e alle comunità impegnati nello sviluppo del calcolo distribuito open-source, e nuovi progetti non hanno tardato ad arrivare.
Tuttavia, nonostante il notevole aumento del volume di informazioni disponibili sui progressi nel campo della costruzione di reti e del lavoro con l'attrezzatura, i creatori di sistemi innovativi dovranno affrontare anche seri problemi.
La prima di esse, per quanto strano possa sembrare, è il problema della scelta della direzione
La direzione può essere giusta o può portare a un vicolo cieco; non si può sfuggire a questo, le forniture centralizzate di chiaroveggenti nella comunità IT sono ancora in ritardo. Ma è necessario fare una scelta per non cadere nella tradizionale trappola in cui il team abbraccia un campo troppo ampio e cerca di creare fin dall'inizio un altro progetto di calcolo distribuito non specializzato. Sembra che il lavoro non sia poi così spaventoso; si tratta perlopiù di applicare le soluzioni esistenti: collegare i nodi in rete, adattare gli algoritmi per la determinazione delle topologie, lo scambio di dati e il controllo della loro coerenza, implementare metodologie di ranking dei nodi e di raggiungimento del consenso, e infine, ovviamente, semplicemente creare il proprio linguaggio di query e tutto l'ambiente linguistico e computazionale. L'idea di un meccanismo universale è estremamente allettante e riemerge costantemente in vari contesti, ma alla fine si ottiene sempre una delle seguenti tre situazioni: la soluzione sviluppata si rivela un prototipo limitato con un sacco di “ToDo” in attesa nel backlog, diventa un mostro inutilizzabile pronto a risucchiare chiunque si avvicini in una fetida “palude di Turing”, oppure semplicemente muore in modo tranquillo a causa di forze diverse che tirano il progetto in direzioni incomprensibili, come il cigno, il granchio e la carpa che si sono semplicemente strappati.
Non ripeteremo gli errori stupidi e sceglieremo una direzione che abbia un cerchio di compiti chiaro e ben adatto al modello di calcolo distribuito. Si possono comprendere le persone che cercano di fare tutto e subito — di scelte ce ne sono molte. E molte cose sembrano estremamente interessanti sia dal punto di vista della R&D e dello sviluppo, sia dal punto di vista economico. Con una rete distribuita è possibile:
- Addestrare reti neurali
- Elaborare flussi di segnali
- Calcolare la struttura delle proteine
- Effettuare il rendering di scene tridimensionali
- Modellare la fluidodinamica
- Testare strategie di trading per le borse valori
Per non perdersi nella compilazione di un elenco di cose interessanti che si prestano bene alla parallelizzazione, sceglieremo come nostro argomento futuro il rendering distribuito.
Il rendering distribuito, di per sé, non è certo una novità. Gli strumenti di rendering esistenti da tempo supportano la distribuzione del carico su diverse macchine; senza di questo, vivere nel ventunesimo secolo sarebbe piuttosto triste. Tuttavia, non bisogna pensare che l'argomento sia stato esaminato a fondo e non ci sia nulla da fare: discuteremo di un problema attuale specifico: la creazione di uno strumento per formare una rete di rendering.
La rete di rendering consiste in un insieme di nodi che devono eseguire compiti di rendering, insieme a nodi che dispongono di risorse computazionali libere per elaborare il rendering. I proprietari delle risorse collegheranno le proprie stazioni alla rete di rendering per ricevere ed eseguire 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 autonomo, responsabile della distribuzione delle risorse, del controllo di correttezza dell'esecuzione, della gestione dei rischi e di altre problematiche.
In questo modo, esamineremo la creazione di un framework che deve supportare l'integrazione con un insieme di motori di rendering popolari e includere componenti che forniscono strumenti per organizzare una rete di nodi eterogenei e gestire il flusso di attività.
Il modello economico per l'esistenza di una tale rete non ha un'importanza fondamentale, quindi consideriamo il modello simile a quello utilizzato nelle operazioni delle reti di criptovaluta: i consumatori delle risorse invieranno token ai fornitori che eseguono il lavoro di rendering. È molto più interessante capire quali proprietà dovrebbe avere il framework, pertanto esamineremo lo scenario principale di interazione tra i partecipanti alla rete.
Nella rete ci sono tre parti coinvolte: il fornitore di risorse, il fornitore di compiti e l'operatore di rete (che è anche il centro di controllo, la rete, ecc. nel testo).
L'operatore di rete fornisce al fornitore delle risorse un'applicazione client o un'immagine del sistema operativo con un set completo di software, che verrà installato sulla macchina delle risorse che intende fornire, e un pannello di controllo accessibile tramite web che consente di impostare le autorizzazioni di accesso alle risorse e di gestire da remoto il proprio panorama server: controllare i parametri hardware, eseguire configurazioni da remoto, riavviare.
Il sistema di gestione della rete, al momento della connessione di un nuovo nodo, esegue un'analisi dell'hardware e delle impostazioni di accesso configurate, classificandolo e assegnandogli un punteggio, e lo registra nel registro delle risorse. In seguito, per scopi di gestione del rischio, le attività del nodo saranno analizzate e il punteggio del nodo sarà aggiornato per garantire la stabilità del funzionamento della rete. A nessuno fa piacere se la propria scena venga inviata a renderizzare su potenti schede grafiche, ma spesso soggette a surriscaldamento.
L'utente che deve renderizzare una scena può seguire due strade: caricare la scena nel repository della rete tramite interfaccia web o collegare il proprio pacchetto di modellazione o il renderer installato alla rete utilizzando un plugin. In questo caso, viene avviato un contratto intelligente tra l'utente e la rete, il cui requisito di completamento standard è la generazione del risultato del calcolo della scena da parte della rete. L'utente può monitorare il processo di esecuzione del compito e gestirne i parametri tramite l'interfaccia web del proprio pannello di controllo.
Il compito viene inviato a un server, dove viene analizzato il volume della scena e il numero di risorse richieste dall'innovatore del compito, dopo di che viene eseguita una decomposizione del volume totale in parti adattate per il calcolo su una quantità e un tipo di risorse designati dalla rete. L'idea generale è che la visualizzazione possa essere suddivisa in molte piccole attività. I motori sfruttano questo vantaggio distribuendo queste attività tra vari fornitori di risorse. Il modo più semplice è il rendering di piccole parti della scena, chiamate segmenti. Quando ogni segmento è pronto, il compito locale è considerato completato e la risorsa passa all'esecuzione del prossimo tra i non risolti.
Pertanto, per il renderizzatore non c'è alcuna differenza se i calcoli vengono eseguiti su una singola macchina o su una rete di molte stazioni di calcolo separate. Il rendering distribuito semplicemente aggiunge più core nel pool di risorse utilizzate per il compito. Attraverso la rete, riceve tutti i dati necessari per il rendering del segmento, lo calcola, restituisce il segmento e passa al compito successivo. Prima di entrare nel pool comune della rete, ogni segmento riceve un insieme di meta-informazioni che consente ai nodi di esecuzione di selezionare i compiti di calcolo più adatti per loro.
Le attività di segmentazione e distribuzione dei calcoli devono essere affrontate non solo dal punto di vista dell'ottimizzazione dei tempi di esecuzione, ma anche da quello dell'uso ottimale delle risorse e del risparmio energetico, poiché ciò influisce sull'efficienza economica della rete. In caso di decisioni sbagliate, potrebbe essere più conveniente installare un miner su un nodo o spegnerlo per evitare rumore e spese elettriche.
Tornando al processo, quando viene ricevuta una richiesta, viene anche creato un smart contract tra il pool e il nodo, che viene eseguito al momento del calcolo corretto del risultato della richiesta. Al termine dell'esecuzione del contratto, il nodo può ricevere una ricompensa in varie forme.
Il centro di gestione controlla il processo di esecuzione della richiesta, raccogliendo i risultati dei calcoli, reinviando per un ulteriore trattamento quelli errati e classificando la coda, monitorando il termine normativo per l'esecuzione della richiesta (per evitare che l'ultimo segmento non venga gestito da nessun nodo).
I risultati dei calcoli passano attraverso la fase di compositing, dopo di che l'utente riceve i risultati del rendering, mentre la rete può ricevere una ricompensa.
In questo modo si delinea la composizione funzionale del framework paesaggistico, destinato alla costruzione di sistemi di rendering distribuito:
- Pannelli utente con accesso web
- Pacchetto software da installare sui nodi
- Sistemi di gestione:
- Sottosistema di gestione degli accessi
- Sottosistema di decomposizione delle richieste di rendering
- Sottosistema di distribuzione delle richieste
- Sottosistema di compositing
- Sottosistema di gestione del panorama server e della topologia di rete
- Sottosistema di registrazione e audit
- Sottosistema esperto in apprendimento
- Rest API o altro interface per sviluppatori esterni
E voi, cosa ne pensate? Quali domande suscita l'argomento e quali risposte vi interessano?
Fonte: habr.com
