Opdateer!. In die kommentaar het een van die lesers voorgestel om te probeer (miskien werk hy self daaraan), so ek het 'n afdeling oor daardie oplossing bygevoeg. Ek het ook geskryf want die proses is baie anders as die res.
Om eerlik te wees, ek het opgegee en opgegee (ten minste vir nou). Ek sal gebruik . Hoekom? As gevolg van berging! Wie sou kon dink dat ek meer met berging sou mors as met Kubernetes self. ek gebruik , want dit is goedkoop en die werkverrigting is goed, en van die begin af het ek groepe met . Ek het nog nie bestuurde Kubernetes-dienste van Google/Amazon/Microsoft/DigitalOcean ens., ens. probeer nie, want ek wou alles self leer. Ek is ook spaarsamig.
So - ja, ek het baie tyd spandeer om te besluit watter berging om te kies toe ek 'n moontlike stapel op Kubernetes oorweeg het. Ek verkies oopbronoplossings, en nie net as gevolg van die prys nie, maar ek het uit nuuskierigheid na 'n paar betaalde opsies gekyk, want hulle het gratis weergawes met beperkings. Ek het 'n paar syfers van onlangse maatstawwe neergeskryf toe ek verskillende opsies vergelyk het, en dit kan van belang wees vir diegene wat berging in Kubernetes bestudeer. Alhoewel ek persoonlik tot dusver van Kubernetes afskeid geneem het. Ek wil ook noem , waarin jy Hetzner Cloud-volumes direk kan voorsien, maar ek het dit nog nie probeer nie. Ek was op soek na wolksagteware-gedefinieerde berging omdat ek replikasie nodig gehad het en die vermoë gehad het om vinnig aanhoudende volumes op enige nodus te monteer, veral in geval van nodusfoute en ander soortgelyke situasies. Sommige oplossings bied punt-in-tyd-kiekies en rugsteun van die perseel, wat handig is.
Ek het 6-7 bergingsoplossings getoets:
Soos ek reeds gesê het , nadat ek die meeste van die opsies op die lys getoets het, het ek aanvanklik op OpenEBS gevestig. OpenEBS is baie maklik om te installeer en te gebruik, maar om eerlik te wees, nadat dit getoets is met werklike data onder vrag, het sy werkverrigting my teleurgestel. Dit is oopbron, en ontwikkelaars is op hul eie altyd baie behulpsaam wanneer ek hulp nodig gehad het. Ongelukkig het dit baie swak prestasie in vergelyking met ander opsies, so ek moes weer die toetse uitvoer. Op die oomblik het OpenEBS 3 bergingsenjins, maar ek plaas maatstafresultate vir cStor. Ek het nog nie nommers vir Jiva en LocalPV nie.
In 'n neutedop, Jiva is effens vinniger, en LocalPV is oor die algemeen vinnig, nie erger as die dryfmaatstaf direk nie. Die probleem met LocalPV is dat toegang tot die volume slegs verkry kan word op die nodus waar dit voorsien is, en daar is glad geen replikasie nie. Ek het probleme gehad met die herstel van 'n rugsteun via op die nuwe cluster omdat die nodusname anders was. Van rugsteun gepraat, cStor het , waarmee jy van die perseel punt-in-tyd momentopname rugsteun kan maak, wat geriefliker is as lêervlak rugsteun met Velero-Restic. Ek het geskryf om dit makliker te maak om rugsteun en herstel met hierdie inprop te bestuur. Oor die algemeen hou ek baie van OpenEBS, maar die prestasie daarvan ...
Rook is ook oopbron, en verskil van die res van die opsies op die lys deurdat dit 'n bergingsorkeseerder is wat komplekse bergingbestuurstake met verskillende agterkante uitvoer, byvoorbeeld , en ander, wat die werk baie vereenvoudig. Ek het probleme met EfgeFS gehad toe ek dit 'n paar maande gelede probeer het, so ek het hoofsaaklik met Ceph getoets. Ceph bied nie net blokberging nie, maar ook objekberging wat versoenbaar is met S3/Swift en verspreide lêerstelsel. Wat ek van Ceph hou, is die vermoë om volumedata oor verskeie skywe te versprei sodat die volume meer skyfspasie kan gebruik as wat op een skyf kan pas. Dis gemaklik. Nog 'n oulike kenmerk is dat wanneer jy skywe by die groep voeg, dit outomaties data oor alle skywe herverdeel.
Ceph het kiekies, maar sover ek weet kan dit nie direk in Rook/Kubernetes gebruik word nie. Ek het weliswaar nie daarin gedelf nie. Maar daar is geen rugsteun van die webwerf nie, so jy moet iets met Velero / Restic gebruik, maar daar is net rugsteun op lêervlak, nie punt-in-tyd-kiekies nie. Wat ek egter baie van Rook hou, is die gemak om met Ceph te werk - dit versteek byna al die komplekse goed en bied gereedskap om direk met Ceph te praat vir probleemoplossing. Ongelukkig, op die strestoets van Ceph volumes, het ek altyd , wat veroorsaak dat Ceph onstabiel raak. Dit is nog nie duidelik of dit 'n fout in Ceph self is of 'n probleem in hoe Rook Ceph bestuur nie. Ek het met die geheue-instellings gevroetel, en dit het beter geword, maar die probleem is nie heeltemal opgelos nie. Ceph het goeie prestasie soos gesien in die maatstawwe hieronder. Dit het ook 'n goeie dashboard.
Ek hou baie van Longhorn. Ek dink dit is 'n belowende oplossing. Die ontwikkelaars self (Rancher Labs) erken dat dit nog nie geskik is vir 'n produksie-omgewing nie, en dit wys. Dit is oopbron en het ordentlike werkverrigting (alhoewel hulle dit nog nie geoptimaliseer het nie), maar die volumes neem baie lank om aan die peul te heg, en in die ergste gevalle neem dit 15-16 minute, veral na die herstel van 'n groot rugsteun of werklading op te gradeer. Dit het foto's en rugsteun van daardie foto's buite die perseel, maar dit is slegs van toepassing op volumes, so jy het steeds iets soos Velero nodig om die res van die hulpbronne te rugsteun. Rugsteun en herstel is baie betroubaar, maar onbetaamlik stadig. Ernstig, net buitensporig stadig. SVE-gebruik en stelsellading styg dikwels wanneer daar met 'n gemiddelde hoeveelheid data in Longhorn gewerk word. Daar is 'n handige dashboard om Longhorn te bestuur. Ek het al gesê ek hou van Longhorn, maar daar moet behoorlik aan gewerk word.
StorageOS is die eerste betaalde produk op die lys. Dit het 'n ontwikkelaarweergawe met 'n beperkte bestuurde stoorgrootte van 500 GB, maar ek dink nie daar is 'n beperking op die aantal nodusse nie. Die verkoopsafdeling het vir my gesê die koste begin by $125 per maand vir 1 TB, as ek reg onthou. Daar is 'n basiese paneelbord en 'n handige CLI, maar iets vreemds is aan die gang met die werkverrigting: in sommige maatstawwe is dit redelik skaflik, maar in die strestoets van volumes het ek glad nie van die spoed gehou nie. Oor die algemeen weet ek nie wat om te sê nie. So ek het nie regtig verstaan nie. Hier is geen rugsteun van die webwerf nie en jy sal ook Velero met Restic moet gebruik om volumes te rugsteun. Dis vreemd, want die produk is betaal. En die ontwikkelaars was nie gretig om in Slack te kommunikeer nie.
Ek het geleer oor Robin op Reddit by hul CTO. Ek het nog nooit van hom gehoor nie. Miskien omdat ek gratis oplossings gesoek het, en Robin word betaal. Hulle het 'n redelik ruim gratis weergawe met 10 TB berging en drie nodusse. Oor die algemeen is die produk redelik ordentlik en met goeie kenmerke. Daar is 'n wonderlike CLI, maar die coolste ding is dat jy die hele toepassing kan snapshot en rugsteun (genoem Helm-vrystellings of "flex apps" in die hulpbronkieser), insluitend volumes en ander hulpbronne, sodat jy sonder Velero kan klaarkom. En alles sou wonderlik wees as nie vir een klein detail nie: as jy 'n toepassing op 'n nuwe cluster herstel (of "invoer", soos dit in Robin genoem word) - byvoorbeeld in die geval van 'n rampherstel - die herstel, van natuurlik, werk, maar gaan voort om die toepassing te rugsteun dit is verbode. In hierdie weergawe is dit eenvoudig nie moontlik nie, en die ontwikkelaars het dit bevestig. Dit is vreemd, om die minste te sê, veral as jy ander voordele in ag neem (byvoorbeeld, ongelooflike vinnige rugsteun en herstel). Die ontwikkelaars belowe om alles teen die volgende weergawe reg te stel. Die werkverrigting is oor die algemeen goed, maar ek het 'n vreemde ding opgemerk: as jy die maatstaf direk op 'n volume wat aan die gasheer gekoppel is, laat loop, is die leesspoed baie hoër as in dieselfde volume, maar van binne die peul. Alle ander resultate is identies, maar in teorie behoort daar geen verskil te wees nie. Alhoewel hulle daaraan werk, het ek gefrustreerd geraak met die herstel- en rugsteunprobleem - dit het vir my gelyk of ek uiteindelik 'n geskikte oplossing gevind het, en ek was selfs gereed om daarvoor te betaal wanneer ek meer spasie of meer bedieners nodig gehad het.
Ek het nie veel om hier te sê nie. Dit is 'n betaalde produk, ewe gaaf en duur. Die prestasie is net ongelooflik. Tot dusver is dit die beste aanwyser. Slack het vir my gesê pryse begin by $205 per maand per nodus, soos gelys op Google se GKE Marketplace. Ek weet nie of dit goedkoper sal wees as jy direk koop nie. In elk geval, ek kan dit nie bekostig nie, so ek was baie, baie teleurgesteld dat 'n ontwikkelaarlisensie (tot 1TB en 3 nodusse) feitlik nutteloos is met Kubernetes, tensy jy tevrede is met statiese voorsiening. Ek het gehoop dat die volumelisensie aan die einde van die proeftydperk outomaties na ontwikkelaar sou afgradeer, maar dit het nie gebeur nie. Die ontwikkelaarlisensie kan slegs direk met Docker gebruik word, en die opstelling in Kubernetes is baie omslagtig en beperk. Natuurlik verkies ek oopbron, maar as ek geld gehad het, sou ek beslis Portworx kies. Tot dusver vergelyk sy prestasie eenvoudig nie met ander opsies nie.
Ek het hierdie afdeling bygevoeg nadat die pos gepubliseer is, toe 'n leser voorgestel het om Linstor te probeer. Ek het dit probeer en ek het daarvan gehou! Maar jy moet nog grawe. Nou kan ek sê dat die prestasie nie sleg is nie (benchmark-resultate hieronder bygevoeg). Trouens, ek het dieselfde prestasie gekry as vir die aandrywing direk, sonder die oorhoofse koste. (Moenie vra hoekom Portworx se syfers direk beter is as die aandrywer se maatstaf nie. Ek het geen idee nie. Magie, dink ek.) So Linstor lyk tot dusver baie effektief. Dit is nie so moeilik om dit te installeer nie, maar nie so maklik soos ander opsies nie. Ek moes eers Linstor (kernmodule en gereedskap/dienste) installeer en LVM opstel vir dun voorsiening en momentopname-ondersteuning buite Kubernetes, direk op die gasheer, en dan die hulpbronne skep wat nodig is om berging vanaf Kubernetes te gebruik. Ek het nie daarvan gehou dat dit nie op CentOS werk nie en Ubuntu moes gebruik. Nie vreeslik nie, natuurlik, maar 'n bietjie irriterend, want die dokumentasie (wat terloops uitstekend is) noem verskeie pakkette wat nie in die gespesifiseerde Epel-bewaarplekke gevind kan word nie. Linstor het kiekies, maar geen rugsteun van die perseel nie, so hier moes ek weer Velero met Restic gebruik om die volumes te rugsteun. Ek sal foto's verkies bo lêervlak-rugsteun, maar dit kan geduld word as die oplossing beide werksaam en betroubaar is. Linstor is oopbron, maar het betaalde ondersteuning. As ek reg verstaan, kan dit sonder beperkings gebruik word, selfs al het jy nie 'n ondersteuningskontrak nie, maar dit moet uitgeklaar word. Ek weet nie hoe Linstor vir Kubernetes getoets word nie, maar die bergingslaag self is buite Kubernetes en blykbaar het die oplossing nie gister verskyn nie, so dit is waarskynlik reeds in werklike toestande getoets. Is hier 'n oplossing wat my van plan sal laat verander en na Kubernetes sal terugkeer? Ek weet nie. Ons moet nog dieper delf, replikasie bestudeer. Kom ons kyk. Maar die eerste indruk is goed. Ek sal beslis verkies om my eie Kubernetes-klusters in plaas van Heroku te gebruik om meer vryheid te hê en nuwe dinge te leer. Aangesien Linstor nie so maklik is om te installeer soos ander nie, sal ek binnekort 'n plasing daaroor skryf.
Maatstawwe
Ongelukkig het ek min rekord gehou van die vergelyking, want ek het nie gedink dat ek daaroor sou skryf nie. Ek het net fio basislyn maatstaf resultate en slegs vir enkele nodus clusters, so ek het nog nie nommers vir herhaalde konfigurasies nie. Maar uit hierdie resultate kan u 'n rowwe idee kry van wat om van elke opsie te verwag, want ek het dit vergelyk op dieselfde wolkbedieners, 4 kerns, 16 GB RAM, met 'n bykomende 100 GB-skyf vir die getoetsde volumes. Ek het die maatstawwe drie keer vir elke oplossing gehardloop en die gemiddelde resultaat bereken, plus die herstel van die bedienerinstellings vir elke produk. Dit alles is heeltemal onwetenskaplik, net sodat jy in algemene terme verstaan. In ander toetse het ek 38 GB se foto's en video's uit die bundel gekopieer en om lees en skryf te toets, maar, helaas, ek het nie die nommers gestoor nie. Kortom: Portworkx was baie vinniger.
Vir die volume maatstaf het ek hierdie manifes gebruik:
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: 4Ek het eers 'n volume met die toepaslike stoorklas geskep, en toe die werk saam met fio agter die skerms uitgevoer. Ek het 1 GB geneem om die werkverrigting te skat en nie te lank te wag nie. Hier is die resultate:
Ek het die beste waarde vir elke maatstaf in groen uitgelig en die swakste in rooi.
Gevolgtrekking
Soos u kan sien, het Portworx in die meeste gevalle beter gevaar as ander. Maar vir my is dit duur. Ek weet nie hoeveel Robin kos nie, maar daar is 'n wonderlike gratis weergawe, so as jy 'n betaalde produk nodig het, kan jy dit probeer (ek hoop dat hulle gou die probleem met herstel en rugsteun regstel). Van die drie gratis eens het ek die minste probleme met OpenEBS gehad, maar sy werkverrigting is aaklig. Ek is jammer dat ek nie meer resultate gestoor het nie, maar ek hoop die nommers en my kommentaar sal jou help.
Bron: will.com