Update!. Sa mga komento, usa sa mga magbabasa misugyot sa pagsulay (tingali siya mismo ang nagtrabaho niini) mao nga gidugangan nako ang usa ka seksyon bahin sa kini nga solusyon. nagsulat pud ko , tungod kay ang proseso lahi kaayo sa uban.
To be honest, ni give up ko ug ni give up (labing menos sa pagkakaron). akong gamiton . Ngano man? Tungod sa pagtipig! Kinsay magtuo nga mas daghan pa kog ukay-ukay sa storage kaysa sa Kubernetes mismo. akong gigamit kay barato ra ug maayo ang performance ug sukad pa sa sinugdanan nag deploy na ko ug cluster gamit . Wala nako gisulayan ang pagdumala sa mga serbisyo sa Kubernetes gikan sa Google/Amazon/Microsoft/DigitalOcean, ug uban pa, ug uban pa, tungod kay gusto nako nga makat-on sa tanan sa akong kaugalingon. Nagdaginot pud ko.
Mao nga oo, naggugol ako daghang oras sa pagsulay sa pagdesisyon kung unsang pagtipig ang pilion kung gisusi nako ang usa ka posible nga stack sa Kubernetes. Gipalabi nako ang mga solusyon sa bukas nga gigikanan, dili lamang tungod sa presyo, apan gitan-aw nako ang usa ka pares nga bayad nga kapilian tungod sa pagkamausisaon tungod kay sila adunay libre nga mga bersyon nga adunay mga limitasyon. Gisulat nako ang pipila ka mga numero gikan sa bag-o nga mga pagsulay kung gikumpara nako ang lainlaing mga kapilian, ug kini mahimong interesado sa mga nakakat-on bahin sa pagtipig sa Kubernetes. Bisan tuod ako personal nga nanamilit sa Kubernetes sa pagkakaron. Gusto usab nako isulti , nga direktang makahatag ug Hetzner Cloud nga mga volume, apan wala pa nako kini nasulayan. Akong gitan-aw ang cloud software-defined storage tungod kay nagkinahanglan ko og replikasyon ug ang abilidad sa pag-mount dayon sa mga volume sa bisan unsang node, ilabi na sa kaso sa mga node failure ug uban pang susama nga mga sitwasyon. Ang ubang mga solusyon nagtanyag og mga point-in-time nga snapshot ug off-site backups, nga sayon.
Gisulayan nako ang 6-7 nga mga solusyon sa pagtipig:
Ingon sa giingon na nako Nasulayan na ang kadaghanan sa mga kapilian gikan sa lista, una nakong gihusay ang OpenEBS. Ang OpenEBS sayon ββββkaayo nga i-install ug gamiton, apan sa tinuod, human sa pagsulay sa tinuod nga datos ubos sa load, nasagmuyo ako sa performance niini. Kini mao ang bukas nga tinubdan, ug ang mga developers sa ilang kaugalingon kanunay nga makatabang kaayo kung kinahanglan nako ang tabang. Ikasubo, kini adunay dili maayo nga pasundayag kung itandi sa ubang mga kapilian, mao nga ang mga pagsulay kinahanglan nga ipadagan pag-usab. Ang OpenEBS sa pagkakaron adunay 3 ka storage engine, apan nag-post ko og mga resulta sa benchmark para sa cStor. Wala pa koy numero para sa Jiva ug LocalPV.
Sa laktod nga pagkasulti, ang Jiva usa ka gamay nga mas paspas, ug ang LocalPV kasagaran paspas, dili mas grabe pa sa disk benchmark nga direkta. Ang problema sa LocalPV mao nga ang gidaghanon ma-access lamang sa node diin kini giandam, ug wala'y replikasyon. Ako adunay pipila ka mga problema sa pagpasig-uli sa usa ka backup pinaagi sa sa usa ka bag-ong cluster tungod kay ang mga ngalan sa node lahi. Kung maghisgot kita bahin sa mga backup, ang cStor adunay , diin mahimo nimo ang mga pag-backup sa gawas sa site sa mga snapshot sa usa ka punto sa oras, nga labi ka kombenyente kaysa mga pag-backup sa lebel sa file nga adunay Velero-Restic. nagsulat ko , aron mas dali ang pagdumala sa mga pag-backup ug pag-uli gamit kini nga plugin. Sa kinatibuk-an, ganahan kaayo ko sa OpenEBS, pero ang performance niini...
Ang Rook bukas usab nga gigikanan ug lahi sa ubang mga kapilian sa lista tungod kay kini usa ka orkestra sa pagtipig nga nagpahigayon mga komplikado nga buluhaton sa pagdumala sa pagtipig nga adunay lainlaing mga backend, pananglitan. , ug uban pa, nga nagpayano pag-ayo sa trabaho. Naa koy mga problema sa EfgeFS sa dihang gisulayan nako kini pipila ka bulan ang milabay, mao nga gisulayan nako ang kadaghanan sa Ceph. Ang Ceph dili lamang nagtanyag sa block storage, apan ang object storage compatible sa S3/Swift ug distributed file system. Ang gusto nako bahin sa Ceph mao ang abilidad sa pagsabwag sa mga datos sa volume sa daghang mga disk aron ang volume makagamit ug daghang espasyo sa disk kaysa mahimong mohaum sa usa ka disk. Kini komportable. Ang laing cool nga bahin mao nga kung imong idugang ang mga disk sa usa ka kumpol, awtomatiko nga ipang-apod-apod ang datos sa tanan nga mga disk.
Naay snapshots ni Ceph pero sa akong nahibaw-an, dili pwede diretso sa Rook/Kubernetes. Tinuod, wala ko lalim niini. Apan wala'y mga pag-backup sa gawas sa site, mao nga kinahanglan nimo nga gamiton ang usa ka butang sa Velero / Restic, apan adunay mga pag-backup sa lebel sa file, dili point-in-time nga mga snapshot. Ang nakagusto gyud nako sa Rook mao kung unsa kadali ang pagtrabaho kauban si Ceph - gitago niini ang halos tanan nga komplikado nga mga butang ug nagtanyag mga himan aron direktang makigsulti kang Ceph para sa pag-troubleshoot. Ikasubo, sa panahon sa stress test sa mga volume sa Ceph, nagpadayon ako nga adunay mga problema , nga maoy hinungdan sa pagkadili lig-on ni Ceph. Dili pa klaro kung kini usa ka bug sa Ceph mismo o usa ka problema sa paagi sa pagdumala ni Rook kang Ceph. Gisusi nako ang mga setting sa memorya, ug kini nahimong mas maayo, apan ang problema wala masulbad sa hingpit. Si Ceph adunay disente nga pasundayag, ingon sa imong makita sa mga benchmark sa ubos. Kini usab adunay usa ka maayo nga dashboard.
Ganahan kaayo ko sa Longhorn. Sa akong opinyon, kini usa ka maayong solusyon. Tinuod, ang mga nag-develop mismo (Rancher Labs) miangkon nga dili pa kini angay alang sa pagtrabaho nga palibot, ug kini nagpakita. Kini mao ang bukas nga tinubdan ug adunay desente nga performance (bisan tuod sila wala pa optimized niini), apan ang mga volume nagkinahanglan og usa ka kaayo nga taas nga panahon sa pagkonektar sa pod, ug sa pinakagrabe nga mga kaso kini nagkinahanglan 15-16 minutos, ilabi na human sa pagpasig-uli sa usa ka dako nga backup o pag-upgrade sa workload. Kini adunay mga snapshot ug off-site nga pag-backup niini nga mga snapshot, apan kini magamit lamang sa mga volume, mao nga kinahanglan nimo ang usa ka butang sama sa Velero sa pag-backup sa ubang mga kapanguhaan. Ang mga pag-backup ug pag-uli kasaligan kaayo, apan hinay kaayo. Seryoso, hinay ra kaayo. Ang paggamit sa CPU ug ang load sa sistema kanunay nga motaas kung nagtrabaho sa usa ka medium nga kantidad sa datos sa Longhorn. Adunay usa ka kombenyente nga dashboard sa pagdumala sa Longhorn. Nakaingon na ko nga ganahan ko sa Longhorn, pero nagkinahanglan kini og trabaho.
Ang StorageOS mao ang una nga bayad nga produkto sa lista. Kini adunay bersyon sa developer nga adunay limitado nga gidumala nga gidak-on sa pagtipig nga 500GB, apan wala ako maghunahuna nga adunay limitasyon sa gidaghanon sa mga node. Gisultihan ako sa departamento sa pagbaligya nga ang gasto magsugod sa $125 matag bulan alang sa 1 TB, kung husto ang akong nahinumduman. Adunay usa ka sukaranan nga dashboard ug usa ka kombenyente nga CLI, apan adunay usa ka butang nga katingad-an nga nagpadayon sa pasundayag: sa pipila nga mga benchmark kini medyo disente, apan sa pagsulay sa tensiyon sa gidaghanon dili nako gusto ang katulin. Sa kinatibuk-an, wala ko kabalo unsay isulti. So wala kaayo ko kasabot. Walaβy mga pag-backup sa off-site dinhi ug kinahanglan nimo usab nga gamiton ang Velero nga adunay Restic sa pag-backup sa mga volume. Kini talagsaon, tungod kay ang produkto gibayran. Ug ang mga nag-develop dili gusto nga makigsulti sa Slack.
Nahibal-an nako ang bahin ni Robin sa Reddit gikan sa ilang teknikal nga direktor. Wala pa ko makadungog bahin niya kaniadto. Tingali tungod kay nangita ko og libre nga mga solusyon, apan si Robin gibayran. Sila adunay usa ka medyo manggihatagon nga libre nga bersyon nga adunay 10TB nga pagtipig ug tulo ka mga node. Sa kinatibuk-an, ang produkto medyo disente ug adunay nindot nga mga bahin. Adunay usa ka maayo nga CLI, apan ang labing cool nga butang mao nga mahimo nimong i-snapshot ug i-backup ang tibuuk nga aplikasyon (sa tigpili sa kapanguhaan gitawag kini nga pagpagawas sa Helm o "flex apps"), lakip ang mga volume ug uban pang mga kapanguhaan, aron mahimo nimo nga wala si Velero. Ug ang tanan mahimong katingad-an kung dili alang sa usa ka gamay nga detalye: kung imong ibalik (o "import", ingon nga kini gitawag sa Robin) usa ka aplikasyon sa usa ka bag-ong cluster - pananglitan, kung adunay pagkaayo gikan sa usa ka katalagman - ang pagpahiuli, siyempre, nagtrabaho, apan magpadayon sa pag-back up sa aplikasyon nga kini gidili. Dili kini mahimo sa kini nga pagpagawas, ingon nga gikumpirma sa mga developer. Kini mao, sa pagbutang niini sa malumo, katingad-an, ilabi na sa pagkonsiderar sa uban nga mga bentaha (pananglitan, hilabihan ka paspas nga pag-backup ug pag-uli). Ang mga nag-develop nagsaad nga ayohon ang tanan sa sunod nga pagpagawas. Ang pasundayag sa kasagaran maayo, apan akong namatikdan ang usa ka katingad-an: kung akong ipadagan ang benchmark direkta sa usa ka volume nga gilakip sa host, ang katulin sa pagbasa labi ka paspas kaysa pagpadagan sa parehas nga volume gikan sa sulod sa pod. Ang tanan nga uban nga mga resulta managsama, apan sa teorya kinahanglan nga walay kalainan. Bisan kung gitrabaho nila kini, nasuko ako bahin sa problema sa pagpasig-uli ug pag-backup - naghunahuna ko nga sa katapusan nakit-an nako ang usa ka angay nga solusyon, ug andam pa ako nga mobayad niini kung kinahanglan nako ang daghang espasyo o daghang mga server.
Wala kaayo koy ikasulti dinhi. Kini usa ka bayad nga produkto, parehas nga cool ug mahal. Ang pasundayag talagsaon lang. Kini ang labing kaayo nga timailhan hangtod karon. Gisultihan ako ni Slack nga ang presyo magsugod sa $205 matag bulan matag node, ingon nga gilista sa GKE Marketplace sa Google. I don't know kung mas barato ba kung mupalit ka direkta. Dili pa nako makaya, mao nga nasagmuyo kaayo ko nga ang lisensya sa developer (hangtod sa 1 TB ug 3 node) halos walaβy kapuslanan sa Kubernetes gawas kung kontento ka sa static nga paghatag. Naglaum ko nga ang lisensya sa volume awtomatikong mag-downgrade sa developer sa katapusan sa panahon sa pagsulay, apan wala kana mahitabo. Ang lisensya sa developer mahimo ra nga magamit direkta sa Docker, ug ang pag-configure sa Kubernetes labi ka hago ug limitado. Siyempre, mas gusto nako ang open source, pero kung naa koy kwarta, pilion gyud nako ang Portworx. Sa pagkakaron, ang pasundayag niini dili ikumpara sa ubang mga kapilian.
Gidugang nako kini nga seksyon pagkahuman sa pagmantala sa post, kung gisugyot sa usa ka magbabasa nga sulayan ang Linstor. Gisulayan nako kini ug ganahan ko niini! Apan kinahanglan pa natong tun-an pag-ayo. Karon makaingon ko nga ang pasundayag dili daotan (akong gidugang ang mga resulta sa benchmark sa ubos). Sa tinuud, nakuha nako ang parehas nga pasundayag sama sa direkta nga disk, nga walaβy bisan unsang overhead. (Ayaw pangutana kon nganong ang Portworx adunay mas maayo nga mga numero kay sa drive benchmark direkta. Wala koy ideya. Magic, sa akong hunahuna.) Busa Linstor daw epektibo kaayo sa pagkakaron. Dili kini lisud i-install, apan dili kini kadali sama sa ubang mga kapilian. Una kinahanglan nako nga i-install ang Linstor (kernel module ug mga himan / serbisyo) ug i-configure ang LVM alang sa nipis nga paghatag ug suporta sa snapshot sa gawas sa Kubernetes, direkta sa host, ug dayon paghimo sa mga kapanguhaan nga gikinahanglan aron magamit ang pagtipig gikan sa Kubernetes. Dili ko ganahan nga wala kini nagtrabaho sa CentOS ug kinahanglan nako nga gamiton ang Ubuntu. Dili makalilisang, siyempre, apan medyo makalagot, tungod kay ang dokumentasyon (nga maayo kaayo, sa dalan) naghisgot sa daghang mga pakete nga dili makit-an sa gipiho nga mga repositoryo sa Epel. Ang Linstor adunay mga snapshot, apan dili mga pag-backup sa gawas sa site, mao nga dinhi kinahanglan nako nga gamiton ang Velero nga adunay Restic sa pag-backup sa mga volume. Mas gusto nako ang mga snapshot imbes nga mga pag-backup sa lebel sa file, apan mahimo kini nga itugot kung ang solusyon maayo ug kasaligan. Ang Linstor bukas nga tinubdan apan adunay bayad nga suporta. Kung nasabtan nako sa husto, mahimo kini gamiton nga walaβy mga pagdili, bisan kung wala ka usa ka kontrata sa suporta, apan kini kinahanglan nga ipatin-aw. Wala ko mahibal-an kung giunsa ang pagsulay sa Linstor alang sa Kubernetes, apan ang layer sa pagtipig mismo naa sa gawas sa Kubernetes ug, dayag, ang solusyon wala makita kagahapon, mao nga tingali nasulayan na kini sa tinuud nga mga kahimtang. Aduna bay solusyon dinhi nga makapausab sa akong hunahuna ug mobalik sa Kubernetes? Wala ko kabalo. Kinahanglan pa nato nga magkalot ug mas lawom ug magtuon sa replikasyon. Tan-awon nato. Apan ang unang impresyon maayo. Gusto gyud nako nga gamiton ang akong kaugalingon nga mga kumpol sa Kubernetes imbes nga Heroku aron adunay dugang nga kagawasan ug makakat-on og bag-ong mga butang. Tungod kay ang Linstor dili ingon kadali nga i-install sama sa uban, magsulat ako usa ka post bahin niini sa dili madugay.
Mga sukaranan
Ikasubo, wala ako magtipig daghang mga nota bahin sa pagtandi tungod kay wala ako maghunahuna nga isulat ko kini. Naa ra koy resulta gikan sa basic fio benchmarks ug para lang sa single node clusters, mao nga wala pa koy numero para sa gisundog nga mga configuration. Apan gikan sa kini nga mga sangputanan mahimo ka makakuha usa ka dili maayo nga ideya kung unsa ang madahom gikan sa matag kapilian, tungod kay gitandi ko sila sa parehas nga mga server sa panganod, 4 nga mga core, 16 GB sa RAM, nga adunay dugang nga 100 GB nga disk alang sa nasulayan nga mga volume. Gidagan nako ang mga benchmark tulo ka beses alang sa matag solusyon ug gikalkula ang kasagaran nga resulta, dugang nga gi-reset nako ang mga setting sa server alang sa matag produkto. Kining tanan hingpit nga dili siyentipikanhon, aron lang mahatagan ka og kinatibuk-ang ideya. Sa ubang mga pagsulay, gikopya nako ang 38 GB nga mga litrato ug video gikan sa volume ug gisulayan ang pagbasa ug pagsulat, apan, alaut, wala nako gitipig ang mga numero. Sa laktud: Ang Portworkx mas paspas.
Alang sa benchmark sa volume gigamit nako kini nga 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: 4Una nakong gihimo ang usa ka volume nga adunay angay nga klase sa pagtipig ug dayon gipadagan ang trabaho nga adunay fio sa luyo sa mga talan-awon. Gikuha nako ang 1 GB aron mabanabana ang pasundayag ug dili maghulat ug dugay. Ania ang mga resulta:
Gipasiugda nako ang labing kaayo nga kantidad sa matag sukatan sa berde ug ang labing daotan sa pula.
konklusyon
Sama sa imong nakita, sa kadaghanan nga mga kaso ang Portworx mas maayo kaysa sa uban. Pero para nako mahal. Wala ko mahibal-an kung pila ang gasto ni Robin, apan sila adunay usa ka maayo nga libre nga bersyon, mao nga kung gusto nimo ang usa ka bayad nga produkto, mahimo nimong sulayan kini (hinaut nga masulbad nila ang problema sa pag-uli ug pag-backup sa dili madugay). Sa tulo nga libre, ako adunay labing gamay nga mga problema sa OpenEBS, apan ang pasundayag niini dili maayo. Sayang wala ko naka save ug resulta pero hinaot makatabang ni sa imoha ang mga numero ug comment nako.
Source: www.habr.com