Storage solutions in Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Uuendus!. Üks lugejatest kommenteeris, et tasuks proovida Linstor (võib-olla töötab ta isegi selle kallal), nii et ma lisasin selle lahenduse kohta jao. Lisaks kirjutasin postituse selle installimisest, kuna protsess erineb oluliselt teistest.

Ausalt öeldes kapituleerusin ja loobusin Kubernetes (vähemalt praegu). Kasutan Heroku. Miks? Ahnuse pärast! Kes oleks arvanud, et mul on rohkem tegemist salvestustega kui Kubernetesega. Praegu kasutan Hetzner Cloud, sest see on odav ja jõudlus on hea, ning algusest peale olen klastreid seadistanud Rancher. Ma pole katsetanud Google'i/Amazoni/Microsofti/DigitalOceani jms hallatavaid Kubernetes'i teenuseid, kuna tahtsin kõike ise õppida. Ja olen ka kokkuhoidlik.

Nii et jah, kulutasin hunniku aega, püüdes välja selgitada, millist salvestust valida, kui kaalusin võimalikke stäkke Kubernetes'e jaoks. Eelistangi avatud lähtekoodiga lahendusi, mitte ainult hinna pärast, aga ka uudishimu pärast uurisin paar tasulist varianti, sest neil on tasuta versioonid piirangutega. Kirjutasin üles mõned numbrid viimastest testidest, kui võrdlesin erinevaid variante, ja need võivad huvitada inimesi, kes uurivad salvestust Kuberneteses. Kuigi isiklikult olen Kubernetesega hetkel hüvasti jätnud. Soovin veel mainida CSI draiverit, mille abil saab Hetzner Cloud'i mahtusid otse ette valmistada, kuid ma pole seda veel proovinud. Olen uurinud pilvepõhiseid programmide seadistatud salvestusi, kuna mul oli vaja replikatsiooni ja võimalust kiiresti ühenduda püsivatel mahtudel igas sõlmes, eriti sõlmede tõrgete ja muude sarnaste olukordade korral. Mõned lahendused pakuvad ajasnapse ja off site varukoopiaid, mis on mugav.

Olen testinud 6–7 salvestuslahendust:

OpenEBS

Kuidas ma juba mainisin eelmisel postitusel, testides enamikku loendist, peatun esmalt OpenEBS-il. OpenEBS on väga lihtne paigaldada ja kasutada, kuid ausalt öeldes pettusin selle jõudluses, kui testisin seda reaalse andmekoormuse all. See on avatud lähtekoodiga ja arendajad on sellel Slack'i kanalil on alati väga abiks olnud, kui mul on olnud abi vaja. Kahjuks on tema jõudlus teiste valikute kõrval väga madal, seega pidin testid uuesti läbi viima. Praegu on OpenEBS-l 3 salvestusmootorit, kuid avaldan cStor'i jõudlustestide tulemused. Hetkel pole mul andmeid Jiva ja LocalPV kohta.

Lühidalt, Jiva on natuke kiirem, samas kui LocalPV on üldse kiire, mitte halvem kui otse ketta testimine. LocalPV probleem on see, et sellele pääseb ligi ainult neil sõlmedel, kus see on ette valmistatud, ja replikatsiooni pole üldse. Mul oli mõningaid probleeme varukoopia taastamisega läbi Velero uusel klastril, kuna sõlmede nimed olid erinevad. Kui rääkida varukoopia tegemisest, siis cStor'il on Velero plugina, mis võimaldab teha off site varukoopiaid ajahetke sõlmestatud pildi kaudu, mis on mugavam kui taseme failide varukoopiad Velero-Resticuga. Olin kirjutanud mitmeid skripte, et varukoopiate ja taastamiste haldamine selle plugina kaudu oleks lihtsam. Üldiselt meeldib mulle OpenEBS väga, kuid selle jõudlus...

Rook

