Dia tidak membutuhkanmu

Sehubungan dengan meningkatnya popularitas Rook, saya ingin berbicara tentang perangkapnya dan masalah yang menunggu Anda di jalan.

Tentang saya: Pengalaman administrasi Ceph dengan versi palu, pendiri komunitas t.me/ceph_ru di telegram.

Agar tidak berdasar, saya akan merujuk ke posting yang diterima oleh Habr (menilai berdasarkan peringkat) tentang masalah dengan ceph. Saya menemui sebagian besar masalah dalam posting ini juga. Tautan ke materi yang digunakan di akhir posting.

Dalam sebuah posting tentang Rook, kami menyebutkan ceph karena suatu alasan - Rook pada dasarnya ceph dibungkus dengan kubernet, yang berarti ia mewarisi semua masalahnya. Kami akan mulai dengan masalah ceph.

Sederhanakan manajemen klaster

Salah satu kelebihan Rook adalah kemudahan mengelola ceph melalui kuberentes.

Namun, ceph berisi lebih dari 1000 parameter untuk penyetelan, pada saat yang sama melalui rook kita hanya dapat mengedit sebagian kecil saja.

Contoh bercahaya
> ceph daemon mon.a config show | wc -l
1401

Rook diposisikan sebagai cara mudah untuk menginstal dan memperbarui ceph
Tidak ada masalah dengan menginstal ceph tanpa Rook - buku pedoman yang mungkin ditulis dalam 30 menit, tetapi ada banyak masalah dengan memperbarui masalah.

Kutipan dari posting Krok

Contoh: operasi yang salah dari tunables crush setelah meningkatkan dari hummer ke jewel

> ceph osd crush show-tunables
{
...
"Straw_calc_version": 1,
"Diizinkan_bucket_algs": 22,
"Profil": "tidak diketahui",
Optimal_tunables: 0,
...
}

Tetapi bahkan dalam versi minor ada masalah.

Contoh: Pembaruan 12.2.6 membawa gugus ke kondisi kesehatan yang salah dan PG yang rusak kondisional
ceph.com/releases/v12-2-8-released

Jangan perbarui, tunggu, dan uji? Tapi kami agak menggunakan Rook untuk kenyamanan pembaruan juga.

Kompleksitas cluster pemulihan bencana di Rook

Contoh: OSD crash kesalahan rashing di bawah kakinya. Anda menduga bahwa masalahnya ada di salah satu parameter dalam konfigurasi, Anda ingin mengubah konfigurasi untuk daemon tertentu, tetapi Anda tidak bisa, karena Anda memiliki kubernetes dan DaemonSet.

Tidak ada alternatif. ceph tell osd.Num injectargs tidak berfungsi - kebohongan OSD.

Kompleksitas debug

Untuk beberapa pengaturan dan tes kinerja, Anda harus terhubung langsung ke soket daemon osd. Dalam kasus Rook, pertama-tama Anda perlu menemukan wadah yang tepat, lalu masuk ke dalamnya, menemukan yang hilang untuk penyetelan debug dan sangat marah.

Kesulitan meningkatkan OSD secara berurutan

Contoh: OSD jatuh pada OOM, penyeimbangan dimulai, kemudian jatuh berikutnya.

Solusi: Naikkan OSD satu per satu, tunggu hingga sepenuhnya termasuk dalam cluster, dan naikkan yang berikutnya. (Lebih detail dalam laporan Ceph. Anatomi Bencana)

Dalam kasus pemasangan baremetal, ini dilakukan hanya dengan tangan, dalam kasus Rook dan satu OSD pada node, tidak ada masalah khusus, masalah dengan pengangkatan yang berurutan akan terjadi jika OSD> 1 pada node.

Tentu saja, mereka dapat dipecahkan, tetapi kami membawa Rook untuk penyederhanaan, tetapi kami mendapat kesulitan.

Kesulitan memilih batas untuk setan ceph

Untuk pemasangan baremetal ceph, cukup mudah untuk menghitung sumber daya yang diperlukan per cluster - ada rumus dan ada studi. Saat menggunakan CPU yang lemah, Anda masih harus melakukan serangkaian tes kinerja untuk mengetahui apa itu Numa, tetapi masih lebih sederhana daripada di Rook.

