W ostatnich latach kanały informacyjne zostały zalane wiadomościami o nowym typie rozproszonych systemów obliczeniowych, które wydają się pojawiać dosłownie znikąd, próbując rozwiązać różnorodne zadania — uczynić miasta mądrymi, uratować świat przed naruszycielami praw autorskich lub wręcz przeciwnie, potajemnie przekazać informacje czy zasoby, wydostać się spod kontroli państwa w różnych dziedzinach. Bez względu na obszar, wszystkie te systemy mają ze sobą pewne wspólne cechy, co wynika z tego, że ich paliwem rozwoju były algorytmy i techniki, które wyszły na masowy rynek podczas niedawnego boomu kryptowalut oraz związanych z nimi technologii. Prawdopodobnie co trzecia artykuł na profilowych portalach w tamtym czasie w tytule miała słowo „blockchain” — dyskusja na temat nowych rozwiązań programowych i modeli ekonomicznych przez pewien czas stała się dominującym trendem, na tle którego inne obszary zastosowania systemów rozproszonych obliczeń zostały przesunięte na dalszy plan.
Jednocześnie wizjonerzy i profesjonaliści dostrzegli istotę tego zjawiska: masowe obliczenia rozproszone związane z budowaniem sieci z dużą liczbą rozproszonych i różnorodnych uczestników osiągnęły nowy poziom rozwoju. Wystarczy odrzucić chwytliwe tematy i spojrzeć na sprawę z innej perspektywy: wszystkie te sieci, zbudowane z ogromnych pul, w których znajdują się tysiące osamotnionych, zróżnicowanych uczestników, nie pojawiły się same z siebie. Entuzjaści ruchu kryptowalutowego potrafili w nowy sposób rozwiązać skomplikowane problemy synchronizacji danych oraz dystrybucji zasobów i zadań, co umożliwiło połączenie takiej masy sprzętu i stworzenie nowej ekosystemy, zaprojektowanej do rozwiązywania jednego węższozasięgowego zadania.
Oczywiście, to nie umknęło zespołom i społecznościom zajmującym się rozwojem wolnych obliczeń rozproszonych, a nowe projekty szybko się pojawiły.
Jednak mimo znaczącego zwiększenia dostępnych informacji na temat osiągnięć w budowie sieci i pracy ze sprzętem, twórcy obiecujących systemów będą musieli zmierzyć się z poważnymi problemami.
Pierwszym z nich, jakkolwiek dziwnie to brzmi, jest problem wyboru kierunku.
Kierunek może być właściwy, ale może też prowadzić do ślepego zaułka — nie da się tego uniknąć, zcentralizowane dostawy wróżbitów do społeczności IT jak na razie się spóźniają. Jednak trzeba dokonać wyboru, aby nie wpaść w tradycyjną pułapkę, polegającą na tym, że zespół podejmuje zbyt szeroki zakres działań i od początku próbuje stworzyć kolejny niespecjalizowany projekt rozproszonych obliczeń ogólnego profilu. Wydaje się, że front prac nie jest taki straszny, trzeba głównie zastosować istniejące rozwiązania: połączyć węzły w sieć, dostosować algorytmy określania topologii, wymiany danych i kontroli ich spójności, wdrożyć metody rankingu węzłów i znalezienia konsensusu, no i oczywiście stworzyć własny język zapytań oraz całe środowisko językowe i obliczeniowe. Idea uniwersalnego mechanizmu jest bardzo kusząca i ciągle pojawia się w różnych dziedzinach, ale rezultatem wciąż jest jedno z trzech: stworzone rozwiązanie okazuje się na dobrą sprawę ograniczonym prototypem z masą wiszących „ToDo” w backlogu, staje się niezdatnym do użytku potworem, gotowym pochłonąć każdego, kto się z nim zetknie w zgubne „turingowe bagno”, albo po prostu umiera z powodu tego, że ciągnące w nieznanym kierunku projektu żółw, rak i szczupak po prostu się wyczerpały.
Nie popełniajmy głupich błędów i wybierzmy kierunek z jasnym zakresem zadań, dobrze odpowiadający modelowi rozproszonych obliczeń. Można zrozumieć ludzi, którzy próbują zrobić wszystko naraz — oczywiście jest z czego wybierać. I wiele wydaje się niezwykle interesujące zarówno z punktu widzenia R&D, jak i z perspektywy ekonomicznej. Przy pomocy rozproszonej sieci można:
- Szkolenie sieci neuronowych
- Przetwarzanie strumieni sygnałów
- Obliczanie struktury białek
- Renderowanie scen trójwymiarowych
- Modelowanie hydrodynamiki
- Testowanie strategii handlowych dla giełd
Aby nie angażować się w sporządzanie listy interesujących rzeczy, które dobrze się paralelizują, wybierzmy jako nasz dalszy temat rozproszony rendering.
Rozproszona renderowanie sama w sobie to zjawisko, które oczywiście nie jest nowe. Istniejące narzędzia renderujące od dawna wspierają rozdzielanie obciążenia między różnymi maszynami; bez tego życie w XXI wieku byłoby dość smutne. Jednak nie należy myśleć, że temat jest wyeksploatowany i nie ma w nim nic do odkrycia — rozważymy konkretny aktualny problem: stworzenie narzędzia do budowy sieci renderującej.
Nasza sieć renderowania to zbiór węzłów, które muszą realizować zadania renderowania, z węzłami, które mają wolne zasoby obliczeniowe do przetwarzania renderowania. Właściciele zasobów podłączają swoje stacje do sieci renderującej, aby otrzymywać i wykonywać zadania renderowania za pomocą jednego z obsługiwanych przez sieć silników renderujących. Zleceniodawcy zadań będą pracować z siecią jak z chmurą, która samodzielnie wykonuje rozdzielanie zasobów, kontrolę poprawności wykonania, zarządzanie ryzykiem i innymi problemami.
W związku z tym rozważymy stworzenie frameworka, który powinien wspierać integrację z zestawem popularnych silników renderujących oraz zawierać komponenty dostarczające narzędzia do organizacji sieci różnorodnych węzłów i zarządzania przepływem zadań.
Model ekonomiczny istnienia takiej sieci nie ma zasadniczego znaczenia, zatem weźmiemy za bazę schemat podobny do stosowanego w obliczeniach w sieciach kryptowalutowych — konsumenci zasobów będą wysyłać tokeny dostawcom realizującym zadania renderowania. O wiele ciekawsze jest zrozumienie, jakie cechy powinien posiadać framework, dlatego rozważymy główny scenariusz interakcji uczestników sieci.
W sieci istnieją trzy strony interakcji: dostawca zasobów, dostawca zadań oraz operator sieci (zwany również centrum zarządzania, siecią itd. w tekście).
Operator sieci dostarcza dostawcy zasobów aplikację-klienta lub obraz systemu operacyjnego z pełnym zestawem oprogramowania, które ten zainstaluje na maszynie, której zasoby chce udostępnić, oraz dostępny przez interfejs internetowy panel osobisty, umożliwiający mu określenie parametrów dostępu do zasobu i zdalne zarządzanie swoim serwerowym krajobrazem: kontrolowanie parametrów sprzętowych, wykonywanie zdalnych ustawień, ponowne uruchamianie.
System zarządzania siecią przy podłączaniu nowego węzła przeprowadza analizę sprzętu i zadanych parametrów dostępu, klasyfikuje go, przypisując określoną ocenę, i umieszcza w rejestrze zasobów. W dalszej perspektywie, w celu zarządzania ryzykiem, parametry aktywności węzła będą analizowane, a jego ocena będzie korygowana w celu zapewnienia stabilności działania sieci. Nikt nie lubi, gdy ich scena jest wysyłana do renderowania na mocne, ale często zawieszające się z powodu przegrzania karty graficzne?
Użytkownik, który musi odrenderować jakąkolwiek scenę, może postąpić na dwa sposoby: załadować scenę do repozytorium sieci przez interfejs internetowy lub za pomocą wtyczki podłączyć swoje oprogramowanie do modelowania lub zainstalowany renderer do sieci. Przy tym między użytkownikiem a siecią inicjowany jest smart kontrakt, którego standardowym warunkiem zakończenia jest wygenerowanie przez sieć wyniku obliczeń sceny. Użytkownik może śledzić postęp wykonywania zadania i zarządzać jego parametrami za pośrednictwem interfejsu internetowego swojego panelu osobistego.
Zadanie trafia na serwer, gdzie analizowana jest objętość sceny i ilość żądanych przez inicjatora zadania zasobów, po czym wykonuje się dekompozycję całkowitej objętości na części, dostosowane do obliczeń na wydzielonej przez sieć liczbie i typie zasobów. Główna idea polega na tym, że wizualizacja może być podzielona na wiele małych zadań. Silniki wykorzystują tę przewagę, dzieląc te zadania pomiędzy wielu dostawców zasobów. Najprostszym sposobem jest renderowanie małych części sceny, zwanych segmentami. Kiedy każdy segment jest gotowy, lokalne zadanie uznawane jest za wykonane, a zasób przechodzi do realizacji następnego z nierozwiązanych.
Dla renderera nie ma zatem różnicy, czy obliczenia są wykonywane na jednej maszynie, czy na siatce składającej się z wielu oddzielnych stacji obliczeniowych. Rozproszony rendering po prostu dodaje więcej rdzeni do puli zasobów używanych do zadania. Przez sieć uzyskuje wszystkie dane potrzebne do renderowania segmentu, oblicza go, wysyła ten segment z powrotem i przechodzi do następnego zadania. Przed dostarczeniem do wspólnej puli sieci każdy segment otrzymuje zestaw metainformacji, umożliwiających węzłom wykonawczym wybór najbardziej odpowiednich zadań obliczeniowych.
Zadania segmentacji i rozdzielania obliczeń muszą być rozwiązywane nie tylko z punktu widzenia optymalizacji czasu wykonywania, ale także z perspektywy optymalnego wykorzystania zasobów i oszczędzania energii, ponieważ od tego zależy ekonomiczna efektywność sieci. W przypadku nieudanej decyzji, lepiej jest zainstalować na węźle koparkę lub go wyłączyć, aby nie hałasował i nie marnował energii elektrycznej.
Jednak wróćmy do procesu. Po otrzymaniu zadania między pulą a węzłem także tworzony jest smart kontrakt, który wykonywany jest przy poprawnym obliczeniu wyniku zadania. Po wykonaniu kontraktu węzeł może otrzymać nagrodę w różnej formie.
Centrum zarządzania kontroluje proces wykonywania zadania, zbierając wyniki obliczeń, wysyłając do ponownego przetworzenia dane niepoprawne i szeregając kolejkę, monitorując normatywny czas realizacji zadania (aby nie zdarzyło się, że ostatni segment nie jest podejmowany przez żaden węzeł).
Wyniki obliczeń przechodzą etap kompozycji, po czym użytkownik otrzymuje wyniki renderowania, a sieć może uzyskać nagrodę.
W ten sposób wyłania się funkcjonalny skład ramy krajobrazowej, przeznaczonej do budowy systemów rozproszonego renderowania:
- Osobiste konta użytkowników z dostępem przez internet
- Zestaw oprogramowania do instalacji na węzłach
- W systemach zarządzania:
- Podsystem zarządzania dostępem
- Podsystem dekompozycji zadań renderowania
- Podsystem rozdzielania zadań
- Podsystem kompozycji
- Podsystem zarządzania serwerowym krajobrazem i topologią sieci
- Podsystem logowania i audytu
- Uczący się ekspercki podsystem
- Interfejs API lub inny interfejs dla zewnętrznych deweloperów
A co wy myślicie? Jakie pytania rodzi ten temat i jakie odpowiedzi są dla was interesujące?
Źródło: habr.com
