Yoğun projelerde Ceph ile çalışmaya yönelik ipuçları ve püf noktaları

Farklı yüklere sahip projelerde Ceph'i ağ depolama alanı olarak kullandığımızda, ilk bakışta basit veya önemsiz görünmeyen çeşitli görevlerle karşılaşabiliriz. Örneğin:

• yeni kümedeki önceki sunucuların kısmen kullanılmasıyla verilerin eski Ceph'ten yenisine taşınması;
• Ceph'te disk alanı tahsisi sorununa çözüm.

Bu tür sorunlarla uğraşırken, OSD'yi veri kaybı olmadan doğru şekilde kaldırma ihtiyacıyla karşı karşıya kalıyoruz, bu özellikle büyük miktarda veriyle uğraşırken önemlidir. Bu makalede tartışılacaktır.

Aşağıda açıklanan yöntemler Ceph'in herhangi bir sürümü için geçerlidir. Ayrıca Ceph'in büyük miktarda veri depolayabildiği gerçeği de dikkate alınacak: veri kaybını ve diğer sorunları önlemek için bazı eylemler diğerlerine "bölünecek".

OSD hakkında önsöz

Tartışılan üç tariften ikisi OSD'ye ayrılmış olduğundan (Nesne Depolama Programı), pratik kısma dalmadan önce - kısaca Ceph'te ne olduğu ve neden bu kadar önemli olduğu hakkında.

Öncelikle Ceph kümesinin tamamının birçok OSD'den oluştuğunu söylemek gerekiyor. Ne kadar çok olursa Ceph'teki boş veri hacmi de o kadar büyük olur. Buradan anlaşılması kolay ana OSD işlevi: Ceph nesne verilerini tüm küme düğümlerinin dosya sistemlerinde saklar ve buna ağ erişimi sağlar (okuma, yazma ve diğer istekler için).

Aynı düzeyde, çoğaltma parametreleri, nesnelerin farklı OSD'ler arasında kopyalanmasıyla ayarlanır. Ve burada çözümleri aşağıda tartışılacak olan çeşitli sorunlarla karşılaşabilirsiniz.

1 numaralı vaka. Veri kaybı olmadan OSD'yi Ceph kümesinden güvenle kaldırın

OSD'yi kaldırma ihtiyacı, sunucunun kümeden çıkarılmasından - örneğin başka bir sunucuyla değiştirilmesinden - kaynaklanıyor olabilir ki, bu da bizim başımıza geldi ve bu makalenin yazılmasına neden oldu. Bu nedenle, manipülasyonun nihai amacı, belirli bir sunucudaki tüm OSD'leri ve monları çıkarıp durdurulabilmesini sağlamaktır.

Kolaylık sağlamak ve komutları yürütürken gerekli OSD'yi belirtirken hata yaptığımız bir durumu önlemek için, değeri silinecek OSD'nin numarası olacak ayrı bir değişken ayarlayacağız. Hadi onu arayalım ${ID} — burada ve aşağıda böyle bir değişken, üzerinde çalıştığımız OSD numarasının yerini alır.

Çalışmaya başlamadan önce duruma bakalım:

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

OSD kaldırma işlemini başlatmak için sorunsuz bir şekilde gerçekleştirmeniz gerekir. reweight sıfıra kadar. Bu şekilde OSD'deki veri miktarını diğer OSD'lerle dengeleyerek azaltıyoruz. Bunu yapmak için aşağıdaki komutları çalıştırın:

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

... vb. sıfıra kadar devam eder.

Düzgün dengeleme gerekliVeri kaybetmemek için. Bu özellikle OSD'nin büyük miktarda veri içermesi durumunda geçerlidir. Komutları yürüttükten sonra emin olmak için reweight her şey yolunda gitti, tamamlayabilirsin ceph -s veya ayrı bir terminal penceresi çalıştırmasında ceph -w Değişiklikleri gerçek zamanlı olarak gözlemlemek için.

OSD "boşaltıldığında", onu çıkarmak için standart işleme devam edebilirsiniz. Bunu yapmak için istenen OSD'yi duruma aktarın down:

ceph osd down osd.${ID}

OSD'yi kümenin dışına "çekelim":

ceph osd out osd.${ID}

OSD hizmetini durduralım ve FS'deki bölümünün bağlantısını keselim:

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

OSD'yi şuradan kaldır: EZME haritası:

ceph osd crush remove osd.${ID}

OSD kullanıcısını silelim:

ceph auth del osd.${ID}

Son olarak OSD'nin kendisini kaldıralım:

ceph osd rm osd.${ID}

Dikkat: Ceph Luminous sürümünü veya daha üstünü kullanıyorsanız yukarıdaki OSD kaldırma adımları iki komuta indirgenebilir:

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

Yukarıda açıklanan adımları tamamladıktan sonra komutu çalıştırırsanız ceph osd tree, o zaman işin yapıldığı sunucuda, yukarıdaki işlemlerin gerçekleştirildiği OSD'lerin artık bulunmadığı açık olmalıdır:

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

Yol boyunca Ceph kümesinin durumunun değişeceğini unutmayın. HEALTH_WARNAyrıca OSD sayısında ve kullanılabilir disk alanı miktarında da bir azalma göreceğiz.

Sunucuyu tamamen durdurmak ve buna göre Ceph'ten kaldırmak istiyorsanız gerekli olacak adımlar aşağıda açıklanacaktır. Bu durumda şunu hatırlamak önemlidir. Sunucuyu kapatmadan önce tüm OSD'leri kaldırmalısınız bu sunucuda.

Bu sunucuda başka OSD kalmadıysa, bunları kaldırdıktan sonra sunucuyu OSD haritasından hariç tutmanız gerekir. hv-2aşağıdaki komutu çalıştırarak:

ceph osd crush rm hv-2

kaldırmak mon sunucudan hv-2aşağıdaki komutu başka bir sunucuda çalıştırarak (yani bu durumda, hv-1):

ceph-deploy mon destroy hv-2

Bundan sonra sunucuyu durdurabilir ve sonraki işlemlere (yeniden konuşlandırma vb.) başlayabilirsiniz.

2 numaralı vaka. Önceden oluşturulmuş bir Ceph kümesindeki disk alanının dağıtımı

İkinci hikayeye PG hakkında bir önsözle başlayacağım (Yerleşim Grupları). PG'nin Ceph'teki ana rolü öncelikle Ceph nesnelerini toplamak ve bunları OSD'de çoğaltmaktır. Gerekli PG miktarını hesaplayabileceğiniz formül ilgili bölüm Ceph belgeleri. Bu konu orada da spesifik örneklerle tartışılıyor.

Yani: Ceph kullanırken sık karşılaşılan sorunlardan biri, Ceph'teki havuzlar arasındaki dengesiz OSD ve PG sayısıdır.

İlk olarak, bu nedenle, küçük bir havuzda çok fazla PG belirtildiğinde, aslında kümedeki disk alanının mantıksız bir kullanımı olan bir durum ortaya çıkabilir. İkincisi, pratikte daha ciddi bir sorun var: OSD'lerden birinde veri taşması. Bu, kümenin ilk olarak duruma geçişini gerektirir HEALTH_WARN, ve daha sonra HEALTH_ERR. Bunun nedeni Ceph'in mevcut veri miktarını hesaplarken (bunu şu adresten öğrenebilirsiniz: MAX AVAIL komut çıkışında ceph df her havuz için ayrı ayrı) OSD'deki mevcut veri miktarına bağlıdır. En az bir OSD'de yeterli alan yoksa, veriler tüm OSD'ler arasında düzgün şekilde dağıtılıncaya kadar daha fazla veri yazılamaz.

