V posledních letech se novinové kanály zaplnily zprávami o novém typu distribuovaných výpočetních sítí, které se doslova objevují z ničeho a snaží se vyřešit nejrůznější úkoly – udělat město chytrým, zachránit svět před porušovateli autorských práv nebo naopak tajně přenést informace či zdroje a uniknout státní kontrole v dané oblasti. Ať už se jedná o jakoukoli oblast, všechny mají několik společných rysů, které vyplývají z toho, že jejich růst je poháněn algoritmy a metodikami, které se dostaly do širokých mas během nedávného boomu kryptoměn a souvisejících technologií. Snad každá třetí článek na odborných webech v té době obsahoval slovo „blockchain“ – diskuse o nových softwarových řešeních a ekonomických modelech se na chvíli staly dominujícím trendem, na jehož pozadí byly jiné oblasti využití systémů distribuovaných výpočtů posunuty do pozadí.
Současně vizionáři a profesionálové rozpoznali podstatu tohoto jevu: masové distribuované výpočty spojené s budováním sítí z velkého počtu rozptýlených a heterogenních účastníků dosáhly nové úrovně rozvoje. Stačí zapomenout na hype a podívat se na věc z jiného úhlu: všechny tyto sítě, složené z obrovských poolů, ve kterých je tisíce oddělených heterogenních účastníků, nevznikly samy od sebe. Nadšenci kryptohybového hnutí dokázali nově vyřešit složité problémy synchronizace dat a rozdělování zdrojů a úkolů, což umožnilo shromáždit takové množství vybavení a vytvořit nový ekosystém určený k řešení jedné úzce zaměřené úlohy.
Samozřejmě, že to neuniklo týmům a komunitám zaměřeným na rozvoj svobodných distribuovaných výpočtů, a nové projekty na sebe nenechaly dlouho čekat.
Nicméně, i přes výrazné zvýšení objemu dostupných informací o vývoji sítí a práci s vybavením, musí tvůrci perspektivních systémů čelit vážným problémům.
Prvním z nich, jakkoli to může znít podivně, je problém volby směru
Směr může být správný, může vést do slepé uličky - tomuto se nedá vyhnout, centralizované dodávky jasnovidců do IT komunity zatím zůstávají pozadu. Ale je třeba učinit volbu, aby se nepodlehlo tradiční pasti, v níž tým pokrývá příliš širokou oblast a od začátku se snaží vytvořit další nespecializovaný projekt distribuovaných výpočtů širokého profilu. Zdá se, že fronta práce není tak hrozná, většinou stačí aplikovat stávající poznatky: spojit uzly do sítě, přizpůsobit algoritmy pro určení topologií, výměny dat a kontroly jejich konzistence, zavést metody hodnocení uzlů a nalezení konsenzu, a samozřejmě, jen vytvořit svůj jazyk dotazů a celé jazykové a výpočetní prostředí. Myšlenka univerzálního mechanismu je velmi lákavá a neustále se objevuje v různých oblastech, ale výsledkem stále zůstává jedno ze tří: vytvořené řešení buď skutečně končí jako omezený prototyp s hromadou visících „ToDo“ v backlogu, nebo se stává nepoužitelným monstrem, které je připraveno potáhnout každého, kdo se ho dotkne, do smradlavého „turingovského bahna“, nebo prostě šťastně umírá na to, že projekt, táhnoucí nejasným směrem, se totálně zhroutil.
Neudělejme hloupé chyby a vyberme směr, který má jasný okruh úkolů a dobře vyhovuje modelu distribuovaných výpočtů. Lze pochopit lidi, kteří se snaží udělat všechno hned - volby jsou samozřejmě pestré. A mnohé vypadá vskutku zajímavě jak z pohledu R&D a vývoje, tak z pohledu ekonomiky. Díky distribuované síti lze:
- Školit neuronové sítě
- Zpracovávat signální toky
- Počítat strukturu bílkovin
- Provádět rendering trojrozměrných scén
- Modelovat hydrodynamiku
- Testovat obchodní strategie pro burzy
Abychom se nezapletli do sestavování seznamu zajímavých věcí, které se dobře paralelizují, vyberme si jako naše další téma distribuovaný rendering.
Distribuované renderování samo o sobě není samozřejmě žádnou novinkou. Existující renderovací nástroje již dlouho podporují rozložení zátěže mezi různými stroji, bez toho by v jednadvacátém století bylo docela smutné žít. Nicméně bychom si neměli myslet, že téma je probrané do detailu a není co dalšího řešit — zaměříme se na specifický aktuální problém: vytvoření nástroje pro formování renderovací sítě.
Naše renderovací síť je kombinací uzlů, které musí vykonávat úkoly renderování, a uzlů, které mají volné výpočetní zdroje pro zpracování renderování. Vlastníci zdrojů připojí své stanice k renderovací síti, aby mohli přijímat a vykonávat úkoly renderování s využitím jednoho z renderovacích enginů, které síť podporuje. Poskytovatelé úkolů budou při tom pracovat se sítí jako s cloudem, který sám provádí rozložení zdrojů, kontrolu správnosti vykonávání, řízení rizik a další problémy.
Budeme tedy zkoumat vytváření frameworku, který by měl podporovat integraci s sadou populárních renderovacích enginů a obsahovat komponenty poskytující nástroje pro organizaci sítě z heterogenních uzlů a řízení toku úkolů.
Ekonomický model existence takové sítě není principiálně důležitý, proto vezmeme za výchozí schéma podobné tomu, které se používá v výpočtech v kryptoměnových sítích — spotřebitelé zdrojů budou zasílat tokeny poskytovatelům, kteří vykonávají práci renderování. O mnoho zajímavější je pochopit, jakými vlastnostmi by měl framework disponovat, pro což se podíváme na hlavní scénář interakce účastníků sítě.
V síti existují tři strany interakce: poskytovatel zdrojů, poskytovatel úkolů a operátor sítě (tedy centrum řízení, síť atd. v textu).
Provozovatel sítě poskytuje dodavateli zdroje klientskou aplikaci nebo obraz operačního systému s nainstalovaným souborem softwaru, který ten nainstaluje na stroj, jehož zdroje chce poskytnout, a přístupné prostřednictvím webového rozhraní osobního účtu, které mu umožňuje nastavit parametry přístupu ke zdroji a vzdáleně spravovat svůj serverový landscape: sledovat parametry hardwaru, provádět vzdálené nastavení, restartovat.
Systém řízení sítě při připojení nového uzlu provádí analýzu vybavení a zadaných přístupových parametrů, řadí ho a přiděluje mu určitý rating a umísťuje do registru zdrojů. V budoucnu budou s cílem řízení rizika analyzovány parametry aktivity uzlu a rating uzlu bude upravován za účelem zajištění stability provozu sítě. Nikomu totiž nebude příjemné, když se jejich scéna pošle renderovat na výkonné, ale často přehřívající se grafické karty?
Uživatel, který potřebuje zrenderovat nějakou scénu, může jít dvěma cestami: nahrát scénu do repozitáře sítě prostřednictvím webového rozhraní nebo pomocí pluginu připojit svůj modelovací balíček nebo nainstalovaný renderovací systém k síti. Přitom mezi uživatelem a sítí se iniciuje chytrá smlouva, jejíž standardní podmínkou pro dokončení je generování výsledku výpočtu scény sítí. Uživatel může sledovat průběh plnění úkolu a spravovat jeho parametry prostřednictvím webového rozhraní svého osobního účtu.
Úkol přichází na server, kde se analyzuje objem scény a počet zdrojů požadovaných iniciátorem úkolu, po čemž se provádí dekompozice celkového objemu na části přizpůsobené pro výpočet na vyčleněném počtu a typu zdrojů sítě. Obecný koncept spočívá v tom, že vizualizace může být rozdělena na mnoho malých úloh. Renderovací enginy využívají této výhody, když rozdělují tyto úkoly mezi mnoha dodavateli zdrojů. Nejjednodušší způsob je renderování malých částí scény, nazývaných segmenty. Když je každý segment připraven, je místní úkol považován za splněný a zdroje přecházejí k provedení dalšího z dosud nevyřešených.
Pro renderér není v zásadě rozdíl, zda jsou výpočty prováděny na jednom stroji, nebo na gridu složeném z mnoha jednotlivých výpočetních stanic. Distribuovaný rendering jednoduše přidává více jader do fondu zdrojů používaných pro úkol. Skrze síť získává všechna data potřebná k renderování segmentu, počítá ho, odesílá tento segment zpět a přechází k dalšímu úkolu. Před vstupem do společného fondu sítě každý segment dostává sadu meta-informací, které umožňují uzlům-vykonavatelům vybírat pro ně nejvhodnější výpočetní úkoly.
Úkoly segmentace a distribuce výpočtů musí být řešeny nejen z pohledu optimalizace doby provedení, ale také z pohledu optimálního využívání zdrojů a úspory energie, vzhledem k tomu, že od toho závisí ekonomická efektivita sítě. V případě neúspěšného řešení by bylo účelnější umístit na uzel minér nebo jej vypnout, aby nehlučel a neztrácel elektřinu.
Nicméně se vraťme k procesu. Při získání úkolu mezi fondem a uzlem se také formuje smart kontrakt, který se provádí při správném výpočtu výsledku úkolu. Na základě vyhodnocení kontraktu může uzel získat odměnu v nějaké formě.
Centrum řízení kontroluje proces plnění úkolu, shromažďuje výsledky výpočtů, odesílá na opětovné zpracování nesprávné a třídí frontu, sleduje normativní dobu plnění úkolu (aby se nestalo, že poslední segment nebude zpracován žádným uzlem).
Výsledky výpočtů procházejí fází kompozice, po které uživatel obdrží výsledky renderování a síť může získat odměnu.
Tím se vytyčuje funkční složení krajinného frameworku určeného pro budování systémů distribuovaného renderování:
- Uživatelské osobní účty s webovým přístupem
- Sada software pro instalaci na uzly
- Podle systémů řízení:
- Podsystem řízení přístupu
- Podsystem dekompozice úkolů renderování
- Podsystem distribuce úkolů
- Podsystem kompozice
- Podsystem řízení serverového krajinného systému a topologie sítě
- Podsystem logování a auditu
- Učící se expertní podsystem
- Rest API nebo jiného rozhraní pro externí vývojáře
A co si o tom myslíte? Jaké otázky vyvstávají k tomuto tématu a jaké odpovědi vás zajímají?
Zdroj: habr.com