Rook'il on samuti avatud lähtekood, ning erinevalt ülejäänud valikutest nimekirjas on see salvestuskorraldaja, mis täidab keerulisi salvestushaldusülesandeid erinevate tagaplaanidega, näiteks Ceph, EdgeFS ja teised, mis hõlbustavad oluliselt tööd. Mul oli probleeme EdgeFS-iga, kui ma proovisin seda paar kuud tagasi, seega testisin enamasti Cephi. Ceph pakub mitte ainult plokkide salvestust, vaid ka objekti salvestust, mis on S3/Swifti ühilduv ja jaotatud failisüsteem. Mida ma Cephi juures meeldib, on selle võimalus hajutada mahtude andmeid mitmele ketale, et maht saaks kasutada rohkem kettaruumid, kui ühel ketas mahub. See on mugav. Veel üks lahe funktsioon on see, et kui lisad klastrile kettaid, jaotab see automaatselt andmed ümber kõigile ketastele.

Ceph-l on snapshots, kuid, kui ma tean, ei saa neid Rook/Kubernetes'is otse kasutada. Tõsi, ma ei ole sellesse süvenenud. Kuid off-site varukoopiad puuduvad, seega tuleb kasutada midagi Velero/Restic'uga, kuid seal on ainult failitaseme varukoopiad, mitte ajasnapshootid. Kuid mulle meeldis Rookis Ceph'i lihtne kasutamine - see varjab peaaegu kõik keerulised asjad ja pakub tööriistu, et suhelda Ceph'iga otse tõrkeotsingu eesmärgil. Kahjuks tekkis mul Ceph'i mahu stressitesti ajal pidevalt see probleem, mis muudab Ceph'i ebastabiilseks. Veel ei ole selge, kas see on Ceph'i enda viga või probleem selles, kuidas Rook Ceph'i haldab. Ma mängisin mäluseadetega ja olukord paranes, kuid probleem ei lahendatud täielikult. Ceph'il on üsna hea jõudlus, nagu näha allolevatest võrdlustest. Samuti on sellel hea jälgimisliides.

Rancher Longhorn

Mulle meeldib Longhorn väga. Minu arvates on see lubav lahendus. Tõsi, arendajad (Rancher Labs) tunnistavad, et see pole veel töökeskkonnas sobiv ja see on märgatav. Sellel on avatud lähtekood ja hea jõudlus (kuigi selle optimeerimisega nad veel tegelenud pole), kuid mahud ühenduvad podiga väga aeglaselt ja halvematel juhtudel võtab see 15–16 minutit, eriti pärast suurte varukoopiate taastamist või töökoormuse uuendamist. Sellel on snapshots ja off-site varukoopiad nendest snapshots'ist, kuid need kehtivad ainult mahtude kohta, seega on teil ikkagi vaja midagi Velero't varukoopiate tegemiseks muude ressursside jaoks. Varukoopiad ja taastamised on väga usaldusväärsed, kuid kohutavalt aeglased. Tõsiselt, täiesti üle mõistuse aeglased. Protsessorite kasutus ja süsteemi koormus tõusevad sageli keskmise andmemahtu töötades Longhorn'is. On mugav jälgimisliides, et hallata Longhorn'i. Olen juba öelnud, et mulle Longhorn meeldib, kuid selle kallal tuleb tõsiselt töötada.

StorageOS

StorageOS on esimene tasuline toode nimekirjas. Sellel on arendajate versioon, millel on piiratud hallatava salvestUSE suurus 500 GB, kuid sõlmede arv, nagu ma mäletan, ei ole piiratud. Müügiosakonnas öeldi mulle, et hind algab $125 kuus 1 TB eest, kui ma õigesti mäletan. Seal on põhipaneel jälgimiseks ja mugav CLI, kuid jõudlusega on midagi kummalist: mõnedel võrdlustel on see üsna korralik, kuid ma ei olnud mahtude stressitestis kiirusest üldse rahul. Üldiselt ei tea, mida öelda. Seetõttu ma ei uurinud eriti. Siin pole off-site varukoopiaid ja tuleb kasutada ka Velero koos Resticuga mahtude varundamiseks. Kummaline, arvestades, et toode on tasuline. Ja arendajad ei olnud ka jutuks Slackis.

