Hej Habr-samfund! For nylig skrev jeg om vores clusterboard i første version []. I dag vil jeg gerne fortælle om, hvordan vi arbejdede på versionen RAM.
Vi er fascinerede af mini-servere, 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, og de kan hurtigt forbindes i en federation. For eksempel var der 4 processorer i klysten, og efter 5 minutter blev der 16 processorer (uden ekstra netværksudstyr), og alt dette i en kompakt formfaktor, støjsvagt og energivenligt.
Kernen i vores serverarkitektur er det klysterprincip, dvs. vi laver klyngeplader, som gennem ethernet-netværket på pladen forbinder flere beregningsmoduler (processorer). For at forenkle tingene laver vi ikke vores beregningsmoduler endnu, men bruger Raspberry Pi Compute Modules, og vi havde håbet meget på den nye CM4-modul. Men alt gik imod planerne med deres nye formfaktor, og jeg tror, mange er skuffede.
Under katte, hvordan vi gik fra V1 til V2, og hvordan vi måtte navigere med den nye formfaktor Raspberry Pi CM4.
Så, efter oprettelsen af en klynge med 7 noder, spørgsmålet er — hvad nu? Hvordan kan vi øge produktets værdi? 8, 10 eller 16 noder? Hvilke producenter af moduler? Når vi tænkte på produktet som helhed, indså vi, at det her ikke er antallet af noder eller hvem producenten er, men klysternes essens som byggesten. Vi skal finde den mindste byggesten, der
Først, vil være en klynge og samtidig have mulighed for tilslutning af diske og udvidelsesplader. Klysterblokken skal være en selvforsynende basisenhed med brede udvidelsesmuligheder.
Det andet, så de mindste klysterblokke kan forbindes med hinanden for at opbygge større klyster, og at det skal være effektivt i forhold til budget og hastighed for skalering. Hastigheden for skalering skal være højere end at forbinde almindelige computere i et netværk og meget billigere end serverudstyr.
Tredje, de mindste klyngeblokke skal være kompakte, mobile, energieffektive, omkostningseffektive og kræve lidt for driftsbetingelserne. Dette er en af de vigtigste forskelle fra serverracks og alt, hvad der relaterer til dem.
Vi begyndte med at fastslå antallet af noder.
Antallet af noder
Med simple logiske overvejelser fandt vi ud af, at 4 noder er den bedste mulighed for en minimum klyngeblok. 1 node er ikke en klynge, 2 noder er for få (1 master 1 worker, ingen mulighed for skalering inden for blokken, især for heterogene muligheder), 3 noder ser okay ud, men er ikke et multiplum af 2's potenser og har begrænset skalering inden for blokken, 6 noder koster næsten det samme som 7 noder (ud fra vores erfaring er det en høj produktionsomkostning), 8 er for mange, det passer ikke i mini ITX-formfaktoren og er en endnu dyrere løsning til PoC.
Fire noder pr. blok betragter vi som den gyldne mellemvej:
- mindre materialer til klyngepladen, hvilket gør produktionen billigere
- multiplikation af 4, i alt 4 blokke giver 16 fysiske processorer
- stabil opsætning med 1 master og 3 workere
- flere heterogene variationer, general-compute + accelerated-compute moduler
- mini ITX-formfaktor med SSD-diske og udvidelseskort
Beregningsmoduler
Den anden version er baseret på CM4, vi troede, de ville udgive den i SODIMM-formfaktor. Men…
Vi besluttede at lave et SODIMM-datterskud og samle CM4 direkte i moduler, så brugerne ikke skal tænke på CM4.
Turing Pi Compute Module med support for Raspberry Pi CM4
I det hele taget blev der åbnet et helt marked for beregningsmoduler fra små moduler med 128 MB RAM til 8 GB RAM. Fremadskuende moduler med 16 GB RAM og mere. For edge hosting af applikationer baseret på cloud native teknologier er 1 GB RAM allerede utilstrækkeligt, og den nylige introduktion af moduler med 2, 4 og endda 8 GB RAM giver godt rum for vækst. Vi overvejede endda muligheder med FPGA-moduler til maskinlæringsapplikationer, men deres support er udskudt, fordi den softwaremæssige økosystem ikke er udviklet. Under undersøgelsen af markedet for moduler kom vi til ideen om at skabe et universelt interface til moduler, og i V2 begynder vi at standardisere interfacet for beregningsmoduler. Det vil gøre det muligt for ejere af version V2 at tilslutte moduler fra andre producenter og blande dem til specifikke opgaver.
V2 understøtter hele serien af Raspberry Pi 4 Compute Module (CM4), herunder Lite-versioner og moduler med 8 GB RAM.
Periferien
Efter at have identificeret leverandøren af modulerne og antallet af noder, nåede vi til PCI-bussen, hvor periferien findes. PCI-bussen er en standard for perifere enheder og findes næsten i alle beregningsmoduler. Vi har flere noder, og ideelt set skal hver node kunne dele PCI-enheder i en konkurrerende forespørgselsmode. For eksempel, hvis det er et disk drev tilsluttet bussen, er det tilgængeligt for alle noder. Vi begyndte at lede efter PCI-switches med mulighed for at støtte multi-host og opdagede, at ingen af dem opfyldte vores krav. Alle disse løsninger var hovedsageligt begrænset til 1 vært eller multi-værter, men uden mulighed for konkurrerende forespørgsler til endpoints. Det andet problem er den høje pris, fra $50 og op. I V2 besluttede vi at udsætte eksperimenterne med PCI-switches (vi vil vende tilbage til dem senere, efterhånden som vi udvikler os) og valgte i stedet at tildele en rolle til hver node: de første to noder fik en exposure mini PCI Express-port per node, den tredje node fik 2-ports 6 Gbps SATA-controller. For at få adgang til diske fra andre noder kan der anvendes et netværksfilsystem inden for klyngen. Hvorfor ikke?
Sneakpeek
Vi har besluttet at dele nogle skitser af, hvordan den minimale klyngeblok har udviklet sig over tid under diskussion og overvejelse.
Som resultat kom vi frem til en klyngeblok med 4 noder, 260-pin, 2 mini PCIe (Gen 2) porte, 2 SATA (Gen 3) porte. På boardet er der installeret en Layer-2 Managed Switch med støtte for VLAN. Fra den første node er der trukket en mini PCIe-port, hvor en netværkskort kan installeres for at få endnu en Ethernet-port eller en 5G-modem og gøre den første node til en router for netværket i klyngen og Ethernet-porter.
Klyngebussen har flere funktioner, herunder muligheden for at opdatere moduler direkte gennem alle slots, og selvfølgelig FAN-forbindelser på hver node med hastighedsregulering.
Anvendelse
Edge-infrastruktur til selvhostede applikationer & tjenester
Vi designede V2 med det formål at bruge den som en minimal byggesten til forbruger-/kommerciel edge-infrastruktur. Med V2 er det billigt at starte konceptverifikation og skalere i takt med væksten, gradvist flytte applikationer, som det er økonomisk og praktisk forsvarligt at hoste i edge. Klyngeblokke kan sammenkobles for at bygge større klynger. Dette kan gøres trinvist uden større risici for etablerede løsninger.
processer. Allerede i dag er der et væld af applikationer til erhvervslivet, .
ARM Workstation
Med op til 32 GB RAM pr. klynge kan den første node bruges til desktopversionen af OS (f.eks. Ubuntu Desktop 20.04 LTS), mens de resterende 3 noder kan anvendes til kompilering, test og debugging samt udvikling af cloud native løsninger til ARM klynger. Som en node til CI/CD i ARM-infrastruktur i produktion.
Turing V2-klyngen med CM4-moduler er arkitektonisk næsten identisk (forskellen ligger i mindre versioner af ARMv8) med klyngen baseret på AWS Graviton-instanser. I CM4-modulerne bruges ARMv8-arkitekturen, så du kan bygge billeder og applikationer til AWS-instanserne Graviton 1 og 2, som er kendt for at være meget billigere end x86-instanser.
Kilde: habr.com
