🥇Konteinerite salvestusruumid Kuberneteses: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Uuendus!. Üks lugejatest pakkus kommentaarides proovida Linstor (võib-olla töötab ta ise selle kallal), nii et lisasin jao selle lahenduse kohta. Samuti kirjutasin postituse selle installimisest, sest protsess on oluliselt erinev teistest.

Ausalt öeldes loobusin ma ja ei kasuta enam Kubernetes (iga juhul vähemalt seni). Kasutan Heroku. Miks? Sellepärast, et salvestus! Kes oleks võinud arvata, et ma pean rohkem tegelema salvestustega kui Kubernetesega. Kasutan Hetzner Cloud, sest see on odav ja jõudlus on hea, ning alguspealdisest alates olen klastreid juurutanud Rancher. Ma ei ole proovinud Google'i/Amazoni/Microsofti/DigitalOceani jpm hallatavaid Kubernetes teenuseid, sest soovisin kõike ise õppida. Ja ma olen ka säästlik.

Nii et jah, ma kulutasin palju aega, püüdes otsustada, millist salvestust valida, kui mõtlesin Kubernetese võimaliku teeki üle. Eelistangi avatud lähtekoodiga lahendusi, ja mitte ainult hinna pärast, vaid uurisin paar-kolm tasulist varianti ka huvi pärast, kuna neil on piiratud tasuta versioonid. Kirjutasin üles mõned numbrid viimastest testidest, kui võrdlesin erinevaid variante, ja need võivad huvi pakkuda neile, kes uurivad salvestust Kuberneteses. Isiklikult olen ma aga Kubernetese kasutamisest loobunud. Tahan veel mainida CSI draiver, mis võimaldab otse seadistada Hetzner Cloud'i mahuteid, kuid ma ei ole seda veel proovinud. Uurisin pilvepõhiseid tarkvaradefinieritud salvestuslahendusi, kuna vajan replikatsiooni ja võimalust kiiresti ühendada püsivad mahud mistahes sõlmes, eriti sõlmede tõrgete ja muude sarnaste olukordade korral. Mõned lahendused pakuvad ajasnapshotte ja off-site varukoopiaid, mis on mugav.

Testisin 6–7 salvestuslahendust:

OpenEBS

Nagu ma juba ütlesin eelmises postituses, testides enamiku nimekirjas olevatest variantidest, jäi alguses OpenEBS silma. OpenEBS on väga lihtne installida ja kasutada, kuid kui aus olla, siis pärast reaalsete andmete testimist koormuse all pettusin selle jõudluses. See on avatud lähtekoodiga ja arendajad on oma Slacki kanalil alati väga abivalmid, kui mul abi vaja oli. Kahjuks on selle jõudlus teistest variantidest oluliselt madalam, seega pidin testima uuesti. Praegu on OpenEBS-il 3 salvestusmootorit, kuid avaldan tulemused cStor’i jaoks. Hetkel pole mul numbreid Jiva ja LocalPV kohta.

Kokkuvõttes on Jiva veidi kiirem ja LocalPV on üldiselt kiire, mitte halvem kui otseketta bänkmärk. LocalPV probleem on see, et sellele pääseb juurde ainult selles sõlmes, kus see valmis tehti, ja replikatsiooni pole üldse. Mul oli mõningaid raskusi varukoopia taastamisega Velero uues klastris, sest sõlmede nimed olid erinevad. Kui rääkida varukoopiatest, siis cStoril on Velero pluginate, mis võimaldab teha off-site varukoopiaid ajas tehtud snapshots'itest, mis on mugavam kui failitaseme varukoopiad Velero-Resticuga. Kirjutasin mitu skripti, et oleks lihtsam varukoopiate ja taastamiste haldamine selle pistikprogrammi abil. Üldiselt meeldib mulle OpenEBS väga, kuid tema jõudlus...

Rook

