Salvestus Kubernetesis: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Salvestus Kubernetesis: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Värskenda!. Kommentaarides soovitas üks lugejatest proovida Linstor (võib-olla ta töötab selle kallal ise), nii et lisasin selle lahenduse jaotise. kirjutasin ka postitage selle installimise kohtasest protsess on muust väga erinev.

Ausalt öeldes andsin alla ja andsin alla Kubernetes (vähemalt praegu). ma kasutan Heroku. Miks? Ladustamise tõttu! Kes oleks võinud arvata, et hakkan rohkem salvestusega jamama kui Kubernetese endaga. ma kasutan Hetzneri pilv, kuna see on odav ja jõudlus on hea ning algusest peale juurutasin klastreid Rantšer. Ma pole proovinud Google/Amazon/Microsoft/DigitalOcean jne jne hallatavaid Kubernetes teenuseid, sest tahtsin kõike ise õppida. Olen ka kokkuhoidlik.

Seega – jah, kulutasin palju aega, et otsustada, millist salvestusruumi valida, kui kaalusin Kubernetese võimalikku virna. Eelistan avatud lähtekoodiga lahendusi ja mitte ainult hinna pärast, vaid huvi pärast vaatasin paari tasulist varianti, sest neil on piirangutega tasuta versioonid. Erinevate valikute võrdlemisel kirjutasin üles mõned numbrid hiljutistest võrdlusnäitajatest ja need võivad huvi pakkuda neile, kes uurivad Kubernetes salvestusruumi. Kuigi isiklikult olen Kubernetesega siiani hüvasti jätnud. Tahan ka mainida CSI draiver, milles saate otse Hetzner Cloudi köiteid varustada, kuid ma pole seda veel proovinud. Uurisin pilvetarkvara määratletud salvestusruumi, kuna vajasin replikatsiooni ja võimalust püsivaid köiteid kiiresti mis tahes sõlme ühendada, eriti sõlme rikete ja muude sarnaste olukordade korral. Mõned lahendused pakuvad hetktõmmiseid ja varukoopiaid väljaspool saiti, mis on mugav.

Testisin 6-7 salvestuslahendust:

OpenEBS

Nagu ma juba ütlesin eelmises postituses, olles testinud enamikku nimekirjast, otsustasin esialgu OpenEBSi kasuks. OpenEBS-i on väga lihtne paigaldada ja kasutada, kuid ausalt öeldes valmistas selle jõudlus mulle pärast reaalsete andmetega testimist koormuse all pettumust. See on avatud lähtekoodiga ja arendajad on omaette Lõõgastav kanal alati väga abivalmis, kui abi vajasin. Kahjuks on sellel teiste võimalustega võrreldes väga kehv jõudlus, nii et pidin testid uuesti läbi viima. Praegu on OpenEBS-il 3 salvestusmootorit, kuid ma postitan cStori võrdlusuuringu tulemused. Mul pole Jiva ja LocalPV jaoks veel numbreid.

Lühidalt öeldes on Jiva veidi kiirem ja LocalPV üldiselt kiire, mitte halvem kui draivi etalon. LocalPV probleem seisneb selles, et köitele pääseb juurde ainult sõlmes, kus see oli ette nähtud, ja replikatsiooni pole üldse. Mul oli probleeme varukoopia taastamisega Purjekas uues klastris, kuna sõlmede nimed olid erinevad. Rääkides varukoopiatest, siis cStoril on Velero pistikprogramm, mille abil saate teha väljastpoolt hetktõmmiste varukoopiaid, mis on mugavam kui failitasemel varukoopiad Velero-Resticuga. ma kirjutasin mitu skriptiet selle pistikprogrammi abil oleks lihtsam varundada ja taastada. Üldiselt meeldib mulle OpenEBS, kuid selle jõudlus ...

vanker

