Opdatering!. I kommentarerne foreslog en af læserne at prøve (måske han selv arbejder på det) så jeg har tilføjet et afsnit om denne løsning. Jeg skrev også , fordi processen er meget anderledes end resten.
For at være ærlig gav jeg op og gav op (i hvert fald indtil videre). jeg vil bruge . Hvorfor? På grund af opbevaring! Hvem havde troet, at jeg ville pille mere med opbevaring end med selve Kubernetes. jeg bruger fordi det er billigt og ydeevnen er god, og lige fra begyndelsen har jeg installeret klynger vha . Jeg prøvede ikke administrerede Kubernetes-tjenester fra Google/Amazon/Microsoft/DigitalOcean osv. osv., fordi jeg ville lære alt selv. Jeg er også nøjsom.
Så ja, jeg brugte meget tid på at beslutte, hvilket lager jeg skulle vælge, da jeg evaluerede en mulig Kubernetes-stak. Jeg foretrækker open source-løsninger, ikke kun på grund af prisen, men jeg har kigget på et par betalte muligheder af nysgerrighed, fordi de har gratis versioner med begrænsninger. Jeg har noteret nogle tal fra de seneste tests, da jeg sammenlignede forskellige muligheder, og de kan være interessante for dem, der lærer om Kubernetes-lagring. Selvom jeg personligt har sagt farvel til Kubernetes for nu. Jeg vil også nævne , som direkte kan levere Hetzner Cloud-volumener, men jeg har ikke prøvet det endnu. Jeg undersøgte cloud-software-defineret storage, fordi jeg havde brug for replikering og evnen til hurtigt at montere vedvarende volumener på enhver node, især i tilfælde af nodefejl og andre lignende situationer. Nogle løsninger tilbyder øjebliksbilleder og sikkerhedskopier uden for stedet, hvilket er praktisk.
Jeg testede 6-7 lagringsløsninger:
Som jeg allerede har sagt Efter at have testet de fleste af mulighederne fra listen, slog jeg mig til at begynde med med OpenEBS. OpenEBS er meget let at installere og bruge, men for at være ærlig, efter at have testet med rigtige data under belastning, var jeg skuffet over dens ydeevne. Dette er open source, og udviklerne er på egen hånd altid meget hjælpsom, når jeg havde brug for hjælp. Desværre har den meget dårlig ydeevne sammenlignet med andre muligheder, så testene måtte køres igen. OpenEBS har i øjeblikket 3 lagringsmotorer, men jeg poster benchmarkresultater for cStor. Jeg har endnu ikke tal for Jiva og LocalPV.
I en nøddeskal er Jiva lidt hurtigere, og LocalPV er generelt hurtig, ikke værre end diskbenchmark direkte. Problemet med LocalPV er, at volumenet kun kan tilgås på den node, hvor det blev forberedt, og der er ingen replikering overhovedet. Jeg havde nogle problemer med at gendanne en sikkerhedskopi via på en ny klynge, fordi nodenavnene var anderledes. Hvis vi taler om sikkerhedskopier, har cStor , hvormed du kan lave sikkerhedskopier uden for stedet af snapshots på et tidspunkt, hvilket er mere praktisk end sikkerhedskopier på filniveau med Velero-Restic. jeg skrev , for at gøre det nemmere at administrere sikkerhedskopier og gendannelser med dette plugin. Generelt kan jeg virkelig godt lide OpenEBS, men dens ydeevne...
Rook er også open source og adskiller sig fra resten af mulighederne på listen ved, at det er en storage orkestrator, der udfører komplekse storage management opgaver med forskellige backends, f.eks. , og andre, hvilket i høj grad forenkler arbejdet. Jeg havde problemer med EfgeFS, da jeg prøvede det for et par måneder siden, så jeg testede hovedsageligt med Ceph. Ceph tilbyder ikke kun bloklagring, men også objektlagring kompatibel med S3/Swift og distribueret filsystem. Det, jeg godt kan lide ved Ceph, er evnen til at sprede volumendata over flere diske, så diskenheden kan bruge mere diskplads, end der kan være på en enkelt disk. Det er praktisk. En anden fed funktion er, at når du tilføjer diske til en klynge, omdistribuerer den automatisk data på tværs af alle diske.
Ceph har snapshots, men så vidt jeg ved kan de ikke bruges direkte i Rook/Kubernetes. Sandt nok gik jeg ikke dybt ind i dette. Men der er ingen sikkerhedskopier på stedet, så du bliver nødt til at bruge noget med Velero/Restic, men der er kun sikkerhedskopier på filniveau, ikke øjebliksbilleder. Det, jeg virkelig kunne lide ved Rook, var, hvor nemt det er at arbejde med Ceph - det skjuler næsten alle de komplicerede ting og tilbyder værktøjer til at tale med Ceph direkte til fejlfinding. Desværre, under stresstesten af Ceph-volumener, blev jeg ved med at have problemer med , hvilket får Ceph til at blive ustabil. Det er endnu ikke klart, om dette er en fejl i selve Ceph eller et problem i den måde, Rook administrerer Ceph på. Jeg puslede med hukommelsesindstillingerne, og det blev bedre, men problemet var ikke helt løst. Ceph har en anstændig ydeevne, som du kan se i benchmarks nedenfor. Den har også et godt dashboard.
Jeg kan virkelig godt lide Longhorn. Efter min mening er dette en lovende løsning. Det er sandt, at udviklerne selv (Rancher Labs) indrømmer, at det endnu ikke er egnet til arbejdsmiljøet, og det viser. Det er open source og har en anstændig ydeevne (selvom de ikke har optimeret den endnu), men lydstyrkerne tager meget lang tid at oprette forbindelse til poden, og i værste tilfælde tager det 15-16 minutter, især efter gendannelse af en stor backup eller opgradering af arbejdsbyrden. Det har snapshots og sikkerhedskopier uden for stedet af disse snapshots, men de gælder kun for volumener, så du skal stadig bruge noget som Velero til at sikkerhedskopiere andre ressourcer. Sikkerhedskopier og gendannelser er meget pålidelige, men uanstændigt langsomme. Seriøst, bare utrolig langsomt. CPU-brug og systembelastning stiger ofte, når der arbejdes med en medium mængde data i Longhorn. Der er et praktisk dashboard til at administrere Longhorn. Jeg har allerede sagt, at jeg godt kan lide Longhorn, men det kræver noget arbejde.
StorageOS er det første betalte produkt på listen. Den har en udviklerversion med en begrænset administreret lagerstørrelse på 500 GB, men jeg tror ikke, der er en grænse for antallet af noder. Salgsafdelingen fortalte mig, at prisen starter ved $125 pr. måned for 1 TB, hvis jeg husker rigtigt. Der er et grundlæggende instrumentbræt og en praktisk CLI, men der sker noget mærkeligt med ydeevnen: i nogle benchmarks er det ganske anstændigt, men i volumen-stresstesten kunne jeg slet ikke lide hastigheden. Generelt ved jeg ikke hvad jeg skal sige. Så jeg forstod ikke ret meget. Der er ingen off-site sikkerhedskopier her, og du bliver også nødt til at bruge Velero med Restic til at sikkerhedskopiere volumener. Det er mærkeligt, for produktet er betalt. Og udviklerne var ikke ivrige efter at kommunikere på Slack.
Jeg lærte om Robin på Reddit fra deres tekniske direktør. Jeg havde aldrig hørt om ham før. Måske fordi jeg ledte efter gratis løsninger, men Robin er betalt. De har en ret generøs gratis version med 10 TB lagerplads og tre noder. Generelt er produktet ganske anstændigt og har gode funktioner. Der er en fantastisk CLI, men det fedeste er, at du kan snapshotte og tage backup af hele applikationen (i ressourcevælgeren kaldes dette Helm-udgivelser eller "flex apps"), inklusive volumener og andre ressourcer, så du kan undvære Velero. Og alt ville være vidunderligt, hvis ikke for en lille detalje: Hvis du gendanner (eller "importerer", som det hedder i Robin) en applikation på en ny klynge - for eksempel i tilfælde af genopretning fra en katastrofe - fungerer gendannelsen selvfølgelig, men du kan ikke fortsætte med at sikkerhedskopiere applikationen. Dette er simpelthen ikke muligt i denne udgivelse, som udviklerne har bekræftet. Dette er mildt sagt mærkeligt, især i betragtning af de andre fordele (for eksempel utrolig hurtig backup og gendannelse). Udviklerne lover at rette alt inden den næste udgivelse. Ydeevnen er generelt god, men jeg bemærkede en særhed: Hvis jeg kører benchmark direkte på en diskenhed, der er knyttet til værten, er læsehastigheden meget hurtigere end at køre den samme lydstyrke inde fra poden. Alle andre resultater er identiske, men i teorien burde der ikke være nogen forskel. Selvom de arbejder på det, var jeg ked af problemet med gendannelse og backup - jeg troede, at jeg endelig havde fundet en passende løsning, og jeg var endda villig til at betale for det, når jeg havde brug for mere plads eller flere servere.
Jeg har ikke meget at sige her. Dette er et betalt produkt, lige så cool og dyrt. Præstationen er simpelthen fantastisk. Dette er den bedste indikator indtil videre. Slack fortalte mig, at prisen starter ved $205 pr. måned pr. node, som angivet på Googles GKE Marketplace. Jeg ved ikke, om det bliver billigere, hvis du køber direkte. Det har jeg alligevel ikke råd til, så jeg var meget, meget skuffet over, at udviklerlicensen (op til 1 TB og 3 noder) praktisk talt er ubrugelig med Kubernetes, medmindre du nøjes med statisk klargøring. Jeg håbede, at volumenlicensen automatisk ville nedgradere til udvikler ved slutningen af prøveperioden, men det skete ikke. Udviklerlicensen kan kun bruges direkte med Docker, og konfigurationen i Kubernetes er meget besværlig og begrænset. Jeg foretrækker selvfølgelig open source, men hvis jeg havde pengene, ville jeg helt klart vælge Portworx. Indtil videre kan dens ydeevne simpelthen ikke sammenlignes med andre muligheder.
Jeg tilføjede dette afsnit efter indlægget blev udgivet, da en læser foreslog at prøve Linstor. Jeg prøvede det og kunne lide det! Men jeg er nødt til at undersøge det lidt nærmere. Indtil videre kan jeg sige, at ydeevnen er ret god (jeg har tilføjet benchmarkresultaterne nedenfor). Faktisk fik jeg den samme ydeevne som med et Direct Disk-benchmark, uden overhead. (Spørg ikke hvorfor Portworx' tal er bedre end Direct Disk-benchmarket. Jeg aner det ikke. Magi, tror jeg.) Så Linstor virker meget effektiv indtil videre. Det er ikke ligefrem svært at sætte det op, men det er ikke så nemt som andre muligheder. Først skulle jeg installere Linstor (kernemodul og værktøjer/tjenester) og konfigurere LVM til tynd provisionering og snapshot-understøttelse uden for Kubernetes, direkte på værten, og derefter oprette de ressourcer, der var nødvendige for at bruge lageret fra Kubernetes. Jeg var ikke glad for, at det ikke virkede på CentOS og måtte bruge UbuntuDet er selvfølgelig ikke noget stort problem, men det er lidt irriterende, fordi dokumentationen (som i øvrigt er fremragende) nævner flere pakker, der ikke er tilgængelige i de angivne Epel-repositories. Linstor har snapshots, men ingen off-site backups, så jeg var nødt til at bruge Velero med Restic igen til volumenbackups. Jeg foretrækker snapshots frem for filniveaubackups, men det er acceptabelt, hvis løsningen er effektiv og pålidelig. Linstor er open source, men der er betalt support. Hvis jeg forstår det korrekt, kan du bruge det uden begrænsninger, selvom du ikke har en supportkontrakt, men det bliver jeg nødt til at tjekke ud. Jeg ved ikke, hvor testet Linstor er til Kubernetes, men selve lagringslaget ligger uden for Kubernetes, og det ser ud til, at det har eksisteret i et stykke tid, så det er sandsynligvis allerede blevet testet under virkelige forhold. Er der en løsning her, der ville få mig til at ændre mening og skifte tilbage til Kubernetes? Jeg ved det ikke. Jeg er nødt til at undersøge det lidt bedre og lære om replikering. Vi får se. Men førstehåndsindtrykket er godt. Jeg ville helt sikkert foretrække at bruge mine egne Kubernetes-klynger i stedet for Heroku for at få mere frihed og for at lære nye ting. Da Linstor ikke er så nem at installere som andre, skriver jeg et indlæg om det snart.
Benchmarks
Desværre førte jeg ikke mange noter om sammenligningen, fordi jeg ikke troede, jeg ville skrive om den. Jeg har kun resultater fra de grundlæggende fio-benchmarks og kun for enkelte node-klynger, så jeg har ikke tal for replikerede konfigurationer endnu. Men fra disse resultater kan du få en nogenlunde idé om, hvad du kan forvente af hver mulighed, fordi jeg sammenlignede dem på de samme cloud-servere, 4 kerner, 16 GB RAM, med en ekstra 100 GB disk til de testede mængder. Jeg kørte benchmarks tre gange for hver løsning og beregnede det gennemsnitlige resultat, plus jeg nulstillede serverindstillingerne for hvert produkt. Det hele er fuldstændig uvidenskabeligt, bare for at give dig en generel idé. I andre test kopierede jeg 38 GB fotos og videoer fra volumen og testede læsning og skrivning, men desværre gemte jeg ikke tallene. Kort sagt: Portworkx var meget hurtigere.
Til volumenbenchmark brugte jeg dette 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: 4Jeg oprettede først et bind med den passende opbevaringsklasse og kørte derefter jobbet med fio bag kulisserne. Jeg tog 1 GB for at vurdere ydeevnen og ikke vente for længe. Her er resultaterne:
Jeg har fremhævet den bedste værdi for hver metrik i grøn og den dårligste i rød.
Konklusion
Som du kan se, klarede Portworx sig i de fleste tilfælde bedre end andre. Men for mig er det dyrt. Jeg ved ikke, hvor meget Robin koster, men de har en fantastisk gratis version, så hvis du vil have et betalt produkt, kan du prøve det (forhåbentlig løser de problemet med gendannelse og sikkerhedskopier snart). Af de tre gratis, havde jeg de mindste problemer med OpenEBS, men dens ydeevne er afgrundsdyb. Det er ærgerligt, at jeg ikke gemte flere resultater, men jeg håber, at tallene og mine kommentarer vil hjælpe dig.
Kilde: www.habr.com
