Aghjurnate!. In i cumenti, unu di i lettori hà suggeritu di pruvà (forse si travaglia ellu stessu) cusì aghju aghjustatu una sezione nantu à sta suluzione. Aghju scrittu ancu , perchè u prucessu hè assai sfarente da u restu.
Per esse onesto, aghju rinunziatu è rinunciatu (almenu per avà). Aduprà . Perchè? Per via di u almacenamentu! Quale averia pensatu ch'e aghju avutu più cun l'almacenamiento chì cù Kubernetes stessu. I aduprà perchè ùn hè micca prezzu è u rendiment hè bonu è da u principiu aghju implementatu clusters usendu . Ùn aghju micca pruvatu servizii gestiti Kubernetes da Google/Amazon/Microsoft/DigitalOcean, etc., etc., perchè mi vulia amparà tuttu. Sò ancu frugale.
Allora iè, aghju passatu assai tempu per pruvà à decide quale almacenamentu per sceglie quandu stava evaluendu una pussibule stack Kubernetes. Preferite solu suluzioni open source, micca solu per via di u prezzu, ma aghju cercatu un paru di opzioni pagate per curiosità perchè anu versioni libere cù limitazioni. Aghju annotatu uni pochi di numeri da teste recenti quandu paragunanu diverse opzioni chì puderanu interessà à quelli chì cercanu l'almacenamiento Kubernetes. Ancu se personalmente aghju dettu addiu à Kubernetes per ora. Vogliu ancu mintuvà , chì ponu furnisce direttamente volumi Hetzner Cloud, ma ùn aghju micca pruvatu ancu. Aghju cercatu l'almacenamiento definitu da u software in nuvola perchè avia bisognu di replicazione è a capacità di muntà rapidamente volumi persistenti in ogni node, soprattuttu in casu di fallimenti di node è altre situazioni simili. Alcune soluzioni offrenu snapshots puntuali è backups fora di u situ, chì hè convenientu.
Aghju pruvatu 6-7 soluzioni di almacenamento:
Cume aghju digià dettu Dopu avè pruvatu a maiò parte di l'opzioni da a lista, aghju inizialmente stabilitu in OpenEBS. OpenEBS hè assai faciule d'installà è d'utilizà, ma per esse onestu, dopu avè pruvatu cù dati veri sottu carica, aghju dispiacutu da a so prestazione. Questu hè open source, è i sviluppatori sò per sè stessu sempre assai utile quandu avia bisognu di aiutu. Sfurtunatamente, hà un rendimentu assai poveru cumparatu cù altre opzioni, cusì i testi anu da esse re-run. OpenEBS hà attualmente 3 mutori di almacenamiento, ma aghju publicatu risultati di benchmark per cStor. Ùn aghju micca numeri per Jiva è LocalPV.
In poche parole, Jiva hè un pocu più veloce, è LocalPV hè generalmente veloce, micca peggiu cà u benchmark di discu direttamente. U prublema cù LocalPV hè chì u voluminu pò esse accessu solu nantu à u node induve hè stata preparata, è ùn ci hè micca replicazione in tuttu. Aviu avutu qualchì problema per restaurà una copia di salvezza via nantu à un novu cluster perchè i nomi di i nodi eranu diffirenti. Se parlemu di backups, cStor hà , cù quale pudete fà una copia di salvezza fora di u situ di snapshots à un puntu in u tempu, chì hè più còmuda cà e copia di salvezza di u schedariu cù Velero-Restic. Aghju scrittu , per facilità a gestione di backups è restaurazione cù stu plugin. In generale, mi piace assai OpenEBS, ma u so rendiment ...
Rook hè ancu open source è difiere da u restu di l'opzioni nantu à a lista in quantu hè un orchestratore di almacenamiento chì esegue compiti cumplessi di gestione di almacenamento cù backends differenti, per esempiu. , è altri, chì simplificà assai u travagliu. Aviu avutu prublemi cù EfgeFS quandu l'aghju pruvatu uni pochi mesi fà, cusì aghju pruvatu principarmenti cù Ceph. Ceph ùn solu offre u almacenamentu di blocchi, ma ancu u almacenamentu d'ughjettu cumpatibile cù S3 / Swift è u sistema di fugliale distribuitu. Ciò chì mi piace di Ceph hè a capacità di sparghje u voluminu di dati in parechji dischi in modu chì u voluminu pò usà più spaziu di discu di quellu chì si mette in un discu unicu. Hè còmode. Un'altra funzione interessante hè chì quandu aghjunghje dischi à un cluster, redistribuisce automaticamente e dati in tutti i dischi.
Ceph hà snapshots, ma per ciò chì sò, ùn ponu micca esse utilizati direttamente in Rook / Kubernetes. True, ùn aghju micca andatu in fondu in questu. Ma ùn ci hè micca una copia di salvezza fora di u situ, cusì avete bisognu di utilizà qualcosa cù Velero / Restic, ma ci sò solu backups à livellu di fugliale, micca snapshots puntuali. Ciò chì mi piaceva assai di Rook era quantu faciule hè di travaglià cù Ceph - oculta quasi tutte e cose complicate è offre arnesi per parlà cun Ceph direttamente per risolve i prublemi. Sfortunatamente, durante a prova di stress di i volumi di Ceph, aghju continuatu à avè prublemi cù , chì face chì Ceph diventa instabile. Ùn hè ancu chjaru se questu hè un bug in Ceph stessu o un prublema in a manera chì Rook gestisce Ceph. Aghju aghjustatu cù i paràmetri di memoria, è hè megliu, ma u prublema ùn hè micca solu solu solu. Ceph hà un rendiment decentu, cum'è pudete vede in i benchmarks sottu. Hà ancu un bon dashboard.
Mi piace assai Longhorn. In u mo parè, questa hè una suluzione promettente. True, i sviluppatori stessi (Rancher Labs) ammettenu chì ùn hè ancu adattatu per l'ambiente di travagliu, è questu mostra. Hè open source è hà un rendimentu decentu (ancu s'ellu ùn anu micca ottimisatu ancu), ma i volumi pigghianu assai tempu per cunnette à u pod, è in i peggiori casi, ci vole 15-16 minuti, soprattuttu dopu a restaurazione di una grande copia di salvezza o. aghjurnà a carica di travagliu. Hà snapshots è backups fora di u situ di sti snapshots, ma sò appiicati solu à i volumi, cusì avete sempre bisognu di qualcosa cum'è Velero per salvà altre risorse. Backups è restaurazione sò assai affidabili, ma indecently slow. Seriu, solu incredibilmente lento. L'usu di CPU è a carica di u sistema sò spessu picchi quandu travaglianu cù una quantità media di dati in Longhorn. Ci hè un dashboard convenientu per gestisce Longhorn. Aghju digià dettu chì mi piace Longhorn, ma hà bisognu di travagliu.
StorageOS hè u primu pruduttu pagatu in a lista. Havi una versione di sviluppatore cù una dimensione di almacenamentu amministratu limitatu di 500GB, ma ùn pensu micca chì ci hè un limitu in u numeru di nodi. U dipartimentu di vendita m'hà dettu chì u costu principia da $ 125 per mese per 1 TB, se mi ricordu bè. Ci hè un dashboard basicu è un CLI cunvene, ma qualcosa di stranu passa cù u rendiment: in certi benchmarks hè abbastanza decentu, ma in a prova di stress di voluminu ùn mi piaceva micca a veloce. In generale, ùn sò micca ciò chì dì. Allora ùn aghju micca veramente capitu assai. Ùn ci sò micca backups fora di u situ quì è avete ancu aduprà Velero cù Restic per i volumi di salvezza. Hè stranu, perchè u pruduttu hè pagatu. È i sviluppatori ùn anu micca ansiosu di cumunicà nantu à Slack.
Aghju amparatu à Robin nantu à Reddit da u so direttore tecnicu. Ùn avia mai intesu parlà di ellu prima. Forsi perchè cercava suluzioni gratuiti, ma Robin hè pagatu. Hanu una versione libera abbastanza generosa cù 10TB di almacenamiento è trè nodi. In generale, u pruduttu hè abbastanza decentu è hà boni caratteristiche. Ci hè una grande CLI, ma a cosa più bella hè chì pudete snapshot è copia di salvezza di tutta l'applicazione (in u selettore di risorse questu hè chjamatu Helm releases o "flex apps"), cumprese volumi è altre risorse, perchè pudete fà senza Velero. È tuttu saria maravigliu s'ellu ùn hè micca per un picculu dettagliu: se restaurà (o "importa", cum'è chjamatu in Robin) una applicazione nantu à un novu cluster - per esempiu, in casu di ricuperazione da un disastru - a risturazione, di sicuru, travaglia, ma cuntinuà à fà una copia di salvezza di l'applicazione hè pruibita. Questu hè simplicemente micca pussibule in questa versione, cum'è i sviluppatori anu cunfirmatu. Questu hè, per dì un pocu, stranu, soprattuttu cunsiderà l'altri vantaghji (per esempiu, backups è restaurazione incredibbilmente veloci). I sviluppatori prumettenu di riparà tuttu da a prossima versione. A prestazione hè in generale bona, ma aghju nutatu una stranezza: se eseguite u benchmark direttamente nantu à un voluminu attaccatu à l'ospitu, a velocità di lettura hè assai più veloce di eseguisce u stessu voluminu da u pod. Tutti l'altri risultati sò idèntici, ma in teoria ùn deve esse micca diferenza. Ancu s'ellu sò travagliendu nantu à questu, era dispiaciutu per u prublema cù a restaurazione è a copia di salvezza - Pensu chì aghju finalmente trovu una suluzione adattata, è era ancu dispostu à pagà per quandu aghju bisognu di più spaziu o più servitori.
Ùn aghju micca assai da dì quì. Questu hè un pruduttu pagatu, ugualmente cool è caru. U rendiment hè simplicemente maravigghiusu. Questu hè u megliu indicatore finu à avà. Slack m'hà dettu chì i prezzi cumincianu à $ 205 per mese per node, cum'è listatu in u GKE Marketplace di Google. Ùn sò micca sapè s'ellu serà più prezzu se cumprate direttamente. Ùn possu micca permette chì in ogni modu, cusì era assai, assai disappuntu chì a licenza di sviluppatore (finu à 1 TB è 3 nodi) hè praticamente inutile cù Kubernetes, salvu chì ùn site cuntentu cù a pruvista statica. Sperava chì a licenza di u voluminu passassi automaticamente à u sviluppatore à a fine di u periodu di prova, ma ùn hè micca successu. A licenza di sviluppatore pò esse aduprata solu direttamente cù Docker, è a cunfigurazione in Kubernetes hè assai ingombra è limitata. Di sicuru, aghju preferitu l'open source, ma s'ellu aghju avutu i soldi, aghju definitamente sceglie Portworx. Finu a ora, u so rendimentu ùn hè micca paragunatu cù altre opzioni.
Aghju aghjustatu sta sezione dopu a publicazione di u post, quandu un lettore hà suggeritu di pruvà Linstor. Aghju pruvatu è mi piace ! Ma avemu sempre bisognu di scavà più in fondu. Avà possu dì chì u rendiment ùn hè micca male (aghju aghjustatu i risultati di benchmark sottu). Essenzialmente, aghju avutu u listessu rendimentu cum'è u discu direttamente, senza alcunu sopra. (Ùn dumandate micca perchè Portworx hà numeri megliu cà u benchmark di u drive direttamente. Ùn aghju micca idea. Magia, pensu.) Allora Linstor pare assai efficace finu à avà. Ùn hè micca cusì difficiule di stallà, ma ùn hè micca cusì faciule cum'è altre opzioni. Prima aghju avutu à installà Linstor (modulu di kernel è arnesi / servizii) è cunfigurà LVM per un appruvisionamentu sottile è un supportu di snapshot fora di Kubernetes, direttamente nantu à l'ospite, è poi creà e risorse necessarie per utilizà l'almacenamiento da Kubernetes. Ùn mi piace micca chì ùn hà micca travagliatu in CentOS è aghju avutu aduprà Ubuntu. Micca terribili, sicuru, ma un pocu fastidiosu, perchè a ducumentazione (chì hè eccellente, per via) cita parechji pacchetti chì ùn ponu micca truvatu in i repositori Epel specificati. Linstor hà snapshots, ma micca backups fora di u situ, cusì quì di novu aghju avutu aduprà Velero cù Restic per i volumi di salvezza. Preferite snapshots invece di backups à livellu di file, ma questu pò esse tolleratu se a suluzione hè performante è affidabile. Linstor hè open source ma hà supportu pagatu. Se capiscu bè, pò esse usatu senza restrizioni, ancu s'ellu ùn avete micca un cuntrattu di supportu, ma questu deve esse clarificatu. Ùn sò micca sapè quantu hè pruvatu Linstor per Kubernetes, ma a capa di almacenamento stessu hè fora di Kubernetes è, apparentemente, a suluzione ùn hè micca apparsu eri, cusì hè prubabilmente digià pruvatu in cundizioni reali. Ci hè una suluzione quì chì mi farà cambià a mo mente è vultà in Kubernetes? Ùn a sò micca. Avemu sempre bisognu di scavà più profonda è studià a replicazione. Videmu. Ma a prima impressione hè bona. Definitivamente preferite aduprà i mo propri clusters Kubernetes invece di Heroku per avè più libertà è amparà cose novi. Siccomu Linstor ùn hè micca cusì faciule d'installà cum'è l'altri, scriveraghju un post prestu prestu.
Benchmarks
Sfurtunatamente, ùn aghju micca guardatu assai note nantu à a paraguna perchè ùn aghju micca pensatu chì l'aghju da scrive. Aghju solu risultati da i benchmarks di basa fio è solu per i clusters di un node unicu, cusì ùn aghju micca numeri per cunfigurazioni replicate. Ma da questi risultati pudete avè una idea approssimativa di ciò chì aspetta da ogni opzione, perchè l'aghju paragunatu nantu à i stessi servitori di nuvola, 4 core, 16 GB di RAM, cù un discu supplementu di 100 GB per i volumi testati. Aghju curretu i benchmarks trè volte per ogni suluzione è hà calculatu u risultatu mediu, più aghju resettatu i paràmetri di u servitore per ogni pruduttu. Questu hè tuttu micca scientificu, solu per dà una idea generale. In altri testi, aghju copiatu 38 GB di foto è video da u voluminu per pruvà a lettura è a scrittura, ma, sfortunatamente, ùn aghju micca salvatu i numeri. In corta: Portworkx era assai più veloce.
Per u benchmark di u voluminu aghju utilizatu stu manifestu:
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: 4Prima aghju creatu un voluminu cù a classa d'almacenamiento appropritata è poi curria u travagliu cù fio daretu à i sceni. Aghju pigliatu 1 GB per stima u rendiment è ùn aspittà micca troppu longu. Eccu i risultati:
Aghju evidenziatu u megliu valore per ogni metrica in verde è u peghju in rossu.
cunchiusioni
Comu pudete vede, in a maiò parte di i casi Portworx hà fattu megliu cà l'altri. Ma per mè hè caru. Ùn sò micca sapè quantu Robin costa, ma anu una grande versione libera, perchè se vulete un pruduttu pagatu, pudete pruvà (sperendu chì risolve u prublema cù restaurazione è copia di salvezza prestu). Di i trè liberi, aghju avutu u minimu prublemi cù OpenEBS, ma u so rendimentu hè abismu. Hè un peccatu chì ùn aghju micca salvatu più risultati, ma speru chì i numeri è i mo cumenti vi aiutanu.
Source: www.habr.com