Eguneratu!. Iruzkinetan irakurleetako batek probatzea proposatu zuen (agian bera ari da lanean), beraz, irtenbide horri buruzko atal bat gehitu dut. Nik ere idatzi nuen prozesua gainerakoetatik oso ezberdina delako.
Egia esateko, amore eman eta amore eman nuen (oraingoz behintzat). erabiliko dut . Zergatik? Biltegiratzea dela eta! Nork pentsatuko zuen biltegiratzearekin gehiago nahastuko nintzela Kubernetesekin baino. erabiltzen dut , merkea delako eta errendimendua ona delako, eta hasiera-hasieratik klusterrak zabaldu nituen . Ez dut Google/Amazon/Microsoft/DigitalOcean etab.-en Kubernetes kudeatutako zerbitzuak probatu, dena neuk ikasi nahi nuelako. Ni ere xumea naiz.
Beraz, bai, denbora asko eman nuen Kubernetes-en pila posible bat aztertzen ari nintzenean zein biltegiratze aukeratu erabakitzen saiatzen. Kode irekiko irtenbideak nahiago ditut, eta ez bakarrik prezioagatik, baina ordainpeko aukera pare bat begiratu nituen jakin-minagatik, doako bertsioak dituztelako murrizketak. Aukera desberdinak konparatzen ari nintzenean azken erreferentzietako zenbaki batzuk apuntatu nituen, eta Kubernetesen biltegiratzea ikasten ari direnentzat interesgarriak izan daitezke. Orain arte pertsonalki Kubernetesi agur esan diodan arren. Nik ere aipatu nahi dut , zeinetan zuzenean hornitu ditzakezun Hetzner Cloud bolumenak, baina oraindik ez naiz probatu. Hodeiko softwareak definitutako biltegiratzea aztertzen ari nintzen, erreplikazioa eta edozein nodotan bolumen iraunkorrak azkar muntatzeko gaitasuna behar nuelako, batez ere nodoen hutsegiteen eta antzeko beste egoera batzuen kasuan. Soluzio batzuek momentuko argazkiak eta gunez kanpoko babeskopiak eskaintzen dituzte, eta hori erabilgarria da.
6-7 biltegiratze irtenbide probatu nituen:
Esan bezala , zerrendako aukera gehienak probatu ostean, hasieran OpenEBS-en jarri nintzen. OpenEBS oso erraza da instalatzeko eta erabiltzeko, baina egia esan, benetako datuekin kargatuta probatu ondoren, bere errendimenduak etsita ninduen. Hau kode irekia da, eta garatzaileak beren kabuz daude beti oso lagungarria laguntza behar nuenean. Zoritxarrez, oso errendimendu eskasa du beste aukerekin alderatuta, beraz, probak berriro egin behar izan ditut. Oraintxe bertan OpenEBS-k 3 biltegiratze-motor ditu, baina cStor-en erreferentziazko emaitzak argitaratzen ari naiz. Oraindik ez daukat Jiva eta LocalPVrako zenbakirik.
Laburbilduz, Jiva apur bat azkarragoa da, eta LocalPV, oro har, azkarra da, ez da diskoaren erreferentzia zuzenean baino okerragoa. LocalPV-ren arazoa da bolumena hornitu zen nodoan soilik sar daitekeela, eta ez dago batere erreplikaziorik. Arazo batzuk izan nituen babeskopia berreskuratzeko bidez kluster berrian, nodoen izenak desberdinak zirelako. Babeskopiaz hitz egitean, cStor-ek ditu , zeinekin gunez kanpoko instantziako argazkien babeskopiak egin ditzakezu, eta hori Velero-Restic-ekin fitxategi-mailako babeskopiak baino erosoagoa da. idatzi nuen plugin honekin babeskopiak eta leheneratzeak kudeatzea errazteko. Orokorrean, asko gustatzen zait OpenEBS, baina bere errendimendua...
Rook ere kode irekia da, eta zerrendako gainerako aukeretatik desberdina da biltegiratze-orkestratzaile bat delako, eta backend ezberdinekin biltegiratze-kudeaketako zeregin konplexuak egiten ditu, adibidez. , eta beste batzuk, lana asko errazten duena. Duela hilabete batzuk probatu nuenean EfgeFSrekin arazoak izan nituen, beraz, Ceph-ekin probatu nuen batez ere. Ceph-ek blokeen biltegiratzeaz gain, S3/Swift-ekin eta banatutako fitxategi sistemarekin bateragarria den objektuen biltegiratzea ere eskaintzen du. Ceph-i buruz gustatzen zaidana da bolumenaren datuak disko anitzetan zabaltzeko gaitasuna, bolumenak disko batean kabi daitekeena baino espazio gehiago erabil dezan. Erosoa da. Beste ezaugarri on bat da diskoak klusterera gehitzen dituzunean, datuak automatikoki birbanatzen dituela disko guztietan.
Ceph-ek argazkiak ditu, baina nik dakidanez ezin dira zuzenean Rook/Kubernetes-en erabili. Egia esan, ez nintzen horretan sakondu. Baina ez dago gunez kanpoko babeskopirik, beraz, Velero / Restic-ekin zerbait erabili behar duzu, baina fitxategi-mailako babeskopiak baino ez daude, ez une-uneko argazkiak. Rook-etik asko gustatzen zaidana, ordea, Ceph-ekin lan egiteko erraztasuna da: ia gauza konplexu guztiak ezkutatzen ditu eta Ceph-ekin zuzenean hitz egiteko tresnak eskaintzen ditu arazoak konpontzeko. Zoritxarrez, Ceph bolumenen estres proban, beti izan nuen , Ceph ezegonkor bilakatzea eragiten duena. Oraindik ez dago argi Ceph-en beraren akats bat den edo Rook-ek Ceph kudeatzen duen arazo bat den. Memoriaren ezarpenekin ibili nintzen, eta hobetu egin zen, baina arazoa ez zen guztiz konpondu. Ceph-ek errendimendu ona du beheko erreferentzietan ikusten den bezala. Arbel ona ere badu.
Asko gustatzen zait Longhorn. Uste dut irtenbide itxaropentsua dela. Egia da, garatzaileek beraiek (Rancher Labs) onartzen dute oraindik ez dela egokia ekoizpen ingurune baterako, eta horrek erakusten du. Kode irekia da eta errendimendu duina du (oraindik optimizatu ez duten arren), baina bolumenek oso denbora luzea behar dute ontzira lotzeko, eta kasurik txarrenetan 15-16 minutu behar izaten dira, batez ere babeskopia handi bat leheneratu ondoren edo. lan-karga berritzea. Argazki horien argazkiak eta gunez kanpoko babeskopiak ditu, baina bolumenei soilik aplikatzen zaizkie, beraz, Velero bezalako zerbait behar duzu gainerako baliabideen babeskopia egiteko. Babeskopia eta leheneratzeak oso fidagarriak dira, baina oso motelak dira. Serio, debeku motela. PUZaren erabilera eta sistemaren karga askotan igotzen dira Longhorn-en batez besteko datu-kopuru batekin lan egiten denean. Longhorn kudeatzeko panel erabilgarri bat dago. Dagoeneko esan dut Longhorn gustatzen zaidala, baina behar bezala landu behar da.
StorageOS zerrendako ordainpeko lehen produktua da. 500 GB kudeatutako biltegiratze-tamaina mugatua duen garatzaileen bertsioa du, baina ez dut uste nodo kopuruan mugarik dagoenik. Salmenta sailak esan zidan kostua hilean 125 $-tik hasten dela TB 1, ondo gogoratzen badut. Oinarrizko panel bat eta CLI erabilgarri bat daude, baina zerbait arraroa gertatzen ari da errendimenduarekin: erreferentzia batzuetan nahiko duina da, baina bolumenen estres-proban, ez zait batere gustatu abiadura. Orokorrean, ez dakit zer esan. Beraz, ez nuen benetan ulertzen. Hemen ez dago gunez kanpoko babeskopirik eta Velero ere erabili beharko duzu Restic-ekin bolumenak egiteko. Bitxia da, produktua ordainduta dagoelako. Eta garatzaileak ez ziren Slack-en komunikatzeko gogorik.
Robini buruz ikasi nuen Reddit-en beren CTOtik. Ez nuen inoiz haren berririk entzun. Agian doako irtenbideak bilatzen ari nintzelako, eta Robin ordaintzen duelako. Doako bertsio nahiko eskuzabala dute 10TB biltegiratze eta hiru nodorekin. Oro har, produktua nahiko duina eta ezaugarri politak ditu. CLI bikaina dago, baina gauzarik politena da aplikazio guztiaren argazkia eta babeskopia egin dezakezula (Helm bertsioak edo "flex aplikazioak" baliabideen hautatzailean), bolumenak eta beste baliabide batzuk barne, Velerorik gabe egin dezakezula. Eta dena zoragarria izango litzateke xehetasun txiki batengatik ez bada: kluster berri batean aplikazio bat leheneratu (edo "inportatu", Robin-en deitzen den bezala) -adibidez, hondamendia berreskuratzeko kasuan- leheneratzea, noski, funtzionatzen du, baina jarraitu aplikazioaren babeskopia egiten debekatuta dago. Argitalpen honetan, hau ez da posible, eta garatzaileek baieztatu dute. Hau bitxia da, gutxienez, batez ere beste abantaila batzuk kontuan hartzen dituzunean (adibidez, segurtasun-kopia eta leheneratzea izugarri azkarrak). Garatzaileek hurrengo bertsiorako guztia konponduko dutela hitz ematen dute. Errendimendua, oro har, ona da, baina gauza arraro bat nabaritu dut: erreferentea zuzenean ostalari atxikitako bolumen batean exekutatzen baduzu, irakurtzeko abiadura bolumen berean baino askoz handiagoa da, baina pod barrutik. Beste emaitza guztiak berdinak dira, baina teorian ez luke alderik egon behar. Lanean ari diren arren, leheneratu eta babeskopien arazoarekin zapuztu egin nintzen - azkenean irtenbide egoki bat aurkitu nuela iruditu zitzaidan, eta leku gehiago edo zerbitzari gehiago behar nuenean ere ordaintzeko prest nengoen.
Hemen ez daukat gauza handirik esateko. Ordaindutako produktua da, berdin polita eta garestia. Errendimendua harrigarria da. Orain arte hau da adierazle onena. Slack-ek esan zidan prezioak 205 $-tik hasten direla hilean nodo bakoitzeko, Google-ren GKE Marketplace-n agertzen den moduan. Ez dakit merkeagoa izango den zuzenean erosten baduzu. Dena den, ezin dut ordaindu, beraz, oso-oso etsita nengoen garatzaile-lizentzia (1TB eta 3 nodo arte) ia alferrikakoa izateak Kubernetesekin, hornikuntza estatikoarekin konformatzen ez bazara behintzat. Bolumen-lizentzia automatikoki garatzailera jaitsiko zela espero nuen probaldiaren amaieran, baina ez zen hori gertatu. Garatzaile lizentzia Docker-ekin soilik erabil daiteke zuzenean, eta Kubernetes-en konfigurazioa oso astuna eta mugatua da. Noski, nahiago dut kode irekia, baina dirua izango banu Portworx aukeratuko nuke zalantzarik gabe. Orain arte, bere errendimendua ez da beste aukerekin alderatzen.
Posta argitaratu ondoren gehitu nuen atal hau, irakurle batek Linstor probatzea proposatu zuenean. Probatu nuen eta gustatu zitzaidan! Baina oraindik zulatu behar duzu. Orain esan dezaket errendimendua ez dela txarra (erreferentziazko emaitzak behean gehituta). Izan ere, diskoaren errendimendu bera lortu nuen zuzenean, batere gasturik gabe. (Ez galdetu zergatik Portworxen zenbakiak hobeak diren diskoaren erreferentea baino zuzenean. Ez dut ideiarik. Magia, uste dut.) Beraz, Linstor oso eraginkorra dirudi orain arte. Instalatzea ez da hain zaila, baina ez beste aukerak bezain erraza. Lehenik eta behin Linstor instalatu behar izan nuen (kernel-modulua eta tresnak/zerbitzuak) eta LVM konfiguratu behar nuen Kubernetesetik kanpo hornikuntza meherako eta argazkien laguntzarako, zuzenean ostalarian, eta gero Kubernetesetik biltegiratzea erabiltzeko behar diren baliabideak sortu. Ez zitzaidan gustatu CentOSen funtzionatzen ez zuela eta Ubuntu erabili behar izatea. Ez da ikaragarria, noski, baina gogaikarri samarra, dokumentazioan (bide batez, bikaina da) zehaztutako Epel biltegietan aurkitu ezin diren hainbat pakete aipatzen direlako. Linstor-ek argazkiak ditu, baina ez dago gunetik kanpoko babeskopiarik, beraz hemen berriro Velero erabili behar izan dut Restic-ekin bolumenen babeskopia egiteko. Nahiago nuke argazki-argazkiak fitxategi-mailako babeskopien aldean, baina hau onartu daiteke irtenbidea eraginkorra eta fidagarria bada. Linstor kode irekia da baina ordainpeko laguntza du. Ongi ulertzen badut, mugarik gabe erabil daiteke, nahiz eta laguntza-kontraturik ez izan, baina hori argitu beharra dago. Ez dakit nola probatzen den Linstor Kuberneteserako, baina biltegiratze-geruza bera Kubernetesetik kanpo dago eta, antza, irtenbidea ez zen atzo agertu, eta, beraz, ziurrenik baldintza errealetan probatuta dago jada. Ba al dago hemen iritziz aldatu eta Kubernetesera bueltatuko nauen irtenbiderik? Ez dakit. Oraindik sakondu behar dugu, erreplikazioa aztertu. Ikus dezagun. Baina lehen inpresioa ona da. Zalantzarik gabe, nahiago nuke nire Kubernetes klusterrak erabiltzea Herokuren ordez askatasun gehiago izateko eta gauza berriak ikasteko. Linstor beste batzuk bezain erraz instalatzen ez denez, laster idatziko dut horri buruzko mezu bat.
Erreferentziak
Zoritxarrez, konparazioaren erregistro gutxi gorde nituen, ez nuelako uste horri buruz idatziko nuenik. Fio oinarrizko erreferentziako emaitzak baino ez ditut eta nodo bakarreko klusterretarako bakarrik, beraz, oraindik ez daukat zenbakirik errepikatutako konfigurazioetarako. Baina emaitza horietatik aukera bakoitzetik zer espero den jakin dezakezu, hodeiko zerbitzari berdinetan, 4 nukleoetan, 16 GB RAM, 100 GB-ko disko gehigarri batekin alderatu ditudalako probatutako bolumenetarako. Erreferentziak hiru aldiz exekutatu nituen soluzio bakoitzeko eta batez besteko emaitza kalkulatu nuen, baita produktu bakoitzaren zerbitzariaren ezarpenak berrezarri. Hau guztia guztiz ez-zientifikoa da, orokorrean uler dezazun. Beste probetan, bolumenetik eta irakurketa eta idazketa probatzeko 38 GB argazki eta bideo kopiatu nituen, baina, ai, ez nituen zenbakiak gorde. Laburbilduz: Portworkx askoz azkarragoa zen.
Bolumen-erreferentziarako, manifestu hau erabili dut:
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: 4Lehenik eta behin bolumen bat sortu nuen biltegiratze-klase egokiarekin, eta, ondoren, eszena atzean fio-rekin egin nuen lana. 1 GB hartu nuen errendimendua kalkulatzeko eta ez gehiegi itxaron. Hona hemen emaitzak:
Berdez nabarmendu dut metrika bakoitzaren balio onena eta gorriz txarrena.
Ondorioa
Ikus dezakezunez, kasu gehienetan Portworx-ek besteek baino hobeto aritu zen. Baina niretzat garestia da. Ez dakit zenbat kostatzen den Robinek, baina doako bertsio bikaina dago, beraz, ordaindutako produktu bat behar baduzu, probatu dezakezu (espero dut laster konponduko dutela arazoa leheneratu eta babeskopiekin). Doako hiruretatik, OpenEBSrekin izan dut arazo gutxien, baina bere errendimendua izugarria da. Sentitzen dut emaitza gehiago gorde ez izana, baina espero dut zenbakiek eta nire iruzkinek lagungarri izatea.
Iturria: www.habr.com