Hapësira ruajtëse në Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Hapësira ruajtëse në Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Përditëso!. Në komente, një nga lexuesit sugjeroi të provoni Linstor (ndoshta ai është duke punuar në të vetë) kështu që unë kam shtuar një seksion në lidhje me këtë zgjidhje. Kam shkruar edhe unë postoni se si ta instaloni atë, sepse procesi është shumë i ndryshëm nga pjesa tjetër.

Të them të drejtën hoqa dorë dhe hoqa dorë Kubernetes (të paktën tani për tani). do të përdor Heroku. Pse? Për shkak të ruajtjes! Kush do ta kishte menduar se unë do të ndërhyja më shumë me ruajtjen sesa me vetë Kubernetes. Unë përdor Reja Hetznersepse është i lirë dhe performanca është e mirë dhe që në fillim kam vendosur grupe duke përdorur kauboj. Nuk i provova shërbimet e menaxhuara të Kubernetes nga Google/Amazon/Microsoft/DigitalOcean, etj., etj., sepse doja të mësoja gjithçka vetë. Unë jam gjithashtu i kursyer.

Pra, po, kalova shumĂ« kohĂ« duke u pĂ«rpjekur tĂ« vendos se cilin hapĂ«sirĂ« ​​ruajtĂ«se tĂ« zgjidhja kur vlerĂ«soja njĂ« pirg tĂ« mundshĂ«m Kubernetes. UnĂ« preferoj zgjidhjet me burim tĂ« hapur, jo vetĂ«m pĂ«r shkak tĂ« çmimit, por kam shikuar disa opsione me pagesĂ« pĂ«r kuriozitet, sepse ato kanĂ« versione falas me kufizime. UnĂ« kam shĂ«nuar disa numra nga testet e fundit kur krahasova opsione tĂ« ndryshme dhe ato mund tĂ« jenĂ« me interes pĂ«r ata qĂ« mĂ«sojnĂ« rreth ruajtjes sĂ« Kubernetes. Edhe pse unĂ« personalisht i kam thĂ«nĂ« lamtumirĂ« Kubernetes tani pĂ«r tani. UnĂ« gjithashtu dua tĂ« pĂ«rmend Shofer CSI, i cili mund tĂ« ofrojĂ« drejtpĂ«rdrejt vĂ«llimet e Hetzner Cloud, por unĂ« nuk e kam provuar ende. Shikova hapĂ«sirĂ«n ruajtĂ«se tĂ« pĂ«rcaktuar nga softueri cloud, sepse kisha nevojĂ« pĂ«r pĂ«rsĂ«ritje dhe aftĂ«sinĂ« pĂ«r tĂ« montuar shpejt vĂ«llime tĂ« vazhdueshme nĂ« çdo nyje, veçanĂ«risht nĂ« rast tĂ« dĂ«shtimeve tĂ« nyjeve dhe situatave tĂ« tjera tĂ« ngjashme. Disa zgjidhje ofrojnĂ« fotografi moment-nĂ«-kohĂ« dhe kopje rezervĂ« jashtĂ« sajtit, gjĂ« qĂ« Ă«shtĂ« e pĂ«rshtatshme.

Kam testuar 6-7 zgjidhje ruajtjeje:

OpenEBS

Siç e thashë tashmë në një postim të mëparshëmPasi testova shumicën e opsioneve nga lista, fillimisht u vendosa në OpenEBS. OpenEBS është shumë i lehtë për t'u instaluar dhe përdorur, por për të qenë i sinqertë, pas testimit me të dhëna reale nën ngarkesë, u zhgënjeva me performancën e tij. Ky është me burim të hapur dhe zhvilluesit janë më vete Kanali i dobët gjithmonë shumë i dobishëm kur kam nevojë për ndihmë. Fatkeqësisht, ai ka performancë shumë të dobët në krahasim me opsionet e tjera, kështu që testet duhej të rifilloheshin. OpenEBS aktualisht ka 3 motorë ruajtjeje, por unë po postoj rezultatet e standardeve për cStor. Nuk kam ende numra për Jiva dhe LocalPV.