Rook on samuti avatud lähtekoodiga ja erineb ülejäänud loendis olevatest valikutest selle poolest, et tegemist on salvestusruumi orkestraatoriga, mis täidab keerukaid salvestushaldusülesandeid erinevate taustaprogrammidega, näiteks ceph, EdgeFS ja teised, mis lihtsustab oluliselt tööd. Mul oli EfgeFS-iga probleeme, kui seda paar kuud tagasi proovisin, seega testisin peamiselt Cephiga. Ceph pakub mitte ainult plokkide salvestusruumi, vaid ka S3/Swifti ja hajutatud failisüsteemiga ühilduvat objektide salvestusruumi. Mulle meeldib Cephi juures võimalus levitada mahuandmeid mitmele kettale, nii et köide võib kasutada rohkem kettaruumi, kui ühele kettale mahub. See on mugav. Veel üks lahe funktsioon on see, et kui lisate klastrisse kettaid, jagab see andmed automaatselt ümber kõigi ketaste vahel.

Cephil on hetktõmmised, kuid minu teada ei saa neid Rookis/Kuberneteses otse kasutada. Tuleb tunnistada, et ma sellesse ei süvenenud. Kuid seal pole varukoopiaid, nii et peate Velero / Resticuga midagi kasutama, kuid seal on ainult failitaseme varukoopiad, mitte hetketõmmised. Mis mulle aga Rooki juures väga meeldib, on Cephiga töötamise lihtsus – see peidab endas peaaegu kõik keerulised asjad ja pakub tööriistu, et Cephiga tõrkeotsinguks otse rääkida. Kahjuks oli mul Cephi mahtude koormustestil see alati olnud see probleem, mille tõttu muutub Ceph ebastabiilseks. Pole veel selge, kas see on Cephi viga või probleem selles, kuidas Rook Cephi haldab. Tublisin mäluseadetega ja see läks paremaks, kuid probleem ei lahenenud täielikult. Cephil on head tulemused, nagu on näha allolevatest võrdlusnäitajatest. Sellel on ka hea armatuurlaud.

Rancher Longhorn

Mulle väga meeldib Longhorn. Ma arvan, et see on paljulubav lahendus. Tõsi, arendajad ise (Rancher Labs) tunnistavad, et tootmiskeskkonda see veel ei sobi ja see näitab. See on avatud lähtekoodiga ja korraliku jõudlusega (kuigi nad pole seda veel optimeerinud), kuid köidete ühendamine taskusse võtab väga kaua aega ja halvimal juhul 15-16 minutit, eriti pärast suure varukoopia taastamist või töökoormuse suurendamine. Sellel on nende hetktõmmiste hetktõmmised ja väljaspool saiti tehtud varukoopiad, kuid need kehtivad ainult köidete kohta, nii et ülejäänud ressursside varundamiseks vajate ikkagi midagi Velero sarnast. Varundamine ja taastamine on väga töökindlad, kuid sündsusetult aeglased. Tõsiselt, lihtsalt ülemäära aeglane. Keskmise andmemahuga töötamisel Longhornis suureneb protsessori kasutus ja süsteemi koormus sageli. Longhorni haldamiseks on mugav armatuurlaud. Ma juba ütlesin, et mulle meeldib Longhorn, aga sellega tuleb korralikult tööd teha.

Salvestus OS

StorageOS on esimene tasuline toode nimekirjas. Sellel on arendajaversioon piiratud hallatava salvestusmahuga 500 GB, kuid ma arvan, et sõlmede arv pole piiratud. Müügiosakonnast öeldi, et 125 TB hind algab 1 dollarist kuus, kui ma õigesti mäletan. Põhiline armatuurlaud ja käepärane CLI on olemas, kuid jõudlusega toimub midagi veidrat: mõnes võrdlusaluses on see päris korralik, kuid mahtude koormustestis ei meeldinud mulle kiirus üldse. Üldiselt ma ei tea, mida öelda. Nii et ma ei saanud eriti aru. Siin ei ole väliseid varukoopiaid ja köidete varundamiseks peate kasutama ka Velerot koos Resticuga. Imelik, sest toode on tasuline. Ja arendajad ei olnud innukad Slackis suhtlema.

