Saugykla „Kubernetes“: „OpenEBS“ prieš „Rook“ („Ceph“) prieš „Rancher Longhorn“ ir „StorageOS“ ir „Robin“ prieš „Portworx“ ir „Linstor“

Atnaujinkite!. Komentaruose vienas iš skaitytojų pasiūlė pabandyti Linstoras (galbūt jis pats su tuo dirba), todėl pridėjau skyrių apie šį sprendimą. Aš irgi parašiau paskelbkite, kaip jį įdiegti, nes procesas labai skiriasi nuo kitų.

Jei atvirai, pasidaviau ir pasidaviau Kubernetes (bent jau kol kas). naudosiu Heroku. Kodėl? Dėl saugojimo! Kas galėjo pagalvoti, kad su saugykla susitvarkysiu daugiau nei su pačia „Kubernetes“. aš naudoju Hetznerio debesisnes tai nebrangi, o našumas geras ir nuo pat pradžių diegiau grupes rančos savininkas. Nebandžiau valdomų Kubernetes paslaugų iš Google/Amazon/Microsoft/DigitalOcean ir t.t. ir t.t., nes norėjau visko išmokti pats. Aš irgi taupus.

Taigi taip, aš praleidau daug laiko, bandydamas nuspręsti, kurią saugyklą pasirinkti, kai vertinau galimą „Kubernetes“ krūvą. Pirmenybę teikiu atvirojo kodo sprendimams ne tik dėl kainos, bet iš smalsumo išnagrinėjau keletą mokamų variantų, nes jie turi nemokamų versijų su apribojimais. Užsirašiau keletą skaičių iš naujausių bandymų, kai palyginau skirtingas parinktis, ir jie gali būti įdomūs tiems, kurie mokosi apie Kubernetes saugyklą. Nors aš asmeniškai kol kas atsisveikinau su Kubernetes. Taip pat noriu paminėti CSI vairuotojas, kuri gali tiesiogiai teikti „Hetzner Cloud“ tomus, bet aš to dar nebandžiau. Išnagrinėjau debesies programinės įrangos apibrėžtą saugyklą, nes man reikėjo replikacijos ir galimybės greitai prijungti nuolatinius tomus bet kuriame mazge, ypač mazgo gedimų ir kitų panašių situacijų atveju. Kai kurie sprendimai siūlo momentines nuotraukas ir atsargines kopijas ne svetainėje, o tai yra patogu.

Išbandžiau 6–7 saugojimo sprendimus:

OpenEBS

Kaip jau sakiau ankstesniame įrašeIšbandęs daugumą sąrašo parinkčių, iš pradžių apsistojau ties OpenEBS. „OpenEBS“ įdiegti ir naudoti yra labai paprasta, tačiau, tiesą pasakius, atlikus testavimą su tikrais apkrovos duomenimis, nusivyliau jo veikimu. Tai yra atvirojo kodo, o kūrėjai yra patys Laisvas kanalas visada labai padeda, kai man reikia pagalbos. Deja, palyginti su kitomis galimybėmis, jos našumas labai prastas, todėl bandymus teko atlikti iš naujo. Šiuo metu OpenEBS turi 3 saugojimo variklius, bet skelbiu cStor etaloninius rezultatus. Dar neturiu Jiva ir LocalPV numerių.

Trumpai tariant, „Jiva“ yra šiek tiek greitesnė, o „LocalPV“ paprastai yra greita, ne blogesnė už disko etaloną. „LocalPV“ problema yra ta, kad tomą galima pasiekti tik tame mazge, kuriame jis buvo paruoštas, ir iš viso nėra replikacijos. Turėjau problemų atkuriant atsarginę kopiją per Burlaivis naujame klasteryje, nes mazgų pavadinimai buvo skirtingi. Jei mes kalbame apie atsargines kopijas, cStor turi Velero įskiepis, su kuria vienu metu galite kurti momentinių nuotraukų atsargines kopijas ne svetainėje, o tai yra patogiau nei failo lygio atsarginės kopijos naudojant Velero-Restic. aš parašiau keli scenarijai, kad būtų lengviau tvarkyti atsargines kopijas ir atkūrimą naudojant šį papildinį. Apskritai man labai patinka OpenEBS, bet jo veikimas...

bokštas

