Lagringslösningar i Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Uppdatering!. I kommentarerna föreslog en av läsarna att jag skulle prova Linstor (kanske arbetar han själv med det), så jag la till en sektion om denna lösning. Jag skrev också ett inlägg om hur man installerar det, eftersom processen skiljer sig mycket från de andra.

Om jag ska vara ärlig gav jag upp och avstod från Kubernetes (åtminstone för tillfället). Jag kommer att använda Heroku. Varför? På grund av lagring! Vem kunde tro att jag skulle pyssla mer med lagringslösningar än med Kubernetes själv. Jag använder Hetzner Cloud, eftersom det är prisvärt och prestandan är bra, och jag har från början distribuerat kluster med hjälp av Rancher. Jag har inte provat de hanterade Kubernetes-tjänsterna från Google/Amazon/Microsoft/DigitalOcean och så vidare, eftersom jag ville lära mig allt själv. Och dessutom är jag sparsam.

Så ja, jag har lagt ner mycket tid på att försöka bestämma vilken lagring jag skulle välja när jag planerade den möjliga stacken för Kubernetes. Jag föredrar lösningar med öppen källkod, inte bara på grund av priset, men jag har också undersökt ett par betalda alternativ av nyfikenhet, eftersom de har gratisversioner med begränsningar. Jag noterade några siffror från de senaste testerna när jag jämförde olika alternativ, och de kan intressera dem som studerar lagring i Kubernetes. Även om jag personligen har sagt adjö till Kubernetes för tillfället. Jag vill också nämna CSI-drivrutinen, där man direkt kan förbereda volymer i Hetzner Cloud, men jag har inte provat den än. Jag har undersökt molnbaserade programvarudefinierade lagringslösningar, eftersom jag behövde replikering och möjlighet att snabbt ansluta permanenta volymer på vilken nod som helst, särskilt i händelse av nodfel och liknande situationer. Vissa lösningar erbjuder snapshots vid en viss tidpunkt och off-site säkerhetskopior, vilket är praktiskt.

Jag har testat 6–7 lagringslösningar:

OpenEBS

Som jag nämnde i det föregående inlägget, efter att ha testat de flesta alternativ från listan, valde jag först OpenEBS. OpenEBS är väldigt enkelt att installera och använda, men ärligt talat, efter tester med verkliga data under belastning, blev jag besviken på dess prestanda. Det är öppen källkod, och utvecklarna är på sin Slack-kanal de har alltid varit till mycket hjälp när jag har behövt assistans. Tyvärr har den mycket låg prestanda jämfört med andra alternativ, så jag var tvungen att göra testerna på nytt. Just nu har OpenEBS 3 lagringsmotorn, men jag publicerar benchmarkresultaten för cStor. Jag har ännu inga siffror för Jiva och LocalPV.

Kort sagt, Jiva är lite snabbare, och LocalPV är verkligen snabb, inte sämre än benchmarken direkt från disken. Problemet med LocalPV är att åtkomsten bara kan fås på den nod där den har förberetts, och det finns ingen replikering. Jag hade vissa problem med att återställa säkerhetskopior genom Velero på den nya klustret eftersom namnen på noderna skilde sig åt. När det gäller säkerhetskopior har cStor en plugin för Velero, som kan göra off site säkerhetskopior av snapshot vid en viss tidpunkt, vilket är bekvämare än säkerhetskopior på filnivå med Velero-Restic. Jag har skrivit några skript, för att enklare hantera säkerhetskopior och återställningar med denna plugin. Sammanfattningsvis gillar jag OpenEBS mycket, men dess prestanda…

Rook

Rook har också öppen källkod, och det skiljer sig från de andra alternativen på listan genom att det är en lagringsorkestrator som utför komplexa uppgifter för lagringshantering med olika backend, exempelvis Ceph, EdgeFS och andra, vilket avsevärt förenklar arbetet. Jag hade problem med EdgeFS när jag testade det för några månader sedan, så jag testade främst med Ceph. Ceph erbjuder inte bara blocklagring utan också objektslagring som är kompatibel med S3/Swift och ett distribuerat filsystem. Vad jag gillar med Ceph är möjligheten att sprida data över flera diskar så att volymen kan använda mer diskutrymme än vad som får plats på en enda disk. Det är praktiskt. En annan bra funktion är när du lägger till diskar i klustret, så omfördelar den automatiskt data över alla diskar.