Bu sorunları açıklamakta fayda var. büyük ölçüde Ceph kümesi yapılandırma aşamasında karar verilir. Kullanabileceğiniz araçlardan biri Ceph PGCalc. Onun yardımıyla gerekli PG miktarı açıkça hesaplanır. Ancak Ceph kümesinin bozulduğu bir durumda da buna başvurabilirsiniz. zaten yanlış yapılandırılmış. Düzeltme çalışmasının bir parçası olarak büyük olasılıkla PG sayısını azaltmanız gerekeceğini ve bu özelliğin Ceph'in eski sürümlerinde mevcut olmadığını burada açıklığa kavuşturmakta fayda var (yalnızca sürümde görünüyordu). Nautilus).

Şimdi şu resmi hayal edelim: kümenin bir durumu var HEALTH_WARN OSD'lerden birinde yer kalmaması nedeniyle. Bu bir hatayla gösterilecektir HEALTH_WARN: 1 near full osd. Aşağıda bu durumdan çıkmak için bir algoritma bulunmaktadır.

Öncelikle mevcut verileri kalan OSD'ler arasında dağıtmanız gerekir. İlk durumda, düğümü "boşalttığımızda" zaten benzer bir işlem gerçekleştirdik - tek fark, şimdi biraz azaltmamız gerekecek reweight. Örneğin, 0.95'e kadar:

ceph osd reweight osd.${ID} 0.95

Bu, OSD'deki disk alanını boşaltır ve sef sağlığındaki hatayı düzeltir. Ancak, daha önce de belirtildiği gibi, bu sorun esas olarak Ceph'in ilk aşamalarda yanlış yapılandırılmasından kaynaklanmaktadır: gelecekte ortaya çıkmaması için yeniden yapılandırma yapmak çok önemlidir.

Bizim özel durumumuzda her şey şuna geldi:

• değer çok yüksek replication_count havuzlardan birinde,
• bir havuzda çok fazla PG, diğerinde ise çok az.

Daha önce bahsedilen hesap makinesini kullanalım. Neyin girilmesi gerektiğini açıkça gösterir ve prensip olarak karmaşık bir şey yoktur. Gerekli parametreleri ayarladıktan sonra aşağıdaki önerileri alıyoruz:

Dikkat: Sıfırdan bir Ceph kümesi kuruyorsanız, hesap makinesinin bir diğer kullanışlı işlevi de tabloda belirtilen parametrelerle sıfırdan havuzlar oluşturacak komutlar oluşturmaktır.

Son sütun gezinmenize yardımcı olur - Önerilen PG Sayısı. Bizim durumumuzda, çoğaltma çarpanını değiştirmeye karar verdiğimiz için çoğaltma parametresinin belirtildiği ikincisi de kullanışlıdır.

Bu nedenle, önce çoğaltma parametrelerini değiştirmeniz gerekir - bu ilk önce yapmaya değer, çünkü çarpanı azaltarak disk alanını boşaltacağız. Komut yürütüldükçe kullanılabilir disk alanının artacağını fark edeceksiniz:

ceph osd pool $pool_name set $replication_size

Ve tamamlandıktan sonra parametre değerlerini değiştiriyoruz pg_num и pgp_num следующим обрахом:

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

Bu çok önemli: Her havuzdaki PG sayısını sırayla değiştirmeli ve uyarılar ortadan kalkana kadar diğer havuzlardaki değerleri değiştirmemeliyiz "Kötü veri artıklığı" и "n-sayfa sayısı bozuldu".

Komut çıktılarını kullanarak her şeyin yolunda gittiğini de kontrol edebilirsiniz. ceph health detail и ceph -s.

3 numaralı vaka. Bir sanal makineyi LVM'den Ceph RBD'ye geçirme

Bir projenin, kiralanan yalın donanım sunuculara kurulu sanal makineleri kullandığı bir durumda, hataya dayanıklı depolama sorunu sıklıkla ortaya çıkar. Bu depolamada yeterli alanın olması da çok arzu edilir... Diğer bir yaygın durum: sunucuda yerel depolamaya sahip bir sanal makine var ve diski genişletmeniz gerekiyor, ancak gidecek hiçbir yer yok çünkü sunucuda kalan boş disk alanı.