„Rook“ taip pat yra atvirojo kodo, o iš kitų sąraše esančių parinkčių jį išskiria tuo, kad tai yra saugyklos organizatorius, kuris atlieka sudėtingas saugyklos valdymo užduotis su skirtingomis sistemomis, pvz., Cef, EdgeFS ir kiti, o tai labai supaprastina darbą. Turėjau problemų su EfgeFS, kai bandžiau jį prieš kelis mėnesius, todėl daugiausia testavau su Ceph. Ceph siūlo ne tik blokų saugyklą, bet ir objektų saugyklą, suderinamą su S3/Swift ir paskirstyta failų sistema. „Ceph“ man patinka galimybė paskleisti apimties duomenis keliuose diskuose, kad tomas galėtų naudoti daugiau vietos diske, nei telpa viename diske. Tai patogu. Kita puiki savybė yra ta, kad kai pridedate diskus į klasterį, jis automatiškai perskirsto duomenis visuose diskuose.

Ceph turi momentinių nuotraukų, bet, kiek aš žinau, jų negalima naudoti tiesiogiai Rook / Kubernetes. Tiesa, į tai nesigilinau. Tačiau nėra atsarginių kopijų ne svetainėje, todėl turėsite ką nors naudoti su Velero / Restic, tačiau yra tik failo lygio atsarginės kopijos, o ne momentinės kopijos. Man labai patiko Rook, kaip lengva dirbti su Ceph – jame slepiami beveik visi sudėtingi dalykai ir siūlomi įrankiai, leidžiantys tiesiogiai pasikalbėti su Ceph, kad būtų pašalintos problemos. Deja, atliekant Ceph apimčių testavimą nepalankiausiomis sąlygomis, aš nuolat turėjau problemų Ši problema, todėl Ceph tampa nestabilus. Dar neaišku, ar tai paties Ceph klaida, ar Rooko Ceph valdymo problema. Sutvarkiau atminties nustatymus ir pagerėjo, bet problema nebuvo iki galo išspręsta. Kaip matote toliau pateiktuose etalonuose, Cepho našumas yra geras. Jis taip pat turi gerą prietaisų skydelį.

Rančeris Longhornas

Man labai patinka Longhorn. Mano nuomone, tai perspektyvus sprendimas. Tiesa, patys kūrėjai („Rancher Labs“) pripažįsta, kad jis dar netinka darbo aplinkai, ir tai rodo. Jis yra atvirojo kodo ir turi neblogą našumą (nors jie dar neoptimizavo), tačiau tomas užtrunka labai ilgai, kol prisijungia prie podelio, o blogiausiu atveju tai užtrunka 15-16 minučių, ypač atkūrus didelę atsarginę kopiją arba darbo krūvio atnaujinimas. Jame yra momentinių nuotraukų ir šių momentinių nuotraukų atsarginių kopijų ne svetainėje, tačiau jos taikomos tik tomams, todėl jums vis tiek reikės kažko panašaus į „Velero“, kad galėtumėte kurti atsargines kitų išteklių kopijas. Atsarginės kopijos ir atkūrimas yra labai patikimi, bet nepadoriai lėti. Rimtai, tiesiog neįtikėtinai lėtai. CPU naudojimas ir sistemos apkrova dažnai iškyla dirbant su vidutiniu duomenų kiekiu Longhorn. Yra patogus prietaisų skydelis, skirtas valdyti Longhorn. Jau sakiau, kad man patinka Longhorn, bet reikia šiek tiek padirbėti.

„StorageOS“.

„StorageOS“ yra pirmasis mokamas produktas sąraše. Ji turi kūrėjo versiją su ribotu valdomu 500 GB atminties dydžiu, bet nemanau, kad mazgų skaičius ribojamas. Pardavimo skyrius man pasakė, kad kaina prasideda nuo 125 USD per mėnesį už 1 TB, jei gerai prisimenu. Yra pagrindinis prietaisų skydelis ir patogus CLI, bet kažkas keisto vyksta su našumu: kai kuriuose etalonuose jis yra gana neblogas, tačiau atliekant garsumo testą nepalankiausiomis sąlygomis greitis man visiškai nepatiko. Apskritai, aš nežinau, ką pasakyti. Taigi nelabai supratau. Čia nėra atsarginių kopijų ne svetainėje, taip pat turėsite naudoti Velero su Restic, kad sukurtumėte atsargines apimtis. Keista, nes prekė mokama. Ir kūrėjai nenorėjo bendrauti „Slack“.

