Update!. One of the readers suggested trying (perhaps he is working on it himself), so I added a section about this solution. I also wrote , because the process is quite different from others.
To be honest, I gave up and turned away from (for now at least). I will use . Why? Because of storage! Who would have thought I would spend more time on storage than on Kubernetes itself. I'm using , because it's inexpensive and performs well, and right from the start I deployed clusters using . I haven't tried managed Kubernetes services from Google/Amazon/Microsoft/DigitalOcean, and others, because I wanted to learn everything myself. And I'm also cost-conscious.
So yes, I spent a lot of time trying to decide which storage to choose when I was estimating a possible stack on Kubernetes. I prefer open-source solutions, not only because of the price, but I also explored a couple of paid options out of curiosity, because they offer free versions with limitations. I noted some figures from my recent tests comparing different options, which may interest those exploring storage in Kubernetes. Although personally, for now, I've parted ways with Kubernetes. I also want to mention , which allows you to prepare Hetzner Cloud volumes directly, but I haven't tried it yet. I studied cloud software-defined storage because I needed replication and the ability to quickly attach persistent volumes to any node, especially in case of node failures and similar situations. Some solutions offer snapshots at a point in time and offsite backups, which is convenient.
I tested 6-7 storage solutions:
As I mentioned , after testing most options from the list, I initially settled on OpenEBS. OpenEBS is very easy to install and use, but to be honest, after tests with real data under load, its performance disappointed me. It's open-source, and the developers are on their kanë gjithmonë shumë të ndihmojnë, kur kam pasur nevojë për ndihmë. Fatkeqësisht, ai ka një performancë shumë të ulët në krahasim me opsionet e tjera, prandaj pata nevojë të bëja testet përsëri. Tani OpenEBS ka 3 motorë ruajtjeje, por po publikoj rezultatet e benchmarkut për cStor. Nuk kam ende numra për Jiva dhe LocalPV.
Në dy fjalë, Jiva është pak më e shpejtë, ndërsa LocalPV është vërtet e shpejtë, ashtu si benchmark-u i diskut direkt. Problemi me LocalPV është se aksesin mund ta fitosh vetëm në nodën ku është përgatitur, dhe nuk ka replikim. Kam pasur disa probleme me rikuperimin e backup-it për në klusterin e ri, sepse emrat e nodës ishin të ndryshëm. Nëse flasim për backup-et, cStor ka , me të cilin mund të bësh backup-e off-site të snapshot-eve në një moment të caktuar, që është më e përshtatshme se backup-et në nivelin e skedarëve me Velero-Restic. Kam shkruar , për ta bërë më të lehtë menaxhimin e backup-eve dhe rikuperimeve me këtë plugin. Në përgjithësi, më pëlqen shumë OpenEBS, por performanca e tij...
Rook gjithashtu ka kod të hapur, dhe nga opsionet e tjera në listë, ai dallon sepse është një orkestrues ruajtjeje, i cili kryen detyra të komplikuara për menaxhim ruajtjeje me backend të ndryshme, për shembull , dhe të tjera, që e bën punën shumë më të lehtë. Kam pasur probleme me EfgeFS, kur e provova disa muaj më parë, kështu që kam testuar kryesisht me Ceph. Ceph ofron jo vetëm ruajtje bllokësh, por edhe ruajtje objektesh, e cila është e përputhshme me S3/Swift dhe një sistem skedarësh të shpërndarë. Ajo që më pëlqen në Ceph është mundësia për të shpërndarë të dhënat e volumit në disa disqe, kështu që volumi mund të përdorë më shumë hapësirë disku sesa mund të ruhet në një disk të vetëm. Kjo është e dobishme. Një veçori tjetër e shkëlqyer është që kur shton disqe në kluster, ai automatikisht riban të dhënat në të gjitha disqet.
Ceph ka snapshotet, por, sa e njohur, nuk mund tĂ« pĂ«rdoren drejtpĂ«rdrejt nĂ« Rook/Kubernetes. MegjithatĂ«, nuk jam thelluar shumĂ« nĂ« kĂ«tĂ«. Nuk ka backup off-site, kĂ«shtu qĂ« do tĂ« duhet tĂ« pĂ«rdorĂ«sh diçka me Velero/Restic, por aty janĂ« vetĂ«m backupet nĂ« nivelin e skedarĂ«ve dhe jo snapshotet nĂ« njĂ« moment tĂ« caktuar. MegjithatĂ«, mĂ« pĂ«lqeu shumĂ« puna e thjeshtĂ« me Ceph nĂ« Rookâai fsheh pothuajse tĂ« gjithĂ« gjĂ«rat e komplikuara dhe ofron mjete pĂ«r tĂ« komunikuar drejtpĂ«rdrejt me Ceph pĂ«r tĂ« zgjidhur problemet. FatkeqĂ«sisht, gjatĂ« testimit tĂ« stresit tĂ« volumit tĂ« Ceph, kam pasur vazhdimisht , i cili e bĂ«n Ceph tĂ« paqĂ«ndrueshĂ«m. Deri tani nuk Ă«shtĂ« e qartĂ« nĂ«se Ă«shtĂ« njĂ« defekt nĂ« vetĂ« Ceph ose njĂ« problem me mĂ«nyrĂ«n se si Rook menaxhon Ceph. Kisha luajtur me konfigurimet e memories dhe u bĂ« mĂ« mirĂ«, por problemi nuk u zgjodh plotĂ«sisht. Ceph ka njĂ« performancĂ« tĂ« mirĂ«, siç dallohet nga benchmark-et mĂ« poshtĂ«. Po ashtu, ka njĂ« panel tĂ« mirĂ« monitorimi.
MĂ« pĂ«lqen shumĂ« Longhorn. Mendoj se Ă«shtĂ« njĂ« zgjidhje e perspektivĂ«s. MegjithatĂ«, vetĂ« zhvilluesit (Rancher Labs) pranojnĂ« se pĂ«r ambientin e punĂ«s nuk Ă«shtĂ« ende i pĂ«rshtatshĂ«m, dhe kjo Ă«shtĂ« e dukshme. Ka burim tĂ« hapur dhe performancĂ« tĂ« mirĂ« (pavarĂ«sisht qĂ« ende nuk kanĂ« punuar nĂ« optimizimin e saj), por volumet lidhĂ«n shumĂ« ngadalĂ« me podin, duke zgjatur deri nĂ« 15â16 minuta, sidomos pas rikuperimit tĂ« njĂ« backup-i tĂ« madh ose pĂ«rmirĂ«simit tĂ« ngarkesĂ«s sĂ« punĂ«s. Ka snapshotet dhe backupet off-site tĂ« kĂ«tyre snapshot-eve, por ato shtrihen vetĂ«m pĂ«r volumin, kĂ«shtu qĂ« ende do tĂ« duhet diçka si Velero pĂ«r backupin e burimeve tĂ« tjera. Backupet dhe rikuperimet janĂ« shumĂ« tĂ« besueshme, por jashtĂ«zakonisht tĂ« ngadalta. MarrĂ«dhĂ«nia me resurset e procesorit dhe ngarkesa e sistemit shpesh rriten kur punon me njĂ« sasi mesatare tĂ« tĂ« dhĂ«nave nĂ« Longhorn. Ka njĂ« panel monitorimi tĂ« pĂ«rshtatshĂ«m pĂ«r tĂ« menaxhuar Longhorn. Kisha thĂ«nĂ« qĂ« mĂ« pĂ«lqen Longhorn, por duhet tĂ« punohet mirĂ« mbi tĂ«.
StorageOS është prodotti i parë me pagesë në listë. Ka një version për zhvilluesit me një madhësi të kufizuar të ruajtjes së menaxhuar prej 500 GB, por numri i nyjeve, mendoj, nuk është i kufizuar. Në departamentin e shitjeve më thanë se çmimi fillon nga 125 dollarë në muaj për 1 TB, nëse e mbaj mend saktë. Ka një panel bazë monitorimi dhe një CLI të përshtatshëm, por performanca duket ka ndodhur diçka e çuditshme: në disa testime renditjeje është mjaft e pranueshme, por në testin e stresit të volumeve, shpejtësia më la shumë për të dëshiruar. Në thelb, nuk e di çfarë të them. Prandaj nuk e kam shqyrtuar shumë. Këtu nuk ka kopje rezervë off site dhe do të duhet të përdor Velero me Restic për kopjimin e volumeve. E çuditshme, pasi produkti është me pagesë. Dhe gjithashtu zhvilluesit nuk kishin dëshirë të komunikonin në Slack.
MĂ«sova pĂ«r Robin nĂ« Reddit nga drejtori i tyre teknik. Nuk kisha dĂ«gjuar ndonjĂ«herĂ« pĂ«r tĂ«. Ndoshta sepse kĂ«rkoja zgjidhje falas, ndĂ«rsa Robin Ă«shtĂ« me pagesĂ«. Ata kanĂ« njĂ« version tĂ« lirĂ« mjaft bujar me njĂ« ruajtje prej 10 TB dhe tre node. NĂ« pĂ«rgjithĂ«si, produkti Ă«shtĂ« mjaft i mirĂ« dhe me funksione tĂ« kĂ«ndshme. Ka njĂ« CLI tĂ« shkĂ«lqyer, por mĂ« e mira Ă«shtĂ« se mund tĂ« bĂ«ni njĂ« snapshot dhe backup tĂ« gjithĂ« aplikacionit (nĂ« selektorin e burimeve quhet lĂ«shime Helm ose "flex apps"), duke pĂ«rfshirĂ« volumin dhe burime tĂ« tjera, kĂ«shtu qĂ« mund tĂ« kaloni pa Velero. Dhe do tĂ« ishte gjithçka e shkĂ«lqyer, nĂ«se nuk do tĂ« ishte pĂ«r njĂ« detaj tĂ« vogĂ«l: nĂ«se rikthehet (ose "importohet", siç quhet nĂ« Robin) njĂ« aplikacion nĂ« njĂ« klaster tĂ« ri â pĂ«r shembull, nĂ« rastin e rikuperimit pas njĂ« katastrofe â rikthimi, sigurisht, punon, por nuk mund tĂ« vazhdojĂ« backup-i i aplikacionit. NĂ« kĂ«tĂ« lĂ«shim, kjo thjesht nuk Ă«shtĂ« e mundur, dhe zhvilluesit e konfirmuan. Kjo, pĂ«r ta thĂ«nĂ« butĂ«, Ă«shtĂ« e çuditshme, veçanĂ«risht kur merrni parasysh avantazhet e tjera (pĂ«r shembull, backup-et dhe rikthimet jashtĂ«zakonisht tĂ« shpejta). Zhvilluesit premtojnĂ« se do tĂ« korrigjojnĂ« gjithçka deri nĂ« lĂ«shimin e ardhshĂ«m. Performanca, nĂ« pĂ«rgjithĂ«si, Ă«shtĂ« e mirĂ«, por vura re njĂ« çuditĂ«ri: nĂ«se ekzekuton njĂ« benchmark direkt nĂ« volum, tĂ« lidhur me hostin, shpejtĂ«sia e leximit Ă«shtĂ« shumĂ« mĂ« e lartĂ« se nĂ« tĂ« njĂ«jtin volum, por brenda pod-it. TĂ« gjitha rezultatet e tjera janĂ« identike, por nĂ« teori nuk duhet tĂ« ketĂ« ndonjĂ« ndryshim. Edhe pse po punojnĂ« mbi kĂ«tĂ«, isha i shqetĂ«suar pĂ«r problemin me rikthimin dhe backup-in â mĂ« dukej se pĂ«rfundimisht kisha gjetur zgjidhjen e duhur, dhe isha madje i gatshĂ«m tĂ« paguaja pĂ«r tĂ«, kur tĂ« mĂ« duhej mĂ« shumĂ« hapĂ«sirĂ« apo mĂ« shumĂ« servera.
Këtu nuk kam shumë për të thënë. Ky është një produkt me pagesë, po aq i klasës së lartë sa i kushtueshëm. Përshtatshmëria është thjesht mrekulli. Deri më tani, ky është treguesi më i mirë. Në Slack më thanë se çmimi fillon nga 205 dollarë në muaj për nod, siç është e shënuar në tregun e GKE të Google. Nuk e di nëse do të jetë më lirë nëse blihet direkt. Në çdo rast, nuk mund ta lejoj dot një gjë të tillë, ndaj u ndjeva shumë dhe shumë i zhgënjyer që licenca e zhvilluesit (deri në 1 TB dhe 3 nod) është praktikisht e paefektshme me Kubernetes, përveç nëse jeni të kënaqur me përgatitjen statike. Shpresoja se licenca e korporatës do të kalonte automatikisht në nivelin e zhvilluesit në fund të periudhës provuese, por nuk ndodhi. Licenca e zhvilluesit mund të përdoret vetëm drejtpërdrejt me Docker, dhe konfigurimi në Kubernetes është shumë i komplikuar dhe i kufizuar. Sigurisht, preferoj open source, por po të kisha para, do të zgjidhja me siguri Portworx. Deri tani, përformanca e tij është thjesht e pa krahasueshme me opsionet e tjera.
E shtova këtë seksion pas publikimit të postit, kur një lexues sugjeroi të provonim Linstor. E provova dhe më pëlqeu! Por duhet të hulumtoj më shumë. Tani mund të them se performanca është e kënaqshme (rezultatet e benchmarkut i kam shtuar më poshtë). Në thelb, mora të njëjtën performancë si me diskun e drejtpërdrejtë, pa asnjë humbje. (Mos pyesni pse numrat për Portworx janë më të mirë se benchmarku i diskut të drejtpërdrejtë. Nuk e di. Magji, ndoshta.) Pra, Linstor deri tani duket shumë efikase. Instalimi i tij nuk është aspak i thjeshtë, por as shumë i vështirë si opsionet e tjera. Fillimisht, më duhej të instaloj Linstor (moduli i bërthamës dhe mjetet/ shërbimet) dhe të konfiguroj LVM për thin provisioning dhe mbështetje për snapshotet jashtë Kubernetes, direkt në host, pastaj të krijoj burimet e nevojshme për të përdorur magazinën nga Kubernetes. Nuk më pëlqeu që nuk funksionoi në CentOS dhe më duhej të përdorja Ubuntu. Nuk është tragjike, sigurisht, por është pak e bezdisshme, sepse në dokumentacion (i cili, për rastin e parë, është shumë i mirë) përmenden disa paketa që nuk mund të gjej në repositorët e shënuar Epel. Në Linstor ka snapshotet, por jo backup-e off site, kështu që këtu isha sërish i detyruar të përdor Velero me Restic për backup-et e volumit. Do të preferoja snapshotet në vend të backup-eve në nivel skedari, por këtë mund ta pranosh nëse zgjidhja është e fuqishme dhe e besueshme. Linstor ka burim të hapur, por ka mbështetje me pagesë. Nëse kuptoj drejt, mund ta përdorësh pa kufizime, edhe nëse nuk ke një marrëveshje mbështetjeje, por kjo duhet të sqarohen. Nuk e di sa e testuar është Linstor për Kubernetes, por niveli i ruajtjes është jashtë Kubernetes dhe, duket se zgjidhja nuk ka dalë dje, kështu që ndoshta është testuar në kushte reale. Ka ndonjë zgjidhje këtu që do të më bëjë të rishikoj dhe të kthehem te Kubernetes? Nuk e di, nuk e di. Duhet të hap një hulumtim më të thellë, të studioj replikimin. Do të shohim. Por përshtypja e parë është e mirë. Unë përfundimisht do të preferoja të përdorja klastra të mia Kubernetes në vend të Heroku, për të fituar më shumë liri dhe për të mësuar të reja. Duke qenë se instalimi i Linstor nuk është aq i lehtë sa të tjerat, së shpejti do të shkruaj një postim rreth kësaj.
Benchmark
Fatkeqësisht, kam ruajtur pak të dhëna krahasuese, sepse nuk mendova se do të shkruaja për këtë. Kam vetëm rezultatet e benchmark-ëve bazikë fio dhe për klasterët me një nod, kështu që për konfigurimet e replikuara nuk kam ende numra. Por nga këto rezultate mund të merrni një ide të përafërt se çfarë të prisni nga çdo opsion, sepse i kam krahasuar ato në serverë të njëjtë në cloud, 4 bërthama, 16 GB RAM, me një disk shtesë 100 GB për volumet e testuara. Kam kryer benchmark-ët tri herë për çdo zgjidhje dhe kam llogaritur rezultatin mesatar, përveç se kam rikuperuar konfigurimet e serverit për çdo produkt. Të gjitha këto nuk janë aspak shkencore, vetëm në mënyrë që të kuptoni në vijimësi. Në teste të tjera kam kopjuar 38 GB foto dhe video nga volumi dhe dhe në, për të testuar leximin dhe shkrimin, por fatkeqësisht nuk ruajta numrat. Në përmbledhje: Portworx ishte shumë më i shpejtë.
Për benchmark-un e volumit kam përdorur këtë 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: 4Së pari krijova një volum me klasën përkatëse të ruajtjes, pastaj bëra një punë me fio në sfond. Zgjodha 1 GB, për të llogaritur performancën dhe për të mos pritur shumë gjatë. Ja rezultatet:
Kam theksuar vlerën më të mirë për çdo tregues me të gjelbër, dhe më të keqen me të kuqe.
PĂ«rfundim
Siç mund ta shihni, në shumicën e rasteve Portworx u tregua më mirë se të tjerët. Por për mua është i shtrenjtë. Nuk e di sa kushton Robin, por ka një version të shkëlqyer falas, kështu që, nëse ju nevojitet një produkt i paguar, mund ta provoni (shpresoj se së shpejti do të riparojnë problemin me rikuperimin dhe backup-et). Nga tre falas, kam pasur më pak probleme me OpenEBS, por performanca e tij është e keqe. Më vjen keq që nuk ruajta më shumë rezultate, por shpresoj se numrat e dhëna dhe komentet e mia do t'ju ndihmojnë.
Burimi: habr.com