selle atribuudi järgi omab mitut erinevat väärtust —

Robinist kuulsin Redditis nende tehniliselt direktorilt. Varem ei olnud ma sellest kuulnud. Võib-olla sellepärast, et otsisin tasuta lahendusi, kuid Robin on tasuline. Neil on üsna helde tasuta versioon, millel on 10 TB salvestusruumi ja kolm sõlme. Kokkuvõttes on toode täiesti väärtuslik ja meeldivate funktsioonidega. Seal on suurepärane CLI, kuid kõige ägedam on see, et saad teha snapshote ja varundusi kogu rakendusest (ressursside valikus nimetatakse seda Helm'i väljaanneteks või «flex apps'iks»), sealhulgas dokke ja teisi ressursse, nii et saan ilma Velero't kasutada. Ja kõik oleks suurepärane, kui mitte üks väike detail: kui taastada (või «importida», nagu Robin seda nimetab) rakendust uuel klastril – näiteks avarii taastamise korral – taaskäivitamine töötab, kuid rakenduse varundust ei saa jätkata. Seda versioonis lihtsalt ei ole võimalik teha, ja arendajad on kinnitanud. See on, pehmelt öeldes, imelik, eriti arvestades muid eeliseid (näiteks uskumatult kiire varundamine ja taastamine). Arendajad lubavad kõik järgmise väljaande jaoks parandada. Üldine jõudlus on hea, kuid ma märkasin imelikku asja: kui käivitada mõõdik otse dokis, mis on ühendatud hostiga, on lugemise kiirus palju suurem, kui sama dok, kuid podi seest. Kõik teised tulemused on samad, kuid teoreetiliselt ei tohiks see nii olla. Kuigi nad töötavad selle kallal, olin ma pettunud taastamise ja varundamise probleemist – tundus, et olin lõpuks leidnud sobiva lahenduse ja olin isegi valmis maksma selle eest, kui mul on rohkem ruumi või rohkem servereid.

Portworx

Siin mul ei ole eriti midagi öelda. See on tasuline toode, sama hästi valmistatud ja kallis. Jõudlus on lihtsalt suurepärane. Praegu on see parim näitaja. Slackis öeldi mulle, et hind algab 205 dollarist kuus sõlme kohta, nagu on märgitud Google GKE turul. Ma ei tea, kas see oleks odavam, kui osta otse. Igal juhul ei saa ma endale sellist lubada, seega olin väga ja väga pettunud, et arendaja litsents (kuni 1 TB ja 3 sõlme) on Kubernetesiga peaaegu kasutamatu, kui te ei lepi staatilise ettevalmistusega. Lootsin, et äri litsents langeb automaatselt arendaja tasemele prooviperioodi lõpus, aga nii ei juhtunud. Arendaja litsentsi saab kasutada ainult otse Dockeriga, ja Kubernetesis seadistamine on väga tülikas ja piiratud. Muidugi eelistan avatud lähtekoodi, aga kui mul oleks raha, valiksin kindlasti Portworxi. Praegu on selle jõudlus lihtsalt võrreldamatu teiste variantidega.

Linstor

