Witam społeczność Habr! Niedawno pisałem o naszej pierwszej wersji płyty klastrowej []. A dziś chcę opowiedzieć, jak pracowaliśmy nad wersją pamięci operacyjnej.
Pasjonujemy się mini serwerami, które można wykorzystać zarówno do lokalnego rozwoju, jak i do lokalnego hostingu. W przeciwieństwie do komputerów stacjonarnych czy laptopów, nasze serwery są zaprojektowane do pracy 24/7; szybko można je łączyć w federacje, na przykład było 4 procesory w klastrze, a w ciągu 5 minut stało się ich 16 (bez dodatkowego sprzętu sieciowego) i wszystko to w kompaktowym formacie, cicho i energooszczędnie.
Podstawą architektury naszych serwerów jest klastrowa zasada budowy, tzn. tworzymy płyty klastrowe, które za pomocą sieci ethernetowej na płycie łączą kilka modułów obliczeniowych (procesorów). Na razie uprościliśmy sytuację, nie tworząc własnych modułów obliczeniowych, a wykorzystując moduły Raspberry Pi Compute i bardzo liczyliśmy na nowy moduł CM4. Jednak wszystko poszło niezgodnie z planem z powodu ich nowego formatu i myślę, że wielu jest rozczarowanych.
Zobacz, jak przeszliśmy od V1 do V2 i jak musieliśmy się dostosować do nowego formatu Raspberry Pi CM4.
A więc, po stworzeniu klastra z 7 węzłami, pytania — co dalej? Jak zwiększyć wartość produktu? 8, 10 czy 16 węzłów? Jacy są producenci modułów? Myśląc o produkcie w całości, zrozumieliśmy, że nie chodzi tu o ilość węzłów czy producenta, ale o samą istotę klastrów jako elementów budowlanych. Musimy znaleźć minimalny element budowlany, który
Pierwsze, będzie stanowił klaster i jednocześnie będzie miał możliwość podłączenia dysków i płyt rozszerzeń. Klastrowy blok musi być samowystarczającym podstawowym węzłem z szerokimi możliwościami rozszerzeń.
Drugie, aby minimalne bloki klastrowe mogły być ze sobą łączone w większe klastry w sposób efektywny zarówno budżetowo, jak i pod względem szybkości skalowania. Szybkość skalowania powinna być wyższa niż łączenie zwykłych komputerów w sieć i znacznie tańsza od sprzętu serwerowego.
Trzecie, minimalne bloki klastrowe powinny być wystarczająco kompaktowe, mobilne, energooszczędne, opłacalne i nie wymagające szczególnych warunków eksploatacji. To jedna z kluczowych różnic w porównaniu do szaf serwerowych i wszystkiego, co się z nimi wiąże.
Rozpoczęliśmy od określenia ilości węzłów.
Liczba węzłów
Rozumując logicznie, doszliśmy do wniosku, że 4 węzły to najlepsza opcja dla minimalnego klastra. 1 węzeł to nie klaster, 2 węzły to mało (1 master, 1 worker, brak możliwości skalowania w ramach bloku, zwłaszcza dla heterogenicznych wariantów), 3 węzły wyglądają w porządku, ale nie są liczbą potęgową 2 i mają ograniczoną skalowalność w ramach bloku, 6 węzłów kosztuje prawie tyle co 7 węzłów (z naszego doświadczenia, to już wysoki koszt), 8 to dużo, nie mieści się w formacie mini ITX i jest jeszcze droższym rozwiązaniem dla PoC.
Cztery węzły na blok uważamy za złoty środek:
- mniej materiałów na płytę klastrową, co oznacza tańszą produkcję
- czterokrotnie 4, w sumie 4 bloki dają 16 fizycznych procesorów
- stabilny schemat 1 master i 3 workery
- więcej heterogenicznych wariantów, moduły ogólne + przyspieszone obliczenia
- mini ITX form factor z dyskami SSD i płytami rozszerzeń
Moduły obliczeniowe
Druga wersja opiera się na CM4, myśleliśmy, że zostanie wydana w formacie SODIMM. Ale...
Postanowiliśmy zrobić płytę podrzędną SODIMM i montować CM4 bezpośrednio w modułach, aby użytkownicy nie musieli myśleć o CM4.
Moduł obliczeniowy Turing Pi z obsługą Raspberry Pi CM4
W poszukiwaniu modułów odkryto cały rynek modułów obliczeniowych, od małych modułów z 128 MB RAM do 8 GB RAM. W przyszłości mają być moduły na 16 GB RAM i więcej. Dla edge hostingu aplikacji opartych na technologiach cloud native 1 GB RAM już nie wystarcza, a niedawne pojawienie się modułów z 2, 4, a nawet 8 GB RAM daje dobre możliwości rozwoju. Nawet rozważano opcje z modułami FPGA dla aplikacji uczenia maszynowego, jednak ich wsparcie zostało opóźnione, ponieważ ekosystem oprogramowania nie jest rozwinięty. Podczas badania rynku modułów doszliśmy do pomysłu stworzenia uniwersalnego interfejsu dla modułów, a w V2 rozpoczynamy unifikację interfejsu modułów obliczeniowych. To umożliwi właścicielom wersji V2 podłączanie modułów innych producentów i ich miksowanie pod konkretne zadania.
V2 obsługuje całą linię modułów obliczeniowych Raspberry Pi 4 (CM4), w tym wersje Lite oraz moduły na 8 GB RAM
Peryferia
Po ustaleniu dostawcy modułów i liczby węzłów przeszliśmy do magistrali PCI, na której znajduje się peryferia. Magistrala PCI jest standardem dla urządzeń peryferyjnych i jest obecna prawie we wszystkich modułach obliczeniowych. Mamy kilka węzłów i w idealnym przypadku każdy węzeł powinien mieć możliwość współdzielenia urządzeń PCI w trybie konkurencyjnych zapytań. Na przykład, jeśli to jest dysk podłączony do magistrali, to jest dostępny dla wszystkich węzłów. Zaczęliśmy szukać przełączników PCI z możliwością wsparcia dla wielu hostów i odkryliśmy, że żaden z nich nie spełnia naszych wymagań. Wszystkie te rozwiązania były głównie ograniczone do 1 hosta lub wielu hostów, ale bez trybu konkurencyjnych zapytań do punktów końcowych. Drugim problemem jest wysoki koszt zaczynający się od 50 USD i więcej za chip. W V2 postanowiliśmy wstrzymać eksperymenty z przełącznikami PCI (wrócimy do nich później w miarę rozwoju) i poszliśmy w kierunku przypisania roli dla każdego węzła: pierwsze dwa węzły miały mini PCI express port na każdy węzeł, trzeci węzeł miał dwa porty 6 Gbps SATA kontrolera. Aby uzyskać dostęp do dysków z innych węzłów, można użyć sieciowego systemu plików w ramach klastra. Dlaczego nie?
Sneakpeek
Postanowiliśmy podzielić się kilkoma szkicami, jak ewoluował minimalny blok klastrowy z biegiem czasu podczas dyskusji i przemyśleń
W rezultacie doszliśmy do klastra z 4 węzłami 260-pinowymi, 2 mini PCIe (Gen 2) portami, 2 portami SATA (Gen 3). Na płycie umieszczono przełącznik zarządzany warstwy 2 z obsługą VLAN. Z pierwszego węzła wyprowadzono port mini PCIe, do którego można podłączyć kartę sieciową, uzyskując dodatkowy port Ethernet lub modem 5G, a tym samym przekształcić pierwszy węzeł w router dla sieci w klastrze i portów Ethernet.
Magistrala klastrowa ma więcej funkcji, w tym możliwość programowania modułów bezpośrednio przez wszystkie sloty oraz oczywiście złącza wentylatorów na każdym węźle z kontrolą prędkości.
Zastosowanie
Edge infrastructure for self-hosted applications & services
Projektowaliśmy V2 z zamiarem wykorzystania jej jako minimalny blok budowlany dla infrastruktury brzegowej o jakości konsumenckiej/komercyjnej. Dzięki V2 tanio można rozpocząć weryfikację koncepcji i skalować w miarę wzrostu, stopniowo przenosząc aplikacje, które są ekonomicznie i praktycznie bardziej opłacalne do hostowania na brzegu. Bloki klastrowe można łączyć, tworząc większe klastry. Można to robić stopniowo, bez szczególnych ryzyk dla ustabilizowanych
procesów. Już dzisiaj dostępna jest ogromna liczba aplikacji dla biznesu, .
ARM Workstation
Z pamięcią operacyjną do 32 GB RAM na klaster, pierwszy węzeł można używać dla wersji desktopowej systemu operacyjnego (na przykład Ubuntu Desktop 20.04 LTS), a pozostałe 3 węzły do zadań kompilacji, testowania i debugowania oraz rozwijania rozwiązań cloud native dla klastrów ARM. Jako węzeł dla CI/CD w produkcji ARM infrastruktura zewnętrzna.
Klastr Turing V2 z modułami CM4 jest architektonicznie prawie identyczny (różnica w minorowych wersjach ARMv8) z klastrem opartym na instancjach AWS Graviton. W procesorze modułów CM4 wykorzystana jest architektura ARMv8, dzięki czemu możesz tworzyć obrazy i aplikacje dla instancji AWS Graviton 1 i 2, które są znane z tego, że są znacznie tańsze od instancji x86.
Źródło: habr.com
