Update!. Dina komentar, salah sahiji pamiarsa nyarankeun nyobian (meureun manehna dipake dina eta sorangan) jadi Kuring geus ditambahkeun bagian ngeunaan solusi ieu. Kuring ogé nulis , sabab prosésna béda pisan sareng anu sanés.
Jujur, kuring nyerah sareng nyerah (sahenteuna pikeun ayeuna). Kuring bakal ngagunakeun . Naha? Kusabab gudang! Anu bakal nyangka yén kuring bakal tinker leuwih mibanda gudang ti ku Kubernetes sorangan. Kuring make sabab éta murah jeung kinerja anu alus sarta ti mimiti pisan kuring geus deploying klaster ngagunakeun . Kuring henteu nyobian jasa Kubernetes anu diurus ti Google / Amazon / Microsoft / DigitalOcean, jsb., jsb, sabab kuring hoyong diajar sadayana nyalira. Abdi ogé hemat.
Janten enya, kuring nyéépkeun seueur waktos pikeun mutuskeun panyimpen mana anu kedah dipilih nalika kuring ngevaluasi tumpukan Kubernetes anu mungkin. Abdi langkung resep solusi open source, sanés ngan ukur kusabab hargana, tapi kuring parantos ningali sababaraha pilihan anu mayar kusabab panasaran sabab gaduh versi gratis kalayan watesan. Kuring geus jotted handap sababaraha angka tina tés panganyarna nalika kuring ngabandingkeun pilihan béda, sarta aranjeunna bisa jadi dipikaresep ku nu diajar ngeunaan gudang Kubernetes. Sanajan kuring pribadi geus pamit ka Kubernetes pikeun ayeuna. Abdi ogé hoyong nyebatkeun , anu tiasa langsung nyayogikeun volume Hetzner Cloud, tapi kuring henteu acan nyobian. Kuring ningali kana panyimpenan anu didefinisikeun ku parangkat lunak awan sabab kuring peryogi réplikasi sareng kamampuan pikeun gancang masang jilid pengkuh dina node mana waé, khususna upami gagal node sareng kaayaan anu sami. Sababaraha solusi nawiskeun snapshots point-in-time sareng cadangan off-site, anu merenah.
Kuring nguji 6-7 solusi panyimpenan:
Sakumaha anu kuring parantos nyarios Saatos nguji seueur pilihan tina daptar, kuring mimitina netep dina OpenEBS. OpenEBS gampang pisan dipasang sareng dianggo, tapi jujur, saatos nguji sareng data nyata dina beban, kuring kuciwa kalayan kinerjana. Ieu open source, sarta pamekar sorangan salawasna pohara mantuan lamun kuring diperlukeun pitulung. Hanjakal, éta boga kinerja pisan goréng dibandingkeun pilihan séjén, jadi tés kudu ulang ngajalankeun. OpenEBS ayeuna gaduh 3 mesin panyimpen, tapi kuring ngeposkeun hasil patokan pikeun cStor. Abdi henteu gaduh nomer pikeun Jiva sareng LocalPV acan.
Singkatna, Jiva rada gancang, sareng LocalPV umumna gancang, henteu langkung parah tibatan patokan disk langsung. Masalah sareng LocalPV nyaéta polumeu ngan ukur tiasa diaksés dina titik dimana éta disiapkeun, sareng teu aya réplikasi pisan. Kuring kungsi sababaraha masalah malikkeun cadangan via dina klaster anyar sabab ngaran titik éta béda. Lamun urang ngobrol ngeunaan cadangan, cStor boga , nu bisa nyieun cadangan kaluar-situs snapshots dina hiji titik dina waktu, nu leuwih merenah ti file-tingkat cadangan kalawan Velero-Restic. Abdi nyerat , Sangkan leuwih gampang ngatur cadangan tur malikkeun kalawan plugin ieu. Gemblengna, kuring resep pisan OpenEBS, tapi pagelaran na ...
Rook oge open source sarta béda ti sesa pilihan dina daptar nu eta mangrupakeun orchestrator gudang nu ngalakukeun tugas manajemén gudang kompléks kalawan backends béda, f.eks. , jeung sajabana, nu greatly simplifies karya. Kuring kungsi masalah sareng EfgeFS nalika kuring diusahakeun eta sababaraha bulan kapengker, jadi kuring diuji utamana kalawan Ceph. Ceph teu ukur nawarkeun gudang block, tapi ogé gudang obyék cocog sareng S3 / Swift sarta sistem file disebarkeun. Anu kuring resep ngeunaan Ceph nyaéta kamampuan nyebarkeun data volume dina sababaraha disk supados volume tiasa nganggo langkung seueur rohangan disk tibatan anu pas dina hiji disk. Nyaman. Fitur anu sanés nyaéta nalika anjeun nambihan disk kana klaster, éta sacara otomatis nyebarkeun data ka sadaya disk.
Ceph boga snapshots, Tapi sajauh I terang, aranjeunna teu bisa dipaké langsung di Rook / Kubernetes. Leres, kuring henteu lebet kana ieu. Tapi teu aya cadangan kaluar-situs, jadi Anjeun kudu make hiji hal kalawan Velero / Restic, tapi ngan aya cadangan file-tingkat, teu titik-di-waktu snapshots. Anu kuring resep pisan ngeunaan Rook nyaéta kumaha gampangna damel sareng Ceph - éta nyumput ampir sadaya barang pajeulit sareng nawiskeun alat pikeun ngobrol sareng Ceph langsung pikeun ngungkulan. Hanjakal, salila test stress of Ceph jilid, Kuring terus ngalaman masalah , nu ngabalukarkeun Ceph jadi teu stabil. Ieu mah can écés naha ieu téh bug di Ceph sorangan atawa masalah dina cara Rook manages Ceph. Kuring tinkered kalawan setélan memori, sarta eta ngagaduhan hadé, tapi masalahna teu lengkep direngsekeun. Ceph boga kinerja santun, anjeun tiasa ningali dina tolok ukur handap. Éta ogé gaduh dasbor anu saé.
Abdi resep pisan Longhorn. Dina pamanggih kuring, ieu mangrupikeun solusi anu ngajangjikeun. Leres, pamekar sorangan (Rancher Labs) ngaku yén éta henteu acan cocog pikeun lingkungan kerja, sareng ieu nunjukkeun. Ieu open source sarta boga kinerja santun (sanajan maranéhna teu acan dioptimalkeun deui), tapi volume butuh waktu anu pohara lila pikeun nyambung ka pod, sarta dina kasus awon butuh 15-16 menit, utamana sanggeus mulangkeun cadangan badag atawa. ningkatkeun beban kerja. Éta gaduh jepretan sareng cadangan kaluar-situs tina jepretan ieu, tapi aranjeunna ngan ukur dilarapkeun kana jilid, ku kituna anjeun masih peryogi sapertos Velero pikeun nyadangkeun sumber daya sanés. Nyadangkeun tur malikkeun pisan dipercaya, tapi teu sopan slow. Serius, ngan incredibly slow. Pamakéan CPU sareng beban sistem sering naék nalika damel sareng jumlah data sedeng di Longhorn. Aya dasbor merenah pikeun ngatur Longhorn. Kuring geus ngomong yén kuring resep Longhorn, tapi perlu sababaraha karya.
StorageOS mangrupikeun produk anu mayar munggaran dina daptar. Éta ngagaduhan versi pamekar kalayan ukuran panyimpenan anu diurus dugi ka 500GB, tapi kuring henteu nyangka aya wates dina jumlah titik. Departemén penjualan ngawartoskeun kuring yén biaya dimimitian dina $125 per bulan pikeun 1 TB, lamun kuring apal neuleu. Aya dasbor dasar sareng CLI anu saé, tapi aya anu anéh dina pagelaran: dina sababaraha tolok ukur éta lumayan, tapi dina tés setrés volume kuring henteu resep kana lajuna. Sacara umum, kuring henteu terang naon anu kedah dicarioskeun. Janten kuring henteu ngartos pisan. Henteu aya cadangan di luar situs di dieu sareng anjeun ogé kedah nganggo Velero sareng Restic kana jilid cadangan. Ieu aneh, sabab produk mayar. Sareng pamekar henteu hoyong pisan komunikasi dina Slack.
Kuring diajar ngeunaan Robin on Reddit ti diréktur teknis maranéhanana. Abdi henteu kantos nguping anjeunna sateuacanna. Panginten kusabab kuring milarian solusi gratis, tapi Robin dibayar. Aranjeunna gaduh vérsi gratis anu lumayan ageung kalayan panyimpenan 10TB sareng tilu titik. Gemblengna, produkna cukup santun sareng gaduh fitur anu saé. Aya CLI anu saé, tapi anu paling keren nyaéta anjeun tiasa nyandak snapshot sareng nyadangkeun sadaya aplikasi (dina pamilih sumber ieu disebut pelepasan Helm atanapi "aplikasi fleksibel"), kalebet volume sareng sumber daya sanés, janten anjeun tiasa ngalakukeun tanpa Velero. Sareng sadayana bakal saé upami henteu pikeun hiji detil anu alit: upami anjeun malikkeun (atanapi "impor", sapertos anu disebat dina Robin) aplikasi dina klaster énggal - contona, upami pulih tina musibah - restorasi, tangtu, jalan, tapi terus nyadangkeun aplikasi eta dilarang. Ieu ngan saukur teu mungkin dina release ieu, sakumaha pamekar geus dikonfirmasi. Ieu, nempatkeun eta mildly, aneh, utamana tempo kaunggulan sejenna (Contona, incredibly gancang cadangan tur restores). Pamekar janji bakal ngalereskeun sadayana ku sékrési salajengna. Performance umumna alus, tapi kuring noticed hiji oddity: lamun kuring ngajalankeun patokan langsung dina volume napel host teh, speed maca leuwih gancang ti ngajalankeun volume sarua ti jero pod nu. Sadaya hasil anu sanés sami, tapi dina téori henteu kedah aya bédana. Sanajan aranjeunna keur dipake dina, Kuring éta kesel ngeunaan masalah sareng balikkeun na cadangan - Teu sangka Kuring tungtungna kapanggih solusi cocog, sarta kuring malah daék mayar eta nalika kuring diperlukeun leuwih spasi atawa leuwih server.
Kuring teu boga loba ngomong di dieu. Ieu mangrupikeun produk anu mayar, sami-sami tiis sareng mahal. kinerja anu saukur endah. Ieu indikator pangalusna jadi jauh. Slack nyarioskeun ka kuring yén hargana dimimitian dina $ 205 per bulan per node, sapertos didaptarkeun dina Pasar GKE Google. Abdi henteu terang upami anjeun mésér langsung langkung mirah. Abdi henteu tiasa nanggung éta, janten kuring kuciwa pisan yén lisénsi pamekar (dugi ka 1 TB sareng 3 titik) praktis henteu aya gunana sareng Kubernetes kecuali anjeun sugema ku provisioning statik. Abdi ngarepkeun yén lisénsi volume bakal otomatis turun ka pamekar dina ahir jaman percobaan, tapi éta henteu kajantenan. Lisensi pamekar ngan tiasa dianggo langsung sareng Docker, sareng konfigurasi di Kubernetes pisan pajeujeut sareng kawates. Tangtosna, kuring resep open source, tapi upami kuring gaduh artos, kuring pasti bakal milih Portworx. Sajauh ieu, kinerjana ngan saukur henteu dibandingkeun sareng pilihan anu sanés.
Kuring nambahkeun bagian ieu saatos tulisan ieu dipedalkeun, nalika aya nu maca nyarankeun pikeun nyobian Linstor. Kuring geus nyobian sareng resep! Tapi kuring kedah nalungtik deui. Ayeuna, kuring tiasa nyarios yén kinerjana lumayan saé (kuring parantos nambihan hasil patokan di handap). Kanyataanna, kuring kéngingkeun kinerja anu sami sareng patokan disk langsung, tanpa aya biaya tambahan. (Tong naroskeun kunaon angka Portworx langkung saé tibatan patokan disk langsung. Kuring teu terang. Sihir, sigana mah.) Janten, Linstor sigana épéktip pisan dugi ka ayeuna. Nyetélna henteu sesah, tapi henteu gampang sapertos pilihan sanés. Mimitina, kuring kedah masang Linstor (modul kernel sareng alat/jasa) sareng nyetél LVM pikeun panyediaan tipis sareng dukungan snapshot di luar Kubernetes, langsung dina host, teras nyiptakeun sumber daya anu diperyogikeun pikeun nganggo panyimpenan tina Kubernetes. Kuring henteu resep yén éta henteu tiasa dianggo dina CentOS sareng kedah nganggo UbuntuTangtosna sanés masalah ageung, tapi rada ngaganggu sabab dokuméntasina (anu saé pisan) nyebatkeun sababaraha pakét anu henteu sayogi dina repositori Epel anu ditangtukeun. Linstor gaduh snapshot, tapi teu aya cadangan di luar situs, janten kuring kedah nganggo Velero sareng Restic deui pikeun cadangan volume. Kuring langkung milih snapshot tibatan cadangan tingkat file, tapi éta tiasa ditolerir upami solusina berkinerja sareng tiasa dipercaya. Linstor mangrupikeun sumber terbuka, tapi aya dukungan anu mayar. Upami kuring ngartos leres, anjeun tiasa nganggo éta tanpa larangan sanaos anjeun henteu gaduh kontrak dukungan, tapi kuring kedah mariksa éta. Kuring henteu terang sabaraha diuji Linstor pikeun Kubernetes, tapi lapisan panyimpenan éta sorangan aya di luar Kubernetes, sareng sigana parantos aya salami sababaraha waktos, janten sigana parantos diuji dina kaayaan dunya nyata. Naha aya solusi di dieu anu bakal ngajantenkeun kuring ngarobih pikiran kuring sareng ngalih deui ka Kubernetes? Kuring henteu terang. Abdi kedah nalungtik deui sakedik deui sareng diajar ngeunaan réplikasi. Urang tingali wé. Tapi kesan munggaran mah saé. Abdi langkung milih nganggo klaster Kubernetes abdi nyalira tibatan Heroku supados langkung bébas sareng tiasa diajar hal-hal énggal. Kusabab Linstor henteu gampang dipasang sapertos anu sanés, abdi bakal nyerat tulisan ngeunaan éta pas geura-giru.
Tolok ukur
Hanjakal, kuring teu nyimpen loba catetan ngeunaan babandingan sabab kuring teu nyangka bakal nulis ngeunaan eta. Kuring ngan boga hasil tina tolok ukur fio dasar sarta ngan pikeun klaster titik tunggal, jadi kuring teu boga angka pikeun konfigurasi replicated acan. Tapi tina hasil ieu anjeun tiasa nampi ide kasar ngeunaan naon anu bakal diarepkeun tina unggal pilihan, sabab kuring ngabandingkeunana dina server awan anu sami, 4 inti, 16 GB RAM, kalayan tambahan 100 GB disk pikeun volume anu diuji. Kuring ngajalankeun tolok ukur tilu kali pikeun tiap solusi sareng ngitung hasil rata-rata, tambah kuring ngareset setélan pangladén pikeun tiap produk. Ieu kabeh sagemblengna unscientific, ngan pikeun masihan anjeun gagasan umum. Dina tés anu sanés, kuring nyalin 38 GB poto sareng pidéo tina volume pikeun nguji maca sareng nyerat, tapi, sayang, kuring henteu nyimpen nomerna. Pondokna: Portworkx éta leuwih gancang.
Pikeun tolok ukur volume kuring nganggo manifest ieu:
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: 4Kuring mimiti dijieun volume kalawan kelas gudang luyu lajeng ngajalankeun pakasaban kalawan fio balik layar. Kuring nyandak 1 GB pikeun ngira-ngira kinerja sareng henteu ngantosan panjang teuing. Ieu hasilna:
Kuring geus disorot nilai pangalusna pikeun tiap métrik dina héjo sarta awon dina beureum.
kacindekan
Sakumaha anjeun tiasa tingali, dina kalolobaan kasus Portworx ngalaksanakeun langkung saé tibatan anu sanés. Tapi keur kuring mahal. Kuring henteu weruh sabaraha Robin waragad, Tapi maranéhna boga hébat bebas Vérsi, jadi upami anjeun hoyong produk mayar, anjeun bisa coba eta (mudahan aranjeunna ngalereskeun masalah sareng balikkeun na cadangan pas). Tina tilu anu gratis, kuring ngagaduhan masalah pangsaeutikna sareng OpenEBS, tapi prestasina abysmal. Hanjakal kuring henteu ngahemat langkung seueur hasil, tapi kuring ngarepkeun nomer sareng koméntar kuring bakal ngabantosan anjeun.
sumber: www.habr.com