Rooki allika kood on samuti avatud, ja teistest loetletud variantidest eristub ta selle poolest, et tegemist on salvestusorkestriga, mis täidab keerulisi salvestushalduse ülesandeid erinevate tagapindadega, näiteks Ceph, EdgeFS ja teised, mis lihtsustavad tööd märkimisväärselt. Mul olid paar kuud tagasi EdgeFS-iga probleeme, seega testisin peamiselt Ceph-i. Ceph pakub mitte ainult plokk salvestust, vaid ka S3/Swift ühilduvat objektisalvestust ja jaotatud failisüsteemi. Mulle meeldib Ceph-is see, et see võimaldab andmemahtu jagada mitme kettaga, et maht saaks kasutada rohkem kettaruumi, kui ühte ketast mahub. See on mugav. Veel üks lahe funktsioon on see, et kui lisad klastrisse kettaid, jagab see automaatselt andmed kõikide kettaste vahel.

Ceph-il on snapshots, kuid nii palju, kui mina tean, ei saa neid Rook/Kubernetesis otse kasutada. Tõsi, ma ei ole süvitsi läinud. Off-site varukoopiad puuduvad, seega tuleb kasutada midagi Velero/Resticiga, aga seal on ainult failitasandi varukoopiad, mitte ajas tehtud snapshots. Kuid mulle Rookis meeldis väga lihtne töö Cephiga — see varjab peaaegu kõiki keerulisi aspekte ja pakub tööriistu Cephiga otse suhtlemiseks tõrgete kõrvaldamiseks. Kahjuks tekkis mul Ceph-i mahtude koormustestis pidevalt see probleem, mis muudab Cephi ebastabiilseks. Hetkel ei ole selge, kas see on bug Cephis endas või probleem selles, kuidas Rook Cephi haldab. Mängisin mälu seadistustega ja olukord paranes, kuid probleem pole lõpuni lahendatud. Cephil on korralik jõudlus, nagu on näha allolevates benchmarkides. Lisaks on tal hea seirepaneel.

Rancher Longhorn

Mulle meeldib Longhorn väga. Minu arvates on see tulevikku suunatud lahendus. Tõsi, arendajad ise (Rancher Labs) tunnistavad, et see ei sobi praegu tootmiskeskkonda, ja see on näha. Sellel on avatud lähtekood ja üsna hea jõudlus (kuigi selle optimeerimisega pole nad veel tegelenud), kuid mahud ühenduvad jättes kauem aega, ja halvematel juhtudel võib see võtta aega kuni 15–16 minutit, eriti pärast suure varukoopia või töökoormuse uuendamise taastamist. Tal on snapshot'id ja off-site varukoopiad neist snapshot'idest, kuid need kehtivad ainult mahtude kohta, seega vajate ikka midagi nagu Velero, et varundada teisi ressursse. Varundamine ja taastamine on väga usaldusväärsed, kuid äärmiselt aeglased. Ausalt öeldes on need lihtsalt kohutavalt aeglased. Protsessorite kasutamine ja süsteemi koormus tõusevad sageli keskmise andmemahtudega töötamisel Longhornis. Seal on mugav jälgimisliides, et hallata Longhorn'i. Olen juba maininud, et mulle meeldib Longhorn, kuid selle kallal tuleb tõsiselt töötada.

StorageOS

StorageOS — see esimene tasuline toode nimekirjas. Sellel on arendajatele mõeldud versioon, kus hallatava salvestusruumi suurusega on piirang 500 GB, kuid node'ide arvu osas ei paista olema piiranguid. Müügiosakonnas öeldi, et hind algab 125 dollarist kuus 1 TB eest, kui ma õigesti mäletan. Seal on põhimonitorimisplaat ja mugav CLI, kuid jõudlusega on midagi kummalist: mõnes testi tulemuses on see täiesti korralik, kuid ma ei olnud mahutestressitestis kiirusest sugugi rahul. Ühesõnaga, ei tea, mida öelda. Seetõttu ma ei uurinud seda eriti lähemalt. Siin ei ole off-site varukoopiaid ja tuleb kasutada Velero't koos Restic'iga mahutite varundamiseks. Kummaline, arvestades, et toode on tasuline. Ja arendajad ei olnud kaastundlikud suhtlema Slackis.

Robin

