Pozdrowienia dla społeczności Habr! Niedawno pisałem o naszej pierwszej wersji tablicy klastrowej []. A dzisiaj chcę Wam opowiedzieć, jak pracowaliśmy nad wersją pamięć o dostępie swobodnym.
Lubimy mini serwery, które można wykorzystać zarówno do lokalnego rozwoju, jak i lokalnego hostingu. W przeciwieństwie do komputerów stacjonarnych czy laptopów, nasze serwery są przystosowane do pracy 24/7, można je szybko sfederować, np. w klastrze były 4 procesory, a po 5 minutach było 16 procesorów (bez dodatkowego sprzętu sieciowego) i to wszystko w kompaktowej obudowie cichy i energooszczędny.
Architektura naszych serwerów oparta jest na zasadzie budowy klastrów, tj. wykonujemy tablice klastrowe, które wykorzystując sieć ethernet na płycie łączą kilka modułów obliczeniowych (procesorów). Upraszczając, nie tworzymy jeszcze własnych modułów obliczeniowych, ale korzystamy z modułów obliczeniowych Raspberry Pi i naprawdę mieliśmy nadzieję na nowy moduł CM4. Ale wszystko poszło wbrew planom z ich nową obudową i myślę, że wielu jest rozczarowanych.
Poniżej o tym, jak przeszliśmy z wersji 1 do wersji 2 i jak musieliśmy wyjść z nowym formatem Raspberry Pi CM4.
Tak więc po utworzeniu klastra na 7 węzłów pojawiają się pytania - co dalej? Jak podnieść wartość produktu? 8, 10 czy 16 węzłów? Jacy producenci modułów? Myśląc o produkcie jako całości, zdaliśmy sobie sprawę, że najważniejsza jest tutaj nie liczba węzłów czy producent, ale sama istota klastrów jako budulca. Musimy szukać minimalnego elementu konstrukcyjnego, który to umożliwia
Pierwszy, będzie klastrem i jednocześnie będzie mógł łączyć dyski i karty rozszerzeń. Blok klastra powinien być samowystarczalnym węzłem bazowym i posiadać szerokie możliwości rozbudowy.
Sekund, aby minimalne bloki klastrów można było łączyć ze sobą budując klastry o większym rozmiarze i aby było to efektywne pod względem budżetu i szybkości skalowania. Szybkość skalowania musi być szybsza niż podłączenie zwykłych komputerów do sieci i znacznie tańsza niż sprzęt serwerowy.
trzeci, minimalne jednostki klastrowe powinny być wystarczająco zwarte, mobilne, energooszczędne, opłacalne i niewymagające warunków eksploatacji. To jedna z kluczowych różnic w stosunku do szaf serwerowych i wszystkiego, co jest z nimi związane.
Zaczęliśmy od określenia liczby węzłów.
Liczba węzłów
Dzięki prostym osądom logicznym zdaliśmy sobie sprawę, że 4 węzły to najlepsza opcja dla minimalnego bloku klastra. 1 węzeł to nie klaster, 2 węzły to za mało (1 master 1 worker, nie ma możliwości skalowania w obrębie bloku, szczególnie dla opcji heterogenicznych), 3 węzły wyglądają ok, ale nie wielokrotność potęgi 2 i skalowanie w obrębie blok jest ograniczony, 6 węzłów ma cenę prawie jak 7 węzłów (z naszego doświadczenia wynika, że to już duży koszt), 8 to dużo, nie mieści się w obudowie mini ITX i jeszcze droższe rozwiązanie PoC.
Cztery węzły na blok są uważane za złoty środek:
- mniej materiałów na tablicę klastrową, a więc tańsza w produkcji
- wielokrotność 4, łącznie 4 bloki dają 16 fizycznych procesorów
- stabilny obwód 1 mistrz i 3 pracowników
- bardziej heterogeniczne odmiany, moduły ogólne + obliczenia przyspieszone
- mini ITX z dyskami SSD i kartami rozszerzeń
Moduły obliczeniowe
Druga wersja jest oparta na CM4, myśleliśmy, że zostanie wydana w formacie SODIMM. Ale…
Podjęliśmy decyzję o stworzeniu płyty rozszerzenia SODIMM i zmontowaniu CM4 bezpośrednio w moduły, aby użytkownicy nie musieli myśleć o CM4.
Moduł obliczeniowy Turing Pi obsługujący Raspberry Pi CM4
Ogólnie rzecz biorąc, w poszukiwaniu modułów otwarto cały rynek modułów obliczeniowych od małych modułów z 128 MB RAM do 8 GB RAM. Przed nami moduły z 16 GB RAM i więcej. W przypadku hostingu aplikacji brzegowych opartych na technologiach natywnych w chmurze 1 GB RAM to już za mało, a niedawne pojawienie się modułów na 2, 4, a nawet 8 GB RAM zapewnia dobre miejsce na rozwój. Rozważali nawet opcje z modułami FPGA dla aplikacji uczenia maszynowego, ale ich wsparcie zostało opóźnione, ponieważ ekosystem oprogramowania nie jest rozwinięty. Badając rynek modułów wpadliśmy na pomysł stworzenia uniwersalnego interfejsu dla modułów, a w V2 zaczynamy ujednolicać interfejs modułów obliczeniowych. Dzięki temu posiadacze wersji V2 będą mogli łączyć moduły innych producentów i mieszać je do konkretnych zadań.
V2 obsługuje całą linię Raspberry Pi 4 Compute Module (CM4), w tym wersje Lite i moduły 8 GB RAM
Urządzenia peryferyjne
Po ustaleniu dostawcy modułów oraz ilości węzłów podeszliśmy do szyny PCI, na której znajdują się peryferia. Magistrala PCI jest standardem dla urządzeń peryferyjnych i można ją znaleźć w prawie wszystkich modułach obliczeniowych. Mamy kilka węzłów i idealnie byłoby, gdyby każdy węzeł mógł współdzielić urządzenia PCI w trybie jednoczesnego żądania. Na przykład, jeśli jest to dysk podłączony do magistrali, to jest dostępny dla wszystkich węzłów. Zaczęliśmy szukać przełączników PCI z obsługą wielu hostów i stwierdziliśmy, że żaden z nich nie spełnia naszych wymagań. Wszystkie te rozwiązania były w większości ograniczone do 1 hosta lub wielu hostów, ale bez trybu równoczesnych żądań do punktów końcowych. Drugim problemem jest wysoki koszt 50 USD lub więcej za chip. W V2 zdecydowaliśmy się odłożyć eksperymenty z przełącznikami PCI (powrócimy do nich później w miarę rozwoju) i poszliśmy ścieżką przypisywania roli dla każdego węzła: pierwsze dwa węzły odsłoniły port mini PCI express na węzeł, trzeci węzeł odsłonięty 2-portowy kontroler SATA 6 Gb/s. Aby uzyskać dostęp do dysków z innych węzłów, można użyć sieciowego systemu plików w klastrze. Dlaczego nie?
Zapowiedź
Postanowiliśmy podzielić się kilkoma szkicami tego, jak minimalny blok klastrów ewoluował w czasie poprzez dyskusję i refleksję.
W rezultacie doszliśmy do jednostki klastra z 4 260-pinowymi węzłami, 2 portami mini PCIe (Gen 2), 2 portami SATA (Gen 3). Płyta posiada zarządzalny przełącznik Layer-2 z obsługą VLAN. Z pierwszego węzła usunięto port mini PCIe, do którego można zainstalować kartę sieciową i dostać kolejny port Ethernet lub modem 5G oraz zrobić router do sieci na klastrze i porty Ethernet z pierwszego węzła.
Magistrala klastra ma więcej funkcji, w tym możliwość flashowania modułów bezpośrednio przez wszystkie gniazda i oczywiście złącza FAN na każdym węźle z kontrolą prędkości.
Stosowanie
Infrastruktura brzegowa dla aplikacji i usług hostowanych samodzielnie
Zaprojektowaliśmy wersję V2 jako minimalny element konstrukcyjny infrastruktury brzegowej klasy konsumenckiej/komercyjnej. Dzięki wersji 2 można tanio rozpocząć weryfikację koncepcji i skalować ją w miarę rozwoju, stopniowo przenosząc aplikacje, które są bardziej opłacalne i praktyczne w hostowaniu na brzegu sieci. Bloki klastrów można łączyć ze sobą, tworząc większe klastry. Można to zrobić stopniowo, bez większego ryzyka dla ustalonych
procesy. Już dziś istnieje ogromna liczba aplikacji dla biznesu, .
Stacja robocza ARM
Dzięki maksymalnie 32 GB pamięci RAM na klaster, pierwszy węzeł może być używany przez komputerową wersję systemu operacyjnego (na przykład Ubuntu Desktop 20.04 LTS), a pozostałe 3 węzły do zadań związanych z kompilacją, testowaniem i debugowaniem, tworząc natywne rozwiązania chmurowe dla ARM klastry. Jako węzeł dla CI/CD na infrastrukturze brzegowej ARM w prod.
Klaster Turing V2 z modułami CM4 jest niemal identyczny architektonicznie (różnica w mniejszych wersjach ARMv8) do klastra opartego na instancjach AWS Graviton. Procesor modułu CM4 wykorzystuje architekturę ARMv8, dzięki czemu można budować obrazy i aplikacje dla instancji AWS Graviton 1 i 2, o których wiadomo, że są znacznie tańsze niż instancje x86.
Źródło: www.habr.com