Ceph har snapshots, men såvitt jag vet kan de inte användas direkt i Rook/Kubernetes. Dock har jag inte grävt djupare i det. Men det finns inga off-site-backups, så det blir nödvändigt att använda något som Velero/Restic, men de erbjuder bara filnivå-backups, inte snapshots vid en viss tidpunkt. Dessutom gillade jag verkligen hur enkelt det är att arbeta med Ceph i Rook – det döljer nästan alla komplicerade grejer och erbjuder verktyg för att kommunicera med Ceph direkt för felsökning. Tyvärr uppstod alltid detta problem, vilket gör att Ceph blir instabilt. Än så länge är det oklart om det är en bugg i Ceph själv eller ett problem med hur Rook hanterar Ceph. Jag har lekt med minnesinställningarna, och det blev bättre, men problemet är inte helt löst. Ceph har bra prestanda, som syns i benchmarksen nedan. Dessutom har den en bra övervakningspanel.

Rancher Longhorn

Jag gillar Longhorn mycket. Jag tycker att det är en lovande lösning. Utvecklarna själva (Rancher Labs) erkänner dock att det ännu inte är klart för produktionsmiljö, och det märks. Det har öppen källkod och hyfsad prestanda (även om de ännu inte har arbetat med att optimera den), men volymerna ansluter sig väldigt långsamt till podden, och i värsta fall tar det 15–16 minuter, särskilt efter återställning av en stor backup eller uppgradering av arbetsbelastningen. Det har snapshots och off-site-backups av dessa snapshots, men de gäller endast volymer, så du kommer fortfarande att behöva något som Velero för backup av de andra resurserna. Backups och återställningar är mycket pålitliga, men obscena långsamma. Seriöst, de är bara absurt långsamma. Användningen av CPU-resurser och systembelastningen skjuter ofta i höjden när man arbetar med medelstora datamängder i Longhorn. Det finns en användarvänlig övervakningspanel för att hantera Longhorn. Jag har redan sagt att jag gillar Longhorn, men det behöver verkligen förbättras.

StorageOS

StorageOS är den första betalprodukten i listan. Den har en utvecklarversion med ett begränsat storlek på hanterat lagringsutrymme på 500 GB, men antalet noder verkar inte vara begränsat. I försäljningsavdelningen sa de att kostnaden börjar från $125 per månad för 1 TB, om jag minns rätt. Det finns en grundläggande övervakningspanel och en användarvänlig CLI, men prestandan är märklig: i vissa benchmarks är den helt acceptabel, men i stresstesterna var hastigheten inte alls tillfredsställande. Så jag vet inte vad jag ska säga. Därför har jag inte granskat det särskilt noga. Här finns inga off-site-backuper, och man måste också använda Velero med Restic för att säkerhetskopiera volymer. Konstigt, eftersom produkten är betalad. Dessutom verkade utvecklarna inte vara särskilt intresserade av att kommunicera på Slack.

Robin

Jag hörde om Robin på Reddit från deras tekniska chef. Jag hade aldrig hört talas om det tidigare. Kanske för att jag sökte gratislösningar, medan Robin är betald. De har en ganska generös gratisversion med 10 TB lagring och tre noder. Generellt är produkten mycket bra och har trevliga funktioner. Det finns en utmärkt CLI, men det bästa är att man kan ta snapshots och säkerhetskopiera hela applikationen (i resursväljaren kallas detta för Helm-releaser eller "flex apps"), inklusive volymer och andra resurser, så att man kan klara sig utan Velero. Och allt skulle vara fantastiskt om det inte vore för en liten detalj: om man ska återställa (eller "importera", som det kallas i Robin) applikationen på en ny kluster – till exempel i händelse av katastrofåterställning – så fungerar återställningen, men man kan tyvärr inte fortsätta med säkerhetskopieringen av applikationen. I denna release är det helt enkelt omöjligt, och utvecklarna har bekräftat detta. Det ä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 allt kommer att åtgärdas i nästa release. Prestandan är överlag bra, men jag märkte en avvikelse: om man kör en benchmark direkt på volymen som är ansluten till värden, så är läshastigheten mycket högre än på samma volym inuti podden. Alla andra resultat är identiska, men teoretiskt sett borde det inte finnas någon skillnad. Även om de arbetar på det här, blev jag besviken över problemet med återställning och säkerhetskopiering – jag kände att jag äntligen hade hittat en lämplig lösning, och jag var till och med redo att betala för den när jag behövde mer utrymme eller fler servrar.

Portworx