Robinist kuulsin Redditis nende tehnilise juhi kaudu. Varem ei olnud ma temast kuulnud. Võib-olla seetõttu, et otsisin tasuta lahendusi, aga Robin on tasuline. Neil on üsna lahke tasuta versioon, mis sisaldab 10 TB salvestusruumi ja kolme sõlme. Üldiselt on toode üsna arvestatav ning mõnusate funktsioonidega. Neil on suurepärane CLI, kuid kõige toredam on see, et saate teha kogu rakenduse jaoks snapshot'i ja varukoopia (ressursside valijas nimetatakse seda Helm'i väljaanneteks või „flex rakendusteks“), sealhulgas mahuteid ja muid ressursse, nii et saate ilma Velero'ta toime tulla. Kõik oleks hästi, kui mitte üks väike detail: kui soovite rakendust uues klastris taastada (või „importida“, nagu seda Robin'is nimetatakse) - näiteks õnnetusjuhtumi taastamisel - siis taastamine toimib ilmselgelt, kuid rakenduse varukoopia jätkamise võimalus puudub. Selles väljaandes pole see lihtsalt võimalik ja arendajad on seda kinnitanud. See on, õrnalt öeldes, kummaline, eriti arvestades teisi eeliseid (näiteks uskumatult kiired varukoopiad ja taastamised). Arendajad lubavad kõik järgmises väljaandes parandada. Üldiselt on jõudlus hea, kuid märkasin ühte kummalist asja: kui käivitate benchmark'i otse hostiga ühendatud mahutil, on lugemise kiirus palju kõrgem kui samal mahutil, kuid podi sees. Kõik muud tulemused on identsed, kuid teoorias ei tohiks erinevusi olla. Kuigi nad töötavad selle kallal, olin ma taastamis- ja varukoopia probleemi pärast pettunud - tundus, et olin lõpuks leidnud sobiva lahenduse, ja olin isegi valmis selle eest maksma, kui mul oleks rohkem ruumi või rohkem servereid.

Portworx

Siin mul eriti midagi öelda pole. See on tasuline toode, sama hea kui kallis. Jõudlus on lihtsalt imeline. Praegu on see parim näitaja. Slackis öeldi mulle, et hind algab alates 205 dollarist kuus sõlme kohta, nagu on näidatud Google'i 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 Kubernetesega praktiliselt kasutuks, kui sa ei lepi staatilise ettevalmistusega. Lootsin, et ettevõtte litsents alandatakse automaatselt arendaja tasemele katseaega lõppedes, kuid seda ei juhtunud. Arendaja litsentsi saab kasutada ainult otse Dockeriga ja seadistamine Kuberneteses on väga kohmakas ja piiratud. Muidugi eelistan avatud lähtekoodiga lahendusi, kuid kui mul oleks raha, valiksin Portworxi kindlalt. Praegu ei saa tema jõudlus lihtsalt teiste variantidega võrreldagi.

Linstor

Lisasin selle osa pärast postituse avaldamist, kui üks lugeja soovitas proovida Linstor. Proovisin ja see meeldis mulle! Aga natuke veel peab kaevuma. Praegu võin öelda, et jõudlus on üsna hea (benchmarki tulemused on allpool). Sisuliselt sain sama jõudluse nagu otse diskilt, täielike kuludeta. (Ärge küsige, miks Portworxi numbrid on paremad kui otse diskilt. Pole aimugi. Ilmselt maagia.) Seega tundub Linstor praegu väga efektiivne. Selle seadistamine pole just keeruline, aga ei ole ka nii lihtne kui teised variandid. Esiteks pidin paigaldama Linstori (tuuma moodul ja tööriistad/teenused) ja seadistama LVM-i õhukese varude haldamiseks ja koopia tegemiseks Kubernetesest väljaspool, otse hostis. Siis tuli luua ressursid, mis on vajalikud salvestuse kasutamiseks Kubernetesest. Mind häiris, et see ei töödanud CentOS-is ja pidin kasutama Ubuntut. See pole hirmus, kuid on natuke tüütu, sest dokumentatsioonis (see on muide suurepärane) mainitakse mitmeid pakette, mida antud Epel'i hoidlatest ei leia. Linstoril on koopiaid, kuid mitte kaugbackup'e, seega pidin taas kasutama Velero koos Resticuga, et varundada mahtusid. Eelistan koopiaid failitasandi backup'ide asemel, kuid selle võib taluda, kui lahendus on jõuline ja usaldusväärne. Linstor on avatud lähtekoodiga, kuid pakub tasulist tuge. Kui ma õigesti aru saan, saab seda kasutada piiranguteta, isegi kui lepingut toetuse saamiseks ei ole, kuid seda tuleb kontrollida. Ma ei tea, kui hästi on Linstor Kuberneteses testitud, kuid salvestustase on Kubernetesest väljas ja tundub, et lahendus pole ilmnenud eile, seega on seda tõenäoliselt juba reaalses keskkonnas testitud. Kas siin on lahendus, mis paneb mind ümber mõtlema ja tagasi Kubernetesesse naasma? Ei tea, ei tea. Pean veel uurima, uurima replikatsiooni. Näeme. Aga esimene mulje on hea. Eelistaksin kindlasti kasutada oma klastreid Kuberneteses, mitte Heroku, et saada rohkem vabadust ja õppida uut. Kuna Linstori seadistamine ei ole nii lihtne kui teistel, kirjutan sellest varsti postituse.

