Memperbarui!. Di komentar, salah satu pembaca menyarankan untuk mencoba (mungkin dia sedang mengerjakannya sendiri) jadi saya telah menambahkan bagian tentang solusi ini. Saya juga menulis , karena prosesnya sangat berbeda dari yang lain.
Sejujurnya, saya menyerah dan menyerah (setidaknya untuk sekarang). saya akan gunakan . Mengapa? Karena penyimpanan! Siapa sangka saya akan lebih banyak mengutak-atik penyimpanan dibandingkan dengan Kubernetes itu sendiri. saya menggunakan karena murah dan performanya bagus dan dari awal saya sudah men-deploy cluster menggunakan . Saya tidak mencoba layanan Kubernetes terkelola dari Google/Amazon/Microsoft/DigitalOcean, dll., dll., karena saya ingin mempelajari semuanya sendiri. Saya juga hemat.
Jadi ya, saya menghabiskan banyak waktu untuk mencoba memutuskan penyimpanan mana yang akan dipilih ketika saya mengevaluasi kemungkinan tumpukan Kubernetes. Saya lebih memilih solusi open source, bukan hanya karena harganya, tapi saya telah melihat beberapa opsi berbayar karena penasaran karena mereka memiliki versi gratis dengan keterbatasan. Saya telah mencatat beberapa angka dari pengujian terbaru ketika saya membandingkan berbagai opsi, dan angka tersebut mungkin menarik bagi mereka yang mempelajari penyimpanan Kubernetes. Meskipun saya pribadi sudah mengucapkan selamat tinggal pada Kubernetes untuk saat ini. Saya juga ingin menyebutkan , yang bisa langsung menyediakan volume Hetzner Cloud, tapi saya belum mencobanya. Saya mencari penyimpanan yang ditentukan perangkat lunak cloud karena saya memerlukan replikasi dan kemampuan untuk memasang volume persisten dengan cepat di node mana pun, terutama jika terjadi kegagalan node dan situasi serupa lainnya. Beberapa solusi menawarkan snapshot point-in-time dan pencadangan di luar lokasi, yang memudahkan Anda.
Saya menguji 6-7 solusi penyimpanan:
Seperti yang sudah saya katakan Setelah menguji sebagian besar opsi dari daftar, saya awalnya memilih OpenEBS. OpenEBS sangat mudah untuk diinstal dan digunakan, tetapi sejujurnya, setelah pengujian dengan data nyata yang sedang dimuat, saya kecewa dengan kinerjanya. Ini adalah open source, dan pengembangnya melakukannya sendiri selalu sangat membantu ketika saya membutuhkan bantuan. Sayangnya, kinerjanya sangat buruk dibandingkan opsi lain, sehingga pengujian harus dijalankan ulang. OpenEBS saat ini memiliki 3 mesin penyimpanan, tapi saya memposting hasil benchmark untuk cStor. Saya belum memiliki nomor untuk Jiva dan LocalPV.
Singkatnya, Jiva sedikit lebih cepat, dan LocalPV umumnya cepat, tidak lebih buruk dari benchmark disk secara langsung. Masalah dengan LocalPV adalah volumenya hanya dapat diakses pada node yang disiapkan, dan tidak ada replikasi sama sekali. Saya mengalami beberapa masalah saat memulihkan cadangan melalui pada cluster baru karena nama node berbeda. Jika kita berbicara tentang cadangan, cStor punya , yang dengannya Anda dapat membuat cadangan snapshot di luar lokasi pada suatu waktu, yang lebih nyaman daripada cadangan tingkat file dengan Velero-Restic. saya menulis , untuk memudahkan pengelolaan backup dan pemulihan dengan plugin ini. Secara keseluruhan, saya sangat menyukai OpenEBS, tetapi kinerjanya...
Benteng juga bersifat open source dan berbeda dari opsi lainnya dalam daftar karena merupakan orkestrator penyimpanan yang melakukan tugas manajemen penyimpanan kompleks dengan backend berbeda, misalnya. , dan lain-lain, yang sangat menyederhanakan pekerjaan. Saya mengalami 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. Yang saya sukai dari Ceph adalah kemampuannya untuk menyebarkan data volume ke beberapa disk sehingga volume tersebut dapat menggunakan lebih banyak ruang disk daripada yang dapat ditampung dalam satu disk. Itu nyaman. Fitur keren lainnya adalah ketika Anda menambahkan disk ke sebuah cluster, secara otomatis mendistribusikan ulang data ke semua disk.
Ceph punya snapshot, tapi sejauh yang saya tahu, snapshot tersebut tidak bisa digunakan langsung di Rook/Kubernetes. Benar, saya tidak membahasnya secara mendalam. Namun tidak ada pencadangan di luar situs, jadi Anda harus menggunakan sesuatu dengan Velero/Restic, tetapi yang ada hanya pencadangan tingkat file, bukan snapshot titik waktu. Apa yang benar-benar saya sukai dari Rook adalah betapa mudahnya bekerja dengan Ceph - ia menyembunyikan hampir semua hal rumit dan menawarkan alat untuk berbicara langsung dengan Ceph untuk pemecahan masalah. Sayangnya, selama stress test volume Ceph, saya terus mengalami masalah , yang menyebabkan Ceph menjadi tidak stabil. Belum jelas apakah ini merupakan bug pada Ceph itu sendiri atau merupakan masalah pada cara Rook mengelola Ceph. Saya mengutak-atik pengaturan memori, dan menjadi lebih baik, tetapi masalahnya belum sepenuhnya terpecahkan. Ceph memiliki performa yang lumayan, seperti yang bisa Anda lihat pada benchmark di bawah ini. Dasbornya juga bagus.
Saya sangat menyukai Longhorn. Menurut pendapat saya, ini adalah solusi yang menjanjikan. Benar, pengembangnya sendiri (Rancher Labs) mengakui bahwa ini belum cocok untuk lingkungan kerja, dan ini terlihat. Ini open source dan memiliki kinerja yang layak (walaupun mereka belum mengoptimalkannya), tetapi volume memerlukan waktu yang sangat lama untuk terhubung ke pod, dan dalam kasus terburuk memerlukan waktu 15-16 menit, terutama setelah memulihkan cadangan besar atau meningkatkan beban kerja. Ini memiliki snapshot dan cadangan snapshot ini di luar situs, tetapi itu hanya berlaku untuk volume, jadi Anda masih memerlukan sesuatu seperti Velero untuk membuat cadangan sumber daya lainnya. Pencadangan dan pemulihan sangat andal, namun sangat lambat. Serius, sangat lambat. Penggunaan CPU dan beban sistem sering kali melonjak saat bekerja dengan data dalam jumlah sedang di Longhorn. Ada dasbor yang nyaman untuk mengelola Longhorn. Saya sudah mengatakan bahwa saya menyukai Longhorn, tetapi ini perlu perbaikan.
StorageOS adalah produk berbayar pertama dalam daftar. Ini memiliki versi pengembang dengan ukuran penyimpanan terkelola terbatas sebesar 500GB, tapi menurut saya tidak ada batasan jumlah node. Bagian penjualan memberi tahu saya bahwa biayanya mulai dari $125 per bulan untuk 1 TB, jika saya ingat dengan benar. Ada dasbor dasar dan CLI yang nyaman, tetapi sesuatu yang aneh terjadi dengan kinerjanya: di beberapa benchmark cukup baik, tetapi dalam uji stres volume saya tidak menyukai kecepatannya sama sekali. Secara umum, saya tidak tahu harus berkata apa. Jadi saya tidak terlalu mengerti. Tidak ada pencadangan di luar situs di sini dan Anda juga harus menggunakan Velero dengan Restic untuk mencadangkan volume. Aneh, karena produknya berbayar. Dan para pengembang tidak ingin berkomunikasi di Slack.
Saya mengetahui tentang Robin di Reddit dari direktur teknis mereka. Saya belum pernah mendengar tentang dia sebelumnya. Mungkin karena saya mencari solusi gratis, tapi Robin berbayar. Mereka memiliki versi gratis yang cukup besar dengan penyimpanan 10TB dan tiga node. Secara keseluruhan, produk ini cukup baik dan memiliki fitur-fitur bagus. Ada CLI yang bagus, tetapi yang paling keren adalah Anda dapat mengambil snapshot dan mencadangkan seluruh aplikasi (di 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 bukan karena satu detail kecil: jika Anda memulihkan (atau "mengimpor", sebagaimana disebut dalam Robin) aplikasi pada cluster baru - misalnya, jika terjadi pemulihan dari bencana - pemulihan, tentu saja berhasil, namun terus membackup aplikasi itu dilarang. Hal ini tidak mungkin dilakukan dalam rilis ini, seperti yang telah dikonfirmasi oleh pengembang. Hal ini, secara halus, aneh, terutama mengingat keuntungan lainnya (misalnya, pencadangan dan pemulihan yang sangat cepat). Pengembang berjanji untuk memperbaiki semuanya pada rilis berikutnya. Performanya secara umum bagus, tetapi saya melihat ada keanehan: jika saya menjalankan benchmark langsung pada volume yang terpasang pada host, kecepatan bacanya jauh lebih cepat daripada menjalankan volume yang sama dari dalam pod. Semua hasil lainnya sama, namun secara teori seharusnya tidak ada perbedaan. Meskipun mereka sedang mengerjakannya, saya kesal dengan masalah pemulihan dan pencadangan - saya pikir saya akhirnya menemukan solusi yang sesuai, dan saya bahkan bersedia membayarnya ketika saya membutuhkan lebih banyak ruang atau lebih banyak server.
Saya tidak punya banyak hal untuk dikatakan di sini. Ini adalah produk berbayar, sama keren dan mahalnya. Performanya sungguh luar biasa. Ini adalah indikator terbaik sejauh ini. Slack memberi tahu saya bahwa harga mulai dari $205 per bulan per node, seperti yang tercantum di GKE Marketplace Google. Saya tidak tahu apakah akan lebih murah jika membeli langsung. Lagipula saya tidak mampu membelinya, jadi saya sangat, sangat kecewa karena lisensi pengembang (hingga 1 TB dan 3 node) praktis tidak berguna dengan Kubernetes kecuali Anda puas dengan penyediaan statis. Saya berharap lisensi volume akan diturunkan versinya secara otomatis ke pengembang di akhir masa uji coba, tetapi itu tidak terjadi. 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 publikasi postingan, ketika salah satu pembaca menyarankan untuk mencoba Linstor. Saya mencobanya dan saya menyukainya! Namun kita masih perlu menggali lebih dalam. Sekarang saya bisa mengatakan bahwa kinerjanya tidak buruk (saya menambahkan hasil benchmark di bawah). Pada dasarnya, saya mendapatkan kinerja yang sama dengan disk secara langsung, tanpa biaya tambahan apa pun. (Jangan tanya mengapa Portworx memiliki angka yang lebih baik daripada benchmark drive secara langsung. Saya tidak tahu. Ajaib, menurut saya.) Jadi sejauh ini Linstor tampaknya sangat efektif. Menginstalnya tidak terlalu sulit, tetapi tidak semudah opsi lainnya. Pertama saya harus menginstal Linstor (modul kernel dan alat/layanan) dan mengkonfigurasi LVM untuk penyediaan tipis dan dukungan snapshot di luar Kubernetes, langsung di host, dan kemudian membuat sumber daya yang diperlukan untuk menggunakan penyimpanan dari Kubernetes. Saya tidak suka karena ini tidak berfungsi di CentOS dan saya harus menggunakan Ubuntu. Tidak buruk, tentu saja, tetapi sedikit mengganggu, karena dokumentasinya (yang sangat bagus) menyebutkan beberapa paket yang tidak dapat ditemukan di repositori Epel yang ditentukan. Linstor memiliki snapshot, tetapi tidak memiliki cadangan di luar situs, jadi di sini sekali lagi saya harus menggunakan Velero dengan Restic untuk membuat cadangan volume. Saya lebih memilih snapshot daripada pencadangan tingkat file, namun hal ini dapat ditoleransi jika solusinya berkinerja baik dan dapat diandalkan. Linstor adalah open source tetapi memiliki dukungan berbayar. Jika saya memahaminya dengan benar, ini dapat digunakan tanpa batasan, meskipun Anda tidak memiliki kontrak dukungan, tetapi hal ini perlu diperjelas. Saya tidak tahu seberapa diuji Linstor untuk Kubernetes, tetapi lapisan penyimpanannya sendiri berada di luar Kubernetes dan, tampaknya, solusinya tidak muncul kemarin, jadi mungkin sudah diuji dalam kondisi nyata. Apakah ada solusi yang akan membuat saya berubah pikiran dan kembali ke Kubernetes? Saya tidak tahu. Kita masih perlu menggali lebih dalam dan mempelajari replikasi. Mari kita lihat. Tapi kesan pertama bagus. Saya pasti lebih suka menggunakan cluster Kubernetes saya sendiri daripada Heroku untuk mendapatkan lebih banyak kebebasan dan mempelajari hal-hal baru. Karena Linstor tidak mudah dipasang seperti yang lain, saya akan segera menulis postingan tentangnya.
Tolak ukur
Sayangnya, saya tidak membuat banyak catatan tentang perbandingan tersebut karena saya rasa saya tidak akan menulisnya. Saya hanya mendapatkan hasil dari benchmark fio dasar dan hanya untuk cluster node tunggal, jadi saya belum memiliki nomor untuk konfigurasi yang direplikasi. Namun dari hasil ini Anda bisa mendapatkan gambaran kasar tentang apa yang diharapkan dari setiap opsi, karena saya membandingkannya di server cloud yang sama, 4 core, RAM 16 GB, dengan tambahan disk 100 GB untuk volume yang diuji. Saya menjalankan benchmark tiga kali untuk setiap solusi dan menghitung hasil rata-rata, ditambah lagi saya mengatur ulang pengaturan server untuk setiap produk. Ini semua sama sekali tidak ilmiah, hanya untuk memberi Anda gambaran umum. Dalam pengujian lain, saya menyalin foto dan video 38 GB dari volume untuk menguji membaca dan menulis, tetapi sayangnya saya tidak menyimpan nomornya. 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: 4Saya pertama kali membuat volume dengan kelas penyimpanan yang sesuai dan kemudian menjalankan pekerjaan dengan fio di belakang layar. Saya mengambil 1 GB untuk memperkirakan kinerjanya dan tidak menunggu terlalu lama. Berikut hasilnya:
Saya telah menyorot nilai terbaik untuk setiap metrik dengan warna hijau dan nilai terburuk dengan warna merah.
Kesimpulan
Seperti yang Anda lihat, dalam banyak kasus, Portworx berkinerja lebih baik daripada yang lain. Tapi bagi saya itu mahal. Saya tidak tahu berapa harga Robin, tetapi mereka memiliki versi gratis yang bagus, jadi jika Anda menginginkan produk berbayar, Anda dapat mencobanya (semoga mereka segera memperbaiki masalah pemulihan dan pencadangan). Dari tiga yang gratis, saya memiliki paling sedikit masalah dengan OpenEBS, namun kinerjanya sangat buruk. Sayang sekali saya tidak menyimpan lebih banyak hasil, tapi saya harap angka dan komentar saya dapat membantu Anda.
Sumber: www.habr.com