Sorun farklı şekillerde çözülebilir - örneğin başka bir sunucuya geçerek (varsa) veya sunucuya yeni diskler ekleyerek. Ancak bunu yapmak her zaman mümkün olmadığından LVM'den Ceph'e geçiş bu soruna mükemmel bir çözüm olabilir. Bu seçeneği seçerek, yerel depolamayı bir hipervizörden diğerine taşımaya gerek kalmayacağından, sunucular arasında daha sonraki geçiş sürecini de basitleştiriyoruz. Tek sorun, iş yürütülürken VM'yi durdurmanız gerekmesidir.

Aşağıdaki tarif alıntıdır bu blogdan makale, talimatları çalışırken test edilmiştir. Bu arada, Sorunsuz geçiş yöntemi de burada açıklanmaktadırancak bizim durumumuzda buna gerek yoktu, bu yüzden kontrol etmedik. Bu, projeniz için kritikse, sonuçları yorumlarda duymaktan memnuniyet duyarız.

Pratik kısma geçelim. Örnekte virsh ve buna göre libvirt kullanıyoruz. Öncelikle verilerin taşınacağı Ceph havuzunun libvirt'e bağlı olduğundan emin olun:

virsh pool-dumpxml $ceph_pool

Havuz açıklaması, yetkilendirme verileriyle birlikte Ceph'e bağlantı verilerini içermelidir.

Bir sonraki adım, LVM görüntüsünün Ceph RBD'ye dönüştürülmesidir. Yürütme süresi öncelikle görüntünün boyutuna bağlıdır:

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

Dönüştürmeden sonra bir LVM görüntüsü kalacaktır; bu, VM'nin RBD'ye taşınması başarısız olursa ve değişiklikleri geri almanız gerekiyorsa faydalı olacaktır. Ayrıca değişiklikleri hızla geri alabilmek için sanal makine yapılandırma dosyasının yedeğini alalım:

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

... ve orijinali düzenleyin (vm_name.xml). Diskin açıklamasını içeren bir blok bulalım (satırla başlar) <disk type='file' device='disk'> ve ile biter </disk>) ve aşağıdaki forma düşürün:

<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>

Bazı ayrıntılara bakalım:

1. Protokole source Ceph RBD'deki depolamanın adresi belirtilir (bu, Ceph havuzunun adını ve ilk aşamada belirlenen RBD görüntüsünü gösteren adrestir).
2. blokta secret türü belirtildi cephve ona bağlanılacak sırrın UUID'si. Uuid'si şu komut kullanılarak bulunabilir: virsh secret-list.
3. blokta host Ceph monitörlerinin adresleri belirtilir.

Yapılandırma dosyasını düzenledikten ve LVM'den RBD'ye dönüştürme işlemini tamamladıktan sonra, değiştirilen yapılandırma dosyasını uygulayabilir ve sanal makineyi başlatabilirsiniz:

virsh define $vm_name.xml
virsh start $vm_name

Sanal makinenin doğru şekilde başlatıldığını kontrol etme zamanı geldi: örneğin, SSH veya aracılığıyla bağlanarak bunu öğrenebilirsiniz. virsh.

Sanal makine düzgün çalışıyorsa ve başka bir sorunla karşılaşmadıysanız artık kullanılmayan LVM görüntüsünü silebilirsiniz:

lvremove main/$vm_image_name

Sonuç

Açıklanan tüm durumlarla pratikte karşılaştık - talimatların diğer yöneticilerin benzer sorunları çözmelerine yardımcı olacağını umuyoruz. Ceph'i kullanma deneyiminize ilişkin yorumlarınız veya benzer hikayeleriniz varsa, bunları yorumlarda görmekten memnuniyet duyarız!

PS

Blogumuzda da okuyun:

• «Elimiz can sıkıntısı için değil: K8'lerdeki Kale kümesini eski haline getirmek";
• «Kaleye gitmek ya da kaleye girmemek - işte bütün mesele bu";
• «Rook - Kubernetes için "self servis" veri ambarı";
• «Ceph'e dayalı Kubernetes'te provizyonla kalıcı depolama oluşturma'.

Kaynak: habr.com