Negli ultimi anni, i feed di notizie sono stati inondati di messaggi su un nuovo tipo di reti informatiche distribuite apparse letteralmente dal nulla, risolvendo (o meglio, cercando di risolvere) un'ampia varietà di problemi: rendere una città intelligente, salvare il mondo dal diritto d'autore trasgressori o viceversa, trasferendo segretamente informazioni o risorse, sfuggendo al controllo statale in un'area o nell'altra. Indipendentemente dal campo, hanno tutti una serie di caratteristiche comuni dovute al fatto che il carburante per la loro crescita sono stati gli algoritmi e le tecniche resi noti al pubblico durante il recente boom delle criptovalute e delle tecnologie correlate. Probabilmente un articolo su tre sulle risorse specializzate a quel tempo aveva la parola "blockchain" nel titolo - la discussione su nuove soluzioni software e modelli economici divenne per qualche tempo la tendenza dominante, sullo sfondo della quale furono altri campi di applicazione dei sistemi informatici distribuiti relegato in secondo piano.
Allo stesso tempo, visionari e professionisti hanno visto l'essenza principale del fenomeno: il calcolo distribuito di massa, associato alla costruzione di reti da un gran numero di partecipanti disparati ed eterogenei, ha raggiunto un nuovo livello di sviluppo. Basta buttare via dalla testa gli argomenti hype e guardare l'argomento dall'altra parte: tutte queste reti, assemblate da enormi pool, costituiti da migliaia di partecipanti eterogenei isolati, non sono apparse da sole. Gli appassionati del movimento crittografico sono stati in grado di risolvere problemi complessi di sincronizzazione dei dati e distribuzione di risorse e compiti in un modo nuovo, che ha permesso di mettere insieme una massa simile di attrezzature e creare un nuovo ecosistema progettato per risolvere un problema ristretto.
Naturalmente, questo non è passato ai team e alle comunità coinvolte nello sviluppo del calcolo distribuito gratuito, e i nuovi progetti non si sono fatti attendere.
Tuttavia, nonostante il significativo aumento del volume delle informazioni disponibili sugli sviluppi nel campo della costruzione di reti e del lavoro con le apparecchiature, i creatori di sistemi promettenti dovranno risolvere seri problemi.
Il primo di questi, per quanto strano possa sembrare, è il problema della scelta della direzione.
La direzione può essere giusta, oppure può portare a un vicolo cieco, a questo non c'è via d'uscita; l'approvvigionamento centralizzato di chiaroveggenti alla comunità informatica è ancora in ritardo. Ma la scelta deve essere fatta in modo da non cadere nella tradizionale trappola in cui il team si prende un'area troppo ampia e cerca di creare fin dall'inizio un altro progetto di calcolo distribuito generale e non specializzato. Sembra che lo scopo del lavoro non sia così spaventoso, per la maggior parte dobbiamo solo applicare gli sviluppi esistenti: combinare i nodi in una rete, adattare algoritmi per determinare le topologie, scambiare dati e monitorarne la coerenza, introdurre metodi per classificare i nodi e trovare consenso e, ovviamente, crea semplicemente il tuo linguaggio di query e l'intero linguaggio e ambiente informatico. L'idea di un meccanismo universale è molto allettante e spunta costantemente in un'area o nell'altra, ma il risultato finale è ancora una delle tre cose: la soluzione creata risulta essere un prototipo limitato con un mucchio di "Cose da fare" sospese " nell'arretrato, o diventa un mostro inutilizzabile pronto a trascinare via chiunque tocchi la fetida "palude di Turing", o semplicemente muore sano e salvo per il fatto che il cigno, il gambero e il luccio, che stavano trascinando il progetto in una direzione incomprensibile, semplicemente si sono sforzati troppo.
Non ripetiamo errori stupidi e scegliamo una direzione che abbia una gamma chiara di compiti e che si adatti bene al modello di calcolo distribuito. Puoi capire le persone che cercano di fare tutto in una volta: ovviamente c'è molto da scegliere. E molte cose sembrano estremamente interessanti sia dal punto di vista della ricerca e sviluppo, sia dal punto di vista economico. Utilizzando una rete distribuita è possibile:
- Addestrare le reti neurali
- Flussi di segnali di processo
- Calcolare la struttura delle proteine
- Rendering di scene XNUMXD
- Simulare l'idrodinamica
- Testare le strategie di trading per le borse
Per non lasciarci trasportare dalla compilazione di un elenco di cose interessanti ben parallelizzate, sceglieremo il rendering distribuito come ulteriore argomento.
Il rendering distribuito in sé non è, ovviamente, una novità. I toolkit di rendering esistenti supportano da tempo la distribuzione del carico su diverse macchine; senza di ciò, vivere nel ventunesimo secolo sarebbe piuttosto triste. Tuttavia, non dovresti pensare che l'argomento sia stato trattato in lungo e in largo e non ci sia nulla da fare lì: considereremo un problema urgente separato: creare uno strumento per creare una rete di rendering.
La nostra rete di rendering è una combinazione di nodi che devono eseguire attività di rendering con nodi che dispongono di risorse informatiche gratuite per elaborare il rendering. I proprietari delle risorse collegheranno le loro stazioni alla rete di rendering per ricevere ed eseguire lavori di rendering utilizzando uno dei motori di rendering supportati dalla rete. In questo caso, i fornitori di attività lavoreranno con la rete come un cloud, distribuendo in modo indipendente le risorse, monitorando la correttezza dell'esecuzione, la gestione del rischio e altri problemi.
Pertanto, prenderemo in considerazione la creazione di un framework che dovrebbe supportare l'integrazione con una serie di motori di rendering popolari e contenere componenti che forniscano strumenti per organizzare una rete di nodi eterogenei e gestire il flusso delle attività.
Il modello economico dell'esistenza di una tale rete non è di fondamentale importanza, quindi prenderemo come schema iniziale uno schema simile a quello utilizzato nei calcoli nelle reti di criptovaluta: i consumatori della risorsa invieranno token ai fornitori che eseguono il lavoro di rendering. È molto più interessante capire quali proprietà dovrebbe avere un framework, per il quale considereremo lo scenario principale di interazione tra i partecipanti alla rete.
Ci sono tre lati di interazione nella rete: fornitore di risorse, fornitore di attività e operatore di rete (noto anche come centro di controllo, rete, ecc. nel testo).
L'operatore di rete fornisce al fornitore di risorse un'applicazione client o un'immagine del sistema operativo con un insieme di software distribuito, che installerà sulla macchina di cui desidera fornire le risorse, e un account personale accessibile tramite l'interfaccia web, che gli consente di impostare i parametri di accesso alla risorsa e gestire da remoto il suo panorama server: controllare i parametri hardware, eseguire la configurazione remota, riavviare.
Quando un nuovo nodo viene connesso, il sistema di gestione della rete analizza l'apparecchiatura e i parametri di accesso specificati, lo classifica, assegnando un determinato punteggio e lo inserisce nel registro delle risorse. In futuro, per gestire il rischio, verranno analizzati i parametri di attività del nodo e la valutazione del nodo verrà adeguata per garantire la stabilità della rete. Nessuno sarà contento se la propria scena viene inviata a renderizzare su schede potenti che spesso si bloccano a causa del surriscaldamento?
Un utente che deve eseguire il rendering di una scena può procedere in due modi: caricare la scena su un repository di rete tramite l'interfaccia web o utilizzare un plug-in per connettere il proprio pacchetto di modellazione o il renderer installato alla rete. In questo caso viene avviato un contratto intelligente tra l'utente e la rete, la cui condizione standard per il completamento è la generazione del risultato del calcolo della scena da parte della rete. L'utente può monitorare il processo di completamento di un'attività e gestirne i parametri attraverso l'interfaccia web del proprio account personale.
L'attività viene inviata al server, dove vengono analizzati il volume della scena e il numero di risorse richieste dall'iniziatore dell'attività, dopodiché il volume totale viene scomposto in parti adatte per il calcolo in base al numero e al tipo di risorse allocate dalla rete . L'idea generale è che la visualizzazione può essere suddivisa in tanti piccoli compiti. I motori ne traggono vantaggio distribuendo queste attività tra più fornitori di risorse. Il modo più semplice è renderizzare piccole parti della scena chiamate segmenti. Quando ogni segmento è pronto, l'attività locale viene considerata completata e la risorsa passa all'attività successiva in sospeso.
Per il renderer non fa quindi alcuna differenza se i calcoli vengono eseguiti su una singola macchina o su una griglia di molte singole stazioni di calcolo. Il rendering distribuito aggiunge semplicemente più core al pool di risorse utilizzate per un'attività. Attraverso la rete, riceve tutti i dati necessari per eseguire il rendering di un segmento, lo calcola, rimanda indietro il segmento e passa all'attività successiva. Prima di entrare nel pool generale della rete, ogni segmento riceve una serie di metainformazioni che consentono ai nodi di esecuzione di selezionare le attività di calcolo più adatte a loro.
I problemi di segmentazione e distribuzione dei calcoli devono essere risolti non solo dal punto di vista dell'ottimizzazione dei tempi di esecuzione, ma anche dal punto di vista dell'uso ottimale delle risorse e del risparmio energetico, poiché da questo dipende l'efficienza economica della rete . Se la soluzione non dovesse avere successo, sarebbe più opportuno installare un miner sul nodo oppure spegnerlo in modo che non faccia rumore e non sprechi energia elettrica.
Tuttavia, torniamo al processo. Quando viene ricevuta un'attività, viene formato anche uno smart contract tra il pool e il nodo, che viene eseguito quando il risultato dell'attività viene calcolato correttamente. In base ai risultati dell'adempimento del contratto, il nodo può ricevere una ricompensa in una forma o nell'altra.
Il centro di controllo controlla il processo di esecuzione dell'attività, raccogliendo i risultati dei calcoli, inviando quelli errati per la rielaborazione e classificando la coda, monitorando la scadenza standard per il completamento dell'attività (in modo che non accada che l'ultimo segmento non venga occupato da qualsiasi nodo).
I risultati dei calcoli passano attraverso la fase di composizione, dopodiché l'utente riceve i risultati del rendering e la rete può ricevere una ricompensa.
Emerge così la composizione funzionale di un quadro paesaggistico progettato per la costruzione di sistemi di rendering distribuito:
- Account utente personali con accesso web
- Kit software per installazione su nodi
- Per sistema di controllo:
- Sottosistema di controllo degli accessi
- Sottosistema di decomposizione dell'attività di rendering
- Sottosistema di distribuzione dei compiti
- Sottosistema di composizione
- Sottosistema di gestione del panorama dei server e della topologia di rete
- Sottosistema di registrazione e controllo
- Sottosistema esperto di apprendimento
- Rest API o altra interfaccia per sviluppatori esterni
Cosa ne pensi? Quali domande solleva l’argomento e quali risposte ti interessano?
Fonte: habr.com