W ostatnich latach kanały informacyjne zostały zalane wiadomościami o nowym typie rozproszonych sieci komputerowych pojawiających się dosłownie znikąd, rozwiązujących (a raczej próbujących rozwiązać) szeroką gamę problemów - czyniących miasto inteligentnymi, ratujących świat przed prawami autorskimi naruszających prawo lub odwrotnie, potajemnie przekazując informacje lub zasoby, uciekając spod kontroli państwa w tym czy innym obszarze. Niezależnie od dziedziny, wszystkie mają szereg cech wspólnych ze względu na fakt, że paliwem dla ich rozwoju były algorytmy i techniki, które ujrzały światło dzienne podczas niedawnego boomu na kryptowaluty i technologie z nimi związane. Prawdopodobnie co trzeci artykuł poświęcony zasobom specjalistycznym w tamtym czasie miał w tytule słowo „blockchain” – dyskusja o nowych rozwiązaniach programowych i modelach ekonomicznych stała się na jakiś czas dominującym trendem, na tle którego wyodrębniono inne obszary zastosowań rozproszonych systemów obliczeniowych zepchnięty na dalszy plan.
Jednocześnie wizjonerzy i profesjonaliści dostrzegli główną istotę zjawiska: masowe przetwarzanie rozproszone, związane z budową sieci z dużej liczby odrębnych i heterogenicznych uczestników, osiągnęło nowy poziom rozwoju. Wystarczy wyrzucić z głowy szumne tematy i spojrzeć na temat z drugiej strony: wszystkie te sieci, zebrane z ogromnych pul, które składają się z tysięcy izolowanych, heterogenicznych uczestników, nie pojawiły się same. Entuzjastom ruchu kryptograficznego udało się w nowy sposób rozwiązać złożone problemy synchronizacji danych oraz podziału zasobów i zadań, co umożliwiło zebranie podobnej masy sprzętu i stworzenie nowego ekosystemu zaprojektowanego do rozwiązania jednego wąsko ukierunkowanego problemu.
Oczywiście nie ominęło to zespołów i społeczności zaangażowanych w rozwój darmowego przetwarzania rozproszonego, a na nowe projekty nie trzeba było długo czekać.
Jednak pomimo znacznego wzrostu ilości dostępnych informacji o rozwoju w dziedzinie budowy sieci i pracy ze sprzętem, twórcy obiecujących systemów będą musieli rozwiązać poważne problemy.
Pierwszym z nich, jakkolwiek dziwnie by to nie zabrzmiało, jest problem wyboru kierunku.
Kierunek może być słuszny, ale może też prowadzić w ślepy zaułek – nie ma od tego ucieczki, scentralizowane dostawy jasnowidzów do społeczności IT wciąż spóźniają się. Trzeba jednak dokonać wyboru, aby nie wpaść w tradycyjną pułapkę, w której zespół zajmuje zbyt szeroki obszar i próbuje od początku stworzyć kolejny, niewyspecjalizowany, ogólny projekt obliczeń rozproszonych. Wydaje się, że zakres prac nie jest aż tak straszny, w większości wystarczy zastosować istniejące rozwiązania: połączyć węzły w sieć, dostosować algorytmy wyznaczania topologii, wymiany danych i monitorowania ich spójności, wprowadzić metody rankingu węzłów i znajdowania konsensus i oczywiście po prostu stwórz własny język zapytań oraz cały język i środowisko komputerowe. Pomysł na uniwersalny mechanizm jest bardzo kuszący i ciągle pojawia się w tym czy innym obszarze, ale efekt końcowy to wciąż jedna z trzech rzeczy: stworzone rozwiązanie albo okazuje się ograniczonym prototypem z mnóstwem zawieszonych „Zadań do wykonania” ” w zaległościach, albo staje się bezużytecznym potworem gotowym odciągnąć każdego, kto dotknie cuchnącego „bagna Turinga”, albo po prostu umiera bezpiecznie z powodu tego, że łabędź, raki i szczupaki, które ciągnęły projekt w niezrozumiałym kierunku, po prostu przeciążyli się.
Nie powtarzajmy głupich błędów i wybierajmy kierunek, który ma jasny zakres zadań i jest dobrze dostosowany do modelu obliczeń rozproszonych. Można zrozumieć ludzi, którzy starają się zrobić wszystko na raz – oczywiście jest w czym wybierać. A wiele rzeczy wygląda niezwykle interesująco zarówno z punktu widzenia B+R i rozwoju, jak i z punktu widzenia ekonomii. Korzystając z sieci rozproszonej, możesz:
- Trenuj sieci neuronowe
- Strumienie sygnałów procesowych
- Oblicz strukturę białka
- Renderuj sceny XNUMXD
- Symuluj hydrodynamikę
- Testuj strategie handlowe dla giełd
Aby nie dać się ponieść tworzeniu listy interesujących rzeczy, które są dobrze zrównoleglone, jako nasz dalszy temat wybierzemy renderowanie rozproszone.
Sam rendering rozproszony nie jest oczywiście niczym nowym. Istniejące zestawy narzędzi do renderowania od dawna obsługują rozkład obciążenia na różne maszyny; bez tego życie w XXI wieku byłoby dość smutne. Nie należy jednak myśleć, że temat został szeroko omówiony i nie ma w tym nic do zrobienia - rozważymy osobny palący problem: stworzenie narzędzia do tworzenia sieci renderującej.
Nasza sieć renderująca to połączenie węzłów, które muszą wykonywać zadania renderowania, z węzłami posiadającymi wolne zasoby obliczeniowe do przetwarzania renderowania. Właściciele zasobów podłączą swoje stacje do sieci renderującej, aby odbierać i wykonywać zadania renderowania przy użyciu jednego z obsługiwanych przez sieć silników renderujących. W takim przypadku dostawcy zadań będą współpracować z siecią jak z chmurą, samodzielnie dystrybuując zasoby, monitorując poprawność wykonania, zarządzając ryzykiem i innymi problemami.
Dlatego rozważymy stworzenie frameworka, który powinien wspierać integrację z zestawem popularnych silników renderujących i zawierać komponenty zapewniające narzędzia do organizowania sieci heterogenicznych węzłów i zarządzania przepływem zadań.
Model ekonomiczny istnienia takiej sieci nie ma zasadniczego znaczenia, dlatego jako początkowy schemat przyjmiemy schemat podobny do tego stosowanego w obliczeniach w sieciach kryptowalutowych - konsumenci zasobu będą wysyłać tokeny do dostawców wykonujących prace renderujące. O wiele bardziej interesujące jest zrozumienie, jakie właściwości powinien mieć framework, dla którego rozważymy główny scenariusz interakcji między uczestnikami sieci.
W sieci istnieją trzy strony interakcji: dostawca zasobów, dostawca zadań i operator sieci (w tekście zwany także centrum kontroli, siecią itp.).
Operator sieci udostępnia dostawcy zasobów aplikację kliencką lub obraz systemu operacyjnego z wdrożonym zestawem oprogramowania, które zainstaluje na maszynie, której zasoby chce udostępnić, oraz konto osobiste dostępne poprzez interfejs WWW, umożliwiające mu ustawiaj parametry dostępu do zasobu i zdalnie zarządzaj jego krajobrazem serwerowym: kontroluj parametry sprzętu, przeprowadzaj zdalną konfigurację, restartuj.
Po podłączeniu nowego węzła system zarządzania siecią analizuje sprzęt i określone parametry dostępu, klasyfikuje go, przydziela określoną ocenę i umieszcza w rejestrze zasobów. W przyszłości, w celu zarządzania ryzykiem, analizowane będą parametry pracy węzła i dostosowywana będzie ocena węzła w celu zapewnienia stabilności sieci. Nikt nie będzie zadowolony, jeśli jego scena zostanie wysłana do renderowania na wydajnych kartach, które często zawieszają się z powodu przegrzania?
Użytkownik chcący wyrenderować scenę może skorzystać z dwóch sposobów: przesłać scenę do repozytorium sieciowego za pośrednictwem interfejsu internetowego lub użyć wtyczki, aby podłączyć swój pakiet modelowania lub zainstalowany moduł renderujący do sieci. W tym przypadku inicjowany jest inteligentny kontrakt pomiędzy użytkownikiem a siecią, którego standardowym warunkiem zawarcia jest wygenerowanie przez sieć wyniku obliczenia sceny. Użytkownik może monitorować proces realizacji zadania i zarządzać jego parametrami poprzez interfejs WWW swojego konta osobistego.
Zadanie wysyłane jest na serwer, gdzie analizowana jest objętość sceny oraz ilość zasobów żądanych przez inicjatora zadania, po czym całkowity wolumen jest rozkładany na części przystosowane do obliczenia liczby i rodzaju zasobów przydzielonych przez sieć . Ogólna koncepcja jest taka, że wizualizację można podzielić na wiele małych zadań. Silniki wykorzystują to, rozdzielają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, zadanie lokalne uważa się za zakończone, a zasób przechodzi do następnego zaległego zadania.
Zatem dla renderera nie ma znaczenia, czy obliczenia wykonywane są na pojedynczej maszynie, czy na siatce wielu pojedynczych stacji obliczeniowych. Renderowanie rozproszone po prostu dodaje więcej rdzeni do puli zasobów wykorzystywanych do wykonania zadania. Za pośrednictwem sieci otrzymuje wszystkie dane potrzebne do wyrenderowania segmentu, oblicza je, odsyła segment i przechodzi do następnego zadania. Każdy segment przed wejściem do ogólnej puli sieci otrzymuje zestaw metainformacji, które pozwalają węzłom wykonawczym wybrać najodpowiedniejsze dla nich zadania obliczeniowe.
Problemy segmentacji i rozkładu obliczeń muszą być rozwiązywane nie tylko z punktu widzenia optymalizacji czasu wykonania, ale także z punktu widzenia optymalnego wykorzystania zasobów i oszczędności energii, ponieważ od tego zależy efektywność ekonomiczna sieci . Jeśli rozwiązanie się nie powiedzie, bardziej wskazane byłoby zainstalowanie górnika na węźle lub wyłączenie go, aby nie hałasował i nie marnował prądu.
Wróćmy jednak do procesu. Po otrzymaniu zadania pomiędzy pulą a węzłem tworzony jest również inteligentny kontrakt, który jest wykonywany, gdy wynik zadania zostanie poprawnie obliczony. Na podstawie wyników realizacji kontraktu węzeł może otrzymać nagrodę w takiej czy innej formie.
Centrum kontroli kontroluje proces realizacji zadania, zbierając wyniki obliczeń, przesyłając nieprawidłowe do ponownego przetworzenia i ustalając ranking kolejki, monitorując standardowy termin wykonania zadania (aby nie zdarzyło się, że ostatni segment nie zostanie zajęty przez dowolny węzeł).
Wyniki obliczeń przechodzą przez etap kompozycji, po którym użytkownik otrzymuje wyniki renderowania, a sieć może otrzymać nagrodę.
W ten sposób wyłania się funkcjonalna kompozycja struktury krajobrazu przeznaczonej do budowania rozproszonych systemów renderowania:
- Osobiste konta użytkowników z dostępem do Internetu
- Zestaw oprogramowania do instalacji na węzłach
- Według systemu sterowania:
- Podsystem kontroli dostępu
- Podsystem rozkładu zadań renderowania
- Podsystem podziału zadań
- Podsystem komponowania
- Podsystem zarządzania krajobrazem serwerów i topologią sieci
- Podsystem logowania i audytu
- Podsystem ekspercki uczenia się
- Rest API lub inny interfejs dla zewnętrznych programistów
Co myślisz? Jakie pytania rodzi ten temat i jakie odpowiedzi Cię interesują?
Źródło: www.habr.com