Me pak fjalë, Jiva është pak më i shpejtë, dhe LocalPV është përgjithësisht i shpejtë, jo më keq se standardi i diskut drejtpërdrejt. Problemi me LocalPV është se vëllimi mund të aksesohet vetëm në nyjen ku është përgatitur dhe nuk ka fare përsëritje. Kam pasur disa probleme me rivendosjen e një kopje rezervë nëpërmjet varkë me vela në një grup të ri sepse emrat e nyjeve ishin të ndryshëm. Nëse flasim për kopje rezervë, cStor ka shtojcë për Velero, me të cilin mund të bëni kopje rezervë jashtë sajtit të fotografive në një moment kohor, gjë që është më e përshtatshme se kopjet rezervë në nivel skedari me Velero-Restic. unë shkruajta disa skenare, për ta bërë më të lehtë menaxhimin e kopjeve rezervë dhe rikthimet me këtë shtesë. Në përgjithësi, më pëlqen shumë OpenEBS, por performanca e tij...

sorrë

Rook Ă«shtĂ« gjithashtu me burim tĂ« hapur dhe ndryshon nga pjesa tjetĂ«r e opsioneve nĂ« listĂ« nĂ« atĂ« qĂ« Ă«shtĂ« njĂ« orkestrues i ruajtjes qĂ« kryen detyra komplekse tĂ« menaxhimit tĂ« ruajtjes me backend tĂ« ndryshĂ«m, p.sh. ceph, EdgeFS dhe tĂ« tjera, gjĂ« qĂ« e thjeshton shumĂ« punĂ«n. Kam pasur probleme me EfgeFS kur e provova disa muaj mĂ« parĂ«, kĂ«shtu qĂ« testova kryesisht me Ceph. Ceph jo vetĂ«m qĂ« ofron ruajtje nĂ« bllok, por edhe ruajtje tĂ« objekteve tĂ« pajtueshme me S3/Swift dhe sistemin e skedarĂ«ve tĂ« shpĂ«rndarĂ«. Ajo qĂ« mĂ« pĂ«lqen te Ceph Ă«shtĂ« aftĂ«sia pĂ«r tĂ« shpĂ«rndarĂ« tĂ« dhĂ«nat e volumit nĂ«pĂ«r disqe tĂ« shumta, nĂ« mĂ«nyrĂ« qĂ« vĂ«llimi tĂ« pĂ«rdorĂ« mĂ« shumĂ« hapĂ«sirĂ« ​​​​nĂ« disk sesa mund tĂ« vendoset nĂ« njĂ« disk tĂ« vetĂ«m. ËshtĂ« komode. NjĂ« veçori tjetĂ«r interesante Ă«shtĂ« se kur shtoni disqe nĂ« njĂ« grup, ai rishpĂ«rndan automatikisht tĂ« dhĂ«nat nĂ« tĂ« gjithĂ« disqet.

Ceph ka fotografi, por me sa di unë, ato nuk mund të përdoren drejtpërdrejt në Rook/Kubernetes. Vërtetë, nuk u futa thellë në këtë. Por nuk ka kopje rezervë jashtë sajtit, kështu që do t'ju duhet të përdorni diçka me Velero/Restic, por ka vetëm kopje rezervë në nivel skedari, jo fotografi të momentit në kohë. Ajo që më pëlqeu shumë te Rook ishte sa e lehtë është të punosh me Ceph - ai fsheh pothuajse të gjitha gjërat e ndërlikuara dhe ofron mjete për të biseduar drejtpërdrejt me Ceph për zgjidhjen e problemeve. Fatkeqësisht, gjatë testit të stresit të vëllimeve të Ceph, vazhdova të kisha probleme ky problem, gjë që bën që Cefi të bëhet i paqëndrueshëm. Nuk është ende e qartë nëse ky është një gabim në vetë Ceph apo një problem në mënyrën se si Rook menaxhon Ceph. Kam ndërhyrë me cilësimet e kujtesës dhe u bë më mirë, por problemi nuk u zgjidh plotësisht. Ceph ka performancë të mirë, siç mund ta shihni në standardet më poshtë. Gjithashtu ka një pult të mirë.

Rancher Longhorn

