Hilsen Habr-samfundet! Jeg skrev for nylig om vores første version af klyngebræt []. Og i dag vil jeg fortælle dig, hvordan vi arbejdede på versionen Random Access Memory.
Vi er glade for miniservere, der kan bruges til både lokal udvikling og lokal hosting. I modsætning til stationære computere eller bærbare computere er vores servere designet til at arbejde 24/7, de kan hurtigt sammenføjes, for eksempel var der 4 processorer i en klynge, og efter 5 minutter var der 16 processorer (ingen yderligere netværksudstyr) og alt dette i en kompakt formfaktor lydløs og energieffektiv.
Arkitekturen på vores servere er baseret på klyngeprincippet om konstruktion, dvs. vi laver klyngekort, der ved hjælp af ethernet-netværket på kortet forbinder flere computermoduler (processorer). For at forenkle, laver vi ikke vores egne computermoduler endnu, men bruger Raspberry Pi Compute Modules og vi håbede virkelig på det nye CM4-modul. Men alt gik imod planerne med deres nye formfaktor, og jeg tror, at mange er skuffede.
Under skæringen, hvordan vi gik fra V1 til V2, og hvordan vi skulle komme ud med den nye Raspberry Pi CM4 formfaktor.
Så efter at have oprettet en klynge til 7 noder, er spørgsmålene - hvad er det næste? Hvordan øger man værdien af et produkt? 8, 10 eller 16 noder? Hvilke modulproducenter? Når vi tænker på produktet som helhed, indså vi, at det vigtigste her ikke er antallet af noder eller hvem producenten er, men selve essensen af klynger som byggesten. Vi er nødt til at lede efter den mindste byggesten
Den første, vil være en klynge og samtidig kunne tilslutte diske og udvidelseskort. Klyngeblokken skal være en selvforsynende basisknude og med en bred vifte af udvidelsesmuligheder.
sekunder, så de mindste klyngeblokke kan forbindes med hinanden ved at bygge klynger af større størrelse, og så det er effektivt i forhold til budget og skaleringshastighed. Skaleringshastigheden skal være hurtigere end at tilslutte almindelige computere til et netværk og meget billigere end serverhardware.
tredje, skal minimumklyngeenhederne være tilstrækkeligt kompakte, mobile, energieffektive, omkostningseffektive og ikke krævende for driftsbetingelserne. Dette er en af de vigtigste forskelle fra serverracks og alt, der er forbundet med dem.
Vi startede med at bestemme antallet af noder.
Antal noder
Med enkle logiske vurderinger indså vi, at 4 noder er den bedste mulighed for minimum klyngeblok. 1 node er ikke en klynge, 2 noder er ikke nok (1 master 1 arbejder, der er ingen mulighed for skalering inden for en blok, især for heterogene muligheder), 3 noder ser ok ud, men ikke et multiplum af potenser af 2 og skalering inden for en blok er begrænset, 6 noder kommer til en pris næsten som 7 noder (fra vores erfaring er dette allerede en stor kostpris), 8 er meget, passer ikke i mini ITX formfaktoren og en endnu dyrere PoC løsning.
Fire noder pr. blok betragtes som den gyldne middelvej:
- færre materialer pr. klyngeplade, og dermed billigere at fremstille
- multiplum af 4, i alt 4 blokke giver 16 fysiske processorer
- stabilt kredsløb 1 master og 3 arbejdere
- mere heterogene variationer, general-compute + accelerated-compute-moduler
- mini ITX formfaktor med SSD-drev og udvidelseskort
Beregn moduler
Den anden version er baseret på CM4, vi troede, at den ville blive udgivet i SODIMM-formfaktor. Men…
Vi tog en beslutning om at lave et SODIMM-datterkort og samle CM4 direkte i moduler, så brugerne ikke behøver at tænke på CM4.
Turing Pi Compute Module, der understøtter Raspberry Pi CM4
Generelt, på jagt efter moduler, blev et helt marked af computermoduler åbnet fra små moduler med 128 MB RAM til 8 GB RAM. Moduler med 16 GB RAM og mere er forude. For edge-applikationshosting baseret på cloud-native teknologier er 1 GB RAM allerede ikke nok, og den nylige fremkomst af moduler til 2, 4 og endda 8 GB RAM giver god plads til vækst. De overvejede endda muligheder med FPGA-moduler til maskinlæringsapplikationer, men deres support er blevet forsinket, fordi softwareøkosystemet ikke er udviklet. Mens vi studerede modulmarkedet, kom vi på ideen om at skabe en universel grænseflade til moduler, og i V2 begynder vi at forene grænsefladen for computermoduler. Dette vil give ejere af V2-versionen mulighed for at forbinde moduler fra andre producenter og blande dem til specifikke opgaver.
V2 understøtter hele Raspberry Pi 4 Compute Module (CM4) linjen, inklusive Lite-versioner og 8 GB RAM-moduler
periferi
Efter at have bestemt leverandøren af modulerne og antallet af noder, nærmede vi os PCI-bussen, hvorpå periferiudstyret er placeret. PCI-bussen er standarden for periferiudstyr og findes i næsten alle computermoduler. Vi har flere noder, og ideelt set bør hver node være i stand til at dele PCI-enheder i samtidig anmodningstilstand. For eksempel, hvis det er en disk forbundet til bussen, så er den tilgængelig for alle noder. Vi begyndte at lede efter PCI-switche med multi-host-understøttelse og fandt ud af, at ingen af dem passede til vores krav. Alle disse løsninger var for det meste begrænset til 1 vært eller flere værter, men uden tilstanden med samtidige anmodninger til slutpunkter. Det andet problem er de høje omkostninger på $50 eller mere pr. chip. I V2 besluttede vi at udskyde eksperimenter med PCI-switche (vi vender tilbage til dem senere, efterhånden som vi udvikler) og gik ad vejen med at tildele en rolle for hver node: de første to noder eksponerede mini-PCI-ekspresport pr. node, den tredje node eksponeret 2-ports 6 Gbps SATA-controller. For at få adgang til diske fra andre noder kan du bruge netværksfilsystemet i klyngen. Hvorfor ikke?
Smugkig
Vi besluttede at dele nogle skitser af, hvordan minimum klyngeblokken har udviklet sig over tid gennem diskussion og refleksion.
Som et resultat kom vi til en klyngeenhed med 4 260-pin noder, 2 mini PCIe (Gen 2) porte, 2 SATA (Gen 3) porte. Kortet har en Layer-2 Managed Switch med VLAN-understøttelse. Der er fjernet en mini PCIe-port fra den første node, hvori du kan installere et netværkskort og få en anden Ethernet-port eller 5G-modem og lave en router til netværket på klyngen og Ethernet-porte fra den første node.
Clusterbussen har flere funktioner, herunder muligheden for at flashe moduler direkte gennem alle slots og selvfølgelig FAN-stik på hver node med hastighedskontrol.
Ansøgning
Edge-infrastruktur til selv-hostede applikationer og tjenester
Vi har designet V2 til at være minimumsbyggestenen til en forbruger-/kommerciel-grade edge-infrastruktur. Med V2 er det billigt at starte proof-of-concept og skalere, efterhånden som du vokser, og gradvist overføre applikationer, der er mere omkostningseffektive og praktiske at hoste på kanten. Klyngeblokke kan forbindes sammen for at bygge større klynger. Dette kan gøres gradvist uden stor risiko for at etablere
processer. Allerede i dag er der et stort antal ansøgninger til erhvervslivet, .
ARM arbejdsstation
Med op til 32 GB RAM pr. klynge kan den første node bruges til desktopversionen af operativsystemet (for eksempel Ubuntu Desktop 20.04 LTS) og de resterende 3 noder til kompilerings-, test- og fejlfindingsopgaver, udvikling af cloud-native løsninger til ARM klynger. Som en node for CI / CD på ARM edge infrastruktur i prod.
Turing V2-klynge med CM4-moduler er næsten identisk arkitektonisk (forskel i mindre versioner af ARMv8) til klynge baseret på AWS Graviton-instanser. CM4-modulprocessoren bruger ARMv8-arkitekturen, så du kan bygge billeder og applikationer til AWS Graviton 1- og 2-instanser, som er kendt for at være meget billigere end x86-instanser.
Kilde: www.habr.com