Mini ITX-klustret Turing Pi 2 med 32 GB RAM.

Hej Habr-gemenskap! Nyligen skrev jag om vårt klusterkort av första versionen [V1]. Idag vill jag berätta hur vi arbetade med versionen Turing V2 med 32 GB arbetsminnet.

Vi är entusiastiska över mini-servrar som kan användas både för lokal utveckling och för att hosta lokalt. Till skillnad från stationära datorer eller bärbara datorer är våra servrar designade för att arbeta 24/7, och de kan snabbt kopplas samman i en federation; till exempel hade vi 4 processorer i klustret, och efter 5 minuter hade vi 16 processorer (utan extra nätverksutrustning), allt i en kompakt formfaktor, ljudlöst och energieffektivt.

Grunden för arkitekturen av våra servrar är klusterprincipen; vi gör klusterkort som med hjälp av Ethernet-nätverket på kortet ansluter flera beräkningsmoduler (processorer). För att förenkla gör vi för tillfället inte våra egna beräkningsmoduler utan använder Raspberry Pi Compute Modules, och vi hade stora förhoppningar på den nya modul CM4. Men allt gick emot planerna med deras nya formfaktor, och jag tror att många blivit besvikna.

Under detta inlägg kommer vi att visa hur vi gick från V1 till V2 och hur vi fick hantera den nya formfaktorn av Raspberry Pi CM4.

Så, efter att ha skapat en kluster med 7 noder, frågor - vad nu? Hur ökar vi produktens värde? 8, 10 eller 16 noder? Vilka tillverkare av moduler? När vi tänkte på produkten som helhet insåg vi att det centrala inte handlar om antalet noder eller vem tillverkaren är, utan själva essensen av kluster som byggblock. Vi behöver hitta den minimi byggstenen, som

Första, ska utgöra klustret och samtidigt ha möjlighet att ansluta diskar och expansionskort. Klusterblocket måste vara en självförsörjande grundnod med omfattande expansionsmöjligheter.

Den andra, så att de minimi klusterblock kan kopplas samman för att bygga större kluster, och att detta ska vara kostnadseffektivt och snabbt att skala. Hastigheten för skalning bör vara högre än att koppla vanliga datorer till ett nätverk och mycket billigare än serverutrustning.

Det tredje, minimala klusterblock måste vara tillräckligt kompakta, mobila, energieffektiva, kostnadseffektiva och inte kräva mycket av driftsförhållandena. Detta är en av de huvudsakliga skillnaderna från serverrack och allt som är relaterat till dem.

Vi började med att bestämma antalet noder.

Antalet noder

Genom enkla logiska resonemang kom vi fram till att 4 noder är det bästa alternativet för en minimal klusterblock. 1 nod är inte ett kluster, 2 noder är för få (1 master, 1 arbetare, ingen möjlighet till skalning inom blocket, särskilt för heterogena alternativ), 3 noder ser okej ut, men är inte multiplar av 2 och har begränsad skalning inom blocket, 6 noder kostar nästan lika mycket som 7 noder (från vår erfarenhet är det redan en hög kostnad), 8 noder är för mycket, får inte plats i mini ITX-formfaktorn och är en ännu dyrare lösning för PoC.

Fyra noder per block anser vi vara en gyllene medelväg:

• mindre material för klusterkortet, vilket gör produktionen billigare
• multiplar av 4, totalt 4 block ger 16 fysiska processorer
• stabil konfiguration med 1 master och 3 arbetare
• fler heterogena variationer, allmän databehandling + accelererad databehandling moduler
• mini ITX formfaktor med SSD-diskar och expansionskort

Beräkningsmoduler

Den andra versionen baseras på CM4. Vi trodde att den skulle släppas i SODIMM-formfaktor. Men…
Vi beslutade att göra en dotterkort SODIMM och montera CM4 direkt i moduler så att användarna inte behöver tänka på CM4.

Turing Pi Compute Module med stöd för Raspberry Pi CM4