MĂ« pĂ«lqen shumĂ« Longhorn. PĂ«r mendimin tim, kjo Ă«shtĂ« njĂ« zgjidhje premtuese. VĂ«rtetĂ«, vetĂ« zhvilluesit (Rancher Labs) pranojnĂ« se nuk Ă«shtĂ« ende i pĂ«rshtatshĂ«m pĂ«r mjedisin e punĂ«s, dhe kjo tregon. ËshtĂ« me burim tĂ« hapur dhe ka performancĂ« tĂ« mirĂ« (edhe pse nuk e kanĂ« optimizuar ende), por vĂ«llimet kĂ«rkojnĂ« njĂ« kohĂ« shumĂ« tĂ« gjatĂ« pĂ«r t'u lidhur me podin, dhe nĂ« rastet mĂ« tĂ« kĂ«qija duhen 15-16 minuta, veçanĂ«risht pas rivendosjes sĂ« njĂ« kopje rezervĂ« tĂ« madhe ose pĂ«rmirĂ«simi i ngarkesĂ«s sĂ« punĂ«s. Ai ka fotografi tĂ« çastit dhe kopje rezervĂ« jashtĂ« sajtit tĂ« kĂ«tyre fotografive, por ato zbatohen vetĂ«m pĂ«r vĂ«llime, kĂ«shtu qĂ« do t'ju duhet ende diçka si Velero pĂ«r tĂ« rezervuar burime tĂ« tjera. Rezervimet dhe rikthimet janĂ« shumĂ« tĂ« besueshme, por nĂ« mĂ«nyrĂ« tĂ« pahijshme tĂ« ngadalta. Seriozisht, thjesht tepĂ«r i ngadalshĂ«m. PĂ«rdorimi i procesorit dhe ngarkesa e sistemit shpesh rriten kur punoni me njĂ« sasi mesatare tĂ« tĂ« dhĂ«nave nĂ« Longhorn. Ekziston njĂ« panel i pĂ«rshtatshĂ«m pĂ«r tĂ« menaxhuar Longhorn. TashmĂ« kam thĂ«nĂ« qĂ« mĂ« pĂ«lqen Longhorn, por ka nevojĂ« pĂ«r punĂ«.

StorageOS

StorageOS Ă«shtĂ« produkti i parĂ« me pagesĂ« nĂ« listĂ«. Ka njĂ« version zhvilluesi me njĂ« madhĂ«si tĂ« kufizuar tĂ« ruajtjes sĂ« menaxhuar prej 500 GB, por nuk mendoj se ka njĂ« kufi nĂ« numrin e nyjeve. Departamenti i shitjeve mĂ« tha se kostoja fillon me 125 dollarĂ« nĂ« muaj pĂ«r 1 TB, nĂ«se mĂ« kujtohet mirĂ«. Ekziston njĂ« pult bazĂ« dhe njĂ« CLI i pĂ«rshtatshĂ«m, por diçka e çuditshme po ndodh me performancĂ«n: nĂ« disa standarde Ă«shtĂ« mjaft e mirĂ«, por nĂ« testin e stresit tĂ« vĂ«llimit nuk mĂ« pĂ«lqeu fare shpejtĂ«sia. NĂ« pĂ«rgjithĂ«si, nuk di çfarĂ« tĂ« them. KĂ«shtu qĂ« nuk kuptova shumĂ«. KĂ«tu nuk ka kopje rezervĂ« jashtĂ« sajtit dhe do t'ju duhet gjithashtu tĂ« pĂ«rdorni Velero me Restic pĂ«r tĂ« rezervuar vĂ«llime. ËshtĂ« e çuditshme, sepse produkti paguhet. Dhe zhvilluesit nuk ishin tĂ« etur pĂ«r tĂ« komunikuar nĂ« Slack.

Gushëkuq

