Kemas kini!. Dalam komen, salah seorang pembaca mencadangkan mencuba (mungkin dia sedang mengusahakannya sendiri) jadi saya telah menambah bahagian tentang penyelesaian ini. Saya juga menulis , kerana prosesnya sangat berbeza daripada yang lain.
Sejujurnya, saya berputus asa dan berputus asa (sekurang-kurangnya buat masa ini). saya akan guna . kenapa? Kerana penyimpanan! Siapa sangka saya akan bermain lebih banyak dengan storan berbanding dengan Kubernetes sendiri. saya guna kerana ia adalah murah dan prestasinya bagus dan dari awal lagi saya telah menggunakan kluster menggunakan . Saya tidak mencuba perkhidmatan Kubernetes terurus daripada Google/Amazon/Microsoft/DigitalOcean, dsb., dsb., kerana saya ingin mempelajari semuanya sendiri. Saya juga berjimat cermat.
Jadi ya, saya menghabiskan banyak masa cuba memutuskan storan yang hendak dipilih semasa saya menilai timbunan Kubernetes yang mungkin. Saya lebih suka penyelesaian sumber terbuka, bukan sahaja kerana harga, tetapi saya telah melihat beberapa pilihan berbayar kerana ingin tahu kerana ia mempunyai versi percuma dengan batasan. Saya telah mencatat beberapa nombor daripada ujian baru-baru ini apabila saya membandingkan pilihan yang berbeza, dan ia mungkin menarik minat mereka yang mempelajari tentang storan Kubernetes. Walaupun saya secara peribadi telah mengucapkan selamat tinggal kepada Kubernetes buat masa ini. Saya juga ingin menyebut , yang boleh menyediakan jumlah Hetzner Cloud secara langsung, tetapi saya belum mencubanya lagi. Saya melihat storan yang ditentukan oleh perisian awan kerana saya memerlukan replikasi dan keupayaan untuk melekapkan volum berterusan dengan cepat pada mana-mana nod, terutamanya dalam kes kegagalan nod dan situasi serupa yang lain. Sesetengah penyelesaian menawarkan syot kilat titik dalam masa dan sandaran luar tapak, yang memudahkan.
Saya menguji 6-7 penyelesaian storan:
Seperti yang telah saya katakan Setelah menguji kebanyakan pilihan daripada senarai, saya pada mulanya menetap di OpenEBS. OpenEBS sangat mudah untuk dipasang dan digunakan, tetapi sejujurnya, selepas menguji dengan data sebenar di bawah beban, saya kecewa dengan prestasinya. Ini adalah sumber terbuka, dan pembangunnya sendiri sentiasa membantu apabila saya memerlukan bantuan. Malangnya, ia mempunyai prestasi yang sangat lemah berbanding dengan pilihan lain, jadi ujian terpaksa dijalankan semula. OpenEBS kini mempunyai 3 enjin storan, tetapi saya menyiarkan hasil penanda aras untuk cStor. Saya belum mempunyai nombor untuk Jiva dan LocalPV.
Secara ringkasnya, Jiva adalah lebih pantas sedikit, dan LocalPV biasanya pantas, tidak lebih teruk daripada penanda aras cakera secara langsung. Masalah dengan LocalPV ialah volum hanya boleh diakses pada nod di mana ia disediakan, dan tiada replikasi sama sekali. Saya mempunyai beberapa masalah memulihkan sandaran melalui pada kelompok baharu kerana nama nod adalah berbeza. Jika kita bercakap tentang sandaran, cStor mempunyai , yang dengannya anda boleh membuat sandaran syot kilat di luar tapak pada satu masa, yang lebih mudah daripada sandaran peringkat fail dengan Velero-Restic. saya tulis , untuk memudahkan pengurusan sandaran dan pemulihan dengan pemalam ini. Secara keseluruhan, saya sangat menyukai OpenEBS, tetapi prestasinya...
Rook juga merupakan sumber terbuka dan berbeza daripada pilihan lain dalam senarai kerana ia adalah orkestra storan yang melaksanakan tugas pengurusan storan yang kompleks dengan bahagian belakang yang berbeza, mis. , dan lain-lain, yang sangat memudahkan kerja. Saya mempunyai masalah dengan EfgeFS apabila saya mencubanya beberapa bulan yang lalu, jadi saya menguji terutamanya dengan Ceph. Ceph bukan sahaja menawarkan storan blok, tetapi juga storan objek yang serasi dengan S3/Swift dan sistem fail teragih. Apa yang saya suka tentang Ceph ialah keupayaan untuk menyebarkan data volum merentasi berbilang cakera supaya volum boleh menggunakan lebih banyak ruang cakera daripada yang boleh dimuatkan pada satu cakera. Ia selesa. Satu lagi ciri hebat ialah apabila anda menambah cakera pada kluster, ia secara automatik mengagihkan semula data ke semua cakera.
Ceph ada snapshot, tetapi setahu saya, ia tidak boleh digunakan terus di Rook/Kubernetes. Benar, saya tidak mendalami perkara ini. Tetapi tiada sandaran luar tapak, jadi anda perlu menggunakan sesuatu dengan Velero/Restic, tetapi hanya terdapat sandaran peringkat fail, bukan syot kilat titik dalam masa. Apa yang saya sangat suka tentang Rook ialah betapa mudahnya bekerja dengan Ceph - ia menyembunyikan hampir semua perkara yang rumit dan menawarkan alat untuk bercakap dengan Ceph secara terus untuk menyelesaikan masalah. Malangnya, semasa ujian tekanan jilid Ceph, saya terus menghadapi masalah , yang menyebabkan Ceph menjadi tidak stabil. Ia masih belum jelas sama ada ini adalah pepijat dalam Ceph sendiri atau masalah dalam cara Rook menguruskan Ceph. Saya bermain-main dengan tetapan memori, dan ia menjadi lebih baik, tetapi masalah itu tidak diselesaikan sepenuhnya. Ceph mempunyai prestasi yang baik, seperti yang anda lihat dalam penanda aras di bawah. Ia juga mempunyai papan pemuka yang baik.
Saya sangat suka Longhorn. Pada pendapat saya, ini adalah penyelesaian yang menjanjikan. Benar, pemaju sendiri (Rancher Labs) mengakui bahawa ia belum sesuai untuk persekitaran kerja, dan ini menunjukkan. Ia adalah sumber terbuka dan mempunyai prestasi yang baik (walaupun mereka belum mengoptimumkannya lagi), tetapi volum mengambil masa yang sangat lama untuk disambungkan ke pod, dan dalam kes yang paling teruk, ia mengambil masa 15-16 minit, terutamanya selepas memulihkan sandaran besar atau menaik taraf beban kerja. Ia mempunyai syot kilat dan sandaran di luar tapak bagi syot kilat ini, tetapi ia hanya digunakan pada jilid, jadi anda masih memerlukan sesuatu seperti Velero untuk membuat sandaran sumber lain. Sandaran dan pemulihan sangat boleh dipercayai, tetapi perlahan-lahan. Serius, hanya sangat perlahan. Penggunaan CPU dan beban sistem sering meningkat apabila bekerja dengan jumlah data sederhana di Longhorn. Terdapat papan pemuka yang mudah untuk menguruskan Longhorn. Saya telah mengatakan bahawa saya suka Longhorn, tetapi ia memerlukan usaha.
StorageOS ialah produk berbayar pertama dalam senarai. Ia mempunyai versi pembangun dengan saiz storan terurus terhad sebanyak 500GB, tetapi saya tidak fikir terdapat had pada bilangan nod. Jabatan jualan memberitahu saya bahawa kos bermula pada $125 sebulan untuk 1 TB, jika saya ingat dengan betul. Terdapat papan pemuka asas dan CLI yang mudah, tetapi sesuatu yang pelik sedang berlaku dengan prestasi: dalam beberapa penanda aras ia agak baik, tetapi dalam ujian tekanan volum saya tidak menyukai kelajuan sama sekali. Secara umum, saya tidak tahu apa yang perlu saya katakan. Jadi saya tidak begitu faham. Tiada sandaran luar tapak di sini dan anda juga perlu menggunakan Velero dengan Restic untuk membuat sandaran volum. Ia pelik, kerana produk itu dibayar. Dan pembangun tidak berminat untuk berkomunikasi di Slack.
Saya belajar tentang Robin di Reddit daripada pengarah teknikal mereka. Saya tidak pernah mendengar tentang dia sebelum ini. Mungkin kerana saya sedang mencari penyelesaian percuma, tetapi Robin dibayar. Mereka mempunyai versi percuma yang cukup murah dengan storan 10TB dan tiga nod. Secara keseluruhan, produk ini agak baik dan mempunyai ciri-ciri yang bagus. Terdapat CLI yang hebat, tetapi perkara yang paling menarik ialah anda boleh merakam dan menyandarkan keseluruhan aplikasi (dalam pemilih sumber ini dipanggil keluaran Helm atau "aplikasi fleksibel"), termasuk volum dan sumber lain, jadi anda boleh melakukannya tanpa Velero. Dan segala-galanya akan menjadi indah jika bukan untuk satu butiran kecil: jika anda memulihkan (atau "import", seperti yang dipanggil dalam Robin) aplikasi pada kluster baru - sebagai contoh, sekiranya pemulihan daripada bencana - pemulihan, sudah tentu, berfungsi, tetapi terus membuat sandaran aplikasi yang dilarang. Ini tidak mungkin berlaku dalam keluaran ini, seperti yang telah disahkan oleh pembangun. Ini, secara ringkas, pelik, terutamanya memandangkan kelebihan lain (contohnya, sandaran dan pemulihan yang sangat pantas). Pembangun berjanji untuk membetulkan segala-galanya menjelang keluaran seterusnya. Prestasi umumnya baik, tetapi saya melihat satu keanehan: jika saya menjalankan penanda aras secara terus pada volum yang dilampirkan pada hos, kelajuan baca adalah lebih pantas daripada menjalankan volum yang sama dari dalam pod. Semua keputusan lain adalah sama, tetapi secara teori tidak sepatutnya ada perbezaan. Walaupun mereka sedang mengusahakannya, saya kecewa dengan masalah pemulihan dan sandaran - saya fikir akhirnya saya telah menemui penyelesaian yang sesuai, malah saya sanggup membayarnya apabila saya memerlukan lebih banyak ruang atau lebih banyak pelayan.
Saya tidak mempunyai banyak perkara untuk diperkatakan di sini. Ini adalah produk berbayar, sama hebat dan mahal. Persembahannya sungguh menakjubkan. Ini adalah penunjuk terbaik setakat ini. Slack memberitahu saya bahawa harga bermula pada $205 sebulan setiap nod, seperti yang disenaraikan dalam GKE Marketplace Google. Tak tahulah kalau beli terus lebih murah. Saya tidak mampu lagi, jadi saya sangat, sangat kecewa kerana lesen pembangun (sehingga 1 TB dan 3 nod) boleh dikatakan tidak berguna dengan Kubernetes melainkan anda berpuas hati dengan peruntukan statik. Saya berharap lesen volum akan diturunkan secara automatik kepada pembangun pada penghujung tempoh percubaan, tetapi itu tidak berlaku. Lesen pembangun hanya boleh digunakan secara terus dengan Docker, dan konfigurasi dalam Kubernetes sangat menyusahkan dan terhad. Sudah tentu, saya lebih suka sumber terbuka, tetapi jika saya mempunyai wang, saya pasti akan memilih Portworx. Setakat ini, prestasinya tidak setanding dengan pilihan lain.
Saya menambah bahagian ini selepas penerbitan siaran, apabila seorang pembaca mencadangkan mencuba Linstor. Saya mencubanya dan saya menyukainya! Tetapi kita masih perlu menggali lebih dalam. Sekarang saya boleh mengatakan bahawa prestasinya tidak buruk (saya menambah hasil penanda aras di bawah). Pada asasnya, saya mendapat prestasi yang sama seperti cakera secara langsung, tanpa sebarang overhed. (Jangan tanya mengapa Portworx mempunyai nombor yang lebih baik daripada penanda aras pemacu secara langsung. Saya tidak tahu. Sihir, saya rasa.) Jadi Linstor nampaknya sangat berkesan setakat ini. Ia tidak begitu sukar untuk dipasang, tetapi ia tidak semudah pilihan lain. Mula-mula saya perlu memasang Linstor (modul kernel dan alatan/perkhidmatan) dan mengkonfigurasi LVM untuk peruntukan nipis dan sokongan syot kilat di luar Kubernetes, terus pada hos, dan kemudian mencipta sumber yang diperlukan untuk menggunakan storan daripada Kubernetes. Saya tidak suka bahawa ia tidak berfungsi pada CentOS dan saya terpaksa menggunakan Ubuntu. Tidak mengerikan, sudah tentu, tetapi sedikit menjengkelkan, kerana dokumentasi (yang sangat baik, dengan cara itu) menyebut beberapa pakej yang tidak dapat ditemui dalam repositori Epel yang ditentukan. Linstor mempunyai syot kilat, tetapi bukan sandaran luar tapak, jadi di sini sekali lagi saya terpaksa menggunakan Velero dengan Restic untuk membuat sandaran volum. Saya lebih suka syot kilat daripada sandaran peringkat fail, tetapi ini boleh diterima jika penyelesaiannya berprestasi dan boleh dipercayai. Linstor adalah sumber terbuka tetapi mempunyai sokongan berbayar. Jika saya faham dengan betul, ia boleh digunakan tanpa sekatan, walaupun anda tidak mempunyai kontrak sokongan, tetapi ini perlu dijelaskan. Saya tidak tahu sejauh mana Linstor diuji untuk Kubernetes, tetapi lapisan storan itu sendiri berada di luar Kubernetes dan, nampaknya, penyelesaiannya tidak muncul semalam, jadi ia mungkin telah diuji dalam keadaan sebenar. Adakah terdapat penyelesaian di sini yang akan membuat saya berubah fikiran dan kembali ke Kubernetes? Saya tidak tahu. Kita masih perlu menggali lebih dalam dan mengkaji replikasi. Jom tengok. Tetapi kesan pertama adalah baik. Saya pasti lebih suka menggunakan kluster Kubernetes saya sendiri dan bukannya Heroku untuk mempunyai lebih kebebasan dan mempelajari perkara baharu. Memandangkan Linstor tidak semudah dipasang seperti yang lain, saya akan menulis siaran mengenainya tidak lama lagi.
Penanda aras
Malangnya, saya tidak menyimpan banyak nota tentang perbandingan itu kerana saya tidak fikir saya akan menulis mengenainya. Saya hanya mempunyai hasil daripada penanda aras fio asas dan hanya untuk kelompok nod tunggal, jadi saya tidak mempunyai nombor untuk konfigurasi yang direplikasi lagi. Tetapi daripada hasil ini, anda boleh mendapatkan gambaran kasar tentang apa yang diharapkan daripada setiap pilihan, kerana saya membandingkannya pada pelayan awan yang sama, 4 teras, 16 GB RAM, dengan cakera 100 GB tambahan untuk volum yang diuji. Saya menjalankan penanda aras tiga kali untuk setiap penyelesaian dan mengira hasil purata, ditambah saya menetapkan semula tetapan pelayan untuk setiap produk. Ini semua tidak saintifik sama sekali, hanya untuk memberi anda gambaran umum. Dalam ujian lain, saya menyalin 38 GB foto dan video daripada volum untuk menguji membaca dan menulis, tetapi, malangnya, saya tidak menyimpan nombor itu. Pendek kata: Portworkx adalah lebih pantas.
Untuk penanda aras volum saya menggunakan manifes ini:
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: 4Saya mula-mula mencipta kelantangan dengan kelas storan yang sesuai dan kemudian menjalankan tugas dengan fio di belakang tabir. Saya mengambil 1 GB untuk menganggarkan prestasi dan tidak menunggu terlalu lama. Berikut adalah keputusannya:
Saya telah menyerlahkan nilai terbaik untuk setiap metrik dalam warna hijau dan yang paling teruk dalam warna merah.
Kesimpulan
Seperti yang anda lihat, dalam kebanyakan kes Portworx berprestasi lebih baik daripada yang lain. Tetapi bagi saya ia mahal. Saya tidak tahu berapa kos Robin, tetapi mereka mempunyai versi percuma yang hebat, jadi jika anda mahukan produk berbayar, anda boleh mencubanya (semoga mereka menyelesaikan masalah dengan pemulihan dan sandaran tidak lama lagi). Daripada tiga yang percuma, saya mempunyai paling sedikit masalah dengan OpenEBS, tetapi prestasinya adalah buruk. Sayang sekali saya tidak menyimpan lebih banyak keputusan, tetapi saya harap nombor dan komen saya akan membantu anda.
Sumber: www.habr.com