Sehubungan dengan populariti Rook yang semakin meningkat, saya ingin bercakap tentang perangkap dan masalah yang menanti anda sepanjang perjalanan.
Mengenai saya: Pengalaman dalam pentadbiran ceph dari versi tukul, pengasas komuniti dalam telegram.
Untuk tidak berasas, saya akan merujuk kepada jawatan yang diterima oleh Habr (berdasarkan penilaian) tentang masalah dengan ceph. Saya juga menghadapi kebanyakan masalah dalam siaran ini. Pautan kepada bahan yang digunakan ada di penghujung siaran.
Dalam siaran tentang Rook, kami menyebut ceph atas sebab - Rook pada asasnya ceph dibalut dengan kubernetes, yang bermaksud ia mewarisi semua masalahnya. Mari kita mulakan dengan masalah ceph.
Permudahkan pengurusan kluster
Salah satu kelebihan Rook ialah kemudahan mengurus ceph melalui kuberentes.
Walau bagaimanapun, ceph mengandungi lebih daripada 1000 parameter untuk konfigurasi, manakala pada masa yang sama, melalui rook kita hanya boleh mengedit minoriti daripadanya.
Contoh pada Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook diletakkan sebagai cara yang mudah untuk memasang dan mengemas kini ceph
Tiada masalah dengan memasang ceph tanpa Rook - buku permainan ansible ditulis dalam masa 30 minit, tetapi terdapat banyak masalah dengan mengemas kini.
Petikan dari siaran Krok
Contoh: crush talam tidak berfungsi dengan betul selepas mengemas kini daripada hummer kepada permata
> ceph osd crush show-tunables
{
...
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"profile": "tidak diketahui",
"optimum_tunables": 0,
...
}
Tetapi walaupun dalam versi kecil terdapat masalah.
Contoh: Kemas kini 12.2.6 membawa kluster ke dalam keadaan ralat kesihatan dan PG rosak bersyarat
Jangan kemas kini, tunggu dan uji? Tetapi kami nampaknya menggunakan Rook untuk kemudahan kemas kini, antara lain.
Kerumitan kelompok pemulihan bencana di Rook
Contoh: OSD jatuh dengan ruam ralat di kakinya. Anda mengesyaki bahawa masalahnya adalah dalam salah satu parameter dalam konfigurasi, anda ingin menukar konfigurasi untuk daemon tertentu, tetapi anda tidak boleh kerana anda mempunyai kubernetes dan DaemonSet.
Tiada alternatif. ceph tell osd.Num injectargs tidak berfungsi - OSD berbohong.
Kesukaran nyahpepijat
Sesetengah persediaan dan ujian prestasi memerlukan penyambungan terus ke soket osd daemon. Dalam kes Rook, anda perlu mencari bekas yang diingini terlebih dahulu, kemudian pergi ke dalamnya, cari alatan yang hilang untuk nyahpepijat dan berasa sangat kecewa.
Kesukaran menaikkan OSD secara konsisten
Contoh: OSD jatuh dalam OOM, pengimbangan semula bermula, selepas itu OSD jatuh.
Penyelesaian: Naikkan OSD satu demi satu, tunggu sehingga ia dimasukkan sepenuhnya dalam kelompok dan naikkan yang seterusnya. (Maklumat lanjut dalam laporan Ceph. Anatomi bencana).
Dalam kes pemasangan baremetal, ini dilakukan hanya dengan tangan; dalam kes Rook dan satu OSD setiap nod, tidak ada masalah tertentu; masalah dengan pengangkatan ganti akan timbul jika OSD > 1 setiap nod.
Sudah tentu, mereka boleh diselesaikan, tetapi kami menggunakan Rook untuk memudahkan perkara, tetapi mendapatkan lebih kerumitan.
Kesukaran dalam memilih had untuk syaitan ceph
Untuk pemasangan baremetal ceph, agak mudah untuk mengira sumber yang diperlukan untuk kluster - terdapat formula dan penyelidikan tersedia. Jika anda menggunakan CPU yang lemah, anda masih perlu menjalankan beberapa ujian prestasi untuk mengetahui apa itu Numa, tetapi ia masih lebih mudah daripada Rook.
Dalam kes Rook, sebagai tambahan kepada had memori yang boleh dikira, anda mempunyai persoalan untuk menetapkan had CPU.
Dan di sini anda perlu bekerja keras dengan ujian prestasi. Jika anda menurunkan had, anda akan mendapat kluster perlahan; jika anda menetapkan unlim, anda akan mendapat penggunaan CPU aktif semasa pengimbangan semula, yang akan memberi kesan buruk pada aplikasi anda dalam kubernetes.
Isu Rangkaian v1
Untuk ceph adalah disyorkan untuk menggunakan rangkaian 2x10GB. Satu untuk trafik pelanggan, satu lagi untuk keperluan perkhidmatan ceph (rebalance). Jika anda tinggal dengan ceph pada baremetal, maka bahagian ini mudah dikonfigurasikan, jika anda tinggal dengan Rook, maka pembahagian mengikut rangkaian akan menyebabkan anda masalah, kerana fakta bahawa tidak setiap konfigurasi kluster membolehkan anda memberi makan dua rangkaian berbeza ke pod .
Isu Rangkaian v2
Jika anda enggan memisahkan rangkaian, maka apabila mengimbangi semula, trafik ceph akan menyumbat keseluruhan saluran dan aplikasi anda dalam kubernetes akan menjadi perlahan atau ranap. Anda boleh mengurangkan kelajuan pengimbangan semula ceph, tetapi kemudian disebabkan pengimbangan semula yang lama, anda mendapat peningkatan risiko nod kedua terkeluar daripada kluster melalui cakera atau OOM, dan sudah ada jaminan bacaan sahaja untuk kluster.
Imbangan semula yang lama - aplikasi yang lama ketinggalan
Petikan dari siaran Ceph. Anatomi bencana.
Uji prestasi kluster:
Operasi tulis bersaiz 4 KB mengambil masa 1 ms, prestasi ialah 1000 operasi/saat dalam 1 utas.
Operasi 4 MB (saiz objek) mengambil masa 22 ms, prestasi ialah 45 operasi/saat.
Akibatnya, apabila satu daripada tiga domain gagal, kluster berada dalam keadaan terdegradasi untuk beberapa waktu, dan separuh daripada objek panas diedarkan pada versi yang berbeza, maka separuh daripada operasi tulis akan bermula dengan pemulihan paksa.
Kami mengira masa pemulihan paksa kira-kira - tulis operasi ke objek yang terdegradasi.
Mula-mula kita membaca 4 MB dalam 22 ms, menulis 22 ms, dan kemudian dalam 1 ms kita menulis 4 KB data sebenar. Sebanyak 45 ms setiap operasi tulis ke objek terdegradasi pada SSD, apabila prestasi standard ialah 1 ms - penurunan prestasi 45 kali ganda.
Semakin tinggi peratusan objek terdegradasi yang kita miliki, semakin buruk segala-galanya.
Ternyata kelajuan pengimbangan semula adalah kritikal untuk operasi kluster yang betul.
Tetapan pelayan khusus untuk ceph
ceph mungkin memerlukan penalaan hos khusus.
Contoh: tetapan sysctl dan JumboFrame yang sama, beberapa tetapan ini boleh menjejaskan muatan anda secara negatif.
Keperluan sebenar untuk Rook masih menjadi persoalan
Jika anda berada dalam awan, anda mempunyai storan daripada pembekal awan anda, yang lebih mudah.
Jika anda berada di pelayan anda sendiri, maka mengurus ceph akan menjadi lebih mudah tanpa kubernetes.
Adakah anda menyewa pelayan daripada beberapa pengehosan kos rendah? Kemudian anda akan berseronok dengan rangkaian, kelewatan dan lebar jalurnya, yang jelas memberi kesan negatif kepada ceph.
Jumlah: Melaksanakan kuberentes dan melaksanakan storan adalah tugas yang berbeza dengan input yang berbeza dan pilihan penyelesaian yang berbeza - mencampurkannya bermakna membuat pertukaran yang mungkin berbahaya demi satu atau yang lain. Ia akan menjadi sangat sukar untuk menggabungkan penyelesaian ini walaupun pada peringkat reka bentuk, dan masih terdapat tempoh operasi.
Senarai kesusasteraan terpakai:
Tetapi anda berkata Ceph... adakah dia benar-benar baik?
Ceph. Anatomi bencana
Sumber: www.habr.com