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 denne løsning. Jeg har også skrevet , fordi processen adskiller sig meget fra de andre.
Ærligt talt, jeg gav op og opgav (i hvert fald for nu). Jeg vil bruge . Hvorfor? På grund af opbevaring! Hvem kunne have troet, at jeg ville bruge mere tid på opbevaring end på Kubernetes selv. Jeg bruger , fordi det er billigt og ydeevnen er god, og fra starten har jeg implementeret klynger ved hjælp af . Jeg har ikke prøvet de administrerede Kubernetes-tjenester fra Google/Amazon/Microsoft/DigitalOcean osv., fordi jeg ville lære alt selv. Og så er jeg økonomisk.
Så ja, jeg har brugt en masse tid på at beslutte, hvilket lager jeg skulle vælge, da jeg overvejede den mulige stak på Kubernetes. Jeg foretrækker open source-løsninger, ikke kun på grund af prisen, men jeg har undersøgt et par betalte muligheder ud af nysgerrighed, fordi de har gratis versioner med begrænsninger. Jeg noterede nogle tal fra de seneste tests, da jeg sammenlignede forskellige muligheder, og de kan interessere dem, der undersøger opbevaring i Kubernetes. Selvom jeg personligt har sagt farvel til Kubernetes for nu. Jeg vil også nævne , hvor man kan forberede Hetzner Cloud-volumener direkte, men jeg har ikke prøvet det endnu. Jeg har undersøgt cloud-baseret softwaredefineret opbevaring, fordi jeg havde brug for replikering og evnen til hurtigt at tilslutte persistente volumen på enhver node, især i tilfælde af nodefejl og lignende situationer. Nogle løsninger tilbyder snapshots på et givent tidspunkt og off-site backups, hvilket er praktisk.
Jeg har testet 6–7 lagringsløsninger:
Som jeg allerede har nævnt , efter at have testet de fleste af mulighederne på listen, gik jeg oprindeligt med OpenEBS. OpenEBS er meget let at installere og bruge, men ærligt talt, efter tests med reelle data under belastning, blev jeg skuffet over dens ydeevne. Det er open source, og udviklerne er på deres har altid været en stor hjælp, når jeg havde brug for assistance. Desværre har det en meget lav ydeevne sammenlignet med andre muligheder, så jeg var nødt til at køre testene igen. Nu har OpenEBS 3 lagringsmotorer, men jeg offentliggør benchmark-resultaterne for cStor. Jeg har endnu ikke tal for Jiva og LocalPV.
Kort sagt er Jiva lidt hurtigere, mens LocalPV er meget hurtig, ikke værre end benchmarket direkte på disken. Problemet med LocalPV er, at adgangen kun kan fås på den node, hvor den blev forberedt, og der findes slet ingen replikation. Jeg har haft nogle problemer med at gendanne backup via på den nye klynge, fordi noderne havde forskellige navne. Hvad angår backups, har cStor en , som gør det muligt at lave off-site backups af snapshots på et givet tidspunkt, hvilket er mere praktisk end filniveau backups med Velero-Restic. Jeg har skrevet , for at gøre det lettere at administrere backups og gendannelser med dette plugin. Generelt er jeg meget glad for OpenEBS, men dens ydeevne…
Rook har også åben kildekode, og adskiller sig fra de andre muligheder på listen ved at være en lagerorkestrator, der udfører komplekse opgaver til lagerstyring med forskellige backend-løsninger, såsom , og andre, hvilket væsentligt forenkler arbejdet. Jeg havde problemer med EdgeFS, da jeg prøvede det for nogle måneder siden, så jeg testede primært med Ceph. Ceph tilbyder ikke kun bloklager, men også objektlager, der er kompatibelt med S3/Swift og et distribueret filsystem. Hvad jeg kan lide ved Ceph, er muligheden for at sprede dataene af volumener over flere diske, så volumen kan bruge mere diskplads end hvad der kan være på en enkelt disk. Det er praktisk. En anden fed funktion er, at når du tilføjer diske til klyngen, omfordeler den automatisk dataene på tværs af alle diske.
Ceph har snapshots, men så vidt jeg ved, kan de ikke bruges direkte i Rook/Kubernetes. Jeg har dog ikke dykket dybere ind i det. Off-site backups findes ikke, så det bliver nødvendigt at bruge noget som Velero/Restic, men der er kun backups på filniveau, ikke snapshots på et bestemt tidspunkt. Til gengæld har jeg virkelig nydt den enkle håndtering af Ceph i Rook — det skjuler næsten alle komplicerede ting og tilbyder værktøjer til at interagere med Ceph direkte for fejlfinding. Desværre har jeg konstant haft , som gør Ceph ustabilt. Det er endnu ikke klart, om det er en fejl i selve Ceph eller et problem med, hvordan Rook styrer Ceph. Jeg har leget lidt med hukommelsesindstillingerne, og det blev bedre, men problemet er ikke helt løst. Ceph har en rimelig ydeevne, som det kan ses i benchmarks nedenfor. Og så har det et godt overvågningspanel.
Jeg kan virkelig godt lide Longhorn. Jeg synes, det er en lovende løsning. Selvom udviklerne selv (Rancher Labs) erkender, at det endnu ikke er klart til produktionsmiljøer, hvilket er tydeligt. Det har open source-kode og en god ydeevne (selvom de ikke har arbejdet på optimering endnu), men volume kan tage lang tid at tilslutte til en pod, og i de værste tilfælde kan det tage 15-16 minutter, især efter gendannelse af en stor backup eller opgradering af arbejdsbelastningen. Det har snapshots og off-site backups af disse snapshots, men de gælder kun for volumes, så du får stadig brug for noget som Velero til backup af de andre ressourcer. Backups og gendannelser er meget pålidelige, men grusomt langsomme. Seriøst, det er bare ekstremt langsomt. Brug af CPU-ressourcer og systembelastning stiger ofte, når der arbejdes med en gennemsnitlig datamængde i Longhorn. Der er et brugervenligt overvågningspanel til at administrere Longhorn. Jeg har nævnt, at jeg kan lide Longhorn, men der skal virkelig arbejdes på det.
StorageOS er det første betalte produkt på listen. Der findes en udviklerversion med en begrænset størrelse af det administrerede lager på 500 GB, men antallet af noder er, efter min mening, ikke begrænset. I salgsafdelingen sagde de, at prisen starter fra $125 om måneden for 1 TB, hvis jeg husker rigtigt. Der er et grundlæggende overvågningspanel og et brugervenligt CLI, men noget underligt foregår med ydeevnen: i nogle benchmarks er den ganske anstændig, men i stresstests af volumenerne kunne jeg ikke lide hastigheden overhovedet. Generelt ved jeg ikke, hvad jeg skal sige. Derfor har jeg ikke dykket alt for meget ned i det. Der er ingen off-site backups, og man må også bruge Velero med Restic til at tage backups af volumenerne. Underligt, siden produktet er betalt. Og desuden har udviklerne ikke været ivrige efter at kommunikere i Slack.
Jeg fik kendskab til Robin på Reddit fra deres tekniske direktør. Jeg havde aldrig hørt om det før, muligvis fordi jeg ledte efter gratis løsninger, mens Robin er betalt. De har en ret generøs gratis version med 10 TB lager og tre noder. Generelt er produktet ganske udmærket og har nogle gode funktioner. Der er en fremragende CLI, men det bedste er, at man kan lave snapshots og backups af hele applikationen (i ressourcevælgeren kaldes det Helm-releases eller «flex apps»), inklusive volumes og andre ressourcer, så man kan undgå Velero. Og alt ville være vidunderligt, hvis det ikke var for en lille detalje: hvis man gendanner (eller «importerer», som det hedder i Robin) applikationen på et nyt cluster — for eksempel ved katastrofegendannelse — så virker gendannelsen selvfølgelig, men man kan ikke fortsætte med at tage backup af applikationen. I denne version er det simpelthen ikke muligt, og udviklerne har bekræftet det. Det er mildt sagt underligt, især i betragtning af de andre fordele (for eksempel utroligt hurtige backups og gendannelser). Udviklerne lover at rette det til næste version. Ydelsen er generelt god, men jeg bemærkede noget mærkeligt: hvis man kører et benchmark direkte på volume, der er tilsluttet til værten, er læsehastigheden meget højere end i den samme volume, men indefra pod'en. Alle andre resultater er identiske, men i teorien burde der ikke være nogen forskel. Selvom de arbejder på dette, blev jeg skuffet over problemet med gendannelse og backup — jeg troede, jeg endelig havde fundet den rigtige løsning, og jeg var endda klar til at betale for det, når jeg ville have brug for mere plads eller flere servere.
Her har jeg ikke meget at sige. Det er et betalingsprodukt af høj kvalitet, men også dyrt. Ydelsen er simpelthen fantastisk. Indtil videre er det den bedste præstation. I Slack blev jeg informeret om, at prisen starter fra $205 om måneden pr. node, som angivet i Googles GKE Marketplace. Jeg ved ikke, om det bliver billigere, hvis man køber direkte. Under alle omstændigheder har jeg ikke råd til det, så jeg blev meget skuffet over, at udviklertilladelsen (op til 1 TB og 3 noder) er praktisk taget ubrugelig med Kubernetes, medmindre man nøjes med statisk opsætning. Jeg havde håbet, at virksomhedstilladelsen automatisk ville nedjusteres til udviklerniveau ved slutningen af prøveperioden, men det skete ikke. Udviklertilladelsen 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 pengene, ville jeg helt sikkert vælge Portworx. Indtil videre kan dens ydeevne simpelthen ikke sammenlignes med andre muligheder.
Jeg tilføjede denne sektion efter publiceringen af indlægget, da en læser foreslog at prøve Linstor. Jeg prøvede det, og jeg kan godt lide det! Men jeg skal stadig undersøge det nærmere. Lige nu kan jeg sige, at ydeevnen er fin (benchmarkresultaterne er tilføjet nedenfor). I princippet har jeg fået samme ydeevne som direkte fra disken, helt uden omkostninger. (Spørg ikke, hvorfor Portworx's tal er bedre end benchmarken for disken direkte. Jeg har ikke noget svar. Magi, måske.) Så Linstor ser indtil videre ud til at være meget effektivt. Det er ikke ligefrem svært at installere, men det er heller ikke så let som de andre muligheder. Først måtte jeg installere Linstor (kernelmodul og værktøjer/tjenester) og konfigurere LVM til thin provisioning og understøttelse af snapshots uden for Kubernetes, direkte på værten, og derefter oprette de nødvendige ressourcer til at bruge lageret fra Kubernetes. Jeg kunne ikke lide, at det ikke fungerede på CentOS, så jeg måtte bruge Ubuntu. Det er selvfølgelig ikke en katastrofe, men det er lidt frustrerende, fordi dokumentationen (som i øvrigt er fremragende) nævner flere pakker, som ikke kan findes i de angivne Epel-repositories. Linstor har snapshots, men ikke offsite backups, så jeg blev igen nødt til at bruge Velero med Restic til at tage backups af volumener. Jeg ville have foretrukket snapshots frem for backups på filniveau, men det kan tolereres, hvis løsningen er effektiv og pålidelig. Linstor har open source, men der er betalt support. Hvis jeg forstår det korrekt, kan det bruges uden begrænsninger, selvom du ikke har en supportaftale, men det skal bekræftes. Jeg ved ikke, hvor godt Linstor er testet for Kubernetes, men selve lagerlaget er uden for Kubernetes, og åbenbart har løsningen ikke set dagens lys i går, så det er nok blevet testet under virkelige forhold. Er der nogen løsning her, der vil få mig til at ombestemme mig og vende tilbage til Kubernetes? Jeg ved ikke, jeg ved ikke. Jeg skal stadig undersøge det nærmere og se på replikering. Vi får se. Men det første indtryk er godt. Jeg ville helt klart foretrække at bruge mine egne Kubernetes-klynger frem for Heroku for at få mere frihed og lære noget nyt. Da Linstor ikke er så nemt at installere som de andre, vil jeg snart skrive et indlæg om det.
Benchmarktests
Desværre har jeg gemt få sammenligningsoplysninger, fordi jeg ikke tænkte, at jeg ville skrive om dette. Jeg har kun resultaterne fra de grundlæggende benchmarks fra fio, og kun for klynger med én node, så jeg har ikke tal for replikerede konfigurationer endnu. Men ud fra disse resultater kan du få en idé om, hvad du kan forvente af hver mulighed, da jeg sammenlignede dem på de samme cloud-servere med 4 kerner, 16 GB RAM og med en ekstra 100 GB disk til de testede volumener. Jeg kørte benchmarks tre gange for hver løsning og beregnede det gennemsnitlige resultat, plus at jeg nulstillede serverindstillingerne for hvert produkt. Alt dette er på ingen måde videnskabeligt, det var bare for at give dig en generel forståelse. I andre tests kopierede jeg 38 GB billeder og videoer fra et volumen og til et andet for at teste læsning og skrivning, men desværre har jeg ikke gemt tallene. Kort sagt: Portworx var langt hurtigere.
Til volume benchmark 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: 4Først oprettede jeg et volumen med den relevante lagerklasse, og derefter kørte jeg en opgave med fio i baggrunden. Jeg valgte 1 GB for at estimere ydeevnen og for ikke at vente for længe. Her er resultaterne:
Jeg har fremhævet den bedste værdi for hver måling med grønt og den værste med rødt.
Konklusion
Som du kan se, præsterede Portworx bedre end de andre i de fleste tilfælde. Men for mig er det dyrt. Jeg ved ikke, hvad Robin koster, men de har en fremragende gratis version, så hvis du har brug for et betalt produkt, kan du prøve det (jeg håber, de snart løser problemerne med gendannelse og backup). Af de tre gratis løsninger havde jeg færrest problemer med OpenEBS, men dets ydeevne er ikke særlig god. Det er ærgerligt, at jeg ikke gemte flere resultater, men forhåbentlig hjælper de angivne tal og mine kommentarer dig.
Kilde: habr.com
