Hilsen Habr-samfunnet! Jeg skrev nylig om vår første versjon av klyngebrett []. Og i dag vil jeg fortelle deg hvordan vi jobbet med versjonen tilfeldig tilgangsminne.
Vi er glad i miniservere som kan brukes til både lokal utvikling og lokal hosting. I motsetning til stasjonære datamaskiner eller bærbare datamaskiner, er serverne våre designet for å fungere 24/7, de kan raskt forenes, for eksempel var det 4 prosessorer i en klynge, og etter 5 minutter var det 16 prosessorer (ingen ekstra nettverksutstyr) og alt dette i en kompakt formfaktor lydløs og energieffektiv.
Arkitekturen til våre servere er basert på klyngeprinsippet for konstruksjon, dvs. vi lager klyngekort som ved hjelp av ethernet-nettverket på brettet kobler sammen flere datamoduler (prosessorer). For å forenkle så lager vi ikke våre egne datamoduler ennå, men bruker Raspberry Pi Compute Modules og vi håpet virkelig på den nye CM4-modulen. Men, alt gikk mot planene med deres nye formfaktor og jeg tror mange er skuffet.
Under kuttet hvordan vi gikk fra V1 til V2 og hvordan vi måtte komme oss ut med den nye Raspberry Pi CM4-formfaktoren.
Så, etter å ha opprettet en klynge for 7 noder, er spørsmålene - hva er det neste? Hvordan øke verdien av et produkt? 8, 10 eller 16 noder? Hvilke modulprodusenter? Når vi tenker på produktet som helhet, innså vi at det viktigste her ikke er antall noder eller hvem produsenten er, men selve essensen av klynger som byggestein. Vi må se etter minimumsbyggesteinen som
Første, vil være en klynge og samtidig kunne koble til disker og utvidelseskort. Klyngeblokken skal være en selvforsynt basenode og med et bredt spekter av utvidelsesmuligheter.
andre, slik at minimumsklyngeblokkene kan kobles til hverandre ved å bygge klynger av større størrelse og slik at det blir effektivt med tanke på budsjett og skaleringshastighet. Skaleringshastigheten må være raskere enn å koble vanlige datamaskiner til et nettverk og mye billigere enn servermaskinvare.
tredje, bør minimumsklyngeenhetene være tilstrekkelig kompakte, mobile, energieffektive, kostnadseffektive og ikke krevende for driftsforhold. Dette er en av de viktigste forskjellene fra serverrack og alt som er forbundet med dem.
Vi startet med å bestemme antall noder.
Antall noder
Med enkle logiske vurderinger innså vi at 4 noder er det beste alternativet for minimum klyngeblokk. 1 node er ikke en klynge, 2 noder er ikke nok (1 master 1 arbeider, det er ingen mulighet for skalering innenfor en blokk, spesielt for heterogene alternativer), 3 noder ser ok ut, men ikke et multiplum av potenser på 2 og skalering innenfor en blokk er begrenset, 6 noder har en pris nesten som 7 noder (fra vår erfaring er dette allerede en stor kostpris), 8 er mye, passer ikke i mini ITX-formfaktoren og en enda dyrere PoC-løsning.
Fire noder per blokk regnes som den gyldne middelvei:
- mindre materialer per klyngeplate, derav billigere å produsere
- multiplum av 4, totalt 4 blokker gir 16 fysiske prosessorer
- stabil krets 1 master og 3 arbeidere
- mer heterogene variasjoner, generell-beregning + akselerert-beregning-moduler
- mini ITX formfaktor med SSD-stasjoner og utvidelseskort
Beregne moduler
Den andre versjonen er basert på CM4, vi trodde at den vil bli utgitt i SODIMM-formfaktor. Men…
Vi tok en beslutning om å lage et SODIMM-datterkort og sette sammen CM4 direkte til moduler slik at brukerne ikke trenger å tenke på CM4.
Turing Pi Compute Module som støtter Raspberry Pi CM4
Generelt, på jakt etter moduler, ble et helt marked for datamoduler åpnet fra små moduler med 128 MB RAM til 8 GB RAM. Moduler med 16 GB RAM og mer er i forkant. For avansert applikasjonshosting basert på skybaserte teknologier er 1 GB RAM allerede ikke nok, og den nylige opptredenen av moduler for 2, 4 og til og med 8 GB RAM gir godt rom for vekst. De vurderte til og med alternativer med FPGA-moduler for maskinlæringsapplikasjoner, men støtten deres har blitt forsinket fordi programvareøkosystemet ikke er utviklet. Mens vi studerte modulmarkedet, kom vi opp med ideen om å lage et universelt grensesnitt for moduler, og i V2 begynner vi å forene grensesnittet til datamoduler. Dette vil tillate eiere av V2-versjonen å koble til moduler fra andre produsenter og blande dem for spesifikke oppgaver.
V2 støtter hele Raspberry Pi 4 Compute Module (CM4)-linjen, inkludert Lite-versjoner og 8 GB RAM-moduler
Utkanten
Etter å ha bestemt leverandøren av modulene og antall noder, nærmet vi oss PCI-bussen som periferiutstyret er plassert på. PCI-bussen er standarden for periferiutstyr og finnes i nesten alle datamoduler. Vi har flere noder, og ideelt sett bør hver node kunne dele PCI-enheter i samtidig forespørselsmodus. For eksempel, hvis det er en disk koblet til bussen, er den tilgjengelig for alle noder. Vi begynte å se etter PCI-svitsjer med multi-host-støtte og fant ut at ingen av dem tilfredsstilte kravene våre. Alle disse løsningene var stort sett begrenset til 1 vert eller flere verter, men uten modusen for samtidige forespørsler til endepunkter. Det andre problemet er den høye kostnaden på $50 eller mer per brikke. I V2 bestemte vi oss for å utsette eksperimenter med PCI-svitsjer (vi kommer tilbake til dem senere etter hvert som vi utvikler) og gikk langs veien med å tildele en rolle for hver node: de to første nodene eksponerte mini PCI-ekspressport per node, den tredje noden eksponert 2-porter 6 Gbps SATA-kontroller . For å få tilgang til disker fra andre noder, kan du bruke nettverksfilsystemet i klyngen. Hvorfor ikke?
Sniktitt
Vi bestemte oss for å dele noen skisser av hvordan minimum klyngeblokken har utviklet seg over tid gjennom diskusjon og refleksjon.
Som et resultat kom vi til en klyngeenhet med 4 260-pinners noder, 2 mini PCIe (Gen 2) porter, 2 SATA (Gen 3) porter. Brettet har en Layer-2 Managed Switch med VLAN-støtte. En mini PCIe-port er fjernet fra den første noden, hvor du kan installere et nettverkskort og få en annen Ethernet-port eller 5G-modem og lage en ruter for nettverket på klyngen og Ethernet-portene fra den første noden.
Klyngebussen har flere funksjoner, inkludert muligheten til å flashe moduler direkte gjennom alle spor og selvfølgelig FAN-kontakter på hver node med hastighetskontroll.
Søknad
Edge-infrastruktur for selvvertsbaserte applikasjoner og tjenester
Vi utformet V2 for å være minimumsbyggesteinen for en forbruker/kommersiell infrastruktur. Med V2 er det billig å starte proof-of-concept og skalere etter hvert som du vokser, og gradvis portere applikasjoner som er mer kostnadseffektive og praktiske å hoste på kanten. Klyngeblokker kan kobles sammen for å bygge større klynger. Dette kan gjøres gradvis uten stor risiko for etablert
prosesser. Allerede i dag er det et stort antall søknader for bedrifter, .
ARM arbeidsstasjon
Med opptil 32 GB RAM per klynge kan den første noden brukes for skrivebordsversjonen av operativsystemet (for eksempel Ubuntu Desktop 20.04 LTS) og de resterende 3 nodene for kompilering, testing og feilsøkingsoppgaver, utvikling av skybaserte løsninger for ARM klynger. Som en node for CI / CD på ARM edge infrastruktur i prod.
Turing V2-klynge med CM4-moduler er nesten identisk arkitektonisk (forskjell i mindre versjoner av ARMv8) med klynge basert på AWS Graviton-forekomster. CM4-modulprosessoren bruker ARMv8-arkitekturen slik at du kan bygge bilder og applikasjoner for AWS Graviton 1- og 2-forekomster, som er kjent for å være mye billigere enn x86-forekomster.
Kilde: www.habr.com