liepsnelė

Apie Robiną „Reddit“ sužinojau iš jų techninio direktoriaus. Niekada anksčiau apie jį nebuvau girdėjęs. Gal todėl, kad ieškojau nemokamų sprendimų, bet Robinui mokama. Jie turi gana dosnią nemokamą versiją su 10 TB saugykla ir trimis mazgais. Apskritai, produktas yra gana geras ir turi puikių savybių. Yra puikus CLI, bet šauniausias dalykas yra tai, kad galite padaryti visos programos momentinį vaizdą ir atsarginę kopiją (išteklių parinkiklyje tai vadinama „Helm“ leidimais arba „flex programomis“), įskaitant apimtis ir kitus išteklius, todėl galite apsieiti be „Velero“. Ir viskas būtų nuostabu, jei ne viena smulkmena: jei atkursite (arba „importuosite“, kaip tai vadinama Robin) programą naujame klasteryje - pavyzdžiui, atsigavus po nelaimės - atkūrimą, žinoma, veikia, bet toliau kurti atsargines programos kopijas draudžiama. Šiame leidime tai tiesiog neįmanoma, kaip patvirtino kūrėjai. Tai, švelniai tariant, keista, ypač turint omenyje kitus privalumus (pavyzdžiui, neįtikėtinai greitas atsargines kopijas ir atkūrimą). Kūrėjai žada viską sutvarkyti iki kitos versijos. Našumas paprastai yra geras, bet pastebėjau keistenybę: jei etaloną paleidžiu tiesiai prie pagrindinio kompiuterio prijungtame tome, skaitymo greitis yra daug greitesnis nei paleidus tą patį garsą iš lizdo. Visi kiti rezultatai yra identiški, tačiau teoriškai skirtumo neturėtų būti. Nors jie dirba prie to, mane nuliūdino atkūrimo ir atsarginių kopijų kūrimo problema – maniau, kad pagaliau radau tinkamą sprendimą ir net buvau pasirengęs už tai mokėti, kai man reikėjo daugiau vietos ar daugiau serverių.

„Portworx“

Neturiu čia daug ką pasakyti. Tai yra mokamas produktas, vienodai šaunus ir brangus. Spektaklis tiesiog nuostabus. Tai kol kas geriausias rodiklis. Slackas man pasakė, kad kainodara prasideda nuo 205 USD per mėnesį už mazgą, kaip nurodyta „Google“ GKE prekyvietėje. Nežinau, ar bus pigiau pirkus tiesiogiai. Šiaip negaliu sau to leisti, todėl labai labai nusivyliau, kad kūrėjo licencija (iki 1 TB ir 3 mazgų) su Kubernetes praktiškai nenaudinga, nebent tenkinatės statiniu aprūpinimu. Tikėjausi, kad pasibaigus bandomajam laikotarpiui bendroji licencija bus automatiškai grąžinta į kūrėją, bet taip neatsitiko. Kūrėjo licenciją galima naudoti tik tiesiogiai su „Docker“, o „Kubernetes“ konfigūracija yra labai sudėtinga ir ribota. Žinoma, man labiau patinka atvirasis kodas, bet jei turėčiau pinigų, tikrai rinkčiausi Portworx. Iki šiol jo veikimas tiesiog neprilygsta kitoms galimybėms.

Linstoras