Benkmarker

Kahjuks olen ma salvestanud väga vähe võrdlusi, kuna ei arvanud, et hakkan sellest kirjutama. Mul on ainult fio põhikatsed ja ainult ühe sõlmega klastrite jaoks, seega ei ole mul veel andmeid replikaadi konfiguratsioonide jaoks. Kuid nende tulemuste põhjal võib saada umbkaudse ülevaate sellest, mida iga variant võib oodata, kuna olen neid võrreldud identsetes pilveserverites, 4 tuuma, 16 GB RAM-i, lisanduv 100 GB ketas testitavatele mahtudele. Käisin iga lahenduse jaoks benchmarque kolm korda läbi ja arvutasin keskmise tulemuse, pluss lähtestasin serveri seadistused iga toote jaoks. Kõik see pole sugugi teaduslik, lihtsalt et saaksite üldise arusaama. Teistes testides kopeerisin 38 GB fotosid ja videoid mahtudest ja nendele, et testida lugemist ja kirjutamist, kuid kahjuks ei ole andmeid salvestanud. Lühidalt öeldes: Portworx oli palju kiirem.

Ma kasutasin selle mahu benchmarque jaoks sellist manifeesti:

tüüp: PersistentVolumeClaim
apiVersion: v1
metaandmed:
  nimi: dbench
spetsifikatsioon:
  storageClassName: ...
  accessModes:
    - ReadWriteOnce
  ressursid:
    taotlused:
      storage: 5Gi
---
apiVersion: batch/v1
tüüp: Job
metaandmed:
  nimi: dbench
spetsifikatsioon:
  mall:
    spetsifikatsioon:
      konteinerid:
      - nimi: dbench
        pilt: sotoaster/dbench:latest
        imagePullPolicy: IfNotPresent
        keskkond:
          - nimi: DBENCH_MOUNTPOINT
            väärtus: /data
          - nimi: FIO_SIZE
            väärtus: 1G
        volumeMounts:
        - nimi: dbench-pv
          mountPath: /data
      taaskäivituspolitiika: Never
      maht:
      - nimi: dbench-pv
        persistentVolumeClaim:
          claimName: dbench
  backoffLimit: 4

Esmalt lõin ma mahuti, millel on sobiv salvestusklass, ja seejärel käivitasin taustal fio ülesande. Valisin 1 GB, et jälgida jõudlust ja mitte liiga kaua oodata. Siin on tulemused:

Märgistasin iga mõõdiku parima väärtuse roheliseks ja halvimad punaseks.

Kokkuvõte

Nagu näete, on Portworx enamikul juhtudel näidanud paremaid tulemusi kui teised. Aga minu jaoks on see kallis. Ma ei tea, kui palju Robin maksab, kuid seal on suurepärane tasuta versioon, nii et kui vajate tasulist toodet, võite proovida (loodetavasti lahendavad nad varsti taastamise ja varundamise probleemid). Kolmest tasuta võimalusest oli mul kõige vähem probleeme OpenEBS-iga, kuid selle jõudlus on kehv. Kahju, et ma ei salvestanud rohkem tulemusi, kuid loodetavasti aitavad teid esitatud numbrid ja minu kommentaarid.

Allikas: habr.com