Tip & trik untuk bekerja dengan Ceph dalam proyek yang sibuk

Menggunakan Ceph sebagai penyimpanan jaringan dalam proyek dengan beban berbeda, kita mungkin menghadapi berbagai tugas yang sekilas tampak tidak sederhana atau sepele. Misalnya:

• migrasi data dari Ceph lama ke yang baru dengan penggunaan sebagian server sebelumnya di cluster baru;
• solusi untuk masalah alokasi ruang disk di Ceph.

Saat menghadapi masalah seperti itu, kita dihadapkan pada kebutuhan untuk menghapus OSD dengan benar tanpa kehilangan data, yang khususnya penting ketika berhadapan dengan data dalam jumlah besar. Ini akan dibahas dalam artikel.

Metode yang dijelaskan di bawah ini relevan untuk versi Ceph apa pun. Selain itu, fakta bahwa Ceph dapat menyimpan data dalam jumlah besar akan diperhitungkan: untuk mencegah kehilangan data dan masalah lainnya, beberapa tindakan akan “dibagi” menjadi beberapa tindakan lainnya.

Kata Pengantar tentang OSD

Karena dua dari tiga resep yang dibahas didedikasikan untuk OSD (Daemon Penyimpanan Objek), sebelum masuk ke bagian praktis - secara singkat tentang apa itu Ceph dan mengapa itu sangat penting.

Pertama-tama, harus dikatakan bahwa seluruh cluster Ceph terdiri dari banyak OSD. Semakin banyak, semakin besar volume data gratis di Ceph. Sangat mudah untuk memahaminya dari sini fungsi OSD utama: Ini menyimpan data objek Ceph pada sistem file semua node cluster dan menyediakan akses jaringan ke sana (untuk membaca, menulis, dan permintaan lainnya).

Pada tingkat yang sama, parameter replikasi diatur dengan menyalin objek di antara OSD yang berbeda. Dan di sini Anda bisa menemui berbagai masalah, solusinya akan dibahas di bawah ini.

Kasus No.1. Hapus OSD dengan aman dari cluster Ceph tanpa kehilangan data

Kebutuhan untuk menghapus OSD mungkin disebabkan oleh penghapusan server dari cluster - misalnya, untuk menggantinya dengan server lain - itulah yang terjadi pada kami sehingga memunculkan penulisan artikel ini. Oleh karena itu, tujuan akhir manipulasi adalah mengekstrak semua OSD dan mons di server tertentu sehingga dapat dihentikan.

Untuk kenyamanan dan untuk menghindari situasi di mana, saat menjalankan perintah, kami membuat kesalahan dalam menunjukkan OSD yang diperlukan, kami akan menetapkan variabel terpisah, yang nilainya akan menjadi nomor OSD yang akan dihapus. Ayo telepon dia ${ID} — di sini dan di bawah, variabel tersebut menggantikan nomor OSD yang sedang kita kerjakan.

Mari kita lihat kondisinya sebelum mulai bekerja:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

Untuk memulai penghapusan OSD, Anda harus melakukannya dengan lancar reweight di atasnya menjadi nol. Dengan cara ini kami mengurangi jumlah data di OSD dengan menyeimbangkannya dengan OSD lain. Untuk melakukannya, jalankan perintah berikut:

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

...dan seterusnya sampai nol.

Diperlukan keseimbangan yang lancaragar tidak kehilangan data. Hal ini terutama berlaku jika OSD berisi data dalam jumlah besar. Untuk memastikannya setelah menjalankan perintah reweight semuanya berjalan dengan baik, Anda bisa menyelesaikannya ceph -s atau di jendela terminal terpisah dijalankan ceph -w untuk mengamati perubahan secara real time.

Bila OSD “dikosongkan”, Anda dapat melanjutkan dengan operasi standar untuk menghapusnya. Untuk melakukan ini, transfer OSD yang diinginkan ke status down:

ceph osd down osd.${ID}

Mari kita “menarik” OSD keluar dari cluster:

