Opdatering!. I kommentarerne foreslog en af læserne at prøve (måske arbejder han selv på det), så jeg har tilføjet et afsnit om den 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 skulle have troet, at jeg ville rode mere med opbevaring end med Kubernetes selv. Jeg bruger , fordi det er billigt og ydeevnen er god, og lige fra starten har jeg installeret klynger med . Jeg har ikke prøvet 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 mig for, hvilket lager jeg skulle vælge, da jeg overvejede en mulig stack på Kubernetes. Jeg foretrækker open source-løsninger, og ikke kun på grund af prisen, men jeg kiggede på et par betalte muligheder af nysgerrighed, fordi de har gratis versioner med begrænsninger. Jeg noterede et par tal fra de seneste benchmarks, da jeg sammenlignede forskellige muligheder, og de kan være interessante for dem, der studerer opbevaring i Kubernetes. Selvom jeg personligt har sagt farvel til Kubernetes indtil videre. Jeg vil også nævne , hvor du 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 sagde , 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, skuffede dens ydeevne mig. Dette er open source, og udviklere 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å jeg var nødt til at køre testene igen. Lige nu har OpenEBS 3 storage-motorer, 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 drevbenchmark direkte. Problemet med LocalPV er, at volumen kun kan tilgås på den node, hvor den blev klargjort, og der er ingen replikering overhovedet. Jeg havde nogle problemer med at gendanne en sikkerhedskopi via på den nye klynge, fordi nodenavnene var forskellige. Apropos sikkerhedskopier, så har cStor , som du kan lave off-site point-in-time snapshot-sikkerhedskopier med, 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, der er 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å én disk. Det er behageligt. En anden fed funktion er, at når du tilføjer diske til klyngen, 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. Indrømmet, jeg har ikke fordybet mig i det. Men der er ingen off-site backups, så du skal bruge noget med Velero / Restic, men der er kun backup på filniveau, ikke punkt-i-tids-øjebliksbilleder. Det, jeg virkelig godt kan lide ved Rook, er dog, at det er nemt at arbejde med Ceph - det skjuler næsten alle de komplekse ting og tilbyder værktøjer til at tale direkte med Ceph til fejlfinding. På stresstesten af Ceph-volumener havde jeg desværre altid , 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, hvordan Rook administrerer Ceph. Jeg rodede med hukommelsesindstillingerne, og det blev bedre, men problemet var ikke helt løst. Ceph har en god præstation som ses i benchmarks nedenfor. Den har også et godt dashboard.
Jeg kan virkelig godt lide Longhorn. Jeg synes, det er en lovende løsning. Sandt nok indrømmer udviklerne selv (Rancher Labs), at det endnu ikke er egnet til et produktionsmiljø, 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 fastgøre til poden, og i værste tilfælde tager det 15-16 minutter, især efter gendannelse af en stor backup eller opgradering af en arbejdsbyrde. Den har snapshots og sikkerhedskopier uden for stedet af disse snapshots, men de gælder kun for volumener, så du har stadig brug for noget som Velero til at sikkerhedskopiere resten af ressourcerne. Sikkerhedskopier og gendannelser er meget pålidelige, men uanstændigt langsomme. Seriøst, bare uoverkommeligt langsom. CPU-brug og systembelastning stiger ofte, når man arbejder med en gennemsnitlig mængde data i Longhorn. Der er et praktisk dashboard til at styre Longhorn. Jeg har allerede sagt, at jeg godt kan lide Longhorn, men det skal arbejdes ordentligt på.
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 begrænsning på 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 stresstesten af volumener kunne jeg slet ikke lide hastigheden. Generelt ved jeg ikke, hvad jeg skal sige. Så jeg forstod det ikke rigtig. Der er ingen ekstern sikkerhedskopiering her, og du bliver også nødt til at bruge Velero med Restic til at sikkerhedskopiere mængder. Det er mærkeligt, for produktet er betalt. Og udviklerne var ikke ivrige efter at kommunikere i Slack.
Jeg lærte om Robin på Reddit fra deres CTO. Jeg havde aldrig hørt om ham før. Måske fordi jeg ledte efter gratis løsninger, og 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 med gode funktioner. Der er en fantastisk CLI, men det fedeste er, at du kan snapshotte og tage backup af hele applikationen (kaldet Helm-udgivelser eller "flex apps" i ressourcevælgeren), 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 en katastrofegendannelse - gendannelsen, af selvfølgelig virker, men fortsæt med at tage backup af applikationen, det er forbudt. I denne udgivelse er dette simpelthen ikke muligt, og det har udviklerne bekræftet. Dette er mildest talt mærkeligt, især når man overvejer 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 lagde mærke til en mærkelig ting: Hvis du kører benchmark direkte på en volumen, der er knyttet til værten, er læsehastigheden meget højere end i samme volumen, men inde fra poden. Alle andre resultater er identiske, men i teorien burde der ikke være nogen forskel. Selvom de arbejder på det, blev jeg frustreret over gendannelses- og sikkerhedskopieringsproblemet - det så ud til, at jeg endelig havde fundet en passende løsning, og jeg var endda klar 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 bare fantastisk. Indtil videre er dette den bedste indikator. Slack fortalte mig, at priserne 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. Jeg har i hvert fald ikke råd til det, så jeg var meget, meget skuffet over, at en udviklerlicens (op til 1TB 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 opsætningen i Kubernetes er meget besværlig og begrænset. Jeg foretrækker selvfølgelig open source, men hvis jeg havde penge, ville jeg helt klart vælge Portworx. Indtil videre kan dens ydeevne simpelthen ikke sammenlignes med andre muligheder.
Jeg tilføjede denne sektion efter indlægget blev offentliggjort, da en læser foreslog at prøve Linstor. Jeg prøvede det, og jeg kunne lide det! Men du skal stadig grave. Nu kan jeg sige, at ydeevnen ikke er dårlig (benchmark-resultater tilføjet nedenfor). Faktisk fik jeg den samme ydeevne som for drevet direkte, uden overhead overhovedet. (Spørg ikke, hvorfor Portworx's tal er bedre end drevets benchmark direkte. Jeg aner ikke. Magi, tror jeg.) Så Linstor virker meget effektiv indtil videre. Det er ikke så svært at installere det, men ikke så nemt som andre muligheder. Jeg skulle først installere Linstor (kernemodul og værktøjer/tjenester) og konfigurere LVM til tynd klargøring og snapshot-understøttelse uden for Kubernetes, direkte på værten, og derefter oprette de nødvendige ressourcer til at bruge storage fra Kubernetes. Jeg kunne ikke lide, at det ikke virkede på CentOS og skulle bruge Ubuntu. Ikke forfærdeligt, selvfølgelig, men lidt irriterende, for dokumentationen (som i øvrigt er fremragende) nævner flere pakker, som ikke kan findes i de angivne Epel-repositories. Linstor har snapshots, men ingen off-site backups, så her måtte jeg igen bruge Velero med Restic til at sikkerhedskopiere volumerne. Jeg ville foretrække snapshots frem for sikkerhedskopier på filniveau, men dette kan tolereres, hvis løsningen er både effektiv og pålidelig. Linstor er open source, men har betalt support. Hvis jeg forstår det rigtigt, kan det bruges uden begrænsninger, selvom du ikke har en supportkontrakt, men det skal afklares. Jeg ved ikke, hvordan Linstor er testet for Kubernetes, men selve lagerlaget er uden for Kubernetes, og løsningen dukkede tilsyneladende ikke op i går, så den er sandsynligvis allerede testet under virkelige forhold. Er der en løsning her, der får mig til at ændre mening og vende tilbage til Kubernetes? Jeg ved ikke. Vi mangler stadig at grave dybere, studere replikation. Lad os se. Men det første indtryk er godt. Jeg ville helt klart foretrække at bruge mine egne Kubernetes-klynger i stedet for Heroku for at få mere frihed og lære nye ting. Da Linstor ikke er lige så nem at installere som andre, vil jeg snart skrive et indlæg om det.
Benchmarks
Desværre førte jeg få optegnelser over sammenligningen, for jeg troede ikke, at jeg ville skrive om det. Jeg har kun fio-baseline benchmark-resultater og kun for enkelte node-klynger, så jeg har endnu ikke tal for replikerede konfigurationer. 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 nulstilling af serverindstillingerne for hvert produkt. Alt dette er fuldstændig uvidenskabeligt, bare så du forstår i generelle vendinger. I andre test kopierede jeg 38 GB fotos og videoer fra volumen og for at teste 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 der er en fantastisk gratis version, så hvis du har brug for et betalt produkt, kan du prøve det (jeg håber, de løser problemet med gendannelser og sikkerhedskopier snart). Af de tre gratis, har jeg haft færrest problemer med OpenEBS, men dens ydeevne er afgrundsdyb. Jeg er ked af, at jeg ikke har gemt flere resultater, men jeg håber, at tallene og mine kommentarer vil hjælpe dig.
Kilde: www.habr.com