Alkalmazott technológiák a blockchain láz romjain vagy a források elosztásának gyakorlati előnye

Az utóbbi években a hírekben számos olyan bejegyzés jelent meg, amelyek új típusú elosztott számítási hálózatokról szólnak, amelyek szó szerint a semmiből bukkannak fel, és amelyek különféle feladatok megoldására próbálnak megoldást találni — legyünk okos város, megvédjük a világot a szerzői jogok megsértésétől, vagy éppen ellenkezőleg, titkos információt vagy forrásokat továbbítsunk, hogy kiszabaduljunk az állam ellenőrzése alól egy vagy másik területen. A szektor fajtájától függetlenül mindegyik közös jellemzőkkel bír, mivel növekedésük üzemanyaga olyan algoritmusok és módszerek voltak, amelyeket a közelmúlt kriptovaluta- és kapcsolódó technológiáinak robbanása juttatott el széles tömegekhez. Valószínűleg minden harmadik szakmai cikk címében szerepelt a „blokklánc” szó — az új szoftvermegoldások és gazdasági modellek megvitatása egy időben a domináló trenddé vált, amely háttérbe szorította a elosztott számítási rendszerek egyéb alkalmazási területeit.

Ugyanakkor a látnokok és a szakemberek felfedezték a jelenség lényegét: a tömeges elosztott számítások, amelyek számos különböző résztvevőből álló hálózatok építésével járnak, új fejlődési szintre léptek. Elég, ha félretesszük a hype-témákat, és más szemszögből nézünk a dologra: mindezek a hatalmas medencékből összegyűjtött hálózatok, amelyekben ezer különálló, különböző résztvevő van, nem keletkeztek önmaguktól. A kripto-mozgalom lelkes hívei új megközelítéssel tudták megoldani az adatok szinkronizálásával és az erőforrások és feladatok elosztásával kapcsolatos összetett problémákat, ami lehetővé tette számukra, hogy ilyen tömeget összehozzanak és létrehozzanak egy új ökoszisztémát, amely egy szűken meghatározott feladat megoldására lett szánva.

Természetesen ez nem kerülhette el a szabad elosztott számítások fejlesztésével foglalkozó csapatok és közösségek figyelmét, és az új projektek megjelenése sem váratott magára.
Ugyanakkor, a hálózatok építésével és a berendezések kezelésével kapcsolatos információk mennyiségének komoly növekedése ellenére a jövőbeli rendszerek létrehozóinak komoly problémákkal kell szembenézniük.

Az első, bármennyire is furcsán hangzik, az irányválasztás problémája.

A方向可能是正确的，也可能导致死胡同——这一点无法避免，IT社区内集中化的占卜服务迟迟未能跟上。但我们还是要做出选择，以免陷入传统的陷阱，即团队涉及过于广泛的领域，并试图从一开始就创建另一个不特定的广泛计算项目。看似工作量并不那么可怕，主要只是应用现有的成果：将节点合并为网络，调整拓扑结构、数据交换和一致性控制的算法，实施节点评级和共识查找的方法，当然，仅仅创建自己的查询语言以及所有语言和计算环境。普遍机制的想法非常诱人，并且在某个领域不断浮现，但最终产生的结果无非是三种情况：创建的解决方案要么限于一个有限的原型，背负着大量待办事项，要么成为一个无法使用的怪物，随时可能将任何触碰到它的对象拖入可怕的“图灵泥潭”，也有可能只是因为引导项目走向不明方向的“天鹅、螃蟹和鲇鱼”共同作用而平淡无奇地死去。

让我们不要重复愚蠢的错误，选择一个任务范围清晰且非常适合分布式计算模型的方向。可以理解那些试图一口气做完所有事情的人——毕竟可供选择的东西实在太多了。而且，从R&D和开发的角度来看，许多看起来极其有趣。从分布式网络中，我们可以：

