Petua & kiat untuk bekerja dengan Ceph dalam projek yang sibuk

Menggunakan Ceph sebagai storan rangkaian dalam projek dengan beban yang berbeza, kita mungkin menghadapi pelbagai tugas yang pada pandangan pertama nampaknya tidak mudah atau remeh. Sebagai contoh:

• penghijrahan data daripada Ceph lama kepada yang baharu dengan penggunaan separa pelayan terdahulu dalam kelompok baharu;
• penyelesaian kepada masalah peruntukan ruang cakera di Ceph.

Berurusan dengan masalah sedemikian, kami berhadapan dengan keperluan untuk mengalih keluar OSD dengan betul tanpa kehilangan data, yang amat penting apabila berurusan dengan sejumlah besar data. Ini akan dibincangkan dalam artikel.

Kaedah yang diterangkan di bawah adalah relevan untuk mana-mana versi Ceph. Di samping itu, fakta bahawa Ceph boleh menyimpan sejumlah besar data akan diambil kira: untuk mengelakkan kehilangan data dan masalah lain, beberapa tindakan akan "dipecah" kepada beberapa yang lain.

Kata pengantar tentang OSD

Oleh kerana dua daripada tiga resipi yang dibincangkan didedikasikan untuk OSD (Daemon Penyimpanan Objek), sebelum menyelam ke bahagian praktikal - secara ringkas tentang apa yang ada dalam Ceph dan mengapa ia sangat penting.

Pertama sekali, harus dikatakan bahawa keseluruhan kluster Ceph terdiri daripada banyak OSD. Semakin banyak, semakin besar volum data percuma dalam Ceph. Ia mudah difahami dari sini fungsi OSD utama: Ia menyimpan data objek Ceph pada sistem fail semua nod kluster dan menyediakan akses rangkaian kepadanya (untuk membaca, menulis dan permintaan lain).

Pada tahap yang sama, parameter replikasi ditetapkan dengan menyalin objek antara OSD yang berbeza. Dan di sini anda boleh menghadapi pelbagai masalah, penyelesaian yang akan dibincangkan di bawah.

Kes No 1. Alih keluar OSD daripada gugusan Ceph dengan selamat tanpa kehilangan data

Keperluan untuk mengalih keluar OSD mungkin disebabkan oleh mengalih keluar pelayan daripada kluster - sebagai contoh, untuk menggantikannya dengan pelayan lain - itulah yang berlaku kepada kami, menyebabkan penulisan artikel ini. Oleh itu, matlamat akhir manipulasi adalah untuk mengekstrak semua OSD dan mon pada pelayan tertentu supaya ia boleh dihentikan.

Untuk kemudahan dan untuk mengelakkan situasi di mana, semasa melaksanakan arahan, kami membuat kesilapan dalam menunjukkan OSD yang diperlukan, kami akan menetapkan pembolehubah berasingan, yang nilainya akan menjadi nombor OSD yang akan dipadamkan. Jom panggil dia ${ID} — di sini dan di bawah, pembolehubah sedemikian menggantikan nombor OSD yang kami gunakan.

Mari lihat keadaan sebelum mula 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 memulakan penyingkiran OSD, anda perlu melakukan dengan lancar reweight padanya kepada sifar. Dengan cara ini kami mengurangkan jumlah data dalam OSD dengan mengimbanginya kepada OSD lain. Untuk melakukan ini, jalankan arahan berikut:

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

... dan seterusnya sehingga sifar.

Pengimbangan lancar diperlukansupaya tidak kehilangan data. Ini benar terutamanya jika OSD mengandungi sejumlah besar data. Untuk memastikan bahawa selepas melaksanakan arahan reweight semuanya berjalan lancar, anda boleh menyelesaikannya ceph -s atau dalam tetingkap terminal yang berasingan dijalankan ceph -w untuk melihat perubahan dalam masa nyata.

Apabila OSD "dikosongkan", anda boleh meneruskan operasi standard untuk mengeluarkannya. Untuk melakukan ini, pindahkan OSD yang dikehendaki ke keadaan down:

ceph osd down osd.${ID}

Mari "tarik" OSD keluar daripada kluster:

ceph osd out osd.${ID}

Mari hentikan perkhidmatan OSD dan nyahlekap partitionnya dalam FS:

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

Alih keluar OSD daripada CRUSH peta:

ceph osd crush remove osd.${ID}

Mari padamkan pengguna OSD:

ceph auth del osd.${ID}

Dan akhirnya, mari keluarkan OSD itu sendiri:

ceph osd rm osd.${ID}

Nota: Jika anda menggunakan versi Ceph Luminous atau lebih tinggi, maka langkah penyingkiran OSD di atas boleh dikurangkan kepada dua arahan:

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

Jika, selepas melengkapkan langkah yang diterangkan di atas, anda menjalankan arahan ceph osd tree, maka harus jelas bahawa pada pelayan tempat kerja dilakukan tidak ada lagi OSD yang mana operasi di atas dilakukan:

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 perjalanan, ambil perhatian bahawa keadaan gugusan Ceph akan pergi ke HEALTH_WARN, dan kami juga akan melihat penurunan dalam bilangan OSD dan jumlah ruang cakera yang tersedia.

Berikut akan menerangkan langkah-langkah yang diperlukan jika anda ingin menghentikan sepenuhnya pelayan dan, dengan itu, mengalih keluarnya daripada Ceph. Dalam kes ini, adalah penting untuk diingati Sebelum mematikan pelayan, anda mesti mengalih keluar semua OSD pada pelayan ini.

Jika tiada lagi OSD yang tinggal pada pelayan ini, maka selepas mengalih keluarnya anda perlu mengecualikan pelayan daripada peta OSD hv-2dengan menjalankan arahan berikut:

ceph osd crush rm hv-2

Padam mon daripada pelayan hv-2dengan menjalankan arahan di bawah pada pelayan lain (iaitu dalam kes ini, pada hv-1):

ceph-deploy mon destroy hv-2

Selepas ini, anda boleh menghentikan pelayan dan memulakan tindakan seterusnya (mengerahkannya semula, dsb.).

Kes No. 2. Pengagihan ruang cakera dalam kelompok Ceph yang telah dibuat

Saya akan memulakan cerita kedua dengan mukadimah tentang PG (Kumpulan Penempatan). Peranan utama PG dalam Ceph adalah terutamanya untuk mengagregat objek Ceph dan seterusnya mereplikasinya dalam OSD. Formula yang anda boleh mengira jumlah PG yang diperlukan ada bahagian yang berkaitan dokumentasi Ceph. Isu ini juga dibincangkan di sana dengan contoh khusus.

Jadi: salah satu masalah biasa apabila menggunakan Ceph ialah bilangan OSD dan PG yang tidak seimbang antara kolam dalam Ceph.

Pertama, kerana ini, situasi mungkin timbul apabila terlalu banyak PG ditentukan dalam kumpulan kecil, yang pada asasnya merupakan penggunaan ruang cakera yang tidak rasional dalam kelompok. Kedua, dalam amalan terdapat masalah yang lebih serius: limpahan data dalam salah satu OSD. Ini memerlukan kluster peralihan pertama ke negeri HEALTH_WARN, dan kemudian HEALTH_ERR. Sebabnya ialah Ceph, apabila mengira jumlah data yang tersedia (anda boleh mengetahuinya dengan MAX AVAIL dalam output arahan ceph df untuk setiap kumpulan secara berasingan) adalah berdasarkan jumlah data yang tersedia dalam OSD. Jika tidak ada ruang yang mencukupi dalam sekurang-kurangnya satu OSD, tiada lagi data boleh ditulis sehingga data diedarkan dengan betul di antara semua OSD.