Šią skiltį papildžiau po įrašo paskelbimo, kai vienas skaitytojas pasiūlė išbandyti „Linstor“. Išbandžiau ir man patiko! Bet vis tiek turime kasti giliau. Dabar galiu pasakyti, kad pasirodymas neblogas (žemiau pridėjau etaloninius rezultatus). Iš esmės aš gavau tokį patį našumą kaip ir diskas tiesiogiai, be jokių papildomų išlaidų. (Neklauskite, kodėl „Portworx“ turi geresnius skaičius nei tiesiogiai disko etalonas. Neturiu supratimo. Manau, magija.) Taigi „Linstor“ kol kas atrodo labai efektyvus. Tai nėra taip sunku įdiegti, tačiau tai nėra taip paprasta, kaip kitos galimybės. Pirmiausia turėjau įdiegti „Linstor“ (branduolio modulį ir įrankius/paslaugas) ir sukonfigūruoti LVM plonam aprūpinimui ir momentinių nuotraukų palaikymui už „Kubernetes“ ribų, tiesiai pagrindiniame kompiuteryje, o tada sukurti išteklius, reikalingus saugyklai iš „Kubernetes“. Man nepatiko, kad jis neveikė CentOS ir turėjau naudoti Ubuntu. Žinoma, nebaisu, bet šiek tiek erzina, nes dokumentacijoje (beje, puiki) yra paminėti keli paketai, kurių nerasi nurodytose Epel saugyklose. „Linstor“ turi momentinių nuotraukų, bet ne atsarginių kopijų ne vietoje, todėl čia vėl turėjau naudoti „Velero“ su „Restic“, kad sukurčiau atsargines apimtis. Man labiau patiktų momentinės kopijos, o ne failo lygio atsarginės kopijos, tačiau tai gali būti toleruojama, jei sprendimas yra našus ir patikimas. „Linstor“ yra atvirojo kodo, bet turi mokamą palaikymą. Jei gerai suprantu, galima naudoti be apribojimų, net ir neturint paramos sutarties, bet tai reikia išsiaiškinti. Nežinau, kiek Linstor išbandytas Kubernetes, bet pats saugyklos sluoksnis yra už Kubernetes ribų ir, matyt, sprendimas neatsirado vakar, tad tikriausiai jau išbandytas realiomis sąlygomis. Ar čia yra sprendimas, kuris privers mane persigalvoti ir grįžti į Kubernetes? Aš nežinau. Mums vis tiek reikia gilintis ir ištirti replikaciją. Pažiūrėkime. Bet pirmas įspūdis geras. Tikrai norėčiau naudoti savo „Kubernetes“ grupes, o ne „Heroku“, kad turėčiau daugiau laisvės ir išmokčiau naujų dalykų. Kadangi Linstor nėra taip paprasta įdiegti kaip kitus, netrukus parašysiu apie tai įrašą.

Etalonai

Deja, daug pastabų apie palyginimą neužsirašiau, nes nemaniau, kad apie tai parašysiu. Turiu tik pagrindinių fio etalonų ir tik vieno mazgo grupių rezultatus, todėl dar neturiu pakartotų konfigūracijų skaičių. Tačiau iš šių rezultatų galite susidaryti apytikslį supratimą, ko tikėtis iš kiekvienos parinkties, nes aš palyginau juos tuose pačiuose debesies serveriuose, 4 branduoliai, 16 GB RAM, su papildomu 100 GB disku, skirtu išbandytiems tūriams. Tris kartus paleidau kiekvieno sprendimo etalonus ir apskaičiavau vidutinį rezultatą, taip pat iš naujo nustatiau kiekvieno produkto serverio nustatymus. Visa tai yra visiškai nemoksliška, tik tam, kad susidarytumėte bendrą idėją. Kituose bandymuose nukopijavau 38 GB nuotraukų ir vaizdo įrašų iš tomo, kad galėčiau skaityti ir rašyti, bet, deja, skaičių neišsaugojau. Trumpai tariant: „Portworkx“ buvo daug greitesnis.

Apimties etalonui naudojau šį aprašą:

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

Pirmiausia sukūriau tomą su atitinkama saugojimo klase, o tada atlikau darbą su fio užkulisiuose. Užtrukau 1 GB, kad įvertinčiau našumą ir nelaukčiau per ilgai. Štai rezultatai:

Geriausią kiekvienos metrikos vertę paryškinau žalia spalva, o blogiausią – raudona.

išvada

Kaip matote, daugeliu atvejų Portworx pasirodė geriau nei kiti. Bet man tai brangu. Nežinau kiek kainuoja Robin, bet jie turi puikią nemokamą versiją, tad jei norite mokamo produkto, galite jį pabandyti (tikiuosi greitai išspręs problemą su atkūrimu ir atsarginėmis kopijomis). Iš trijų nemokamų turėjau mažiausiai problemų su OpenEBS, tačiau jos našumas yra niūrus. Gaila, kad neišsaugojau daugiau rezultatų, bet tikiuosi, kad skaičiai ir mano komentarai jums padės.

Šaltinis: www.habr.com