• 训练神经网络
• 处理信号流
• 计算蛋白质结构
• 渲染三维场景
• 模拟流体动力学
• 测试股票市场的交易策略

为了不陷入列出有趣的、适合并行处理的内容，我们选择分布式渲染作为我们进一步讨论的主题。

A elosztott renderelés önmagában természetesen nem új jelenség. A létező renderelő eszközök régóta támogatják a terhelés megosztását különböző gépek között, anélkül, hogy ez a huszonegyedik században elviselhető lenne. Azonban nem szabad azt gondolni, hogy a téma kimerült, és itt nincs semmi keresnivaló — egy konkrét aktuális problémát fogunk megvizsgálni: egy eszköz létrehozását a renderelő hálózat kialakításához.

A renderáló hálózatunk csomópontok összessége, amelyeknek renderelési feladatokat kell végrehajtaniuk, és olyan csomópontok, amelyek rendelkeznek szabad számítási erőforrásokkal a renderelés feldolgozásához. Az erőforrások tulajdonosai csatlakoztatják állomásaikat a renderáló hálózathoz, hogy kapjanak és végezzenek el renderelési feladatokat az egyik támogatott renderelő motor segítségével. A feladatküldők a hálózattal mint felhővel dolgoznak, amely önállóan végzi el az erőforrások elosztását, felügyeli a végrehajtás helyességét, kezeli a kockázatokat és egyéb problémákat.

Ezért a célunk egy olyan keretrendszer kialakítása, amely támogatja a népszerű renderelő motorokkal való integrációt, és magában foglalja azokat az összetevőket, amelyek eszközöket biztosítanak a sokféle csomópontból álló hálózat megszervezéséhez és a feladatok áramlásának kezeléséhez.

Egy ilyen hálózat gazdasági modelljének nincs alapvető jelentősége, így kiindulásként vesszük a kriptovaluta hálózatokban alkalmazott sémához hasonló modellt — az erőforrást fogyasztók tokeneket küldenek azokat ellátó szolgáltatóknak, akik elvégzik a renderelő munkát. Sokkal érdekesebb megérteni, hogy milyen tulajdonságokkal kell rendelkeznie a keretrendszernek, ezért megvizsgáljuk a hálózat résztvevői közötti fő interakciós forgatókönyvet.

A hálózatban három kölcsönhatás létezik: az erőforrás szolgáltató, a feladatszolgáltató és a hálózat operátora (ez utóbbi az irányító központ, a hálózat stb. a szövegben).

A hálózati üzemeltető a szolgáltató számára egy kliensalkalmazást vagy egy operációs rendszer képét biztosít, amely tartalmazza a szükséges szoftverek telepített halmazát, amelyet az a gépre telepít, amelynek erőforrásait kínálja, továbbá elérhető egy webes felületet biztosító személyes fiók, amely lehetővé teszi számára az erőforrásokhoz való hozzáférési paraméterek beállítását és a szerverlandscape távoli kezelését: hardver paraméterek ellenőrzése, távoli konfigurálás, újraindítás.

A hálózatirányító rendszer az új csomópont csatlakoztatásakor elemzi a hardvert és a megadott hozzáférési paramétereket, rangsorolva azokat, meghatározott értéket adva nekik, és a nyilvántartásba helyezve az erőforrásokat. A jövőbeli kockázatkezelés célja érdekében az aktív csomópont paramétereit elemezni fogják, és a csomópont értékét korrigálni fogják a hálózat stabil működésének biztosítása érdekében. Senkinek sem lenne kellemes, ha a színpadát olyan erős, de gyakran túlmelegedés miatt leálló kártyákra küldenék renderelésre?

A felhasználó, akinek szüksége van egy színpad renderelésére, két utat választhat: feltöltheti a színpadot a hálózat tárolójába a webes felületen keresztül, vagy egy plugin segítségével csatlakoztathatja a saját modellező csomagját vagy telepített renderelőjét a hálózathoz. Ezenfelül a felhasználó és a hálózat között egy intelligens szerződés jön létre, amelynek a színpad számítási eredményének generálása a standard befejezési feltétele. A felhasználó a feladat végrehajtásának folyamatát és paramétereit a személyes fiókjának webes felületén keresztül tudja nyomon követni és kezelni.

