Ĝisdatigo!. En la komentoj, unu el la legantoj sugestis provi (eble li mem laboras pri ĝi) do mi aldonis sekcion pri ĉi tiu solvo. Mi ankaŭ skribis , ĉar la procezo estas tre malsama de la resto.
Verdire, mi rezignis kaj rezignis (almenaŭ nuntempe). Mi uzos . Kial? Pro stokado! Kiu pensus, ke mi pli ludus kun stokado ol kun Kubernetes mem. mi uzas ĉar ĝi estas malmultekosta kaj la rendimento estas bona kaj ekde la komenco mi disfaldas grapolojn uzante . Mi ne provis administritajn Kubernetes-servojn de Google/Amazon/Microsoft/DigitalOcean, ktp, ktp., ĉar mi volis mem lerni ĉion. Mi ankaŭ estas ŝparema.
Do jes, mi pasigis multan tempon provante decidi kiun stokadon elekti kiam mi taksis eblan Kubernetes-stakon. Mi preferas liberkodajn solvojn, ne nur pro la prezo, sed mi esploris kelkajn pagitajn opciojn pro scivolemo ĉar ili havas senpagajn versiojn kun limigoj. Mi notis kelkajn nombrojn de lastatempaj testoj kiam mi komparis malsamajn opciojn, kaj ili povus interesi tiujn, kiuj lernas pri Kubernetes-stokado. Kvankam mi persone nun adiaŭis Kubernetes. Mi ankaŭ volas mencii , kiu povas rekte provizi Hetzner Cloud-volumojn, sed mi ankoraŭ ne provis ĝin. Mi rigardis en nuba programaro-difinita stokado ĉar mi bezonis reproduktadon kaj la kapablon rapide munti persistajn volumojn sur iu ajn nodo, precipe en kazo de nodaj misfunkciadoj kaj aliaj similaj situacioj. Iuj solvoj ofertas momentajn momentfotojn kaj eksterejn sekurkopiojn, kio estas oportuna.
Mi provis 6-7 stokajn solvojn:
Kiel mi jam diris Provinte la plimulton de la elektoj de la listo, mi komence decidiĝis pri OpenEBS. OpenEBS estas tre facile instalebla kaj uzebla, sed sincere, post testado kun realaj datumoj sub ŝarĝo, mi seniluziiĝis pri ĝia agado. Ĉi tio estas malferma fonto, kaj la programistoj estas solaj ĉiam tre helpema kiam mi bezonis helpon. Bedaŭrinde, ĝi havas tre malbonan rendimenton kompare kun aliaj opcioj, do la testoj devis esti refari. OpenEBS nuntempe havas 3 stokajn motorojn, sed mi afiŝas komparrezultojn por cStor. Mi ankoraŭ ne havas numerojn por Jiva kaj LocalPV.
En resumo, Jiva estas iom pli rapida, kaj LocalPV estas ĝenerale rapida, ne pli malbona ol la diskremarko rekte. La problemo kun LocalPV estas, ke la volumo nur alireblas sur la nodo, kie ĝi estis preta, kaj tute ne ekzistas reproduktado. Mi havis kelkajn problemojn restarigi sekurkopion per sur nova areto ĉar la nodnomoj estis malsamaj. Se ni parolas pri sekurkopioj, cStor havas , kun kiu vi povas fari eksterlokaj sekurkopioj de momentfotoj en momento, kio estas pli oportuna ol dosiernivelaj sekurkopioj kun Velero-Restic. mi skribis , por faciligi administri sekurkopiojn kaj restarigojn per ĉi tiu kromaĵo. Ĝenerale, mi tre ŝatas OpenEBS, sed ĝia agado...
Rook ankaŭ estas malferma fonto, kaj kio distingas ĝin de la resto de la elektoj en la listo estas ke ĝi estas stokada orkestro kiu pritraktas kompleksajn stokadadministrajn taskojn kun malsamaj backends, ekz. , kaj aliaj, kio ege simpligas la laboron. Mi havis problemojn kun EfgeFS kiam mi provis ĝin antaŭ kelkaj monatoj, do mi testis ĉefe kun Ceph. Ceph ne nur ofertas blokan stokadon, sed ankaŭ objektan stokadon kongruan kun S3/Swift kaj distribuita dosiersistemo. Kion mi ŝatas pri Ceph estas la kapablo disvastigi volumenajn datumojn tra pluraj diskoj, por ke la volumo povu uzi pli da diskospaco ol povas konveni sur ununura disko. Estas komforta. Alia bonega funkcio estas, ke kiam vi aldonas diskojn al areto, ĝi aŭtomate redistribuas datumojn tra ĉiuj diskoj.
Ceph havas momentfotojn, sed laŭ mia scio, ili ne povas esti uzataj rekte en Rook/Kubernetes. Vere, mi ne enprofundiĝis en ĉi tion. Sed ne ekzistas eksterejaj sekurkopioj, do vi devos uzi ion kun Velero/Restic, sed ekzistas nur dosiernivelaj sekurkopioj, ne momentaj momentfotoj. Kion mi tre ŝatis pri Rook estis kiom facile estas labori kun Ceph - ĝi kaŝas preskaŭ ĉiujn komplikajn aferojn kaj ofertas ilojn por paroli kun Ceph rekte por solvi problemojn. Bedaŭrinde, dum la streĉa provo de Ceph-volumoj, mi daŭre havis problemojn kun , kiu igas Ceph iĝi malstabila. Ankoraŭ ne estas klare ĉu ĉi tio estas cimo en Ceph mem aŭ problemo en la maniero kiel Rook administras Ceph. Mi tuŝis la memorajn agordojn, kaj ĝi pliboniĝis, sed la problemo ne estis tute solvita. Ceph havas decan rendimenton, kiel vi povas vidi en la komparnormoj sube. Ĝi ankaŭ havas bonan panelon.
Mi tre ŝatas Longhorn. Laŭ mi, ĉi tio estas promesplena solvo. Vere, la programistoj mem (Rancher Labs) akceptas, ke ĝi ankoraŭ ne taŭgas por la labormedio, kaj tio montras. Ĝi estas malferma fonto kaj havas decan rendimenton (kvankam ili ankoraŭ ne optimumigis ĝin), sed la volumoj bezonas tre longan tempon por konekti al la pod, kaj en la plej malbonaj kazoj ĝi daŭras 15-16 minutojn, precipe post restarigo de granda sekurkopio aŭ ĝisdatigante la laborkvanton. Ĝi havas momentfotojn kaj eksterejn sekurkopiojn de ĉi tiuj momentfotoj, sed ili nur validas por volumoj, do vi ankoraŭ bezonos ion kiel Velero por sekurkopii aliajn rimedojn. Sekurkopioj kaj restarigoj estas tre fidindaj, sed maldece malrapidaj. Serioze, nur nekredeble malrapide. CPU-uzado kaj sistema ŝarĝo ofte altiĝas kiam oni laboras kun meza kvanto da datumoj en Longhorn. Estas oportuna panelo por administri Longhorn. Mi jam diris, ke mi ŝatas Longhorn, sed ĝi bezonas iom da laboro.
StorageOS estas la unua pagita produkto en la listo. Ĝi havas programista version kun limigita administrita stokado grandeco de 500GB, sed mi ne pensas, ke ekzistas limo por la nombro da nodoj. La venda fako diris al mi, ke la kosto komenciĝas je $125 monate por 1 TB, se mi ĝuste memoras. Estas baza panelo kaj oportuna CLI, sed io stranga okazas kun la agado: en iuj benchmarkoj ĝi estas sufiĉe deca, sed en la voluma streĉtesto mi tute ne ŝatis la rapidecon. Ĝenerale, mi ne scias kion diri. Do mi vere ne komprenis multon. Ne ekzistas eksterejaj sekurkopioj ĉi tie kaj vi ankaŭ devos uzi Velero kun Restic por rezervaj volumoj. Estas strange, ĉar la produkto estas pagita. Kaj la programistoj ne volis komuniki sur Slack.
Mi eksciis pri Robin ĉe Reddit de ilia teknika direktoro. Mi neniam antaŭe aŭdis pri li. Eble ĉar mi serĉis senpagajn solvojn, sed Robin estas pagita. Ili havas sufiĉe malavaran senpagan version kun 10TB da stokado kaj tri nodoj. Ĝenerale, la produkto estas sufiĉe deca kaj havas belajn funkciojn. Estas bonega CLI, sed la plej bonega afero estas, ke vi povas filmi kaj kopii la tutan aplikaĵon (en la rimedo-elektilo ĉi tio nomiĝas Helm-eldonoj aŭ "fleksaj programoj"), inkluzive de volumoj kaj aliaj rimedoj, do vi povas malhavi Velero. Kaj ĉio estus mirinda se ne por unu malgranda detalo: se vi restarigas (aŭ "importas", kiel ĝi nomiĝas en Robin) aplikaĵon sur nova areto - ekzemple, en kazo de reakiro post katastrofo - la restarigo, kompreneble, funkcias, sed daŭre sekurkopii la aplikaĵon ĝi estas malpermesita. Ĉi tio simple ne eblas en ĉi tiu eldono, kiel la programistoj konfirmis. Ĉi tio estas, milde, stranga, precipe konsiderante la aliajn avantaĝojn (ekzemple, nekredeble rapidaj sekurkopioj kaj restarigoj). La programistoj promesas ripari ĉion antaŭ la venonta eldono. Efikeco estas ĝenerale bona, sed mi rimarkis strangaĵon: se mi kuras la komparnormon rekte sur volumeno ligita al la gastiganto, la legado estas multe pli rapida ol ruli la saman volumon de ene de la pod. Ĉiuj aliaj rezultoj estas identaj, sed en teorio ne devus esti diferenco. Kvankam ili laboras pri ĝi, mi ĉagreniĝis pro la problemo pri restarigo kaj sekurkopio - mi pensis, ke mi finfine trovis taŭgan solvon, kaj mi eĉ volis pagi por ĝi kiam mi bezonis pli da spaco aŭ pli da serviloj.
Mi ne havas multon por diri ĉi tie. Ĉi tio estas pagita produkto, same malvarmeta kaj multekosta. La agado estas simple mirinda. Ĉi tio estas la plej bona indikilo ĝis nun. Slack diris al mi, ke prezoj komenciĝas je $ 205 monate per nodo, kiel listigita en GKE Marketplace de Google. Mi ne scias ĉu ĝi estos pli malmultekosta se vi aĉetos rekte. Mi ne povas pagi tion ĉiukaze, do mi estis tre, tre seniluziigita, ke la programlicenco (ĝis 1 TB kaj 3 nodoj) estas praktike senutila kun Kubernetes krom se vi kontentas pri senmova provizo. Mi esperis, ke la volumlicenco aŭtomate malaltiĝos al programisto ĉe la fino de la provperiodo, sed tio ne okazis. La programlicenco nur povas esti uzata rekte kun Docker, kaj agordo en Kubernetes estas tre maloportuna kaj limigita. Kompreneble, mi preferas malferman fonton, sed se mi havus la monon, mi certe elektus Portworx. Ĝis nun, ĝia agado simple ne komparas kun aliaj opcioj.
Mi aldonis ĉi tiun sekcion post la publikigo de la afiŝo, kiam unu leganto sugestis provi Linstor. Mi provis ĝin kaj mi ŝatis ĝin! Sed ni ankoraŭ bezonas fosi pli profunde. Nun mi povas diri, ke la agado ne estas malbona (mi aldonis la komparnormajn rezultojn sube). Esence, mi ricevis la saman agadon kiel la disko rekte, sen ia superkosto. (Ne demandu kial Portworx havas pli bonajn nombrojn ol la veturadmarko rekte. Mi ne havas ideon. Magio, mi supozas.) Do Linstor ŝajnas tre efika ĝis nun. Ĝi ne estas tiel malfacila instali, sed ĝi ne estas tiel facila kiel aliaj opcioj. Unue mi devis instali Linstor (kernmodulo kaj iloj/servoj) kaj agordi LVM por maldika provizo kaj momentfoto subteno ekster Kubernetes, rekte sur la gastiganto, kaj poste krei la rimedojn necesajn por uzi stokadon de Kubernetes. Mi ne ŝatis, ke ĝi ne funkciis ĉe CentOS kaj mi devis uzi Ubuntu. Ne terura, kompreneble, sed iom ĝena, ĉar la dokumentaro (kiu estas bonega, cetere) mencias plurajn pakaĵojn, kiuj ne troviĝas en la specifitaj deponejoj de Epel. Linstor havas momentfotojn, sed ne eksterejajn sekurkopiojn, do ĉi tie denove mi devis uzi Velero kun Restic por rezervaj volumoj. Mi preferus momentfotojn anstataŭ dosiero-nivelajn sekurkopiojn, sed ĉi tio povas esti tolerita se la solvo estas efika kaj fidinda. Linstor estas malfermkoda sed pagis subtenon. Se mi ĝuste komprenas, ĝi povas esti uzata sen limigoj, eĉ se vi ne havas subtenan kontrakton, sed ĉi tio devas esti klarigita. Mi ne scias kiom testita Linstor estas por Kubernetes, sed la stoka tavolo mem estas ekster Kubernetes kaj, ŝajne, la solvo ne aperis hieraŭ, do ĝi verŝajne jam estis provita en realaj kondiĉoj. Ĉu ekzistas ĉi tie solvo, kiu igos min ŝanĝi mian opinion kaj reveni al Kubernetes? Mi ne scias. Ni ankoraŭ bezonas fosi pli profunde kaj studi reproduktadon. Ni vidu. Sed la unua impreso estas bona. Mi certe preferus uzi miajn proprajn Kubernetes-grupojn anstataŭ Heroku por havi pli da libereco kaj lerni novajn aferojn. Ĉar Linstor ne estas tiel facile instalebla kiel aliaj, mi baldaŭ skribos afiŝon pri ĝi.
Benchmarks
Bedaŭrinde mi ne konservis multajn notojn pri la komparo ĉar mi ne pensis, ke mi skribos pri ĝi. Mi nur havas rezultojn de la bazaj fio-remarkoj kaj nur por ununodaj aretoj, do mi ankoraŭ ne havas nombrojn por reproduktitaj agordoj. Sed el ĉi tiuj rezultoj vi povas akiri malglatan ideon pri tio, kion atendi de ĉiu opcio, ĉar mi komparis ilin sur la samaj nubaj serviloj, 4 kernoj, 16 GB da RAM, kun plia 100 GB-disko por la testitaj volumoj. Mi kuris la benchmarkojn tri fojojn por ĉiu solvo kaj kalkulis la averaĝan rezulton, krome mi restarigis la servilajn agordojn por ĉiu produkto. Ĉio ĉi estas tute nescienca, nur por doni al vi ĝeneralan ideon. En aliaj provoj, mi kopiis 38 GB da fotoj kaj filmetoj de la volumo por testi legadon kaj skribadon, sed, ve, mi ne konservis la nombrojn. Mallonge: Portworkx estis multe pli rapida.
Por la voluma komparnormo mi uzis ĉi tiun manifeston:
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: 4Mi unue kreis volumon kun la taŭga stoka klaso kaj poste kuris la laboron kun fio malantaŭ la kulisoj. Mi prenis 1 GB por taksi la rendimenton kaj ne atendi tro longe. Jen la rezultoj:
Mi reliefigis la plej bonan valoron por ĉiu metriko en verda kaj la plej malbonan en ruĝa.
konkludo
Kiel vi povas vidi, en la plej multaj kazoj Portworx rezultis pli bone ol aliaj. Sed por mi ĝi estas multekosta. Mi ne scias kiom kostas Robin, sed ili havas bonegan senpagan version, do se vi volas pagitan produkton, vi povas provi ĝin (espereble ili baldaŭ riparos la problemon per restarigo kaj sekurkopioj). El la tri senpagaj, mi havis la malplej problemoj kun OpenEBS, sed ĝia agado estas terura. Domaĝe, ke mi ne konservis pli da rezultoj, sed mi esperas, ke la nombroj kaj miaj komentoj helpos vin.
fonto: www.habr.com