Uppdatering!. I kommentarerna föreslog en av lÀsarna att man skulle försöka (kanske han jobbar pÄ det sjÀlv) sÄ jag har lagt till ett avsnitt om den hÀr lösningen. Jag skrev ocksÄ , eftersom processen skiljer sig mycket frÄn resten.
Om jag ska vara Àrlig sÄ gav jag upp och gav upp (Ätminstone för stunden). jag kommer anvÀnda . Varför? PÄ grund av förvaring! Vem hade trott att jag skulle mixtra mer med lagring Àn med sjÀlvaste Kubernetes. jag anvÀnder eftersom det Àr billigt och prestandan Àr bra och jag har redan frÄn början distribuerat kluster med hjÀlp av . Jag provade inte hanterade Kubernetes-tjÀnster frÄn Google/Amazon/Microsoft/DigitalOcean, etc., etc., eftersom jag ville lÀra mig allt sjÀlv. Jag Àr ocksÄ sparsam.
SĂ„ ja, jag tillbringade mycket tid med att försöka bestĂ€mma vilken lagring jag skulle vĂ€lja nĂ€r jag utvĂ€rderade en möjlig Kubernetes-stack. Jag föredrar lösningar med öppen kĂ€llkod, inte bara pĂ„ grund av priset, utan jag har tittat pĂ„ ett par betalalternativ av nyfikenhet eftersom de har gratisversioner med begrĂ€nsningar. Jag har skrivit ner nĂ„gra siffror frĂ„n de senaste testerna nĂ€r jag jĂ€mförde olika alternativ, och de kan vara av intresse för dem som lĂ€r sig om Kubernetes-lagring. Ăven om jag personligen har sagt hejdĂ„ till Kubernetes för nu. Jag vill ocksĂ„ nĂ€mna , som direkt kan tillhandahĂ„lla Hetzner Cloud-volymer, men jag har inte provat det Ă€n. Jag tittade pĂ„ molnprogramvarudefinierad lagring eftersom jag behövde replikering och möjligheten att snabbt montera bestĂ€ndiga volymer pĂ„ vilken nod som helst, sĂ€rskilt i fall av nodfel och andra liknande situationer. Vissa lösningar erbjuder ögonblicksbilder och sĂ€kerhetskopiering utanför platsen, vilket Ă€r bekvĂ€mt.
Jag testade 6-7 lagringslösningar:
Som jag redan sa Efter att ha testat de flesta alternativen frÄn listan bestÀmde jag mig först för OpenEBS. OpenEBS Àr vÀldigt lÀtt att installera och anvÀnda, men för att vara Àrlig, efter att ha testat med riktig data under belastning, blev jag besviken pÄ dess prestanda. Detta Àr öppen kÀllkod, och utvecklarna Àr pÄ egen hand alltid till stor hjÀlp nÀr jag behövde hjÀlp. TyvÀrr har den mycket dÄlig prestanda jÀmfört med andra alternativ, sÄ testerna var tvungna att köras om. OpenEBS har för nÀrvarande 3 lagringsmotorer, men jag publicerar benchmarkresultat för cStor. Jag har inga nummer för Jiva och LocalPV Àn.
I ett nötskal, Jiva Ă€r lite snabbare, och LocalPV Ă€r generellt snabb, inte sĂ€mre Ă€n diskens benchmark direkt. Problemet med LocalPV Ă€r att volymen endast kan nĂ„s pĂ„ noden dĂ€r den förbereddes, och det finns ingen replikering alls. Jag hade nĂ„gra problem med att Ă„terstĂ€lla en sĂ€kerhetskopia via pĂ„ ett nytt kluster eftersom nodnamnen var annorlunda. Om vi ââpratar om sĂ€kerhetskopior sĂ„ har cStor , med vilken du kan göra sĂ€kerhetskopior utanför platsen av ögonblicksbilder vid en tidpunkt, vilket Ă€r bekvĂ€mare Ă€n sĂ€kerhetskopior pĂ„ filnivĂ„ med Velero-Restic. jag skrev , för att göra det enklare att hantera sĂ€kerhetskopior och Ă„terstĂ€llningar med denna plugin. Sammantaget gillar jag verkligen OpenEBS, men dess prestanda...
Rook Àr ocksÄ öppen kÀllkod och skiljer sig frÄn resten av alternativen pÄ listan genom att det Àr en lagringsorkestrator som utför komplexa lagringshanteringsuppgifter med olika backends, t.ex. , och andra, vilket avsevÀrt förenklar arbetet. Jag hade problem med EfgeFS nÀr jag provade det för nÄgra mÄnader sedan, sÄ jag testade frÀmst med Ceph. Ceph erbjuder inte bara blocklagring, utan Àven objektlagring kompatibel med S3/Swift och distribuerade filsystem. Det jag gillar med Ceph Àr möjligheten att sprida volymdata över flera diskar sÄ att volymen kan anvÀnda mer diskutrymme Àn vad som fÄr plats pÄ en enda disk. Det Àr bekvÀmt. En annan cool funktion Àr att nÀr du lÀgger till diskar i ett kluster omfördelar det automatiskt data över alla diskar.
Ceph har ögonblicksbilder, men sĂ„ vitt jag vet kan de inte anvĂ€ndas direkt i Rook/Kubernetes. Det Ă€r sant, jag gick inte djupt in pĂ„ det hĂ€r. Men det finns inga externa sĂ€kerhetskopior, sĂ„ du mĂ„ste anvĂ€nda nĂ„got med Velero/Restic, men det finns bara sĂ€kerhetskopior pĂ„ filnivĂ„, inte ögonblicksbilder. Det jag verkligen gillade med Rook var hur lĂ€tt det Ă€r att arbeta med Ceph â den döljer nĂ€stan alla komplicerade saker och erbjuder verktyg för att prata med Ceph direkt för felsökning. TyvĂ€rr, under stresstestet av Ceph volymer, fortsatte jag att ha problem med , vilket gör att Ceph blir instabil. Det Ă€r Ă€nnu inte klart om detta Ă€r en bugg i Ceph sjĂ€lv eller ett problem i hur Rook hanterar Ceph. Jag mixtrade med minnesinstĂ€llningarna och det blev bĂ€ttre, men problemet var inte helt löst. Ceph har hyfsad prestanda, som du kan se i riktmĂ€rkena nedan. Den har ocksĂ„ en bra instrumentpanel.
Jag gillar verkligen Longhorn. Enligt min mening Àr detta en lovande lösning. Det Àr sant att utvecklarna sjÀlva (Rancher Labs) erkÀnner att det Ànnu inte Àr lÀmpligt för arbetsmiljön, och det mÀrks. Det Àr öppen kÀllkod och har hyfsad prestanda (Àven om de inte har optimerat det Ànnu), men volymerna tar vÀldigt lÄng tid att ansluta till podden, och i vÀrsta fall tar det 15-16 minuter, sÀrskilt efter att en stor sÀkerhetskopia eller uppgradering av arbetsbelastningen. Den har ögonblicksbilder och sÀkerhetskopior utanför platsen av dessa ögonblicksbilder, men de gÀller bara för volymer, sÄ du behöver fortfarande nÄgot som Velero för att sÀkerhetskopiera andra resurser. SÀkerhetskopieringar och ÄterstÀllningar Àr mycket pÄlitliga, men anstÀndigt lÄngsamma. Seriöst, bara otroligt lÄngsamt. CPU-anvÀndning och systembelastning ökar ofta nÀr man arbetar med en medelstor mÀngd data i Longhorn. Det finns en bekvÀm instrumentpanel för att hantera Longhorn. Jag har redan sagt att jag gillar Longhorn, men det krÀvs lite arbete.
StorageOS Àr den första betalda produkten pÄ listan. Den har en utvecklarversion med en begrÀnsad hanterad lagringsstorlek pÄ 500 GB, men jag tror inte att det finns nÄgon grÀns för antalet noder. FörsÀljningsavdelningen berÀttade för mig att kostnaden börjar pÄ $125 per mÄnad för 1 TB, om jag minns rÀtt. Det finns en grundlÀggande instrumentbrÀda och en bekvÀm CLI, men nÄgot konstigt pÄgÄr med prestandan: i vissa riktmÀrken Àr den ganska anstÀndig, men i volymstresstestet gillade jag inte hastigheten alls. I allmÀnhet vet jag inte vad jag ska sÀga. SÄ jag förstod inte sÄ mycket. Det finns inga externa sÀkerhetskopior hÀr och du mÄste ocksÄ anvÀnda Velero med Restic för att sÀkerhetskopiera volymer. Det Àr konstigt, eftersom produkten Àr betald. Och utvecklarna var inte ivriga att kommunicera pÄ Slack.
Jag lĂ€rde mig om Robin pĂ„ Reddit frĂ„n deras tekniska chef. Jag hade aldrig hört talas om honom förut. Kanske för att jag letade efter gratislösningar, men Robin fĂ„r betalt. De har en ganska generös gratisversion med 10 TB lagringsutrymme och tre noder. Sammantaget Ă€r produkten ganska anstĂ€ndig och har fina funktioner. Det finns en fantastisk CLI, men det coolaste Ă€r att du kan ta en ögonblicksbild och sĂ€kerhetskopiera hela applikationen (i resursvĂ€ljaren kallas detta Helm-releaser eller "flex-appar"), inklusive volymer och andra resurser, sĂ„ att du kan klara dig utan Velero. Och allt skulle vara underbart om inte för en liten detalj: om du Ă„terstĂ€ller (eller "importerar", som det kallas i Robin) en applikation pĂ„ ett nytt kluster - till exempel i hĂ€ndelse av Ă„terhĂ€mtning frĂ„n en katastrof - Ă„terstĂ€llandet, naturligtvis fungerar, men fortsĂ€tt att sĂ€kerhetskopiera programmet det Ă€r förbjudet. Detta Ă€r helt enkelt inte möjligt i den hĂ€r utgĂ„van, som utvecklarna har bekrĂ€ftat. Detta Ă€r milt sagt konstigt, sĂ€rskilt med tanke pĂ„ de andra fördelarna (till exempel otroligt snabba sĂ€kerhetskopieringar och Ă„terstĂ€llningar). Utvecklarna lovar att fixa allt till nĂ€sta release. Prestandan Ă€r generellt sett bra, men jag mĂ€rkte en mĂ€rklighet: om jag kör riktmĂ€rket direkt pĂ„ en volym som Ă€r ansluten till vĂ€rden Ă€r lĂ€shastigheten mycket snabbare Ă€n att köra samma volym inifrĂ„n podden. Alla andra resultat Ă€r identiska, men i teorin borde det inte vara nĂ„gon skillnad. Ăven om de jobbar pĂ„ det, var jag upprörd över problemet med Ă„terstĂ€llning och sĂ€kerhetskopiering - jag trodde att jag Ă€ntligen hade hittat en lĂ€mplig lösning, och jag var till och med villig att betala för det nĂ€r jag behövde mer utrymme eller fler servrar.
Jag har inte mycket att sÀga hÀr. Detta Àr en betalprodukt, lika cool och dyr. Prestandan Àr helt enkelt fantastisk. Detta Àr den bÀsta indikatorn hittills. Slack berÀttade för mig att prissÀttningen börjar pÄ $205 per mÄnad per nod, enligt Googles GKE Marketplace. Jag vet inte om det blir billigare om man köper direkt. Jag har inte rÄd med det i alla fall, sÄ jag blev vÀldigt, vÀldigt besviken över att utvecklarlicensen (upp till 1 TB och 3 noder) praktiskt taget Àr vÀrdelös med Kubernetes om du inte nöjer dig med statisk provisionering. Jag hoppades att volymlicensen automatiskt skulle nedgraderas till utvecklare i slutet av testperioden, men sÄ blev det inte. Utvecklarlicensen kan endast anvÀndas direkt med Docker, och konfigurationen i Kubernetes Àr mycket krÄnglig och begrÀnsad. SjÀlvklart föredrar jag öppen kÀllkod, men om jag hade pengarna skulle jag definitivt vÀlja Portworx. Hittills kan dess prestanda helt enkelt inte jÀmföras med andra alternativ.
Jag lade till det hÀr avsnittet efter att inlÀgget publicerades, nÀr en lÀsare föreslog att man skulle prova Linstor. Jag testade det och gillade det! Men jag behöver grÀva lite mer. För tillfÀllet kan jag sÀga att prestandan Àr ganska bra (jag har lagt till benchmarkresultaten nedan). Faktum Àr att jag fick samma prestanda som med ett direktdiskbenchmark, utan nÄgon overhead. (FrÄga inte varför Portworx siffror Àr bÀttre Àn direktdiskbenchmarket. Jag har ingen aning. Magi, antar jag.) SÄ, Linstor verkar vÀldigt effektiv hittills. Att installera det Àr inte direkt svÄrt, men det Àr inte lika enkelt som andra alternativ. Först var jag tvungen att installera Linstor (kÀrnemodul och verktyg/tjÀnster) och konfigurera LVM för tunn provisionering och snapshot-stöd utanför Kubernetes, direkt pÄ vÀrden, och sedan skapa de resurser som behövs för att anvÀnda lagringen frÄn Kubernetes. Jag var inte glad att det inte fungerade pÄ CentOS och var tvungen att anvÀnda UbuntuDet Àr förstÄs ingen stor grej, men det Àr lite irriterande eftersom dokumentationen (som för övrigt Àr utmÀrkt) nÀmner flera paket som inte Àr tillgÀngliga i de angivna Epel-repositorierna. Linstor har snapshots, men inga externa sÀkerhetskopior, sÄ jag var tvungen att anvÀnda Velero med Restic igen för volymsÀkerhetskopior. Jag föredrar snapshots framför sÀkerhetskopior pÄ filnivÄ, men det Àr tolererbart om lösningen Àr effektiv och tillförlitlig. Linstor Àr öppen kÀllkod, men det finns betald support. Om jag förstÄr det rÀtt kan du anvÀnda det utan begrÀnsningar Àven om du inte har ett supportavtal, men jag skulle behöva kolla upp det. Jag vet inte hur testad Linstor Àr för Kubernetes, men sjÀlva lagringslagret ligger utanför Kubernetes, och det ser ut som att det har funnits ett tag, sÄ det har förmodligen redan testats under verkliga förhÄllanden. Finns det en lösning hÀr som skulle fÄ mig att Àndra mig och byta tillbaka till Kubernetes? Jag vet inte. Jag behöver grÀva runt lite mer och lÀra mig om replikering. Vi fÄr se. Men det första intrycket Àr bra. Jag skulle definitivt föredra att anvÀnda mina egna Kubernetes-kluster istÀllet för Heroku för mer frihet och för att lÀra mig nya saker. Eftersom Linstor inte Àr lika lÀtt att installera som andra, kommer jag att skriva ett inlÀgg om det snart.
RiktmÀrken
TyvÀrr förde jag inte mÄnga anteckningar om jÀmförelsen eftersom jag inte trodde att jag skulle skriva om den. Jag har bara resultat frÄn de grundlÀggande fio-riktmÀrkena och endast för enstaka nodkluster, sÄ jag har inga siffror för replikerade konfigurationer Àn. Men frÄn dessa resultat kan du fÄ en ungefÀrlig uppfattning om vad du kan förvÀnta dig av varje alternativ, eftersom jag jÀmförde dem pÄ samma molnservrar, 4 kÀrnor, 16 GB RAM, med ytterligare 100 GB disk för de testade volymerna. Jag körde riktmÀrkena tre gÄnger för varje lösning och berÀknade det genomsnittliga resultatet, plus att jag ÄterstÀllde serverinstÀllningarna för varje produkt. Allt detta Àr helt ovetenskapligt, bara för att ge dig en allmÀn uppfattning. I andra tester kopierade jag 38 GB foton och videor frÄn volymen för att testa lÀsning och skrivning, men tyvÀrr sparade jag inte siffrorna. Kort sagt: Portworkx var mycket snabbare.
För volymriktmÀrket anvÀnde jag detta manifest:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: dbench
spec:
storageClassName: ...
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
name: dbench
spec:
template:
spec:
containers:
- name: dbench
image: sotoaster/dbench:latest
imagePullPolicy: IfNotPresent
env:
- name: DBENCH_MOUNTPOINT
value: /data
- name: FIO_SIZE
value: 1G
volumeMounts:
- name: dbench-pv
mountPath: /data
restartPolicy: Never
volumes:
- name: dbench-pv
persistentVolumeClaim:
claimName: dbench
backoffLimit: 4Jag skapade först en volym med lÀmplig lagringsklass och körde sedan jobbet med fio bakom kulisserna. Jag tog 1 GB för att uppskatta prestandan och inte vÀnta för lÀnge. HÀr Àr resultaten:
Jag har markerat det bÀsta vÀrdet för varje mÀtvÀrde i grönt och det sÀmsta i rött.
Slutsats
Som du kan se presterade Portworx i de flesta fall bÀttre Àn andra. Men för mig Àr det dyrt. Jag vet inte hur mycket Robin kostar, men de har en jÀttebra gratisversion, sÄ om du vill ha en betalprodukt kan du prova den (förhoppningsvis löser de problemet med ÄterstÀllning och sÀkerhetskopiering snart). Av de tre gratis, hade jag minst problem med OpenEBS, men dess prestanda Àr urusel. Det Àr synd att jag inte sparade fler resultat, men jag hoppas att siffrorna och mina kommentarer hjÀlper dig.
KĂ€lla: will.com