ceph osd out osd.${ID}

Mari kita hentikan layanan OSD dan unmount partisinya di FS:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

Hapus OSD dari peta HANCURKAN:

ceph osd crush remove osd.${ID}

Mari kita hapus pengguna OSD:

ceph auth del osd.${ID}

Dan terakhir, mari hapus OSD itu sendiri:

ceph osd rm osd.${ID}

Catatan: Jika Anda menggunakan Ceph Luminous versi atau lebih tinggi, maka langkah-langkah penghapusan OSD di atas dapat dikurangi menjadi dua perintah:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

Jika, setelah menyelesaikan langkah-langkah yang dijelaskan di atas, Anda menjalankan perintah ceph osd tree, maka harus jelas bahwa di server tempat pekerjaan dilakukan, tidak ada lagi OSD yang digunakan untuk melakukan operasi di atas:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

Sepanjang jalan, perhatikan bahwa status cluster Ceph akan berubah HEALTH_WARN, dan kita juga akan melihat penurunan jumlah OSD dan jumlah ruang disk yang tersedia.

Berikut ini akan dijelaskan langkah-langkah yang diperlukan jika Anda ingin menghentikan server sepenuhnya dan, karenanya, menghapusnya dari Ceph. Dalam hal ini, penting untuk mengingat hal itu Sebelum mematikan server, Anda harus menghapus semua OSD di server ini.

Jika tidak ada lagi OSD yang tersisa di server ini, setelah menghapusnya, Anda perlu mengecualikan server dari peta OSD hv-2dengan menjalankan perintah berikut:

ceph osd crush rm hv-2

Menghapus mon dari server hv-2dengan menjalankan perintah di bawah ini pada server lain (yaitu dalam hal ini, on hv-1):

ceph-deploy mon destroy hv-2

Setelah ini, Anda dapat menghentikan server dan memulai tindakan selanjutnya (menyebarkannya kembali, dll.).

Kasus No.2. Distribusi ruang disk di cluster Ceph yang sudah dibuat

Saya akan memulai cerita kedua dengan kata pengantar tentang PG (Grup Penempatan). Peran utama PG di Ceph terutama adalah untuk menggabungkan objek Ceph dan mereplikasinya lebih lanjut di OSD. Rumus yang dapat digunakan untuk menghitung jumlah PG yang dibutuhkan ada di bagian yang relevan Dokumentasi Ceph. Masalah ini juga dibahas di sana dengan contoh-contoh spesifik.

Jadi: salah satu masalah umum saat menggunakan Ceph adalah jumlah OSD dan PG yang tidak seimbang antar pool di Ceph.

Pertama, karena hal ini, situasi mungkin muncul ketika terlalu banyak PG yang ditentukan dalam kumpulan kecil, yang pada dasarnya merupakan penggunaan ruang disk yang tidak rasional dalam cluster. Kedua, dalam praktiknya terdapat masalah yang lebih serius: data meluap di salah satu OSD. Hal ini mengharuskan klaster melakukan transisi terlebih dahulu ke status HEALTH_WARN, kemudian HEALTH_ERR. Alasannya adalah Ceph, saat menghitung jumlah data yang tersedia (Anda dapat mengetahuinya dengan MAX AVAIL dalam keluaran perintah ceph df untuk setiap kumpulan secara terpisah) didasarkan pada jumlah data yang tersedia di OSD. Jika tidak ada cukup ruang di setidaknya satu OSD, data tidak dapat ditulis lagi hingga data didistribusikan dengan benar ke semua OSD.

Perlu diklarifikasi bahwa masalah-masalah ini sebagian besar diputuskan pada tahap konfigurasi cluster Ceph. Salah satu alat yang dapat Anda gunakan adalah Ceph PGCalc. Dengan bantuannya, jumlah PG yang dibutuhkan dihitung dengan jelas. Namun, Anda juga dapat menggunakannya dalam situasi di mana Ceph berkelompok sudah dikonfigurasi secara tidak benar. Perlu diklarifikasi di sini bahwa sebagai bagian dari pekerjaan perbaikan, kemungkinan besar Anda perlu mengurangi jumlah PG, dan fitur ini tidak tersedia di versi Ceph yang lebih lama (hanya muncul di versi Nautilus).

