Actualizare!. În comentarii, unul dintre cititori a sugerat să încercăm (poate că el lucrează la asta), așa că am adăugat un capitol despre această soluție. De asemenea, am scris , deoarece procesul este foarte diferit de celelalte.
Sincer, am renunțat și m-am retras de la (cel puțin deocamdată). Voi folosi . De ce? Din cauza stocării! Cine s-ar fi gândit că voi petrece mai mult timp cu soluțiile de stocare decât cu Kubernetes în sine. Folosesc , pentru că este ieftin și performanța este bună, și de la început am desfășurat clustere folosind . Nu am încercat serviciile gestionate Kubernetes de la Google/Amazon/Microsoft/DigitalOcean și așa mai departe, pentru că am vrut să învăț singur. Și sunt și zgârcit.
Așa că – da, am petrecut o mulțime de timp încercând să decid ce soluție de stocare să aleg, când mă gândeam la posibila stivă pe Kubernetes. Prefer soluțiile open-source, nu doar din cauza prețului, dar am studiat câteva opțiuni plătite din curiozitate, pentru că au versiuni gratuite cu limitări. Am notat câteva cifre din ultimele teste când am comparat diferitele opțiuni și acestea ar putea interesa pe cei care studiază stocarea în Kubernetes. Deși personal m-am despărțit de Kubernetes pentru moment. Vreau să mai menționez , în care poți pregăti direct volumele Hetzner Cloud, dar nu l-am încercat încă. Am studiat stocările cloud definite prin software, deoarece aveam nevoie de replicare și de capacitatea de a monta rapid volume persistente pe orice nod, mai ales în caz de eșec al nodurilor și în alte situații similare. Unele soluții oferă snapshot-uri la un moment dat și backup-uri off-site, ceea ce este convenabil.
Am testat 6–7 soluții pentru stocare:
Așa cum am spus , după ce am testat majoritatea opțiunilor din listă, la început m-am oprit la OpenEBS. OpenEBS este foarte simplu de instalat și utilizat, dar, sincer, după teste cu date reale sub sarcină, performanța sa m-a dezamăgit. Este open-source și dezvoltatorii pe canalul lor m-au ajutat întotdeauna foarte mult când aveam nevoie de ajutor. Din păcate, are o performanță foarte scăzută în comparație cu alte opțiuni, așa că a trebuit să refac testele. În prezent, OpenEBS are 3 motoare de stocare, dar public rezultatele benchmark-ului pentru cStor. Deocamdată nu am cifre pentru Jiva și LocalPV.
În cuvinte simple, Jiva este puțin mai rapid, iar LocalPV este foarte rapid, la fel de bun ca benchmark-ul direct al discului. Problema cu LocalPV este că accesul se poate obține doar pe nodul pe care a fost pregătit, iar replicarea nu există deloc. Am avut unele probleme cu restaurarea backup-ului prin pe un nou cluster, deoarece numele nodurilor erau diferite. Vorbind despre backup-uri, cStor are , cu care se pot face backup-uri off site ale instantaneelor la un moment dat, ceea ce este mai convenabil decât backup-urile la nivel de fișiere cu Velero-Restic. Am scris , pentru a facilita gestionarea backup-urilor și restaurărilor cu acest plugin. În general, îmi place foarte mult OpenEBS, dar performanța lui...
Rook are, de asemenea, cod sursă deschis, iar față de celelalte opțiuni din listă, se diferențiază prin faptul că este un orchestrator de stocare, care îndeplinește sarcini complexe de gestionare a stocării cu diferite backend-uri, de exemplu , și altele, ceea ce simplifică semnificativ munca. Am avut probleme cu EdgeFS când l-am încercat acum câteva luni, așa că am testat în principal cu Ceph. Ceph oferă nu doar stocare de blocuri, ci și stocare de obiecte compatibilă cu S3/Swift și un sistem de fișiere distribuit. Ceea ce îmi place la Ceph este posibilitatea de a răspândi datele volumului pe mai multe discuri, astfel încât volumul să poată folosi mai mult spațiu pe disc decât se încap într-un singur disc. Este convenabil. O altă caracteristică interesantă este că, atunci când adaugi discuri în cluster, le redistribuie automat datele pe toate discurile.
În Ceph există instantanee, dar, din câte știu, acestea nu pot fi utilizate direct în Rook/Kubernetes. Totuși, nu am aprofundat subiectul. Nu există backup-uri off site, deci va trebui să folosim ceva de genul Velero/Restic, dar acestea oferă doar backup-uri la nivel de fișiere, nu instantanee de moment. Totuși, mi-a plăcut foarte mult modul simplu de lucru cu Ceph în Rook—acesta ascunde aproape toate aspectele complexe și oferă instrumente pentru a interacționa direct cu Ceph pentru depanare. Din păcate, am avut întotdeauna probleme pe timpul testării de stres pentru volumele Ceph. , din cauza căreia Ceph devine instabil. Încă nu este clar dacă este o eroare în Ceph însuși sau o problemă de modul în care Rook gestionează Ceph. Am experimentat cu setările de memorie, și a fost un pic mai bine, dar problema nu a fost complet rezolvată. Ceph are o performanță decentă, așa cum se poate observa în benchmark-urile de mai jos. De asemenea, are un panou de monitorizare bun.
Îmi place foarte mult Longhorn. Cred că este o soluție promițătoare. Totuși, dezvoltatorii înșiși (Rancher Labs) recunosc că în prezent nu este potrivit pentru medii de producție, și acest lucru este evident. Este open source și are o performanță decentă (deși optimizarea acesteia nu a fost încă realizată), dar volumele se conectează foarte lent la pod, și în cele mai rele cazuri durează între 15-16 minute, mai ales după ce ai restaurat un backup mare sau după un upgrade de sarcină de lucru. Are instantanee și backup-uri off site ale acestor instantanee, dar se aplică doar volumelor, așa că va trebui să ai totuși ceva de genul Velero pentru backup-ul celorlalte resurse. Backup-urile și restaurările sunt foarte fiabile, dar extrem de lente. Serios, pur și simplu sunt incredibil de lente. Utilizarea resurselor CPU și încărcarea sistemului cresc adesea când lucrezi cu un volum mediu de date în Longhorn. Există un panou de monitorizare convenabil pentru a gestiona Longhorn. Am menționat deja că îmi place Longhorn, dar trebuie să se lucreze serios la el.
StorageOS este primul produs plătit din listă. Are o versiune pentru dezvoltatori cu un spațiu de stocare gestionat limitat la 500 GB, dar numărul de noduri, cred, nu este restricționat. În departamentul de vânzări mi s-a spus că prețul pornește de la 125 USD pe lună pentru 1 TB, dacă mi-am amintit corect. Există un panou de monitorizare de bază și un CLI comod, dar performanța este oarecum ciudată: în anumite benchmarkuri este destul de decentă, dar în testul de stres al volumelor viteza nu mi-a plăcut deloc. În general, nu știu ce să spun. Așa că nu m-am adâncit prea mult. Aici nu sunt back-upuri off-site și va trebui să folosesc Velero cu Restic pentru backupul volumelor. Ciudat, având în vedere că produsul este plătit. Și, de asemenea, dezvoltatorii nu păreau dornici să comunice pe Slack.
Am aflat despre Robin pe Reddit de la directorul lor tehnic. Nu mai auzisem de el până atunci. Poate pentru că căutam soluții gratuite, iar Robin este un produs plătit. Au o versiune gratuită destul de generoasă cu stocare de 10 TB și trei noduri. În general, produsul este destul de bun, având funcții plăcute. Există un CLI excelent, dar cel mai tare este faptul că poți face un snapshot și un backup al întregii aplicații (în selectorul de resurse, aceasta este numită variante Helm sau „flex apps”), inclusiv volumele și alte resurse, astfel încât poți evita Velero. Totul ar fi fost minunat, dacă nu ar fi fost un detaliu mic: dacă restaurezi (sau „importi”, așa cum se numește în Robin) aplicația pe un nou cluster — de exemplu, în cazul unei recuperări după o defecțiune — restaurarea, desigur, funcționează, dar continuarea backup-ului aplicației nu este posibilă. În această variantă, pur și simplu nu se poate face, iar dezvoltatorii au confirmat acest lucru. Este, pe scurt, ciudat, mai ales având în vedere celelalte avantaje (de exemplu, backup-uri și restaurări incredibil de rapide). Dezvoltatorii promit să rezolve toate problemele până la următoarea variantă. Performanța, în general, este bună, dar am observat o ciudățenie: dacă rulezi un benchmark direct pe volumul conectat la gazdă, viteza de citire este mult mai mare decât pe același volum, dar din interiorul podului. Toate celelalte rezultate sunt identice, dar în teorie nu ar trebui să existe o diferență. Deși lucrează la asta, am fost dezamăgit din cauza problemelor cu restaurarea și backup-ul — mi s-a părut că în sfârșit găsisem o soluție potrivită, și chiar eram dispus să plătesc pentru ea atunci când aveam nevoie de mai mult spațiu sau mai multe servere.
Aici nu am multe de spus. Este un produs plătit, la fel de grozav și scump. Performanța este pur și simplu uimitoare. Până acum, acesta este cel mai bun rezultat. În Slack mi-au spus că prețul începe de la 205 USD pe lună pentru un nod, așa cum este menționat în GKE Marketplace de la Google. Nu știu dacă va fi mai ieftin dacă cumpărați direct. În orice caz, nu îmi permit așa ceva, așa că am fost foarte și foarte dezamăgit că licența pentru dezvoltatori (de până la 1 TB și 3 noduri) este practic inutilizabilă cu Kubernetes, decât dacă ești mulțumit cu pregătirea statică. Speram că licența enterprise va trece automat la nivelul de dezvoltator la sfârșitul perioadei de probă, dar nu s-a întâmplat. Licența pentru dezvoltatori poate fi utilizată doar direct cu Docker, iar configurarea în Kubernetes este foarte complexă și limitată. Bineînțeles, prefer open-source, dar dacă aș avea banii, aș alege cu siguranță Portworx. Până acum, performanța sa pur și simplu nu se compară cu alte opțiuni.
Am adăugat această secțiune după publicarea postului, când un cititor a sugerat să încerc Linstor. L-am încercat și mi-a plăcut! Dar mai trebuie să aprofundez. Acum pot spune că performanța este decentă (rezultatele benchmark-ului le-am adăugat mai jos). Practic, am obținut aceeași performanță ca pentru un disc direct, fără costuri suplimentare. (Nu mă întrebați de ce Portworx are cifre mai bune decât benchmark-ul discului direct. N-am idee. Magie, probabil.) Așa că Linstor pare foarte eficient pentru moment. Instalarea nu este extrem de complicată, dar nici atât de simplă precum alte variante. La început, a trebuit să instalez Linstor (modul kernel și instrumente/servicii) și să configurez LVM pentru thin provisioning și suport pentru snapshots în afara Kubernetes, direct pe host, și apoi să creez resursele necesare pentru a utiliza stocarea din Kubernetes. Nu mi-a plăcut că nu a funcționat pe CentOS, așa că a trebuit să folosesc Ubuntu. Nu este o problemă mare, dar este puțin frustrant, deoarece în documentația (care, apropo, este excelentă) sunt menționate câteva pachete care nu pot fi găsite în depozitele Epel indicate. În Linstor există snapshots, dar nu backup-uri off-site, așa că din nou a fost necesar să folosesc Velero cu Restic pentru a face backup-uri ale volumelor. Aș fi preferat snapshots în loc de backup-uri la nivel de fișiere, dar se poate tolera dacă soluția este performantă și de încredere. Linstor are cod sursă deschis, dar există suport plătit. Dacă înțeleg bine, poate fi utilizat fără restricții, chiar dacă nu aveți un contract de suport, dar trebuie să clarific acest lucru. Nu știu cât de bine a fost testat Linstor pentru Kubernetes, dar nivelul de stocare este în afara Kubernetes și, judecând după toate, soluția nu a apărut ieri, așa că probabil a fost testată în condiții reale. Există vreo soluție aici care să mă facă să mă răzgândesc și să mă întorc la Kubernetes? Nu știu, nu știu. Trebuie să mai aprofundez, să studiez replicarea. Vom vedea. Dar prima impresie este bună. Cu siguranță aș prefera să folosesc clusterele mele Kubernetes în loc de Heroku pentru a avea mai multă libertate și a învăța lucruri noi. Deoarece instalarea Linstor nu este atât de simplă ca la celelalte, voi scrie în curând un post despre asta.
Benchmark-uri
Din păcate, am păstrat puține înregistrări despre comparație, pentru că nu am crezut că voi scrie despre asta. Am doar rezultatele benchmark-urilor de bază fio și doar pentru clustere cu un singur nod, astfel că pentru configurațiile replicate nu am cifre pentru moment. Dar pe baza acestor rezultate se poate obține o idee aproximativă despre ce să aștepți de la fiecare opțiune, pentru că le-am comparat pe servere cloud identice, 4 nuclee, 16 GB RAM, cu un disc suplimentar de 100 GB pentru volumele testate. Am rulat benchmark-urile de trei ori pentru fiecare soluție și am calculat rezultatul mediu, plus am resetat setările serverului pentru fiecare produs. Toate acestea nu sunt deloc științifice, doar pentru a vă face o idee generală. În alte teste am copiat 38 GB de fotografii și video de pe volum și pe volum, pentru a testa citirea și scrierea, dar din păcate nu am păstrat cifrele. Pe scurt: Portworx a fost mult mai rapid.
Pentru benchmark-ul volumelor am folosit acest 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: 4La început am creat un volum cu clasa de stocare corespunzătoare, apoi am rulat o sarcină cu fio în fundal. Am ales 1 GB pentru a estima performanța și a nu aștepta prea mult. Iată rezultatele:
Am evidențiat cea mai bună valoare pentru fiecare indicator în verde și cea mai slabă în roșu.
Concluzie
După cum puteți observa, în cele mai multe cazuri, Portworx s-a comportat mai bine decât ceilalți. Dar pentru mine este scump. Nu știu cât costă Robin, dar au o versiune gratuită excelentă, așa că, dacă aveți nevoie de un produs plătit, o puteți încerca (sper că vor rezolva în curând problema cu recuperarea și backup-urile). Dintre cele trei gratuite, am avut cele mai puține probleme cu OpenEBS, dar performanța sa este foarte slabă. Îmi pare rău că nu am păstrat mai multe rezultate, dar sper ca cifrele și comentariile mele să vă ajute.
Sursa: habr.com