A feladat a(z) szerver, ahol a színpad méretének és a feladatszolgáltató által kért erőforrások mennyiségének elemzésére kerül sor, ezt követően a teljes kapacitás részfeladatokká történő dekomponálása történik, amelyek alkalmazkodtak a hálózat által biztosított erőforrások számához és típusához. Az alapötlet az, hogy a vizualizáció sok kis feladatra bontható. A motorok ezt a lehetőséget kihasználva elosztják ezeket a feladatokat az erőforrás-szolgáltatók között. A legegyszerűbb módszer a színpad kis részeinek renderelése, amelyeket szegmenseknek neveznek. Amikor minden szegmens kész, a helyi feladat befejezettnek tekinthető, az erőforrás átkerül a következő, megoldatlan feladat végrehajtására.

Így a renderelő számára nincs lényeges különbség, hogy a számítások egy gépen vagy egy sok különálló számítógépből álló rácson zajlanak. A megosztott renderelés egyszerűen több magot ad hozzá az adott feladathoz használt erőforrásokhoz. A hálózaton keresztül megkapja az összes szükséges adatot a szegmens rendereléséhez, kiszámítja azt, visszaküldi ezt a szegmenst, majd tovább lép a következő feladatra. Mielőtt a közös hálózati poolba kerülne, minden szegmens kap egy metaadat-készletet, amely lehetővé teszi a végrehajtó csomópontok számára, hogy kiválasszák a számukra legmegfelelőbb számítási feladatokat.

A szegmentálási és számításmegosztási feladatokat nemcsak a végrehajtási idő optimalizálása szempontjából kell megoldani, hanem az erőforrások optimális kihasználása és energiahatékonyság szempontjából is, mivel ez befolyásolja a hálózat gazdasági hatékonyságát. Sikertelen döntés esetén érdemesebb lehet a csomópontot bányászgépként üzemeltetni vagy kikapcsolni, hogy ne zajongjon és ne pazarolja az áramot.

Visszatérve a folyamathoz. A feladat átvételekor a pool és a csomópont között egy okos szerződés is létrejön, amely a feladat eredményének helyes kiszámításakor lép életbe. A szerződés teljesítése után a csomópont jutalomban részesülhet valamilyen formában.

A vezérlőközpont figyelemmel kíséri a feladat végrehajtási folyamatát, összegyűjti a számítási eredményeket, újrafeldolgozásra elküldi a hibásakat, és rangsorolja a sort, nyomon követve a feladat normál végrehajtási idejét (hogy elkerülje, hogy az utolsó szegmenst egyetlen csomópont sem vállalja).

A számítási eredmények átmennek egy kompozíciós fázison, ezután a felhasználó megkapja a renderelési eredményeket, míg a hálózat jutalomban részesülhet.

Így kirajzolódik a tájkeretrendszer funkcionális összetétele, amely a megosztott renderelési rendszerek felépítésére szolgál:

1. Felhasználói fiókok webes hozzáféréssel
2. Szoftvercsomag a csomópontokra történő telepítéshez
3. A rendszerek kezelése érdekében:
   • Hozzáférés-vezérlő alrendszer
   • A renderelési feladatok lebontási alrendszere
   • A feladatok elosztási alrendszere
   • A kompozíciós alrendszer
   • A szerver táj és hálózati topológia kezelő alrendszere
   • A naplózási és auditálási alrendszer
   • Önkereső szakértői alrendszer
   • Rest API vagy más interfész külső fejlesztők számára

Mit gondoltok erről? Milyen kérdéseket vet fel a téma, és milyen válaszok érdekelnek benneteket?

Forrás: habr.com