Jadi, bayangkan gambar berikut: cluster tersebut memiliki status HEALTH_WARN karena salah satu OSD kehabisan ruang. Hal ini ditandai dengan adanya kesalahan HEALTH_WARN: 1 near full osd. Di bawah ini adalah algoritma untuk keluar dari situasi ini.

Pertama-tama, Anda perlu mendistribusikan data yang tersedia di antara OSD lainnya. Kami telah melakukan operasi serupa dalam kasus pertama, ketika kami "mengeringkan" node - dengan satu-satunya perbedaan yang sekarang kami perlu sedikit menguranginya reweight. Misalnya, hingga 0.95:

ceph osd reweight osd.${ID} 0.95

Ini akan mengosongkan ruang disk di OSD dan memperbaiki kesalahan pada kesehatan ceph. Namun, seperti yang telah disebutkan, masalah ini terutama terjadi karena konfigurasi Ceph yang salah pada tahap awal: sangat penting untuk melakukan konfigurasi ulang agar tidak muncul di kemudian hari.

Dalam kasus khusus kami, semuanya bermuara pada:

• nilainya terlalu tinggi replication_count di salah satu kolam,
• terlalu banyak PG di satu kelompok dan terlalu sedikit di kelompok lain.

Mari gunakan kalkulator yang telah disebutkan. Ini jelas menunjukkan apa yang perlu dimasukkan dan pada prinsipnya tidak ada yang rumit. Setelah menetapkan parameter yang diperlukan, kami mendapatkan rekomendasi berikut:

Catatan: Jika Anda menyiapkan cluster Ceph dari awal, fungsi lain yang berguna dari kalkulator adalah pembuatan perintah yang akan membuat kumpulan dari awal dengan parameter yang ditentukan dalam tabel.

Kolom terakhir membantu Anda menavigasi - Jumlah PG yang disarankan. Dalam kasus kami, yang kedua juga berguna, di mana parameter replikasi ditunjukkan, karena kami memutuskan untuk mengubah pengali replikasi.

Jadi, pertama-tama Anda perlu mengubah parameter replikasi - ini harus dilakukan terlebih dahulu, karena dengan mengurangi pengali, kami akan mengosongkan ruang disk. Saat perintah dijalankan, Anda akan melihat bahwa ruang disk yang tersedia akan bertambah:

ceph osd pool $pool_name set $replication_size

Dan setelah selesai, kita ubah nilai parameternya pg_num и pgp_num sebagai berikut:

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

Ini penting: kita harus mengubah jumlah PG secara berurutan di setiap pool dan tidak mengubah nilai di pool lain sampai peringatan tersebut hilang "Redundansi data terdegradasi" и "n-jumlah pgs terdegradasi".

Anda juga dapat memeriksa apakah semuanya berjalan baik menggunakan perintah output ceph health detail и ceph -s.

Kasus No.3. Memigrasikan mesin virtual dari LVM ke Ceph RBD

Dalam situasi di mana sebuah proyek menggunakan mesin virtual yang diinstal pada server bare-metal sewaan, masalah penyimpanan yang toleran terhadap kesalahan sering kali muncul. Juga sangat diinginkan bahwa ada cukup ruang dalam penyimpanan ini... Situasi umum lainnya: ada mesin virtual dengan penyimpanan lokal di server dan Anda perlu memperluas disk, tetapi tidak ada tempat untuk pergi, karena tidak ada ruang disk kosong tersisa di server.