MĂ«sova pĂ«r Robin nĂ« Reddit nga drejtori i tyre teknik. Nuk kisha dĂ«gjuar kurrĂ« mĂ« parĂ« pĂ«r tĂ«. Ndoshta sepse kĂ«rkoja zgjidhje falas, por Robin paguhet. Ata kanĂ« njĂ« version mjaft bujar falas me 10 TB ruajtje dhe tre nyje. NĂ« pĂ«rgjithĂ«si, produkti Ă«shtĂ« mjaft i mirĂ« dhe ka karakteristika tĂ« mira. Ekziston njĂ« CLI i shkĂ«lqyeshĂ«m, por gjĂ«ja mĂ« interesante Ă«shtĂ« se ju mund tĂ« fotografoni dhe tĂ« bĂ«ni kopje rezervĂ« tĂ« tĂ« gjithĂ« aplikacionit (nĂ« pĂ«rzgjedhĂ«sin e burimeve kjo quhet lĂ«shimet e Helm ose "aplikacionet e pĂ«rkulura"), duke pĂ«rfshirĂ« vĂ«llimet dhe burimet e tjera, kĂ«shtu qĂ« mund tĂ« bĂ«ni pa Velero. Dhe gjithçka do tĂ« ishte e mrekullueshme nĂ«se jo pĂ«r njĂ« detaj tĂ« vogĂ«l: nĂ«se rivendosni (ose "importoni", siç quhet nĂ« Robin) njĂ« aplikacion nĂ« njĂ« grup tĂ« ri - pĂ«r shembull, nĂ« rast rikuperimi nga njĂ« fatkeqĂ«si - restaurimi, sigurisht, funksionon, por vazhdoni tĂ« bĂ«ni kopje rezervĂ« tĂ« aplikacionit Ă«shtĂ« e ndaluar. Kjo thjesht nuk Ă«shtĂ« e mundur nĂ« kĂ«tĂ« version, siç kanĂ« konfirmuar zhvilluesit. Kjo Ă«shtĂ«, pĂ«r ta thĂ«nĂ« butĂ«, e çuditshme, veçanĂ«risht duke marrĂ« parasysh avantazhet e tjera (pĂ«r shembull, kopjet rezervĂ« dhe rikthimet jashtĂ«zakonisht tĂ« shpejta). Zhvilluesit premtojnĂ« tĂ« rregullojnĂ« gjithçka deri nĂ« versionin e ardhshĂ«m. Performanca Ă«shtĂ« pĂ«rgjithĂ«sisht e mirĂ«, por vura re njĂ« çuditshmĂ«ri: nĂ«se ekzekutoj standardin direkt nĂ« njĂ« vĂ«llim tĂ« bashkangjitur me hostin, shpejtĂ«sia e leximit Ă«shtĂ« shumĂ« mĂ« e shpejtĂ« sesa ekzekutimi i tĂ« njĂ«jtit volum nga brenda pod. TĂ« gjitha rezultatet e tjera janĂ« identike, por nĂ« teori nuk duhet tĂ« ketĂ« asnjĂ« ndryshim. Edhe pse ata po punojnĂ« pĂ«r tĂ«, unĂ« u mĂ«rzita pĂ«r problemin me rivendosjen dhe kopjimin - mendova se mĂ« nĂ« fund kisha gjetur njĂ« zgjidhje tĂ« pĂ«rshtatshme dhe madje isha i gatshĂ«m tĂ« paguaja pĂ«r tĂ« kur kisha nevojĂ« pĂ«r mĂ« shumĂ« hapĂ«sirĂ« ​​ose mĂ« shumĂ« serverĂ«.

portworx

Nuk kam shumë për të thënë këtu. Ky është një produkt me pagesë, po aq i lezetshëm dhe i shtrenjtë. Performanca është thjesht e mahnitshme. Ky është treguesi më i mirë deri tani. Slack më tha se çmimi fillon me 205 dollarë në muaj për nyje, siç renditet në Tregun GKE të Google. Nuk e di nëse do të jetë më lirë nëse blini direkt. Unë nuk mund ta përballoj këtë gjithsesi, kështu që isha shumë, shumë i zhgënjyer që licenca e zhvilluesit (deri në 1 TB dhe 3 nyje) është praktikisht e padobishme me Kubernetes nëse nuk jeni të kënaqur me sigurimin statik. Shpresoja që licenca e vëllimit do të zbriste automatikisht në zhvillues në fund të periudhës së provës, por kjo nuk ndodhi. Licenca e zhvilluesit mund të përdoret vetëm drejtpërdrejt me Docker, dhe konfigurimi në Kubernetes është shumë i rëndë dhe i kufizuar. Sigurisht që preferoj open source, por nëse do të kisha para, do të zgjidhja patjetër Portworx. Deri më tani, performanca e tij thjesht nuk krahasohet me opsionet e tjera.

Linstor