Dalam kasus Rook, selain batas memori yang dapat dihitung, muncul pertanyaan tentang pengaturan batas CPU.

Dan kemudian Anda harus berkeringat dengan tes kinerja. Dalam hal meremehkan batas, Anda akan mendapatkan klaster yang lambat, dalam hal pengaturan unlim Anda akan mendapatkan penggunaan CPU aktif dengan penyeimbangan kembali, yang akan berdampak buruk pada aplikasi Anda di kubernetes.

Masalah jaringan v1

Untuk ceph, disarankan untuk menggunakan jaringan 2x10gb. Satu untuk lalu lintas klien, satu lagi untuk penggunaan kantor ceph (menyeimbangkan). Jika Anda hidup dengan ceph pada baremetal, maka pemisahan ini mudah dikonfigurasikan, jika Anda hidup dengan Rook, maka dengan pemisahan oleh jaringan itu akan menimbulkan masalah bagi Anda, karena fakta bahwa tidak setiap konfigurasi cluster memungkinkan dua jaringan berbeda untuk dikirimkan ke pod.

Masalah jaringan v2

Jika Anda menolak untuk berbagi jaringan, maka dengan menyeimbangkan kembali, lalu lintas ceph akan menyumbat seluruh saluran dan aplikasi Anda di kubernetes akan melambat atau macet. Anda dapat mengurangi tingkat penyeimbangan kembali ceph, tetapi kemudian karena penyeimbangan kembali yang lama, Anda mendapatkan peningkatan risiko simpul kedua jatuh dari gugusan pada disk atau OOM, dan sudah ada jaminan hanya dibaca pada gugus.

Penyeimbangan panjang - rem aplikasi lama

Kutipan dari posting Ceph. Anatomi bencana.

Kinerja Cluster Tes:

Operasi penulisan 4 KB membutuhkan 1 ms, kinerja 1000 operasi / detik dalam 1 aliran.

Operasi berukuran 4 MB (ukuran objek) membutuhkan 22 ms, kinerja 45 operasi / detik.

Oleh karena itu, ketika salah satu dari tiga domain gagal, gugus berada dalam kondisi terdegradasi untuk beberapa waktu, dan setengah dari objek panas akan menyebar menurut versi yang berbeda, maka setengah dari operasi penulisan akan dimulai dengan pemulihan paksa.

Waktu pemulihan paksa dihitung sekitar - tulis operasi dalam objek terdegradasi.

Pertama, kita membaca 4 MB dalam 22 ms, menulis 22 ms, dan kemudian 1 ms kita menulis 4 KB data itu sendiri. Secara total, 45 ms untuk satu operasi tulis ke objek terdegradasi pada SSD, ketika kinerja standar adalah 1 ms - penurunan kinerja 45 kali.

Semakin banyak persentase objek terdegradasi, semakin buruk hasilnya.

Ternyata tingkat penyeimbangan sangat penting untuk operasi cluster yang benar.

Pengaturan khusus server untuk ceph

ceph mungkin perlu penyetelan host tertentu.

Contoh: pengaturan sysctl dan JumboFrame yang sama, beberapa pengaturan ini dapat berdampak negatif pada payload Anda.

Kebutuhan nyata untuk Benteng masih dipertanyakan

Jika Anda berada di cloud, Anda memiliki penyimpanan dari penyedia cloud Anda, yang jauh lebih nyaman.

Jika Anda berada di server Anda, maka manajemen ceph akan lebih mudah tanpa kubernet.

Apakah Anda menyewa server di hosting murah? Kemudian Anda akan menemukan banyak kesenangan dengan jaringan, penundaan dan bandwidth, yang jelas berdampak negatif terhadap ceph.

Total: Pengenalan kuberentes dan pengantar repositori adalah tugas yang berbeda dengan opsi pengantar dan solusi yang berbeda - untuk mencampurkannya, kemudian memungkinkan trade-off berbahaya untuk ini atau itu. Menggabungkan solusi ini akan sangat sulit bahkan pada tahap desain, dan masih ada periode operasi.

Daftar literatur yang digunakan:

Posting # 1 Tapi katamu Ceph ... tapi apakah dia baik?
Posting # 2 Ceph. Anatomi bencana