Sehubungan dengan semakin populernya Benteng, saya ingin berbicara tentang jebakan dan masalah yang menanti Anda selama ini.
Tentang saya: Pengalaman dalam administrasi ceph dari versi hammer, pendiri komunitas di telegram.
Agar tidak berdasar, saya akan merujuk pada postingan yang diterima Habr (dilihat dari ratingnya) tentang masalah ceph. Saya juga menemui sebagian besar masalah dalam postingan ini. Tautan ke materi yang digunakan ada di akhir postingan.
Dalam postingan tentang Benteng, kami menyebutkan ceph karena suatu alasan - Benteng pada dasarnya adalah ceph yang dibungkus dengan kubernetes, yang berarti ia mewarisi semua masalahnya. Mari kita mulai dengan masalah ceph.
Sederhanakan manajemen klaster
Salah satu kelebihan Rook adalah kemudahan pengelolaan ceph melalui kuberentes.
Namun, ceph berisi lebih dari 1000 parameter untuk konfigurasi, sementara pada saat yang sama, melalui benteng kita hanya dapat mengedit sebagian kecil saja.
Contoh pada Bercahaya
> ceph daemon mon.a tampilan konfigurasi | toilet -l
1401
Benteng diposisikan sebagai cara mudah untuk menginstal dan memperbarui ceph
Tidak ada masalah saat menginstal ceph tanpa Benteng - pedoman yang memungkinkan ditulis dalam 30 menit, tetapi ada banyak masalah saat memperbarui.
Kutipan dari postingan Krok
Contoh: crush merdu tidak berfungsi dengan benar setelah memperbarui dari hummer ke permata
> ceph osd crush show-tunables
{
...
"straw_calc_version": 1,
"diizinkan_bucket_algs": 22,
"profil": "tidak diketahui",
"optimal_tunables": 0,
...
}
Tetapi bahkan dalam versi minor pun ada masalah.
Contoh: Pembaruan 12.2.6 membawa cluster ke status health err dan PG rusak secara kondisional
Jangan perbarui, tunggu dan uji? Tapi sepertinya kami menggunakan Benteng untuk kenyamanan pembaruan, antara lain.
Kompleksitas cluster pemulihan bencana di Rook
Contoh: OSD gagal karena banyak kesalahan. Anda menduga masalahnya ada pada salah satu parameter di konfigurasi, Anda ingin mengubah konfigurasi untuk daemon tertentu, tetapi tidak bisa karena Anda memiliki kubernetes dan DaemonSet.
Tidak ada alternatif lain. ceph tell osd.Num injectargs tidak berfungsi - OSD berbohong.
Kesulitan men-debug
Beberapa pengaturan dan pengujian kinerja memerlukan koneksi langsung ke soket osd daemon. Dalam kasus Benteng, pertama-tama Anda harus menemukan wadah yang diinginkan, lalu masuk ke dalamnya, menemukan peralatan yang hilang untuk debug, dan menjadi sangat kesal.
Kesulitan menaikkan OSD secara konsisten
Contoh: OSD jatuh di OOM, penyeimbangan kembali dimulai, setelah itu yang berikut ini jatuh.
Solusi: Naikkan OSD satu per satu, tunggu hingga benar-benar disertakan dalam cluster, lalu naikkan OSD berikutnya. (Lebih detailnya ada di laporan Ceph. Anatomi bencana).
Dalam kasus instalasi baremetal, hal ini dilakukan hanya dengan tangan; dalam kasus Benteng dan satu OSD per node, tidak ada masalah khusus; masalah dengan pengangkatan bergantian akan muncul jika OSD > 1 per node.
Tentu saja, masalah tersebut dapat diselesaikan, tetapi kami menggunakan Benteng untuk menyederhanakan berbagai hal, namun mendapatkan lebih banyak kerumitan.
Kesulitan dalam memilih batasan untuk setan ceph
Untuk instalasi ceph baremetal, cukup mudah untuk menghitung sumber daya yang diperlukan untuk sebuah cluster - ada rumus dan penelitian yang tersedia. Jika Anda menggunakan CPU yang lemah, Anda masih harus menjalankan beberapa tes kinerja untuk mengetahui apa itu Numa, tetapi ini masih lebih mudah daripada Benteng.
Dalam kasus Benteng, selain batas memori yang dapat dihitung, Anda memiliki pertanyaan tentang pengaturan batas CPU.
Dan di sini Anda harus bekerja keras dengan tes kinerja. Jika Anda menurunkan batasnya, Anda akan mendapatkan cluster yang lambat; jika Anda menyetel unlim, Anda akan mendapatkan penggunaan CPU aktif selama penyeimbangan ulang, yang akan berdampak buruk pada aplikasi Anda di kubernetes.
Masalah Jaringan v1
Untuk ceph disarankan menggunakan jaringan 2x10GB. Satu untuk trafik klien, satu lagi untuk kebutuhan layanan ceph (rebalancing). Jika Anda tinggal dengan ceph di baremetal, maka pembagian ini mudah dikonfigurasi, jika Anda tinggal dengan Benteng, maka pembagian berdasarkan jaringan akan menyebabkan masalah bagi Anda, karena fakta bahwa tidak setiap konfigurasi cluster memungkinkan Anda memasukkan dua jaringan berbeda ke pod .
Masalah Jaringan v2
Jika Anda menolak untuk memisahkan jaringan, maka ketika penyeimbangan ulang, lalu lintas ceph akan menyumbat seluruh saluran dan aplikasi Anda di kubernetes akan melambat atau crash. Anda dapat mengurangi kecepatan penyeimbangan ulang ceph, tetapi karena penyeimbangan ulang yang lama, Anda mendapatkan peningkatan risiko node kedua keluar dari cluster melalui disk atau OOM, dan sudah ada jaminan hanya baca untuk cluster tersebut.
Penyeimbangan ulang yang lama - kelambatan aplikasi yang lama
Kutipan dari postingan Ceph. Anatomi bencana.
Uji kinerja kluster:
Operasi tulis berukuran 4 KB membutuhkan waktu 1 ms, kinerja 1000 operasi/detik dalam 1 thread.
Pengoperasian 4 MB (ukuran objek) membutuhkan 22 ms, kinerja 45 operasi/detik.
Akibatnya, ketika satu dari tiga domain gagal, cluster berada dalam kondisi terdegradasi selama beberapa waktu, dan setengah dari objek panas didistribusikan ke versi yang berbeda, maka setengah dari operasi penulisan akan dimulai dengan pemulihan paksa.
Kami menghitung kira-kira waktu pemulihan paksa - operasi tulis ke objek yang terdegradasi.
Pertama kita membaca 4 MB dalam 22 ms, menulis 22 ms, dan kemudian dalam 1 ms kita menulis 4 KB data aktual. Total 45 ms per operasi penulisan ke objek terdegradasi pada SSD, ketika performa standarnya adalah 1 ms - penurunan performa sebesar 45 kali lipat.
Semakin tinggi persentase benda-benda terdegradasi yang kita miliki, maka segala sesuatunya akan semakin buruk.
Ternyata kecepatan penyeimbangan ulang sangat penting untuk pengoperasian cluster yang benar.
Pengaturan server khusus untuk ceph
ceph mungkin memerlukan penyetelan host khusus.
Contoh: pengaturan sysctl dan JumboFrame yang sama, beberapa pengaturan ini mungkin berdampak negatif pada payload Anda.
Kebutuhan sebenarnya akan Benteng masih dipertanyakan
Jika Anda berada di cloud, Anda memiliki penyimpanan dari penyedia cloud Anda, yang jauh lebih nyaman.
Jika Anda menggunakan server Anda sendiri, maka pengelolaan ceph akan lebih nyaman tanpa kubernetes.
Apakah Anda menyewa server dari beberapa hosting berbiaya rendah? Kemudian Anda akan bersenang-senang dengan jaringan, penundaan dan bandwidthnya, yang jelas berdampak negatif pada ceph.
Total: Mengimplementasikan kuberentes dan mengimplementasikan penyimpanan adalah tugas yang berbeda dengan input dan opsi solusi yang berbeda - menggabungkan keduanya berarti melakukan trade-off yang mungkin berbahaya demi salah satu hal. Akan sangat sulit untuk menggabungkan solusi ini bahkan pada tahap desain, dan masih ada masa pengoperasian.
Daftar literatur yang digunakan:
Tapi kamu bilang Ceph... apakah dia benar-benar bagus?
Ceph. Anatomi bencana
Sumber: www.habr.com