punarind

Sain Robini kohta Redditis teada nende CTO-lt. Ma polnud temast varem kuulnud. Võib-olla sellepärast, et otsisin tasuta lahendusi ja Robinile makstakse. Neil on üsna helde tasuta versioon 10 TB salvestusruumi ja kolme sõlmega. Üldiselt on toode üsna korralik ja kenade omadustega. Seal on suurepärane CLI, kuid kõige lahedam on see, et saate teha hetktõmmise ja varundada kogu rakenduse (nimetatakse ressursside valijas Helmi väljalaseteks või paindlikeks rakendusteks), sealhulgas mahtude ja muude ressurssidega, nii et saate ilma Velerota hakkama. Ja kõik oleks imeline, kui mitte üks väike detail: kui taastate (või "impordite", nagu seda Robinis nimetatakse) rakenduse uues klastris - näiteks katastroofi taastamise korral - taastamise, muidugi töötab, kuid jätkake rakenduse varundamisega, see on keelatud. Selles versioonis pole see lihtsalt võimalik ja arendajad on seda kinnitanud. See on pehmelt öeldes kummaline, eriti kui arvestada muid eeliseid (näiteks uskumatult kiireid varundusi ja taasteid). Arendajad lubavad järgmise väljaande jooksul kõik parandada. Jõudlus on üldiselt hea, kuid märkasin kummalist asja: kui käivitada benchmark otse hosti külge kinnitatud helitugevusel, on lugemiskiirus palju suurem kui samas mahus, kuid tasku seest. Kõik muud tulemused on identsed, kuid teoreetiliselt ei tohiks erinevusi olla. Kuigi nad töötavad selle kallal, sain taastamise ja varundamise probleemist meelehärmi - mulle tundus, et olen lõpuks leidnud sobiva lahenduse ja olin valmis selle eest isegi maksma, kui mul oli vaja rohkem ruumi või rohkem servereid.

portworx

Mul pole siin palju öelda. See on tasuline toode, ühtviisi lahe ja kallis. Esitus on lihtsalt hämmastav. Siiani on see parim näitaja. Slack ütles mulle, et hinnad algavad 205 dollarist kuus sõlme kohta, nagu on loetletud Google'i GKE Marketplace'is. Ma ei tea, kas otse ostes tuleb odavam. Igatahes ei saa ma seda endale lubada, seega olin väga-väga pettunud, et arendajalitsents (kuni 1TB ja 3 sõlme) on Kubernetese puhul praktiliselt kasutu, kui just staatilise ettenägemisega ei rahuldu. Lootsin, et prooviperioodi lõpus läheb hulgilitsents automaatselt arendajale alla, kuid seda ei juhtunud. Arendaja litsentsi saab kasutada ainult otse Dockeriga ning Kubernetese seadistamine on väga tülikas ja piiratud. Eelistan muidugi avatud lähtekoodiga, aga kui raha oleks, siis valiksin kindlasti Portworxi. Siiani ei anna selle jõudlust teiste võimalustega võrrelda.

Linstor

