Perbarui! . Dalam komentar, salah satu pembaca menyarankan untuk mencoba Linstor (mungkin dia mengerjakannya sendiri), jadi saya menambahkan bagian tentang solusi ini. Saya juga menulis posting tentang cara menginstalnya , karena prosesnya sangat berbeda dari yang lain.
Sejujurnya, saya menyerah dan meninggalkan Kubernetes (setidaknya untuk saat ini). Saya akan menggunakan Heroku . Mengapa Karena penyimpanan! Siapa yang menyangka bahwa saya akan mengacaukan penyimpanan lebih daripada dengan Kubernetes itu sendiri. Saya menggunakan Hetzner Cloud karena murah dan kinerjanya bagus, dan sejak awal saya menggunakan cluster menggunakan Rancher . Saya belum mencoba layanan yang dikelola Kubernetes dari Google / Amazon / Microsoft / DigitalOcean, dll., Karena saya ingin mempelajari semuanya sendiri. Dan saya ekonomis.
Jadi - ya, saya menghabiskan banyak waktu mencoba memutuskan penyimpanan mana yang akan dipilih ketika saya mempertimbangkan kemungkinan tumpukan di Kubernetes. Saya lebih suka solusi open source, dan bukan hanya karena harganya, tetapi saya mempelajari beberapa opsi berbayar karena penasaran, karena mereka memiliki versi gratis dengan batasan. Saya menuliskan beberapa angka dari tes terbaru ketika saya membandingkan pilihan yang berbeda, dan mereka mungkin menarik bagi mereka yang mempelajari penyimpanan di Kubernetes. Meskipun saya pribadi telah mengucapkan selamat tinggal pada Kubernetes sejauh ini. Saya juga ingin menyebutkan driver CSI , di mana Anda dapat langsung menyiapkan volume Hetzner Cloud, tetapi saya belum mencobanya. Saya mempelajari penyimpanan berbasis perangkat lunak berbasis cloud karena saya membutuhkan replikasi dan kemampuan untuk dengan cepat me-mount volume yang persisten pada sembarang simpul, terutama jika terjadi kegagalan simpul dan situasi serupa lainnya. Beberapa solusi menawarkan snapshot pada suatu waktu dan dari cadangan situs, yang nyaman.
Saya menguji 6-7 solusi penyimpanan:
Seperti yang saya katakan di posting sebelumnya , setelah menguji sebagian besar opsi pada daftar, saya awalnya memilih OpenEBS. OpenEBS sangat mudah dipasang dan digunakan, tetapi jujur saja, setelah pengujian dengan data nyata di bawah beban, kinerjanya mengecewakan saya. Ini adalah sumber terbuka, dan para pengembang di saluran Slack mereka selalu banyak membantu ketika saya membutuhkan bantuan. Sayangnya, ini memiliki kinerja yang sangat rendah dibandingkan dengan opsi lain, jadi saya harus menjalankan tes lagi. OpenEBS sekarang memiliki 3 mesin penyimpanan, tetapi saya memposting hasil benchmark untuk cStor. Sejauh ini saya tidak memiliki nomor untuk Jiva dan LocalPV.
Singkatnya, Jiva sedikit lebih cepat, dan LocalPV umumnya lebih cepat, tidak lebih buruk daripada tolok ukur drive secara langsung. Masalah dengan LocalPV adalah bahwa akses ke volume hanya dapat diperoleh pada node di mana ia disiapkan, dan sama sekali tidak ada replikasi. Saya punya beberapa masalah dalam memulihkan cadangan melalui Velero pada cluster baru, karena nama node berbeda. Jika kita berbicara tentang cadangan, cStor memiliki plugin untuk Velero , yang dengannya Anda dapat melakukan backup snapshot situs sekaligus, yang lebih nyaman daripada cadangan di tingkat file dengan Velero-Restic. Saya menulis beberapa skrip untuk membuatnya lebih mudah untuk mengelola cadangan dan restorasi dengan plugin ini. Secara umum, saya sangat suka OpenEBS, tetapi kinerjanya ...
Rook juga memiliki kode sumber terbuka, dan berbeda dari opsi lain dalam daftar karena Rook adalah orkestrator penyimpanan yang melakukan tugas kompleks mengelola penyimpanan dengan backend yang berbeda, seperti Ceph , EdgeFS dan lainnya, yang sangat menyederhanakan pekerjaan. Saya mempunyai masalah dengan EfgeFS ketika saya mencobanya beberapa bulan yang lalu, jadi saya mengujinya terutama dengan Ceph. Ceph tidak hanya menawarkan penyimpanan blok, tetapi juga penyimpanan objek yang kompatibel dengan S3 / Swift dan sistem file terdistribusi. Apa yang saya suka tentang Ceph adalah kemampuan untuk mendistribusikan data volume di beberapa disk sehingga volume dapat menggunakan lebih banyak ruang disk daripada yang bisa muat pada disk tunggal. Ini nyaman. Fitur keren lainnya adalah ketika Anda menambahkan disk ke sebuah cluster, itu secara otomatis mendistribusikan kembali data di semua disk.
Ada snapshot di Ceph, tetapi sejauh yang saya tahu, mereka tidak dapat digunakan secara langsung di Rook / Kubernetes. Benar, saya tidak membahas ini. Tapi di luar situs tidak ada cadangan, jadi Anda harus menggunakan sesuatu dengan Velero / Restic, tetapi hanya ada cadangan di tingkat file, bukan snapshot pada saat itu. Tetapi di Rook, saya sangat menyukai pekerjaan sederhana dengan Ceph - ini menyembunyikan hampir semua hal yang kompleks dan menawarkan alat untuk berkomunikasi dengan Ceph secara langsung untuk pemecahan masalah. Sayangnya, dalam stress test volume Ceph, saya mengalami masalah ini sepanjang waktu, yang menyebabkan Ceph menjadi tidak stabil. Belum jelas apakah ini bug di Ceph sendiri atau masalah dalam cara Rook mengontrol Ceph. Saya menyihir dengan pengaturan memori, dan itu menjadi lebih baik, tetapi masalahnya tidak terpecahkan sampai akhir. Ceph memiliki kinerja yang baik, seperti yang Anda lihat pada tolok ukur di bawah ini. Ia juga memiliki dashboard yang bagus.
Saya sangat suka Longhorn. Menurut saya, ini adalah solusi yang menjanjikan. Benar, pengembang sendiri (Lab Peternakan) mengakui bahwa itu tidak cocok untuk lingkungan kerja, dan ini bisa dilihat. Ini memiliki kode sumber terbuka dan kinerja yang baik (meskipun belum dioptimalkan), tetapi volume membutuhkan waktu yang sangat lama untuk terhubung ke perapian, dan dalam kasus terburuk dibutuhkan 15-16 menit, terutama setelah memulihkan cadangan besar atau meningkatkan beban kerja. Dia memiliki snapshot dan cadangan situs snapshot ini, tetapi hanya berlaku untuk volume, jadi Anda masih membutuhkan sesuatu seperti Velero untuk membuat cadangan sumber daya lainnya. Pencadangan dan pemulihan sangat andal, namun lambat. Serius, sangat lambat. Pemanfaatan CPU dan pemuatan sistem sering melonjak ketika bekerja dengan data rata-rata di Longhorn. Ada dashboard yang nyaman untuk mengendalikan Longhorn. Saya sudah mengatakan bahwa saya suka Longhorn, tetapi perlu dikerjakan.
StorageOS adalah produk berbayar pertama dalam daftar. Ini memiliki versi untuk pengembang dengan penyimpanan terkelola terbatas 500 GB, tetapi jumlah node, menurut pendapat saya, tidak terbatas. Departemen penjualan memberi tahu saya bahwa biayanya mulai $ 125 per bulan untuk 1 TB, jika saya ingat dengan benar. Ada dasbor dasar dan CLI yang nyaman, tetapi sesuatu yang aneh terjadi dengan kinerja: dalam beberapa tolok ukur itu cukup baik, tapi saya tidak suka kecepatan sama sekali dalam tes stres volume. Secara umum, saya tidak tahu harus berkata apa. Karena itu, saya tidak terlalu mengerti. Tidak ada cadangan di luar situs, dan Anda juga harus menggunakan Velero dengan Restic untuk membuat cadangan volume. Ini aneh, karena produknya dibayar. Dan para pengembang tidak bersemangat untuk berkomunikasi di Slack.
Saya belajar tentang Robin on Reddit dari direktur teknis mereka. Saya belum pernah mendengar tentang dia sebelumnya. Mungkin karena saya mencari solusi gratis, dan Robin membayar. Mereka memiliki versi gratis yang cukup murah hati dengan penyimpanan 10 TB dan tiga node. Secara umum, produk ini cukup baik dan dengan fitur yang bagus. Ada CLI yang hebat di sana, tetapi yang paling keren adalah Anda dapat memotret dan mencadangkan seluruh aplikasi (dalam pemilih sumber daya ini disebut rilis Helm atau "aplikasi fleksibel"), termasuk volume dan sumber daya lainnya, sehingga Anda dapat melakukannya tanpa Velero. Dan semuanya akan luar biasa jika itu bukan untuk satu detail kecil: jika Anda mengembalikan (atau "mengimpor", seperti Robin menyebutnya) aplikasi pada kluster baru - misalnya, dalam hal pemulihan setelah kecelakaan - pemulihan, tentu saja, bekerja, tetapi terus membuat cadangan aplikasi tidak diizinkan Dalam rilis ini, ini sama sekali tidak mungkin, dan para pengembang telah mengkonfirmasi. Ini, secara sederhana, aneh, terutama ketika Anda mempertimbangkan keuntungan lainnya (misalnya, backup dan pemulihan yang sangat cepat). Pengembang berjanji untuk memperbaiki semuanya untuk rilis berikutnya. Performanya secara umum bagus, tetapi saya perhatikan hal yang aneh: jika Anda menjalankan benchmark secara langsung pada volume yang terhubung ke host, kecepatan baca jauh lebih tinggi daripada volume yang sama, tetapi dari dalam. Semua hasil lainnya identik, tetapi secara teori seharusnya tidak ada perbedaan. Walaupun mereka sedang mengerjakan ini, saya kesal karena masalah dengan pemulihan dan cadangan - bagi saya akhirnya saya menemukan solusi yang cocok, dan saya bahkan siap membayar untuk itu ketika saya membutuhkan lebih banyak ruang atau lebih banyak server.
Saya benar-benar tidak punya apa-apa untuk dikatakan di sini. Ini adalah produk berbayar, sama keren dan mahal. Kinerja adalah keajaiban. Sejauh ini ini adalah indikator terbaik. Slack memberi tahu saya bahwa harganya mulai dari $ 205 per bulan per node, seperti yang ditunjukkan di Google GKE Marketplace. Saya tidak tahu apakah akan lebih murah jika Anda membeli langsung. Bagaimanapun, saya tidak mampu membelinya, jadi saya sangat, sangat kecewa bahwa lisensi pengembang (hingga 1 TB dan 3 node) praktis tidak berguna dengan Kubernetes, kecuali jika Anda puas dengan persiapan statis. Saya berharap lisensi volume akan secara otomatis turun ke level pengembang pada akhir periode uji coba, tetapi tidak. Lisensi pengembang hanya dapat digunakan secara langsung dengan Docker, dan konfigurasi di Kubernetes sangat rumit dan terbatas. Tentu saja, saya lebih suka open source, tetapi jika saya punya uang, saya pasti akan memilih Portworx. Sejauh ini, kinerjanya tidak bisa dibandingkan dengan opsi lain.
Saya menambahkan bagian ini setelah posting diterbitkan, ketika seorang pembaca menyarankan mencoba Linstor. Saya mencobanya dan saya menyukainya! Tetapi Anda masih harus menggali. Sekarang saya dapat mengatakan bahwa kinerjanya tidak buruk (saya menambahkan hasil benchmark di bawah). Bahkan, saya mendapatkan kinerja yang sama dengan drive secara langsung, sama sekali tidak ada overhead. (Jangan tanya mengapa Portworx memiliki angka yang lebih baik daripada tolok ukur drive secara langsung. Saya tidak tahu. Sihir, mungkin.) Jadi Linstor tampaknya masih sangat efektif. Memasangnya tidak sesulit itu, tetapi tidak semudah opsi lainnya. Pertama saya harus menginstal Linstor (modul kernel dan alat / layanan) dan mengkonfigurasi LVM untuk provisi tipis dan mendukung snapshot di luar Kubernetes, langsung di host, dan kemudian membuat sumber daya yang diperlukan untuk menggunakan penyimpanan dari Kubernetes. Saya tidak suka itu tidak bekerja pada CentOS dan harus menggunakan Ubuntu. Tentu saja tidak menakutkan, tetapi sedikit menjengkelkan, karena dokumentasi (yang, kebetulan, sangat bagus) menyebutkan beberapa paket yang tidak dapat ditemukan dalam repositori Epel yang ditentukan. Linstor memiliki snapshot, tetapi tidak mematikan backup situs, jadi di sini sekali lagi saya harus menggunakan Velero dengan Restic untuk membuat cadangan volume. Saya lebih suka snapshot daripada cadangan tingkat file, tetapi ini bisa ditoleransi jika solusinya produktif dan dapat diandalkan. Linstor memiliki sumber terbuka, tetapi ada dukungan berbayar. Jika saya mengerti dengan benar, itu dapat digunakan tanpa batasan, bahkan jika Anda tidak memiliki perjanjian dukungan, tetapi ini perlu diklarifikasi. Saya tidak tahu bagaimana Linstor diuji untuk Kubernetes, tetapi tingkat penyimpanannya sendiri berada di luar Kubernetes dan, tampaknya, solusinya tidak muncul kemarin, jadi mungkin sudah diuji dalam kondisi nyata. Apakah ada solusi di sini yang akan membuat saya berubah pikiran dan kembali ke Kubernetes? Saya tidak tahu, saya tidak tahu. Masih perlu untuk menggali lebih dalam, untuk mempelajari replikasi. Ayo lihat. Tapi kesan pertama itu bagus. Saya pasti akan lebih suka menggunakan kelompok Kubernet saya sendiri daripada Heroku untuk mendapatkan lebih banyak kebebasan dan belajar hal-hal baru. Karena Linstor tidak diinstal semudah yang lain, saya akan menulis posting tentang hal itu segera.
Tingkatan yang dicapai
Sayangnya, saya telah menyimpan beberapa catatan perbandingan, karena saya tidak berpikir bahwa saya akan menulis tentang itu. Saya hanya memiliki hasil tolok ukur dasar fio, dan hanya untuk cluster node tunggal, jadi untuk konfigurasi replikasi saya belum memiliki angka. Tetapi dari hasil ini, Anda bisa mendapatkan ide perkiraan tentang apa yang diharapkan dari setiap opsi, karena saya membandingkannya di server cloud yang sama, 4 core, 16 GB RAM, dengan tambahan 100 GB disk untuk volume yang sedang diuji. Saya menjalankan tolok ukur tiga kali untuk setiap solusi dan menghitung hasil rata-rata, plus mengatur ulang pengaturan server untuk setiap produk. Semua ini sama sekali tidak ilmiah, hanya untuk membuat Anda mengerti secara umum. Dalam tes lain, saya menyalin 38 GB foto dan video dari volume dan untuk menguji membaca dan menulis, tetapi, sayangnya, saya tidak menyimpan angka. Singkatnya: Portworkx jauh lebih cepat.
Untuk tolok ukur volume, 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: 4
Pertama saya membuat volume dengan kelas penyimpanan yang sesuai, dan kemudian saya memulai tugas dengan fio di belakang layar. Saya mengambil 1 GB untuk memperkirakan kinerja dan tidak menunggu terlalu lama. Inilah hasilnya:
Saya menyoroti nilai terbaik untuk setiap indikator berwarna hijau, dan yang terburuk dalam warna merah.
Kesimpulan
Seperti yang Anda lihat, dalam kebanyakan kasus Portworx berkinerja lebih baik daripada yang lain. Tapi bagiku, dia sayang. Saya tidak tahu berapa banyak biaya Robin, tetapi ada versi gratis yang hebat, jadi jika Anda memerlukan produk berbayar, Anda dapat mencobanya (saya berharap mereka akan segera memperbaiki masalah dengan pemulihan dan pencadangan). Dari ketiga yang gratis, saya memiliki paling tidak semua masalah dengan OpenEBS, tetapi kinerjanya tidak terlalu buruk. Sayang sekali, saya tidak menyimpan lebih banyak hasil, tetapi saya harap angka yang diberikan dan komentar saya membantu Anda.