近年來，新聞源充斥著關於新型分散式運算網路的消息，這種網路不知從何而來，解決（或更確切地說，試圖解決）各種各樣的問題——使城市變得智能，使世界免受版權侵害。侵權者或反之亦然，秘密轉移資訊或資源，逃離某一地區或另一地區的國家控制。 無論哪個領域，它們都具有許多共同特徵，因為它們增長的動力是在最近加密貨幣和相關技術繁榮期間向公眾公開的演算法和技術。 當時可能每三篇關於專業資源的文章標題中都會出現「區塊鏈」一詞——討論新的軟體解決方案和經濟模型成為一段時間的主導趨勢，在此背景下分散式運算系統的其他應用領域正在興起。退居幕後。
同時，有遠見的人和專業人士看到了這一現象的主要本質：與大量不同和異質參與者構建的網絡相關的大規模分散式計算已經達到了新的發展水平。 只要把你腦中的炒作話題丟掉，從另一個角度看這個話題就足夠了：所有這些網路都是由巨大的池子組裝而成的，這些池子由數千個孤立的異質參與者組成，它們並不是單獨出現的。 加密貨幣運動的愛好者能夠以一種新的方式解決數據同步以及資源和任務分配的複雜問題，這使得將類似數量的設備組合在一起並創建一個旨在解決一個狹隘問題的新生態系統成為可能。
當然，參與免費分散式運算開發的團隊和社群並沒有忽略這一點，新專案很快就會出現。
然而，儘管有關建立網路和使用設備領域的發展的可用資訊量顯著增加，但有前途的系統的創建者將不得不解決嚴重的問題。
第一個，無論聽起來多麼奇怪，都是選擇方向的問題。
方向可能是正確的，也可能會走向死胡同——這是無法逃脫的；向IT社區集中供應千里眼還為時已晚。 但必須做出選擇，以免陷入傳統的陷阱，即團隊範圍太廣，從一開始就試圖創建另一個非專業的通用分散式運算專案。 看起來工作範圍不那麼可怕，在大多數情況下，我們只需要應用現有的開發：將節點組合到網路中，調整用於確定拓撲的演算法，交換資料並監控其一致性，引入對節點進行排序和查找的方法共識，當然，只需創建您自己的查詢語言以及整個語言和計算環境。 通用機制的想法非常誘人，並且不斷在某個領域出現，但最終結果仍然是以下三件事之一：創建的解決方案要么是一個有限的原型，帶有一堆懸置的“待辦事項” 「在積壓的工作中，或者它變成了一個無法使用的怪物，準備把任何接觸惡臭的「圖靈沼澤」的人拖走，或者只是因為天鵝、小龍蝦和梭子魚將項目拉向一個難以理解的方向而安全地死去，簡直就是過度勞累自己。
我們不要重複愚蠢的錯誤，選擇一個任務範圍明確、非常適合分散式運算模型的方向。 你可以理解那些試圖同時做所有事情的人——當然，有很多選擇。 無論是從研發開發的角度，還是從經濟學的角度來看，很多事情看起來都非常有趣。 使用分散式網絡，您可以：
- 訓練神經網絡
- 處理訊號流
- 計算蛋白質結構
- 渲染 XNUMXD 場景
- 模擬流體動力學
- 測試證券交易所的交易策略
為了不沉迷於編譯一系列並行化良好的有趣事物，我們將選擇分散式渲染作為我們的進一步主題。
當然，分散式渲染本身並不是什麼新鮮事。 現有的渲染工具包長期以來一直支援跨不同機器的負載分配；如果沒有這個，生活在二十一世紀將是相當悲傷的。 然而，您不應該認為這個主題已經被廣泛覆蓋，並且沒有什麼可做的 - 我們將考慮一個單獨的緊迫問題：創建一個用於創建渲染網路的工具。
我們的渲染網路是需要執行渲染任務的節點與具有空閒運算資源來處理渲染的節點的組合。 資源擁有者將其工作站連接到渲染網絡，以使用網路支援的渲染引擎之一接收和執行渲染作業。 在這種情況下，任務提供者將像雲端一樣與網路合作，獨立分配資源、監控執行的正確性、管理風險等問題。
因此，我們將考慮創建一個框架，該框架應支援與一組流行渲染引擎的集成，並包含提供用於組織異質節點網路和管理任務流程的工具的元件。
這種網路存在的經濟模型並不重要，因此我們將採用類似於加密貨幣網路計算中使用的方案作為初始方案 - 資源的消費者將向執行渲染工作的供應商發送代幣。 理解框架應該具有哪些屬性更有趣，為此我們將考慮網路參與者之間互動的主要場景。
網路中存在互動的三個面向：資源提供者、任務提供者和網路運營商（文中又稱控制中心、網路等）。
網路營運商向資源提供者提供用戶端應用程式或具有已部署軟體集的作業系統映像，資源提供者將其安裝在他想要提供資源的電腦上，以及可透過Web 介面存取的個人帳戶，使他能夠設定資源的存取參數並遠端管理其伺服器環境：控制硬體參數、執行遠端配置、重新啟動。
當連接新節點時，網路管理系統會分析設備和指定的存取參數，對其進行排名，分配一定的等級，並將其放入資源暫存器中。 未來，為了管理風險，將分析節點的活動參數，調整節點的評級，以確保網路的穩定性。 如果他們的場景被發送到經常因過熱而凍結的強大卡上進行渲染，沒有人會感到高興？
需要渲染場景的使用者可以採用兩種方式：透過 Web 介面將場景上傳到網路儲存庫，或使用外掛程式將其建模套件或安裝的渲染器連接到網路。 在這種情況下，使用者和網路之間發起智慧合約，完成智慧合約的標準條件是網路生成場景計算結果。 使用者可以透過個人帳戶的網路介面監控任務的完成過程並管理其參數。
任務傳送到伺服器，伺服器分析場景的體積和任務發起者請求的資源數量，然後將總體積分解為適合計算網路分配的資源數量和類型的部分。 總體思路是可視化可以分解為許多小任務。 引擎透過在多個資源提供者之間分配這些任務來利用這一點。 最簡單的方法是渲染場景的小部分（稱為片段）。 當每個段準備就緒時，本地任務被視為已完成，並且資源將移至下一個未完成的任務。
因此，對於渲染器來說，無論計算是在單一機器上還是在許多單獨計算站的網格上執行，都沒有區別。 分散式渲染只是將更多核心添加到用於任務的資源池中。 透過網絡，它接收渲染片段所需的所有數據，對其進行計算，將該片段發回，然後繼續下一個任務。 在進入通用網路池之前，每個段都會接收一組元訊息，允許執行節點為它們選擇最合適的計算任務。
計算的分割和分佈問題不僅要從執行時間優化的角度來解決，還要從資源優化利用和節能的角度來解決，因為網路的經濟效益取決於此。 如果解決方案不成功，最好在節點上安裝一個礦機或將其關閉，這樣它就不會發出噪音，也不會浪費電力。
不過，讓我們回到這個過程。 當接收到任務時，礦池和節點之間也會形成智慧合約，當任務結果計算正確時執行。 根據履行合約的結果，節點可以以一種或另一種形式獲得獎勵。
控制中心控制任務執行的過程，收集計算結果，發送錯誤的重新處理併排序佇列，監控完成任務的標準期限（以免出現最後一段沒有被佔用的情況）任何節點）。
計算結果經過合成階段，之後使用者收到渲染結果，網路可以獲得獎勵。
因此，為建構分散式渲染系統而設計的景觀框架的功能組成就出現了：
- 具有網路存取權限的個人使用者帳戶
- 用於在節點上安裝的軟體包
- 按控制系統：
- 門禁子系統
- 渲染任務分解子系統
- 任務分配子系統
- 合成子系統
- 伺服器佈局和網路拓撲管理子系統
- 日誌記錄和稽核子系統
- 學習專家子系統
- Rest API 或其他供外部開發人員使用的介面
你怎麼認為？ 主題提出了哪些問題以及您對哪些答案感興趣？
來源： www.habr.com