Här har jag inte mycket att säga. Det här är en betald produkt, både imponerande och dyr. Prestandan är fantastisk. Hittills är detta den bästa indikatorn. I Slack fick jag veta att priset börjar från $205 per månad för en nod, enligt vad som anges i Google GKE Marketplace. Jag vet inte om det blir billigare om man köper direkt. Hur som helst, jag har inte råd med det, så jag blev mycket besviken över att utvecklarlicensen (upp till 1 TB och 3 noder) är praktiskt taget värdelös med Kubernetes, om man inte är nöjd med statisk beredning. Jag hoppades att företagslicensen automatiskt skulle sänkas till utvecklarlicens vid slutet av provperioden, men så blev det inte. Utvecklarlicensen kan endast användas direkt med Docker, och att ställa in det i Kubernetes är mycket besvärligt och begränsat. Jag föredrar självklart öppen källkod, men om jag hade pengarna skulle jag absolut välja Portworx. Hittills kan dess prestanda helt enkelt inte jämföras med andra alternativ.

Linstor

Jag lade till denna del efter att inlägget publicerades, när en läsare föreslog att jag skulle testa Linstor. Jag provade det och gillade det! Men det finns mer att utforska. Just nu kan jag säga att prestandan är ganska bra (benchmarkresultaten är tillagda nedan). I grund och botten fick jag samma prestanda som för disken direkt, helt utan förluster. (Fråga inte varför Portworx har bättre siffror än benchmarken för disken direkt. Jag har ingen aning. Magi, kanske.) Så Linstor verkar för närvarande mycket effektivt. Att installera det är inte precis svårt, men inte så enkelt som andra alternativ. Först var jag tvungen att installera Linstor (kernmodul och verktyg/tjänster) och konfigurera LVM för thin provisioning och snapshotstöd 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 att jag var tvungen att använda Ubuntu. Det är inte farligt, förstås, men lite frustrerande, eftersom dokumentationen (som för övrigt är utmärkt) nämner flera paket som är omöjliga att hitta i de angivna Epel-repositories. I Linstor finns det snapshots, men inga off-site säkerhetskopior, så här var jag tvungen att använda Velero med Restic för att säkerhetskopiera volymer. Jag skulle föredra snapshots istället för filsystemnivå-säkerhetskopior, men det går att leva med om lösningen är prestandamässig och pålitlig. Linstor är öppen källkod, men det finns 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 det behöver bekräftas. Jag vet inte hur väl Linstor är testat för Kubernetes, men själva lagringsnivån ligger utanför Kubernetes och, som det verkar, har lösningen funnits ett tag, så den har nog testats i praktiken. Finns det en lösning här som får mig att tänka om och återvända till Kubernetes? Jag vet inte, jag vet inte. Jag behöver utforska mer, studera replikering. Vi får se. Men det första intrycket är bra. Jag skulle helt klart föredra att använda mina egna Kubernetes-kluster istället för Heroku för att få mer frihet och lära mig nytt. Eftersom Linstor inte installeras lika enkelt som andra, kommer jag snart att skriva ett inlägg om det.

Benchmarking

Tyvärr har jag sparat få jämförelsetal eftersom jag inte trodde att jag skulle skriva om detta. Jag har endast resultaten från grundläggande fio-benchmarktester och bara för kluster med en nod, så jag har inga siffror för replikerade konfigurationer ännu. Men baserat på dessa resultat kan man få en ungefärlig uppfattning om vad man kan förvänta sig av varje alternativ, eftersom jag jämförde dem på identiska molnservrar, 4 kärnor, 16 GB RAM, med en extra 100 GB disk för de testade volymerna. Jag körde benchmarktester 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 så att ni får en allmän uppfattning. I andra tester kopierade jag 38 GB bilder och videor mellan volymen för att testa läs- och skrivprestanda, men tyvärr har jag inte sparat siffrorna. Kort sagt, Portworx var mycket snabbare.

För volymbenchmarken använde jag denna manifestfil:

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: 4

Först skapade jag en volym med motsvarande lagringsklass och sedan körde jag en uppgift med fio i bakgrunden. Jag valde 1 GB för att uppskatta prestandan och inte behöva vänta för länge. Här är resultaten:

Jag har markerat det bästa värdet för varje mätning i grönt och det sämsta i rött.

Slutsats

Som ni kan se presterade Portworx generellt bättre än de andra. Men för mig är det dyrt. Jag vet inte vad Robin kostar, men de har en utmärkt gratisversion, så om du behöver en betald produkt kan du prova (hoppas de snart löser problemet med återställning och backup). Av de tre gratisalternativen har jag haft minst problem med OpenEBS, men dess prestanda är undermålig. Tyvärr har jag inte sparat fler resultat, men jag hoppas att de siffror och kommentarer jag har kan hjälpa er.

Källa: habr.com