Actualizați!. În comentarii, unul dintre cititori a sugerat să încerce (poate că lucrează el însuși la asta) așa că am adăugat o secțiune despre această soluție. am scris si eu , deoarece procesul este foarte diferit de restul.
Sincer să fiu, am renunțat și am renunțat (cel putin pentru moment). voi folosi . De ce? Din cauza depozitării! Cine ar fi crezut că m-aș juca mai mult cu stocarea decât cu Kubernetes în sine. eu folosesc pentru că este ieftin și performanța este bună și de la bun început am implementat clustere folosind . Nu am încercat serviciile Kubernetes gestionate de la Google/Amazon/Microsoft/DigitalOcean etc., etc., pentru că am vrut să învăț totul singur. Si eu sunt cumpat.
Deci, da, am petrecut mult timp încercând să decid ce spațiu de stocare să aleg atunci când evaluam o posibilă stivă Kubernetes. Prefer soluțiile open source, nu numai din cauza prețului, dar m-am uitat la câteva opțiuni plătite din curiozitate, deoarece au versiuni gratuite cu limitări. Am notat câteva numere din testele recente când am comparat diferite opțiuni și ar putea fi de interes pentru cei care învață despre stocarea Kubernetes. Deși personal mi-am luat rămas bun de la Kubernetes deocamdată. vreau sa mentionez si eu , care poate furniza direct volume Hetzner Cloud, dar nu am încercat încă. M-am uitat la stocarea definită de software în cloud pentru că aveam nevoie de replicare și de capacitatea de a monta rapid volume persistente pe orice nod, mai ales în cazul defecțiunilor nodului și în alte situații similare. Unele soluții oferă instantanee punctuale și backup-uri în afara locației, ceea ce este convenabil.
Am testat 6-7 soluții de stocare:
După cum am spus deja După ce am testat majoritatea opțiunilor din listă, inițial m-am stabilit pe OpenEBS. OpenEBS este foarte ușor de instalat și utilizat, dar sincer să fiu, după ce am testat cu date reale sub încărcare, am fost dezamăgit de performanța sa. Acesta este open source, iar dezvoltatorii sunt pe cont propriu întotdeauna de mare ajutor când am avut nevoie de ajutor. Din păcate, are performanțe foarte slabe în comparație cu alte opțiuni, așa că testele au trebuit să fie reluate. OpenEBS are în prezent 3 motoare de stocare, dar postez rezultate de referință pentru cStor. Nu am încă numere pentru Jiva și LocalPV.
Pe scurt, Jiva este puțin mai rapid, iar LocalPV este în general rapid, nu mai rău decât benchmark-ul direct pe disc. Problema cu LocalPV este că volumul poate fi accesat doar pe nodul în care a fost pregătit și nu există deloc replicare. Am avut câteva probleme la restabilirea unei copii de rezervă prin pe un cluster nou, deoarece numele nodurilor erau diferite. Dacă vorbim de copii de rezervă, cStor are , cu care puteți face copii de siguranță ale instantaneelor la un moment dat, ceea ce este mai convenabil decât backup-urile la nivel de fișier 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 este, de asemenea, open source și diferă de restul opțiunilor de pe listă prin faptul că este un orchestrator de stocare care efectuează sarcini complexe de gestionare a stocării cu backend-uri diferite, de ex. , și altele, ceea ce simplifică foarte mult munca. Am avut probleme cu EfgeFS când l-am încercat acum câteva luni, așa că am testat în principal cu Ceph. Ceph oferă nu numai stocare în bloc, ci și stocare de obiecte compatibile cu S3/Swift și sistemul de fișiere distribuit. Ceea ce îmi place la Ceph este capacitatea de a răspândi datele de volum pe mai multe discuri, astfel încât volumul să poată utiliza mai mult spațiu pe disc decât poate încăpea pe un singur disc. Este confortabil. O altă caracteristică interesantă este că, atunci când adăugați discuri la un cluster, acesta redistribuie automat datele pe toate discurile.
Ceph are instantanee, dar din câte știu eu, acestea nu pot fi folosite direct în Rook/Kubernetes. Adevărat, nu am intrat adânc în asta. Dar nu există copii de rezervă în afara site-ului, așa că va trebui să utilizați ceva cu Velero/Restic, dar există doar copii de rezervă la nivel de fișier, nu instantanee punctuale. Ce mi-a plăcut foarte mult la Rook a fost cât de ușor este să lucrezi cu Ceph - ascunde aproape toate lucrurile complicate și oferă instrumente pentru a vorbi direct cu Ceph pentru depanare. Din păcate, în timpul testului de stres al volumelor Ceph, am continuat să am probleme cu , ceea ce face ca Ceph să devină instabil. Nu este încă clar dacă acesta este o eroare în Ceph în sine sau o problemă în modul în care Rook gestionează Ceph. Am schimbat setările de memorie și s-a îmbunătățit, dar problema nu a fost complet rezolvată. Ceph are performanțe decente, așa cum puteți vedea în benchmark-urile de mai jos. Are și un tablou de bord bun.
Îmi place foarte mult Longhorn. În opinia mea, aceasta este o soluție promițătoare. Adevărat, dezvoltatorii înșiși (Rancher Labs) admit că nu este încă potrivit pentru mediul de lucru, iar acest lucru se vede. Este open source și are performanțe decente (deși încă nu l-au optimizat), dar volumele durează foarte mult până se conectează la pod, iar în cele mai rele cazuri durează 15-16 minute, mai ales după restaurarea unui backup mare sau modernizarea volumului de muncă. Are instantanee și copii de rezervă în afara site-ului ale acestor instantanee, dar acestea se aplică doar volumelor, așa că veți avea nevoie de ceva de genul Velero pentru a face backup altor resurse. Backup-urile și restaurările sunt foarte fiabile, dar indecent de lente. Serios, doar incredibil de lent. Utilizarea procesorului și încărcarea sistemului cresc adesea atunci când lucrați cu o cantitate medie de date în Longhorn. Există un tablou de bord convenabil pentru a gestiona Longhorn. Am spus deja că îmi place Longhorn, dar are nevoie de ceva muncă.
StorageOS este primul produs plătit de pe listă. Are o versiune de dezvoltator cu o dimensiune limitată de stocare gestionată de 500 GB, dar nu cred că există o limită a numărului de noduri. Departamentul de vânzări mi-a spus că costul începe de la 125 USD pe lună pentru 1 TB, dacă îmi amintesc bine. Există un tablou de bord de bază și un CLI convenabil, dar ceva ciudat se întâmplă cu performanța: în unele benchmark-uri este destul de decent, dar în testul de stres al volumului nu mi-a plăcut deloc viteza. În general, nu știu ce să spun. Deci nu am înțeles prea multe. Nu există copii de rezervă în afara site-ului aici și va trebui, de asemenea, să utilizați Velero cu Restic pentru a face backup pentru volume. Este ciudat, pentru că produsul este plătit. Și dezvoltatorii nu au fost dornici să comunice pe Slack.
Am aflat despre Robin pe Reddit de la directorul lor tehnic. Nu auzisem niciodată de el. Poate pentru că căutam soluții gratuite, dar Robin este plătit. Au o versiune gratuită destul de generoasă, cu 10TB de stocare și trei noduri. În general, produsul este destul de decent și are caracteristici frumoase. Există un CLI grozav, dar cel mai tare lucru este că puteți face instantanee și backup pentru întreaga aplicație (în selectorul de resurse aceasta se numește lansări Helm sau „aplicații flexibile”), inclusiv volume și alte resurse, astfel încât să puteți face fără Velero. Și totul ar fi minunat dacă nu pentru un mic detaliu: dacă restaurați (sau „importați”, așa cum se numește în Robin) o aplicație pe un cluster nou - de exemplu, în cazul recuperării după un dezastru - restaurarea, desigur, funcționează, dar continuați să faceți backup pentru aplicație, este interzis. Acest lucru pur și simplu nu este posibil în această versiune, așa cum au confirmat dezvoltatorii. Acest lucru este, ca să spunem ușor, ciudat, mai ales având în vedere celelalte avantaje (de exemplu, backup-uri și restaurări incredibil de rapide). Dezvoltatorii promit să repare totul până la următoarea ediție. Performanța este în general bună, dar am observat o ciudățenie: dacă rulez benchmark-ul direct pe un volum atașat la gazdă, viteza de citire este mult mai mare decât rularea aceluiași volum din interiorul podului. Toate celelalte rezultate sunt identice, dar în teorie nu ar trebui să existe nicio diferență. Deși lucrează la asta, m-a supărat problema cu restaurarea și backupul - credeam că am găsit în sfârșit 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.
Nu am multe de spus aici. Acesta este un produs plătit, la fel de cool și de scump. Performanța este pur și simplu uimitoare. Acesta este cel mai bun indicator de până acum. Slack mi-a spus că prețul începe de la 205 USD pe lună per nod, așa cum este listat în Google GKE Marketplace. Nu stiu daca va fi mai ieftin daca cumperi direct. Oricum nu-mi permit asta, așa că am fost foarte, foarte dezamăgit de faptul că licența de dezvoltator (până la 1 TB și 3 noduri) este practic inutilă cu Kubernetes, dacă nu te mulțumești cu provizionarea statică. Speram că licența de volum va trece automat la versiunea de dezvoltator la sfârșitul perioadei de probă, dar nu s-a întâmplat. Licența de dezvoltator poate fi utilizată doar direct cu Docker, iar configurația în Kubernetes este foarte greoaie și limitată. Desigur, prefer open source, dar dacă aș avea bani, cu siguranță aș alege 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 postării, când un cititor a sugerat să încerci Linstor. L-am incercat si mi-a placut! Dar încă trebuie să săpăm mai adânc. Acum pot spune că performanța nu este rea (am adăugat mai jos rezultatele benchmark-ului). În esență, am obținut aceleași performanțe ca și discul direct, fără nicio suprasarcină. (Nu întrebați de ce Portworx are numere mai bune decât benchmark-ul unității în mod direct. Habar n-am. Magie, cred.) Deci Linstor pare foarte eficient până acum. Nu este atât de greu de instalat, dar nu este la fel de ușor ca alte opțiuni. Mai întâi a trebuit să instalez Linstor (modul kernel și instrumente/servicii) și să configurez LVM pentru thin provisioning și suport pentru instantanee în afara Kubernetes, direct pe gazdă, apoi să creez resursele necesare pentru a utiliza stocarea din Kubernetes. Nu mi-a plăcut că nu funcționează pe CentOS și a trebuit să folosesc Ubuntu. Nu groaznic, desigur, dar puțin enervant, pentru că documentația (care este excelentă, de altfel) menționează mai multe pachete care nu pot fi găsite în depozitele Epel specificate. Linstor are instantanee, dar nu și backup-uri în afara site-ului, așa că aici din nou a trebuit să folosesc Velero cu Restic pentru a face backup pentru volume. Aș prefera instantanee în loc de backup-uri la nivel de fișier, dar acest lucru poate fi tolerat dacă soluția este performantă și fiabilă. Linstor este open source, dar are suport plătit. Dacă am înțeles bine, poate fi folosit fără restricții, chiar dacă nu aveți un contract de suport, dar acest lucru trebuie clarificat. Nu știu cât de testat este Linstor pentru Kubernetes, dar stratul de stocare în sine este în afara Kubernetes și, se pare, soluția nu a apărut ieri, așa că probabil că a fost deja testată în condiții reale. Există o soluție aici care să mă facă să mă răzgândesc și să mă întorc la Kubernetes? Nu stiu. Încă trebuie să săpăm mai adânc și să studiem replicarea. Să vedem. Dar prima impresie este bună. Cu siguranță aș prefera să folosesc propriile mele clustere Kubernetes în loc de Heroku pentru a avea mai multă libertate și pentru a învăța lucruri noi. Deoarece Linstor nu este la fel de ușor de instalat ca altele, voi scrie o postare despre el în curând.
Benchmark-uri
Din păcate, nu am păstrat multe note despre comparație pentru că nu credeam că voi scrie despre asta. Am doar rezultate de la benchmark-urile fio de bază și numai pentru clustere cu un singur nod, așa că nu am încă numere pentru configurațiile replicate. Dar din aceste rezultate vă puteți face o idee aproximativă la ce să vă așteptați de la fiecare opțiune, deoarece le-am comparat pe aceleași servere cloud, 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 sunt complet neștiințifice, doar pentru a vă oferi o idee generală. În alte teste, am copiat 38 GB de fotografii și videoclipuri din volum pentru a testa citirea și scrierea, dar, vai, nu am salvat numerele. Pe scurt: Portworkx a fost mult mai rapid.
Pentru referința de volum 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: 4Am creat mai întâi un volum cu clasa de stocare adecvată și apoi am rulat lucrarea cu fio în culise. Mi-a luat 1 GB pentru a estima performanța și nu aștept prea mult. Iată rezultatele:
Am evidențiat cea mai bună valoare pentru fiecare măsură în verde și cea mai proastă în roșu.
Concluzie
După cum puteți vedea, în majoritatea cazurilor Portworx a avut rezultate mai bune decât altele. Dar pentru mine este scump. Nu știu cât costă Robin, dar au o versiune gratuită grozavă, așa că dacă doriți un produs plătit, îl puteți încerca (sper că vor rezolva problema cu restaurarea și backup-urile în curând). Dintre cele trei gratuite, am avut cele mai puține probleme cu OpenEBS, dar performanța lui este abisală. Păcat că nu am salvat mai multe rezultate, dar sper să vă ajute cifrele și comentariile mele.
Sursa: www.habr.com