Masalahnya dapat diselesaikan dengan berbagai cara - misalnya, dengan bermigrasi ke server lain (jika ada) atau menambahkan disk baru ke server. Namun hal ini tidak selalu memungkinkan, jadi migrasi dari LVM ke Ceph bisa menjadi solusi terbaik untuk masalah ini. Dengan memilih opsi ini, kami juga menyederhanakan proses migrasi lebih lanjut antar server, karena tidak perlu memindahkan penyimpanan lokal dari satu hypervisor ke hypervisor lainnya. Satu-satunya kendala adalah Anda harus menghentikan VM saat pekerjaan sedang dilakukan.

Resep berikut diambil dari artikel dari blog ini, instruksi yang telah diuji dalam tindakan. Omong-omong, metode migrasi tanpa kerumitan juga dijelaskan di sana, namun, dalam kasus kami, hal itu tidak diperlukan, jadi kami tidak memeriksanya. Jika ini penting untuk proyek Anda, kami akan senang mendengar hasilnya di komentar.

Mari kita beralih ke bagian praktisnya. Dalam contoh ini kita menggunakan virsh dan, karenanya, libvirt. Pertama, pastikan kumpulan Ceph tempat data akan dimigrasi terhubung ke libvirt:

virsh pool-dumpxml $ceph_pool

Deskripsi kumpulan harus berisi data koneksi ke Ceph dengan data otorisasi.

Langkah selanjutnya adalah image LVM diubah menjadi Ceph RBD. Waktu eksekusi terutama bergantung pada ukuran gambar:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

Setelah konversi, gambar LVM akan tetap ada, yang akan berguna jika migrasi VM ke RBD gagal dan Anda harus mengembalikan perubahan. Selain itu, agar dapat mengembalikan perubahan dengan cepat, mari buat cadangan file konfigurasi mesin virtual:

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

... dan edit yang asli (vm_name.xml). Mari kita temukan blok dengan deskripsi disk (dimulai dengan baris <disk type='file' device='disk'> dan diakhiri dengan </disk>) dan direduksi menjadi bentuk berikut:

<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
  <secret type='ceph' uuid='sec-ret-uu-id'/>
 </auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
  <host name='10.0.0.1' port='6789'/>
  <host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/> 
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>

Mari kita lihat beberapa detailnya:

1. Untuk protokol source alamat penyimpanan di Ceph RBD ditunjukkan (ini adalah alamat yang menunjukkan nama kumpulan Ceph dan gambar RBD, yang ditentukan pada tahap pertama).
2. Di blok secret jenis ditunjukkan ceph, serta UUID rahasia untuk menyambungkannya. Uuidnya dapat ditemukan menggunakan perintah virsh secret-list.
3. Di blok host alamat ke monitor Ceph ditunjukkan.

Setelah mengedit file konfigurasi dan menyelesaikan konversi LVM ke RBD, Anda dapat menerapkan file konfigurasi yang dimodifikasi dan memulai mesin virtual:

virsh define $vm_name.xml
virsh start $vm_name

Saatnya memeriksa apakah mesin virtual dimulai dengan benar: Anda dapat mengetahuinya, misalnya, dengan menghubungkannya melalui SSH atau melalui virsh.

Jika mesin virtual berfungsi dengan benar dan Anda tidak menemukan masalah lain, maka Anda dapat menghapus image LVM yang tidak lagi digunakan:

lvremove main/$vm_image_name

Kesimpulan

Kami menemukan semua kasus yang dijelaskan dalam praktiknya - kami berharap instruksi ini akan membantu administrator lain memecahkan masalah serupa. Jika Anda memiliki komentar atau cerita serupa lainnya dari pengalaman Anda menggunakan Ceph, kami akan senang melihatnya di komentar!

PS

Baca juga di blog kami:

• «Tangan kami bukan untuk kebosanan: memulihkan cluster Benteng di K8»;
• «Menjadi Benteng atau tidak menjadi Benteng - itulah pertanyaannya»;
• «Benteng - gudang data “layanan mandiri” untuk Kubernetes»;
• «Membuat penyimpanan persisten dengan penyediaan di Kubernetes berdasarkan Ceph'.

Sumber: www.habr.com