Az elmúlt években a hírfolyamokat elárasztották az üzenetek egy új típusú elosztott számítástechnikai hálózatokról, amelyek szó szerint a semmiből jelennek meg, és sokféle problémát megoldanak (vagy inkább megpróbálnak megoldani) - okossá tenni egy várost, megmenteni a világot a szerzői jogoktól. jogsértők, vagy fordítva, titokban információkat vagy erőforrásokat továbbítanak, egy-egy területen – állami ellenőrzés alól – kikerülve. Területtől függetlenül mindegyiknek számos közös vonása van annak köszönhetően, hogy növekedésük üzemanyagát azok az algoritmusok és technikák jelentették, amelyek a kriptovaluták és a kapcsolódó technológiák közelmúltbeli fellendülése során kerültek a nyilvánosság elé. Valószínűleg minden harmadik, speciális erőforrásokról szóló cikk címében szerepelt akkoriban a „blokklánc” szó – az új szoftvermegoldások, gazdasági modellek tárgyalása egy ideig uralkodó irányzattá vált, amelynek hátterében az elosztott számítástechnikai rendszerek más alkalmazási területei is megjelentek. háttérbe szorult.
Ugyanakkor a látnokok és a szakemberek látták a jelenség lényegét: a hatalmas elosztott számítástechnika, amely nagyszámú, egymástól eltérő és heterogén résztvevőből hálózatokat hoz létre, a fejlődés új szintjére lépett. Elég, ha kidobod a fejedből a hype-témákat, és a másik oldalról nézed a témát: mindezek a hatalmas medencékből összerakott hálózatok, amelyek több ezer elszigetelt heterogén résztvevőből állnak, nem jelentek meg maguktól. A kriptomozgalom kedvelői új módon tudták megoldani az adatok szinkronizálásának, valamint az erőforrások és feladatok elosztásának összetett problémáit, ami lehetővé tette egy hasonló tömegű berendezés összeállítását és egy új ökoszisztéma létrehozását, amely egyetlen szűk fókuszú probléma megoldására szolgál.
Természetesen ez nem múlt el az ingyenes elosztott számítástechnika fejlesztésében részt vevő csapatok és közösségek mellett, és az új projektek sem vártak sokáig.
A hálózatépítés és a berendezésekkel való munkavégzés terén elért fejlesztésekről rendelkezésre álló információk számának jelentős növekedése ellenére azonban az ígéretes rendszerek alkotóinak komoly problémákat kell megoldaniuk.
Az első közülük, bármennyire furcsán is hangzik, az irányválasztás problémája.
Lehet, hogy helyes az irány, vagy zsákutcába vezet - ez alól nincs menekvés, az informatikai közösség központosított tisztánlátó-ellátása még mindig késik. De a választást úgy kell meghozni, hogy ne essünk abba a hagyományos csapdába, hogy a csapat túlságosan széles területet vesz fel, és kezdettől fogva megpróbál egy másik, nem specializált általános elosztott számítástechnikai projektet létrehozni. Úgy tűnik, a munka terjedelme nem annyira ijesztő, többnyire csak a meglévő fejlesztéseket kell alkalmazni: csomópontokat hálózatba kell kötni, algoritmusokat adaptálni a topológiák meghatározásához, adatcserét és azok konzisztenciájának figyelését, bevezetni a csomópontok rangsorolásának és megtalálásának módszereit. konszenzusra, és természetesen csak saját lekérdezési nyelvet, valamint a teljes nyelvi és számítási környezetet hozza létre. Az univerzális mechanizmus ötlete nagyon csábító, és folyamatosan felbukkan egyik-másik területen, de a végeredmény mégis a három dolog egyike: a megalkotott megoldás vagy egy korlátozott prototípus lesz egy csomó felfüggesztett „ToDos”-val. ” a lemaradásban, vagy használhatatlan szörnyeteggé válik, aki készen áll arra, hogy elhurcoljon mindenkit, aki hozzáér a büdös „Turing-mocsárhoz”, vagy egyszerűen épségben elpusztul attól, hogy a projektet érthetetlen irányba húzó hattyú, rák és csuka, egyszerűen túlfeszítették magukat.
Ne ismételjük az ostoba hibákat, és válasszunk olyan irányt, amely világos feladatkörrel rendelkezik, és jól illeszkedik az elosztott számítási modellhez. Meg lehet érteni azokat, akik mindent egyszerre próbálnak megtenni – persze van miből válogatni. És sok minden rendkívül érdekesnek tűnik mind K+F és fejlesztés, mind gazdasági szempontból. Elosztott hálózat használatával:
- Neurális hálózatok képzése
- Jelfolyamok feldolgozása
- Számítsa ki a fehérje szerkezetét!
- XNUMXD jelenetek renderelése
- Szimulálja a hidrodinamikát
- Kereskedési stratégiák tesztelése a tőzsdéken
Annak érdekében, hogy ne ragadjunk bele a jól párhuzamosított érdekességek listájának összeállításába, további témánkként az elosztott renderelést választjuk.
Maga az elosztott renderelés természetesen nem újdonság. A meglévő renderelési eszközkészletek régóta támogatják a terheléselosztást a különböző gépek között; e nélkül elég szomorú lenne a huszonegyedik században élni. Nem szabad azonban azt hinni, hogy a témát már messzire lefuttatták, és nincs mit tenni – egy külön sürgető problémát fogunk figyelembe venni: egy renderelési hálózat létrehozására szolgáló eszköz létrehozását.
Megjelenítési hálózatunk olyan csomópontok kombinációja, amelyeknek renderelési feladatokat kell végrehajtaniuk olyan csomópontokkal, amelyek szabad számítástechnikai erőforrásokkal rendelkeznek a renderelés feldolgozásához. Az erőforrás-tulajdonosok csatlakoztatják állomásaikat a renderelési hálózathoz, hogy fogadják és hajtsák végre a renderelési feladatokat a hálózat egyik támogatott renderelő motorjával. Ebben az esetben a feladatszolgáltatók úgy dolgoznak a hálózattal, mintha az egy felhő lenne, önállóan osztják el az erőforrásokat, figyelik a végrehajtás helyességét, kezelik a kockázatokat és egyéb problémákat.
Ezért megfontoljuk egy olyan keretrendszer létrehozását, amelynek támogatnia kell a népszerű renderelő motorokkal való integrációt, és olyan komponenseket kell tartalmaznia, amelyek eszközöket biztosítanak a heterogén csomópontok hálózatának megszervezéséhez és a feladatok áramlásának kezeléséhez.
Egy ilyen hálózat létezésének gazdasági modellje nem alapvető jelentőségű, ezért kiindulási sémának egy, a kriptovaluta hálózatokban használt számításokhoz hasonló sémát veszünk – az erőforrás fogyasztói tokeneket küldenek a renderelési munkát végző beszállítóknak. Sokkal érdekesebb megérteni, hogy milyen tulajdonságokkal kell rendelkeznie egy keretrendszernek, amelyhez figyelembe vesszük a hálózati résztvevők közötti interakció fő forgatókönyvét.
A hálózatban az interakciónak három oldala van: erőforrás-szolgáltató, feladatszolgáltató és hálózatüzemeltető (a szövegben vezérlőközpont, hálózat stb.).
A hálózat üzemeltetője az erőforrás-szolgáltató rendelkezésére bocsát egy kliens alkalmazást vagy egy operációs rendszer képfájlt telepített szoftverkészlettel, amelyet az arra a gépre telepít, amelynek erőforrásait biztosítani kívánja, valamint egy webes felületen keresztül elérhető személyes fiókot, amely lehetővé teszi számára állítsa be a hozzáférési paramétereket az erőforráshoz, és távolról kezelje a szerver környezetét: vezérelje a hardverparamétereket, hajtsa végre a távoli konfigurációt, indítsa újra.
Új csomópont csatlakoztatásakor a hálózatkezelő rendszer elemzi a berendezést és a megadott hozzáférési paramétereket, rangsorolja azokat, egy bizonyos minősítést rendelve hozzá, és elhelyezi az erőforrás-nyilvántartásban. A jövőben a kockázat kezelése érdekében elemzik a csomópont aktivitási paramétereit, és a csomópont minősítését módosítják a hálózat stabilitásának biztosítása érdekében. Senki sem fog örülni, ha a jelenetét olyan erős kártyákra küldik, amelyek gyakran lefagynak a túlmelegedés miatt?
A jelenetet megjelenítő felhasználó kétféleképpen teheti meg: feltöltheti a jelenetet egy hálózati tárolóba a webes felületen keresztül, vagy egy beépülő modul segítségével csatlakoztathatja modellezőcsomagját vagy telepített renderelőjét a hálózathoz. Ebben az esetben a felhasználó és a hálózat között intelligens szerződés jön létre, amelynek teljesítésének alapfeltétele a jelenetszámítás eredményének a hálózat általi generálása. A felhasználó személyes fiókja webes felületén keresztül nyomon követheti egy feladat végrehajtásának folyamatát és kezelheti annak paramétereit.
A feladat elküldésre kerül a szerverre, ahol elemzik a jelenet mennyiségét és a feladat kezdeményezője által kért erőforrások számát, majd a teljes mennyiséget a hálózat által lefoglalt erőforrások számának és típusának kiszámításához adaptált részekre bontják. . Az általános elképzelés az, hogy a vizualizáció sok kis feladatra bontható. A motorok kihasználják ezt azáltal, hogy ezeket a feladatokat több erőforrás-szolgáltató között osztják el. A legegyszerűbb módja a jelenet kis részei, úgynevezett szegmensek renderelése. Amikor minden szegmens készen áll, a rendszer a helyi feladatot befejezettnek tekinti, és az erőforrás továbblép a következő kiemelkedő feladatra.
Így a megjelenítő számára nem mindegy, hogy a számításokat egyetlen gépen vagy több egyedi számítási állomásból álló rácson hajtják végre. Az elosztott renderelés egyszerűen több magot ad a feladathoz használt erőforráskészlethez. A hálózaton keresztül megkapja a szegmens rendereléséhez szükséges összes adatot, kiszámolja, visszaküldi a szegmenst, és továbblép a következő feladatra. Az általános hálózati készletbe való belépés előtt minden szegmens metainformáció-készletet kap, amely lehetővé teszi a végrehajtó csomópontok számára, hogy kiválaszthassák a számukra legmegfelelőbb számítási feladatokat.
A számítások szegmentálási és elosztási problémáit nemcsak a végrehajtási idő optimalizálása, hanem az optimális erőforrás-felhasználás és az energiatakarékosság szempontjából is meg kell oldani, hiszen ettől függ a hálózat gazdasági hatékonysága. . Ha nem sikerül a megoldás, akkor célszerűbb lenne bányászt telepíteni a csomópontra, vagy kikapcsolni, hogy ne adjon zajt és ne pazarolja az áramot.
Térjünk azonban vissza a folyamathoz. Feladat fogadásakor egy intelligens szerződés is létrejön a készlet és a csomópont között, amely a feladat eredményének helyes kiszámításakor kerül végrehajtásra. A szerződés teljesítésének eredménye alapján a csomópont ilyen vagy olyan formában jutalmat kaphat.
Az irányítóközpont felügyeli a feladatvégrehajtás folyamatát, a számítási eredmények összegyűjtését, a hibásak újrafeldolgozásra küldését és a sor rangsorolását, a feladat elvégzésének standard határidejének figyelését (hogy ne forduljon elő, hogy az utolsó szegmenst ne vegye fel bármely csomópont).
A számítások eredményei átmennek az összeállítási szakaszon, amely után a felhasználó megkapja a renderelési eredményeket, a hálózat pedig jutalmat kaphat.
Így kialakul az elosztott renderelő rendszerek építésére tervezett tájkeret funkcionális összetétele:
- Személyes felhasználói fiókok webes hozzáféréssel
- Szoftverkészlet csomópontokra való telepítéshez
- Vezérlőrendszer szerint:
- Beléptető alrendszer
- Renderelési feladat bontási alrendszer
- Feladatelosztási alrendszer
- Összetevő alrendszer
- Szerver tájkép és hálózati topológia menedzsment alrendszer
- Naplózási és auditálási alrendszer
- Tanulási szakértői alrendszer
- Rest API vagy más felület külső fejlesztők számára
Mit gondolsz? Milyen kérdéseket vet fel a téma, és milyen válaszok érdekelnek?
Forrás: will.com