Përditëso!. Në komente, një nga lexuesit sugjeroi të provoni (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ë , sepse procesi është shumë i ndryshëm nga pjesa tjetër.
Të them të drejtën hoqa dorë dhe hoqa dorë (të paktën tani për tani). do të përdor . 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 sepse është i lirë dhe performanca është e mirë dhe që në fillim kam vendosur grupe duke përdorur . 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 , 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:
Siç e thashë tashmë Pasi 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 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 në një grup të ri sepse emrat e nyjeve ishin të ndryshëm. Nëse flasim për kopje rezervë, cStor ka , 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 , 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...
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. , 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 , 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ë.
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 ë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.
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ë.
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.
E shtova këtë pjesë pas publikimit të postimit, kur një lexues sugjeroi të provonte Linstor. E provova dhe më pëlqeu! Por ne ende duhet të gërmojmë më thellë. Tani mund të them që performanca nuk është e keqe (kam shtuar rezultatet e standardeve më poshtë). Në thelb, unë mora të njëjtën performancë si disku direkt, pa asnjë shpenzim. (Mos pyet pse Portworx ka numra më të mirë se standardi i disqeve drejtpërdrejt. Nuk e kam idenë. Magjike, mendoj.) Kështu që Linstor duket shumë efektiv deri më tani. Nuk është aq e vështirë për t'u instaluar, por nuk është aq e lehtë sa opsionet e tjera. Fillimisht më duhej të instaloja Linstor (modulin e kernelit dhe veglat/shërbimet) dhe të konfiguroja LVM për ofrimin e hollësishëm dhe mbështetjen e fotografive jashtë Kubernetes, direkt në host, dhe më pas të krijoja burimet e nevojshme për të përdorur hapësirën ruajtëse nga Kubernetes. Nuk më pëlqeu që nuk funksiononte në CentOS dhe më duhej të përdorja Ubuntu. Jo e tmerrshme, sigurisht, por pak e bezdisshme, sepse dokumentacioni (i cili është i shkëlqyeshëm, meqë ra fjala) përmend disa paketa që nuk mund të gjenden në depot e specifikuara të Epel. Linstor ka fotografi, por jo kopje rezervë jashtë sajtit, kështu që këtu përsëri më duhej të përdor Velero me Restic për të rezervuar vëllime. Unë do të preferoja fotografitë në vend të kopjeve rezervë të nivelit të skedarit, por kjo mund të tolerohet nëse zgjidhja është e efektshme dhe e besueshme. Linstor është me burim të hapur, por ka mbështetje me pagesë. Nëse e kuptoj mirë, mund të përdoret pa kufizime, edhe nëse nuk keni një kontratë mbështetjeje, por kjo duhet të sqarohet. Nuk e di se sa është testuar Linstor për Kubernetes, por vetë shtresa e ruajtjes është jashtë Kubernetes dhe, me sa duket, zgjidhja nuk u shfaq dje, kështu që me siguri tashmë është testuar në kushte reale. A ka ndonjë zgjidhje këtu që do të më bëjë të ndryshoj mendje dhe të kthehem në Kubernetes? Nuk e di. Ne ende duhet të gërmojmë më thellë dhe të studiojmë përsëritjen. Le të shohim. Por përshtypja e parë është e mirë. Do të preferoja patjetër të përdor grupet e mia Kubernetes në vend të Heroku për të pasur 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, unë do të shkruaj një postim për 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: 4Fillimisht 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:
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