Lisasin selle jaotuse pärast postituse avaldamist, kui üks lugeja soovitas proovida Linstor. Proovisin ja mulle meeldis! Kuid tuleb veel süveneda. Praegu oskan öelda, et jõudlus on korralik (benchmarki tulemused on allpool). Sisuliselt sain sama jõudluse nagu otse kettalt, täiesti ilma kuludeta. (Ärge küsige, miks Portworxi numbrid on paremad kui otse ketta benchmark, mul pole aimugi. Maagia, ilmselt.) Seega tundub Linstor praegu väga efektiivne. Selle paigaldamine pole just lihtne, kuid ei ole ka nii keeruline kui teised valikud. Alustuseks pidin paigaldama Linstori (tuumamoodul ja tööriistad/teenused) ja seadma LVM-i õhukese varu ja snapshotite toetamiseks Kubernetes'i väliselt, otse hostis, seejärel looma ressursid, mis on vajalikud Kubernetes'is salvestamise kasutamiseks. Mulle ei meeldinud, et see ei töötanud CentOS-is ja pidin kasutama Ubuntu't. See pole muidugi probleem, kuid natuke tüütab, kuna dokumentatsioon (see on muide suurepärane) mainib mitmeid pakette, mida ei saa leida nimetatud Epel'i hoidlatest. Linstoris on snapshot'id, kuid mitte off-site varukoopiad, seega pidin taas kasutama Velero't koos Restic'iga mahtude varundamiseks. Eelistaksin snapshot'e failitasandi varukoopiate asemel, kuid seda on võimalik taluda, kui lahendus on jõudlik ja usaldusväärne. Linstor on avatud allikakoodiga, kuid pakub tasulist tuge. Kui ma õigesti aru saan, saab seda kasutada ilma piiranguteta, isegi kui teil pole tugilepingut, kuid seda tuleb täpsustada. Ma ei tea, kui hästi on Linstor testitud Kubernetes'i jaoks, kuid salvestustase on Kubernetes'ist väljaspool, ja tundub, et lahendus pole eile ilmunud, seega on see tõenäoliselt juba reaalses keskkonnas testitud. Kas on olemas lahendus, mis paneb mind meelt muutma ja tagasi Kubernetes'i minema? Ei tea, ei tea. Pean veel uurima ja replikatsiooni läbi vaatama. Näeme. Kuid esimene mulje on hea. Eelistaksin kindlasti kasutada oma Kubernetes'i klastri Heroku asemel, et saada rohkem vabadust ja õppida uut. Kuna Linstori paigaldamine ei ole nii lihtne kui teised, kirjutan sellest peagi postituse.

Benkmarkid

Kahjuks olen salvestanud vähe salvestusi võrdlustest, kuna ei arvanud, et hakkan sellest kirjutama. Mul on vaid tulemused põhineb bench-mark'ing fio ja ainult ühe sõlmega klastrite jaoks, seega replitseeritud konfiguratsioonide jaoks ei ole mul veel numbreid. Kuid nende tulemuste põhjal saab saada umbkaudse ettekujutuse selle kohta, mida iga valik pakub, kuna võrreldes neid samade pilveserveritega, 4 tuuma, 16 GB RAM-i, lisadiskiga 100 GB testitavate mahtude jaoks. Käivitasin baasmõõdikud kolm korda iga lahenduse jaoks ja arvutasin keskmise tulemuse, lisaks lähtestasin serveri seadistused igaks tooteks. See kõik ei ole absoluutselt teaduslik, lihtsalt et saaksite üldiselt aru. Teistes testides kopeerisin 38 GB fotosid ja videoid mahult ja tagasi, et testida lugemist ja kirjutamist, kuid numbreid, kahjuks, ei salvestanud. Lühidalt öeldes: Portworkx oli märgatavalt kiirem.

Ma kasutasin selle mahendi jaoks järgmist manifesti:

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: 4

Esmalt lõin ma mahu vastava salvestusklassi ning seejärel käivitasin fio töötluse taustal. Võtsin 1 GB, et hinnata jõudlust ja mitte oodata liiga kaua. Siin on tulemused:

Olen iga mõõdiku parima väärtuse esile tõstnud rohelisega ja halvimad punasega.

Kokkuvõte

Nagu näete, näitas Portworx enamikus katsetes paremat tulemust kui teised. Kuid see on minu jaoks kallis. Ma ei tea, kui palju Robin maksab, kuid seal on suurepärane tasuta versioon, nii et kui vajate tasulist toodet, võite proovida (loodan, et nad lahendavad varsti taastamise ja varundamise probleemid). Kolmest tasuta toote puhul oli mul kõige vähem probleeme OpenEBS-iga, kuid selle jõudlus on kehv. Kahju, et ma ei salvestanud rohkem tulemusi, kuid loodan, et pakkuda on abiks esitatud numbrid ja minu kommentaarid.

Allikas: habr.com