Lisasin selle rubriigi pärast postituse avaldamist, kui lugeja soovitas Linstorit proovida. Proovisin ja mulle meeldis! Aga kaevama peab ikka. Nüüd võin öelda, et sooritus pole halb (allpool lisatud võrdlusuuringu tulemused). Tegelikult sain samasuguse jõudluse nagu otse sõitmisel, ilma üldkuludeta. (Ärge küsige, miks Portworxi numbrid on paremad kui draivi etalon. Mul pole õrna aimugi. Maagia vist.) Nii et Linstor tundub siiani väga tõhus. Selle paigaldamine pole nii keeruline, kuid mitte nii lihtne kui muud võimalused. Pidin esmalt installima Linstori (kerneli moodul ja tööriistad/teenused) ja seadistama LVM-i õhukeste seadmete ja hetketõmmiste toe jaoks väljaspool Kubernetest, otse hosti ning seejärel looma Kubernetesist salvestusruumi kasutamiseks vajalikud ressursid. Mulle ei meeldinud, et see CentOS-is ei töötanud ja pidi kasutama Ubuntut. Pole muidugi kohutav, aga pisut tüütu, sest dokumentatsioonis (mis, muide, suurepärane) on mainitud mitmeid pakette, mida nimetatud Epeli hoidlates ei leidu. Linstoril on hetktõmmised, kuid mitte väljastpoolt varukoopiaid, nii et siin pidin taas kasutama Velero koos Resticuga, et helisid varundada. Eelistaksin hetktõmmiseid failitaseme varukoopiatele, kuid seda saab taluda, kui lahendus on nii toimiv kui ka usaldusväärne. Linstor on avatud lähtekoodiga, kuid sellel on tasuline tugi. Kui ma õigesti aru saan, võib seda kasutada ilma piiranguteta, isegi kui teil pole toetuslepingut, kuid see vajab täpsustamist. Ma ei tea, kuidas Linstorit Kubernetese jaoks testitakse, aga salvestuskiht ise asub Kubernetest väljas ja ilmselt eile lahendus ei ilmunud, seega on see ilmselt juba reaalsetes tingimustes testitud. Kas siin on lahendus, mis paneb mind meelt muutma ja Kubernetesesse tagasi pöörduma? Ma ei tea. Peame ikka veel süvenema, uurima replikatsiooni. Vaatame. Aga esmamulje on hea. Kindlasti eelistaksin Heroku asemel kasutada enda Kubernetese klastreid, et saada rohkem vabadust ja õppida uusi asju. Kuna Linstori paigaldamine pole nii lihtne kui teisi, siis kirjutan sellest varsti postituse.

Võrdlusnäitajad

Kahjuks pidasin võrdluse kohta vähe arvestust, sest ma ei arvanud, et sellest kirjutan. Mul on ainult fio baastaseme võrdlusuuringu tulemused ja ainult ühe sõlme klastrite jaoks, seega pole mul veel kopeeritud konfiguratsioonide numbreid. Kuid nende tulemuste põhjal saate ligikaudse ettekujutuse, mida igast valikust oodata, sest võrdlesin neid samades pilveserverites, 4 tuuma, 16 GB muutmälu ja 100 GB täiendava kettaga testitud mahtude jaoks. Käivitasin iga lahenduse jaoks kolm korda võrdlusuuringuid ja arvutasin keskmise tulemuse ning lähtestasin iga toote serveri seaded. Kõik see on täiesti ebateaduslik, et saaksite üldiselt aru. Teistes testides kopeerisin helitugevusest ning lugemise ja kirjutamise testimiseks 38 GB fotosid ja videoid, kuid kahjuks ma numbreid ei salvestanud. Lühidalt: Portworkx oli palju kiirem.

Mahu võrdlusaluse jaoks kasutasin seda 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 sobiva salvestusklassiga köite ja seejärel tegin selle töö kulisside taga fioga. Võtsin jõudluse hindamiseks ja mitte liiga kaua ootama 1 GB. Siin on tulemused:

Salvestus Kubernetesis: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

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

Järeldus

Nagu näete, toimis Portworx enamikul juhtudel teistest paremini. Aga minu jaoks on see kallis. Ma ei tea, kui palju Robin maksab, kuid seal on suurepärane tasuta versioon, nii et kui teil on vaja tasulist toodet, võite seda proovida (loodan, et nad lahendavad probleemi peagi taastamise ja varundamisega). Kolmest tasuta versioonist on mul kõige vähem probleeme olnud OpenEBS-iga, kuid selle jõudlus on tühine. Mul on kahju, et ma rohkem tulemusi ei salvestanud, kuid loodan, et numbrid ja minu kommentaarid aitavad teid.

Allikas: www.habr.com

Lisa kommentaar