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 publiceringen av inlägget, när en läsare föreslog att prova Linstor. Jag provade det och jag gillade det! Men vi måste fortfarande gräva djupare. Nu kan jag säga att prestandan inte är dålig (jag lade till benchmarkresultaten nedan). I huvudsak fick jag samma prestanda som disken direkt, utan någon overhead. (Fråga inte varför Portworx har bättre siffror än drive-benchmark direkt. Jag har ingen aning. Magi, antar jag.) Så Linstor verkar väldigt effektiv än så länge. Det är inte så svårt att installera, men det är inte lika lätt som andra alternativ. Först var jag tvungen att installera Linstor (kärnmodul och verktyg/tjänster) och konfigurera LVM för tunn provisionering och stöd för ögonblicksbilder utanför Kubernetes, direkt på värden, och sedan skapa de resurser som behövs för att använda lagring från Kubernetes. Jag gillade inte att det inte fungerade på CentOS och jag var tvungen att använda Ubuntu. Inte hemskt förstås, men lite irriterande, eftersom dokumentationen (som för övrigt är utmärkt) nämner flera paket som inte kan hittas i de angivna Epel-förråden. Linstor har ögonblicksbilder, men inte externa säkerhetskopior, så här igen var jag tvungen att använda Velero med Restic för att säkerhetskopiera volymer. Jag skulle föredra ögonblicksbilder istället för säkerhetskopior på filnivå, men detta kan tolereras om lösningen är prestanda och pålitlig. Linstor är öppen källkod men har betald support. Om jag förstår det rätt kan det användas utan begränsningar även om du inte har något supportavtal, men detta behöver förtydligas. Jag vet inte hur testad Linstor är för Kubernetes, men själva lagringslagret ligger utanför Kubernetes och uppenbarligen dök lösningen inte upp igår, så den har förmodligen redan testats under verkliga förhållanden. Finns det en lösning här som får mig att ändra mig och gå tillbaka till Kubernetes? Jag vet inte. Vi behöver fortfarande gräva djupare och studera replikering. Låt oss 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 att få mer frihet och 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