Ia adalah bernilai menjelaskan bahawa masalah ini sebahagian besarnya diputuskan pada peringkat konfigurasi kluster Ceph. Salah satu alat yang boleh anda gunakan ialah Ceph PGCalc. Dengan bantuannya, jumlah PG yang diperlukan dikira dengan jelas. Walau bagaimanapun, anda juga boleh menggunakannya dalam keadaan di mana kelompok Ceph sudah dikonfigurasikan secara tidak betul. Perlu dijelaskan di sini bahawa sebagai sebahagian daripada kerja pembaikan anda berkemungkinan besar perlu mengurangkan bilangan PG, dan ciri ini tidak tersedia dalam versi Ceph yang lebih lama (ia hanya muncul dalam versi Nautilus).

Jadi, mari bayangkan gambar berikut: kluster mempunyai status HEALTH_WARN disebabkan salah satu OSD kehabisan ruang. Ini akan ditunjukkan oleh ralat HEALTH_WARN: 1 near full osd. Di bawah ialah algoritma untuk keluar dari situasi ini.

Pertama sekali, anda perlu mengedarkan data yang tersedia antara OSD yang tinggal. Kami telah melakukan operasi yang sama dalam kes pertama, apabila kami "mengalirkan" nod - dengan satu-satunya perbezaan yang kini kami perlu mengurangkan sedikit reweight. Contohnya, sehingga 0.95:

ceph osd reweight osd.${ID} 0.95

Ini membebaskan ruang cakera dalam OSD dan membetulkan ralat dalam kesihatan ceph. Walau bagaimanapun, seperti yang telah disebutkan, masalah ini berlaku terutamanya disebabkan oleh konfigurasi Ceph yang salah pada peringkat awal: adalah sangat penting untuk membuat konfigurasi semula supaya ia tidak muncul pada masa hadapan.

Dalam kes khusus kami, semuanya datang kepada:

• nilai terlalu tinggi replication_count di salah satu kolam,
• terlalu banyak PG dalam satu kolam dan terlalu sedikit dalam kolam lain.

Mari gunakan kalkulator yang telah disebutkan. Ia jelas menunjukkan apa yang perlu dimasukkan dan, pada dasarnya, tidak ada yang rumit. Setelah menetapkan parameter yang diperlukan, kami mendapat cadangan berikut:

Nota: Jika anda menyediakan gugusan Ceph dari awal, satu lagi fungsi berguna kalkulator ialah penjanaan arahan yang akan mencipta kumpulan dari awal dengan parameter yang dinyatakan dalam jadual.

Lajur terakhir membantu anda menavigasi - Kiraan PG yang dicadangkan. Dalam kes kami, yang kedua juga berguna, di mana parameter replikasi ditunjukkan, kerana kami memutuskan untuk menukar pengganda replikasi.

Jadi, mula-mula anda perlu menukar parameter replikasi - ini patut dilakukan terlebih dahulu, kerana dengan mengurangkan pengganda, kami akan mengosongkan ruang cakera. Apabila arahan itu dilaksanakan, anda akan melihat bahawa ruang cakera yang tersedia akan meningkat:

ceph osd pool $pool_name set $replication_size

Dan selepas selesai, kami menukar nilai parameter pg_num и pgp_num seperti berikut:

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

Ia adalah penting: kita mesti menukar bilangan PG secara berurutan dalam setiap kumpulan dan tidak menukar nilai dalam kumpulan lain sehingga amaran hilang "Lewahan data terdegradasi" и "n-bilangan pgs terdegradasi".

Anda juga boleh menyemak sama ada semuanya berjalan lancar menggunakan output arahan ceph health detail и ceph -s.

Kes No. 3. Memindahkan mesin maya daripada LVM kepada Ceph RBD

Dalam situasi di mana projek menggunakan mesin maya yang dipasang pada pelayan bare-metal yang disewa, isu storan tahan kesalahan sering timbul. Ia juga sangat wajar bahawa terdapat ruang yang mencukupi dalam storan ini... Satu lagi situasi biasa: terdapat mesin maya dengan storan tempatan pada pelayan dan anda perlu mengembangkan cakera, tetapi tidak ada tempat untuk pergi, kerana tidak ada ruang cakera kosong yang ditinggalkan pada pelayan.