E shtova këtë seksion pasi u publikua postimi, kur një lexues sugjeroi të provoja Linstor. E provova dhe më pëlqeu! Por duhet të bëj disa kërkime më të hollësishme. Për momentin, mund të them se performanca është mjaft e mirë (kam shtuar rezultatet e testit benchmark më poshtë). Në fakt, mora të njëjtën performancë si me një test benchmark të diskut direkt, pa asnjë mbingarkesë. (Mos pyet pse numrat e Portworx janë më të mirë se testi benchmark i diskut direkt. Nuk kam ide. Magjike, mendoj.) Pra, Linstor duket shumë efektiv deri më tani. Konfigurimi i tij nuk është pikërisht i vështirë, por nuk është aq i lehtë sa opsionet e tjera. Së pari, më duhej të instaloja Linstor (moduli i bërthamës dhe mjetet/shërbimet) dhe të konfiguroja LVM për ofrimin e hollë dhe mbështetjen e pamjeve të çastit jashtë Kubernetes, direkt në host, dhe pastaj të krijoja burimet e nevojshme për të përdorur hapësirën e ruajtjes nga Kubernetes. Nuk isha i kënaqur që nuk funksionoi në CentOS dhe duhej të përdorte UbuntuNuk është ndonjë problem i madh, sigurisht, por është pak bezdisës sepse dokumentacioni (i cili është i shkëlqyer, meqë ra fjala) përmend disa paketa që nuk janë të disponueshme në depot e specifikuara të Epel. Linstor ka pamje të çastit, por jo kopje rezervë jashtë faqes, kështu që më është dashur të përdor përsëri Velero me Restic për kopje rezervë të vëllimit. Do të preferoja pamjet e çastit sesa kopjet rezervë në nivel skedari, por kjo është e tolerueshme nëse zgjidhja është performuese dhe e besueshme. Linstor është me burim të hapur, por ka mbështetje me pagesë. Nëse e kuptoj saktë, mund ta përdorni pa kufizime edhe nëse nuk keni një kontratë mbështetjeje, por do të duhej ta kontrolloja këtë. Nuk e di sa i testuar është Linstor për Kubernetes, por vetë shtresa e ruajtjes është jashtë Kubernetes, dhe duket sikur ka ekzistuar për një kohë, kështu që ndoshta është testuar tashmë në kushte të botës reale. A ka ndonjë zgjidhje këtu që do të më bënte të ndryshoja mendje dhe të kaloja përsëri në Kubernetes? Nuk e di. Më duhet të gërmoj pak më shumë dhe të mësoj rreth replikimit. Do ta shohim. Por përshtypja e parë është e mirë. Patjetër që do të preferoja të përdorja klasteret e mia Kubernetes në vend të Heroku për më shumë liri dhe për të mësuar gjëra të reja. Meqenëse Linstor nuk është aq i lehtë për t'u instaluar sa të tjerët, do të shkruaj një postim për këtë së shpejti.

Standardet

Fatkeqësisht, nuk mbajta shumë shënime për krahasimin, sepse nuk mendoja se do të shkruaja për të. Unë kam vetëm rezultate nga standardet bazë fio dhe vetëm për grupimet e nyjeve të vetme, kështu që nuk kam ende numra për konfigurime të përsëritura. Por nga këto rezultate mund të merrni një ide të përafërt se çfarë të prisni nga secili opsion, sepse i krahasova në të njëjtët serverë cloud, 4 bërthama, 16 GB RAM, me një disk shtesë prej 100 GB për vëllimet e testuara. Kam përdorur standardet tre herë për secilën zgjidhje dhe kam llogaritur rezultatin mesatar, plus kam rivendosur cilësimet e serverit për secilin produkt. E gjithë kjo është krejtësisht joshkencore, vetëm për t'ju dhënë një ide të përgjithshme. Në teste të tjera, kopjova 38 GB foto dhe video nga vëllimi dhe testova leximin dhe shkrimin, por, mjerisht, nuk i ruajta numrat. Me pak fjalë: Portworkx ishte shumë më i shpejtë.

Për standardin e vëllimit përdora 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: 4

Fillimisht krijova një vëllim me klasën e duhur të ruajtjes dhe më pas e drejtova punën me fio në prapaskenë. Mora 1 GB për të vlerësuar performancën dhe për të mos pritur shumë. Këtu janë rezultatet:

Hapësira ruajtëse në Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Unë kam theksuar vlerën më të mirë për çdo metrikë me të gjelbër dhe më të keqen me të kuqe.

Përfundim

Siç mund ta shihni, në shumicën e rasteve Portworx performoi më mirë se të tjerët. Por për mua është e shtrenjtë. Nuk e di sa kushton Robin, por ata kanë një version të shkëlqyeshëm falas, kështu që nëse dëshironi një produkt me pagesë, mund ta provoni (shpresojmë që së shpejti ta rregullojnë problemin me restaurimin dhe kopjet rezervë). Nga tre ato falas, unë pata më së paku probleme me OpenEBS, por performanca e tij është e paimagjinueshme. Më vjen keq që nuk kam ruajtur më shumë rezultate, por shpresoj se numrat dhe komentet e mia do t'ju ndihmojnë.

Burimi: www.habr.com

Bleni njĂ« host tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, serverĂ« VPS VDS đŸ”„ Bleni hosting tĂ« besueshĂ«m tĂ« faqeve tĂ« internetit me mbrojtje DDoS, servera VPS VDS | ProHoster