Nganyari!. Ing komentar, salah sawijining pembaca nyaranake nyoba (Mungkin dheweke nggarap dhewe) mula aku wis nambah bagean babagan solusi iki. Aku uga nulis , amarga prosese beda banget karo liyane.
Jujur, aku pasrah lan nyerah (paling ora kanggo saiki). Aku bakal nggunakake . Kenging punapa? Amarga saka panyimpenan! Sapa sing bakal ngira yen aku bakal luwih akeh nyimpen tinimbang karo Kubernetes dhewe. Aku nggunakake amarga iku inexpensive lan kinerja apik lan saka awal aku wis deploying kluster nggunakake . Aku ora nyoba ngatur layanan Kubernetes saka Google/Amazon/Microsoft/DigitalOcean, etc., etc, amarga aku pengin sinau kabeh dhewe. Aku uga hemat.
Dadi ya, aku ngenteni akeh wektu kanggo mutusake panyimpenan sing kudu dipilih nalika ngevaluasi tumpukan Kubernetes. Aku luwih seneng solusi open source, ora mung amarga saka rega, nanging aku wis katon menyang sawetara opsi mbayar metu saka penasaran amarga padha duwe versi free karo watesan. Aku wis jotted mudhun sawetara nomer saka tes anyar nalika aku dibandhingake opsi beda, lan padha bisa dadi kapentingan kanggo sing sinau babagan panyimpenan Kubernetes. Senajan aku pribadi wis pamitan kanggo Kubernetes kanggo saiki. Aku uga pengin sebutno , sing bisa langsung nyedhiyakake volume Hetzner Cloud, nanging aku durung nyoba. Aku katon menyang panyimpenan maya software-ditetepake amarga aku mbutuhake réplikasi lan kemampuan kanggo cepet Gunung volume terus-terusan ing sembarang simpul, utamané ing cilik saka gagal simpul lan kahanan liyane padha. Sawetara solusi nawakake snapshot point-in-time lan serep saka situs, sing trep.
Aku nyoba 6-7 solusi panyimpenan:
Kaya sing wis dakkandhakake Sawise nyoba paling akeh pilihan saka dhaptar, aku pisanan manggon ing OpenEBS. OpenEBS gampang banget kanggo nginstal lan nggunakake, nanging jujur, sawise nyoba karo data nyata ing beban, aku kuciwa karo kinerja. Iki minangka sumber terbuka, lan pangembang dhewe tansah mbiyantu nalika aku butuh pitulung. Sayange, kinerja sing kurang apik dibandhingake karo pilihan liyane, mula tes kasebut kudu ditindakake maneh. OpenEBS saiki duwe 3 mesin panyimpenan, nanging aku ngirim asil benchmark kanggo cStor. Aku durung duwe nomer kanggo Jiva lan LocalPV.
Cekakipun, Jiva punika sethitik luwih cepet, lan LocalPV umume cepet, ora Samsaya Awon saka pathokan disk langsung. Masalah karo LocalPV yaiku volume mung bisa diakses ing simpul sing disiapake, lan ora ana replikasi. Aku duwe sawetara masalah mulihake serep liwat ing kluster anyar amarga jeneng simpul beda. Yen kita pirembagan bab serep, cStor wis , kanthi sampeyan bisa nggawe serep jepretan ing njaba situs ing sawijining wektu, sing luwih trep tinimbang serep tingkat file kanthi Velero-Restic. Aku nulis , supaya luwih gampang ngatur serep lan mulihake nganggo plugin iki. Sakabèhé, aku seneng OpenEBS, nanging kinerja ...
Rook uga mbukak sumber lan beda-beda saka liyane saka opsi ing dhaftar ing iku orkestrasi panyimpenan sing nindakake tugas Manajemen panyimpenan Komplek karo backends beda, f.eks. , lan liyane, kang nemen simplifies karya. Aku duwe masalah karo EfgeFS nalika nyoba sawetara wulan kepungkur, mula aku nyoba utamane karo Ceph. Ceph ora mung nawakake panyimpenan pemblokiran, nanging uga panyimpenan obyek kompatibel karo S3 / Swift lan sistem file mbagekke. Sing dakkarepake babagan Ceph yaiku kemampuan nyebarake data volume ing pirang-pirang disk supaya volume bisa nggunakake ruang disk luwih akeh tinimbang sing cocog ing disk siji. Wis nyaman. Fitur keren liyane yaiku yen sampeyan nambah disk menyang kluster, data kasebut kanthi otomatis nyebarake ing kabeh disk.
Ceph wis jepretan, nanging minangka adoh aku ngerti, padha ora bisa digunakake langsung ing Rook / Kubernetes. Bener, aku ora mlebu jero babagan iki. Nanging ora ana serep ing situs, dadi sampeyan kudu nggunakake Velero / Restic, nanging mung ana serep tingkat file, dudu snapshot ing wektu. Apa aku seneng banget babagan Rook yaiku carane gampang nggarap Ceph - ndhelikake meh kabeh barang sing rumit lan nawakake alat kanggo ngobrol karo Ceph kanthi langsung kanggo ngatasi masalah. Sayange, sajrone tes stres volume Ceph, aku terus ngalami masalah , sing nyebabake Ceph dadi ora stabil. Iku durung cetha apa iki bug ing Ceph dhewe utawa masalah ing cara Rook ngatur Ceph. Aku tinkered karo setelan memori, lan dadi luwih apik, nanging masalah iki ora rampung ditanggulangi. Ceph nduweni kinerja sing apik, kaya sing sampeyan deleng ing benchmark ing ngisor iki. Uga nduweni dashboard sing apik.
Aku pancene seneng Longhorn. Ing mratelakake panemume, iki solusi janjeni. Bener, pangembang dhewe (Rancher Labs) ngakoni yen durung cocok kanggo lingkungan kerja, lan iki nuduhake. Iku mbukak sumber lan nduweni kinerja prayoga (sanajan durung optimized iku durung), nanging volume njupuk wektu dawa banget kanggo nyambung menyang pod, lan ing kasus paling awon njupuk 15-16 menit, utamané sawise mulihake serep gedhe utawa nganyarke beban kerja. Nduwe gambar asli lan serep saka situs kasebut, nanging mung ditrapake kanggo volume, dadi sampeyan isih butuh kaya Velero kanggo nggawe cadangan sumber daya liyane. Gawe serep lan mulihake banget dipercaya, nanging ora sopan. Serius, mung luar biasa alon. Panggunaan CPU lan beban sistem asring mundhak nalika nggarap data kanthi jumlah medium ing Longhorn. Ana dashboard trep kanggo ngatur Longhorn. Aku wis ngandika sing aku Longhorn, nanging perlu sawetara karya.
StorageOS minangka produk mbayar pisanan ing dhaptar. Wis versi pangembang karo ukuran panyimpenan ngatur winates 500GB, nanging aku ora mikir ana watesan ing nomer kelenjar. Departemen sales marang kula sing biaya wiwit ing $125 saben sasi kanggo 1 TB, yen aku elinga bener. Ana dashboard dhasar lan CLI sing trep, nanging ana sing aneh karo kinerja: ing sawetara benchmark cukup prayoga, nanging ing tes stres volume aku ora seneng karo kacepetan. Umumé, aku ora ngerti apa sing kudu dakkandhakake. Dadi aku ora ngerti banget. Ora ana serep situs ing kene lan sampeyan uga kudu nggunakake Velero karo Restic kanggo nggawe serep volume. Iku aneh, amarga produk wis mbayar. Lan pangembang ora kepengin banget komunikasi ing Slack.
Aku sinau babagan Robin ing Reddit saka direktur teknis. Aku durung tau krungu bab dheweke sadurunge. Mungkin amarga aku nggoleki solusi gratis, nanging Robin dibayar. Dheweke duwe versi gratis sing apik banget kanthi panyimpenan 10TB lan telung simpul. Sakabèhé, prodhuk iki cukup prayoga lan nduweni fitur sing apik. Ana CLI sing apik, nanging sing paling apik yaiku sampeyan bisa nggawe serep lan nggawe serep kabeh aplikasi (ing pamilih sumber iki diarani rilis Helm utawa "aplikasi fleksibel"), kalebu volume lan sumber daya liyane, supaya sampeyan bisa nindakake tanpa Velero. Lan kabeh bakal apik yen ora kanggo siji rinci cilik: yen sampeyan mulihake (utawa "impor", kaya sing diarani Robin) aplikasi ing kluster anyar - contone, ing acara Recovery saka bilai - pemugaran, mesthi, dianggo, nanging terus gawe serep aplikasi iku pareng. Iki mung ora bisa ditindakake ing rilis iki, amarga pangembang wis dikonfirmasi. Iki, kanggo sijine iku mildly, aneh, utamané considering kaluwihan liyane (contone, luar biasa cepet serep lan mulihake). Pangembang janji bakal ndandani kabeh kanthi rilis sabanjure. Kinerja umume apik, nanging aku weruh keanehan: yen aku mbukak pathokan langsung ing volume sing dipasang ing host, kacepetan maca luwih cepet tinimbang mbukak volume sing padha saka polong. Kabeh asil liyane padha, nanging ing teori mesthine ora ana bedane. Senajan lagi digunakake ing, Aku iki upset bab masalah karo mulihake lan serep - Aku wis pungkasanipun nemu solusi cocok, lan aku malah gelem mbayar nalika aku needed liyane papan utawa server liyane.
Aku ora kudu ngomong akeh ing kene. Iki minangka produk mbayar, padha kelangan lan larang. Kinerja mung apik tenan. Iki minangka indikator paling apik nganti saiki. Slack ngandhani yen rega diwiwiti $ 205 saben wulan saben simpul, kaya sing kadhaptar ing Pasar GKE Google. Aku ora ngerti yen bakal luwih murah yen sampeyan tuku langsung. Aku ora bisa mbayar, mula aku kuciwa banget amarga lisensi pangembang (nganti 1 TB lan 3 kelenjar) ora ana gunane karo Kubernetes kajaba sampeyan seneng karo penyediaan statis. Aku ngarep-arep yen lisensi volume bakal mudhun kanthi otomatis menyang pangembang ing pungkasan periode nyoba, nanging ora kedadeyan. Lisensi pangembang mung bisa digunakake langsung karo Docker, lan konfigurasi ing Kubernetes banget rumit lan winates. Mesthi, aku luwih seneng mbukak sumber, nanging yen aku duwe dhuwit, aku mesthi milih Portworx. Nganti saiki, kinerja mung ora dibandhingake karo pilihan liyane.
Aku nambahake bagean iki sawise postingan iki diterbitake, nalika ana sing maca menehi saran supaya nyoba Linstor. Aku wis nyoba lan seneng! Nanging aku kudu nggoleki luwih akeh. Saiki, aku bisa ujar manawa kinerjane cukup apik (aku wis nambahake asil benchmark ing ngisor iki). Nyatane, aku entuk kinerja sing padha karo benchmark disk langsung, tanpa overhead. (Aja takon kenapa angka Portworx luwih apik tinimbang benchmark disk langsung. Aku ora ngerti. Ajaib, aku kira.) Dadi, Linstor katon efektif banget nganti saiki. Nyetel ora angel banget, nanging ora gampang kaya pilihan liyane. Kapisan, aku kudu nginstal Linstor (modul kernel lan alat/layanan) lan nyetel LVM kanggo thin provisioning lan dhukungan snapshot ing njaba Kubernetes, langsung ing host, banjur nggawe sumber daya sing dibutuhake kanggo nggunakake panyimpenan saka Kubernetes. Aku ora seneng yen ora bisa digunakake ing CentOS lan kudu nggunakake UbuntuIki dudu masalah gedhe, mesthi, nanging rada ngganggu amarga dokumentasine (sing apik banget, omong-omong) nyebutake sawetara paket sing ora kasedhiya ing repositori Epel sing ditemtokake. Linstor duwe snapshot, nanging ora ana serep ing njaba situs, mula aku kudu nggunakake Velero karo Restic maneh kanggo serep volume. Aku luwih seneng snapshot tinimbang serep tingkat file, nanging kuwi bisa ditoleransi yen solusi kasebut kinerjane apik lan dipercaya. Linstor iku sumber terbuka, nanging ana dhukungan sing mbayar. Yen aku ngerti kanthi bener, sampeyan bisa nggunakake tanpa watesan sanajan sampeyan ora duwe kontrak dhukungan, nanging aku kudu mriksa. Aku ora ngerti sepira tes Linstor kanggo Kubernetes, nanging lapisan panyimpenan dhewe ana ing njaba Kubernetes, lan katon kaya wis ana sajrone sawetara wektu, mula mbokmenawa wis diuji ing kahanan nyata. Apa ana solusi ing kene sing bakal nggawe aku ngganti pikiranku lan bali menyang Kubernetes? Aku ora ngerti. Aku kudu nggoleki luwih akeh lan sinau babagan replikasi. Kita bakal weruh. Nanging kesan pisanan apik. Aku mesthi luwih seneng nggunakake kluster Kubernetes dhewe tinimbang Heroku kanggo luwih akeh kebebasan lan sinau babagan anyar. Amarga Linstor ora gampang diinstal kaya liyane, aku bakal nulis postingan babagan iki rauh.
pathokan
Sayange, aku ora nyimpen akeh cathetan babagan perbandingan amarga aku ora mikir bakal nulis babagan iki. Aku mung duwe asil saka pathokan fio dhasar lan mung kanggo kluster simpul siji, supaya aku ora duwe nomer kanggo konfigurasi replicated durung. Nanging saka asil kasebut, sampeyan bisa ngerteni apa sing bakal dikarepake saka saben pilihan, amarga aku mbandhingake ing server maya sing padha, 4 intine, 16 GB RAM, kanthi tambahan 100 GB disk kanggo volume sing diuji. Aku mlayu benchmarks kaping telu kanggo saben solusi lan ngetung asil rata-rata, plus aku ngreset setelan server kanggo saben produk. Iki kabeh pancen ora ilmiah, mung kanggo menehi ide umum. Ing tes liyane, aku nyalin 38 GB foto lan video saka volume kanggo nyoba maca lan nulis, nanging, sayang, aku ora nyimpen nomer kasebut. Singkat: Portworkx luwih cepet.
Kanggo benchmark volume aku nggunakake manifest iki:
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: 4Aku pisanan digawe volume karo kelas panyimpenan cocok lan banjur mbukak proyek karo fio konco sing pemandangan. Aku njupuk 1 GB kanggo ngira kinerja lan ora ngenteni suwene. Mangkene asile:
Aku wis nyorot nilai paling apik kanggo saben metrik ing ijo lan sing paling awon ing abang.
kesimpulan
Kaya sing sampeyan ngerteni, umume Portworx nindakake luwih apik tinimbang liyane. Nanging kanggo kula iku larang. Aku ora ngerti carane akeh biaya Robin, nanging padha duwe gedhe free versi, supaya yen sampeyan pengin produk mbayar, sampeyan bisa nyoba (mugia padha ndandani masalah karo mulihake lan serep rauh). Saka telung free, Aku duwe masalah paling karo OpenEBS, nanging kinerja abysmal. Sayange aku ora nyimpen asil liyane, nanging aku ngarep-arep nomer lan komentar bakal mbantu.
Source: www.habr.com