Under sökandet efter moduler upptäcktes en hel marknad för beräkningsmoduler från små moduler på 128 MB RAM till 8 GB RAM. Framöver finns det moduler med 16 GB RAM och mer. För edge-hosting av applikationer baserade på cloud native-teknologier är 1 GB RAM redan för lite, och den senaste tillkomsten av moduler på 2, 4 och till och med 8 GB RAM ger bra utrymme för tillväxt. Vi övervägde även alternativ med FPGA-moduler för applikationer för maskininlärning, men deras stöd har skjutits upp eftersom den mjukvaru-ekosystemet inte är utvecklat. Under studiet av marknaden för moduler kom vi på idén att skapa ett universellt gränssnitt för moduler och i V2 börjar vi en enhetliggöring av gränssnittet för beräkningsmoduler. Detta kommer att möjliggöra för ägare av V2-versionen att koppla moduler från andra tillverkare och blanda dem för specifika uppgifter.

V2 stödjer hela serien av Raspberry Pi 4 Compute Module (CM4), inklusive Lite-versionerna och moduler på 8 GB RAM

Periferiutrustning

Efter att ha bestämt leverantör för moduler och antal noder kom vi till PCI-bussen, där periferin finns. PCI-bussen är en standard för perifera enheter och finns i nästan alla beräkningsmoduler. Vi har flera noder, och idealiskt sett skulle varje nod kunna dela PCI-enheter i ett läge med konkurrerande förfrågningar. Till exempel, om det är en disk som är ansluten till bussen, är den tillgänglig för alla noder. Vi började leta efter PCI-switchar med stöd för multihost och upptäckte att ingen av dem passade våra krav. Alla dessa lösningar var främst begränsade till 1 värd eller flera värdar, men utan läge för konkurrerande förfrågningar till endpoints. Det andra problemet var den höga kostnaden från $50 och mer per chip. I V2 beslutade vi att skjuta upp experimenten med PCI-switchar (vi kommer att återkomma till dem senare i takt med utvecklingen) och valde istället att tilldela en roll till varje nod: de första två noderna hade en exponerad mini PCI express-port per nod, den tredje noden hade en exponerad 2-portars 6 Gbps SATA-kontroller. För att få tillgång till diskar från andra noder kan man använda ett nätverksfilsystem inom ramen för klustret. Varför inte?

Sneakpeek

Vi har beslutat att dela vissa skisser som visar hur den minimi klusterblocken har utvecklats över tiden under diskussioner och överväganden.

Som resultat kom vi fram till ett klusterblock med 4 noder, 260-pin, 2 mini PCIe (Gen 2) portar, 2 SATA (Gen 3) portar. På kortet finns en Layer-2 Managed Switch med VLAN-stöd. Från den första noden har en mini PCIe-port dragits ut, där man kan installera ett nätverkskort och få ytterligare en Ethernet-port eller en 5G-modem och göra den första noden till en router för nätverket i klustret och Ethernet-portarna.

Klusterbussen har fler funktioner, inklusive möjlighet att göra enhetsuppdateringar direkt genom alla platser och självklart fläktkontakter på varje nod med hastighetskontroll.

Tillämpning

Edge-infrastruktur för självhostade applikationer och tjänster

Vi designade V2 med målet att använda den som en minimal byggsten för infrastructure i consumer/commercial-grade edge infrastrukturen. Med V2 är det billigt att börja bekräfta konceptet och skala upp i takt med tillväxten, gradvis flytta applikationer som är ekonomiskt och praktiskt rimligare att hosta i edge. Klusterblock kan kopplas samman för att bygga större kluster. Detta kan göras gradvis utan betydande risker för etablerade system.
processer. Redan idag finns det ett stort antal applikationer för företag, som kan hostas lokalt.

ARM Workstation

Med upp till 32 GB RAM på klustret kan den första noden användas för desktopversion av OS (som Ubuntu Desktop 20.04 LTS) och de återstående 3 noderna för kompilering, testning och felsökning, utveckling av molnbaserade lösningar för ARM-kluster. Som en nod för CI/CD på ARM-perifierinfrastrukturen i produktion.

Turing V2-klustret med CM4-moduler är arkitektoniskt nästan identiskt (skillnad i mindre versioner av ARMv8) med klustret baserat på AWS Graviton-instanser. I processorn av CM4-moduler används ARMv8-arkitektur, vilket gör att du kan bygga bilder och applikationer för AWS-instanser Graviton 1 och 2, som är betydligt billigare än x86-instanser.

Källa: habr.com