Masalahnya boleh diselesaikan dengan cara yang berbeza - contohnya, dengan berhijrah ke pelayan lain (jika ada) atau menambah cakera baharu ke pelayan. Tetapi ia tidak selalu boleh dilakukan, jadi berhijrah dari LVM ke Ceph boleh menjadi penyelesaian terbaik untuk masalah ini. Dengan memilih pilihan ini, kami juga memudahkan proses pemindahan selanjutnya antara pelayan, kerana tidak akan ada keperluan untuk mengalihkan storan setempat dari satu hipervisor ke yang lain. Satu-satunya tangkapan ialah anda perlu menghentikan VM semasa kerja sedang dijalankan.

Resipi berikut diambil dari artikel dari blog ini, arahan yang telah diuji dalam tindakan. By the way, kaedah migrasi tanpa kerumitan juga diterangkan di sana, bagaimanapun, dalam kes kami ia tidak diperlukan, jadi kami tidak menyemaknya. Jika ini penting untuk projek anda, kami akan gembira mendengar tentang keputusan dalam ulasan.

Mari kita beralih ke bahagian praktikal. Dalam contoh kita menggunakan virsh dan, dengan itu, libvirt. Mula-mula, pastikan kolam Ceph tempat data akan dipindahkan disambungkan ke libvirt:

virsh pool-dumpxml $ceph_pool

Perihalan kumpulan mesti mengandungi data sambungan ke Ceph dengan data kebenaran.

Langkah seterusnya ialah imej LVM ditukar kepada Ceph RBD. Masa pelaksanaan bergantung terutamanya pada saiz imej:

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

Selepas penukaran, imej LVM akan kekal, yang akan berguna jika pemindahan VM ke RBD gagal dan anda perlu melancarkan semula perubahan. Selain itu, untuk dapat melancarkan perubahan dengan cepat, mari buat sandaran fail konfigurasi mesin maya:

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

... dan edit yang asal (vm_name.xml). Mari cari blok dengan penerangan cakera (bermula dengan baris <disk type='file' device='disk'> dan berakhir dengan </disk>) dan kurangkan kepada 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 lihat beberapa butiran:

1. Kepada protokol source alamat ke storan dalam Ceph RBD ditunjukkan (ini adalah alamat yang menunjukkan nama kolam Ceph dan imej RBD, yang ditentukan pada peringkat pertama).
2. Di blok secret jenis ditunjukkan ceph, serta UUID rahsia untuk menyambung kepadanya. uuidnya boleh didapati menggunakan arahan virsh secret-list.
3. Di blok host alamat kepada pemantau Ceph ditunjukkan.

Selepas mengedit fail konfigurasi dan melengkapkan penukaran LVM kepada RBD, anda boleh menggunakan fail konfigurasi yang diubah suai dan memulakan mesin maya:

virsh define $vm_name.xml
virsh start $vm_name

Sudah tiba masanya untuk menyemak sama ada mesin maya dimulakan dengan betul: anda boleh mengetahui, sebagai contoh, dengan menyambung kepadanya melalui SSH atau melalui virsh.

Jika mesin maya berfungsi dengan betul dan anda tidak menemui sebarang masalah lain, maka anda boleh memadamkan imej LVM yang tidak lagi digunakan:

lvremove main/$vm_image_name

Kesimpulan

Kami menemui semua kes yang diterangkan dalam amalan - kami berharap arahan itu akan membantu pentadbir lain menyelesaikan masalah yang sama. Jika anda mempunyai ulasan atau cerita lain yang serupa daripada pengalaman anda menggunakan Ceph, kami akan gembira melihatnya dalam ulasan!

PS

Baca juga di blog kami:

• «Tangan kami bukan untuk kebosanan: memulihkan gugusan Rook dalam K8s»;
• «Kepada Rook atau tidak kepada Rook - itulah persoalannya»;
• «Rook - gudang data "layan diri" untuk Kubernetes»;
• «Mencipta storan berterusan dengan peruntukan dalam Kubernetes berdasarkan Ceph'.

Sumber: www.habr.com