CEPH Genel Bilgiler

CEPH Bluestore & Filestore

Filestore

İlk olarak şunu söyleyerek başlayayım, bluestore yeni depolama backend. Dolayısı ile güncel bir sürüm kullanıyor iseniz (Luminous v12.2.z sonrası) zaten atanmış değer olarak bluestore kullanıyor olacaksınız (filestore kullanma seçeneğiniz hala mevcut)

Filestore ve Bluestore farkını anlamak için ilk olarak ilk olarak eski sistem olan filestore’u inceleyerek başlıyalım. CEPH objeleri eğer Filestore kullanırsanız bir POSIX uyumlu bir dosya sistemi üzerinde (genellikle XFS) dosya olarak saklanmakta. Bu durumun avantajlarını/dezavantajlarını sıralayacak olur isek filestore:

• Uzun zamandır kullanıldığı için kararlı
• Metadata (anahtar/değer çifletleri) dosya sisteminde levelDB üzerine tutuluyor.
• PG’ler dizin, nesneler dosya olarak map edilmiş durumda
• Çok fazla kişi tarafından kullanıldığı için bir sorun çıktığında çözüm bulma olasılığınız fazla

• Veriler iki kez yazıldığı için yavaş (bluestore ile karşılaştırıldığına)
• Enumaration problemleri var. CEPH nesne isimlendirmesini 32-bitlik hash olarak tutuyor, Posix readdir() dizin içindeki dosyaları sıralı vermediği için çok fazla dosya yaratılıp okunduğunda performans sorunlarına neden oluyor. Bunun direkt etkisi cluster obje sayısı arttıkça performansın yavaşlaması.
• Yüksek CPU gücü gerektirmesi

Peki filestore kullandığınızda veri nasıl okuyup yazılıyor ?

1. Ceph veriyi ilk olarak journal olarak tanımlanan diskin ayrı bir bölümüne yazar
2. Veri daha sonra journal’dan OSD’ye sıralı (sequential) kopyalanır
   1. Journal olarak SSD kullanımı ile hızlandırılabilir.
   2. Rastgele I/O istekleri SSD ile karşılanıp SSD’den OSD’ye yazılır
3. Veri ilk olarak birincil (Primary) PG’ye yazılır, oradan diğer (non-primary) PG’lere kopyalanır.

Bu yazdıklarımızın grafiksel olarak aşağıdaki şekilde gösterebiliriz.

Bu durumun en bariz problemi verinin iki kez (bir kez disk journal kısmına bir kez de yazılması). Atanmış değer olarak iki kopya daha tuttuğunuz düşünüldüğünde tek bir yazma işlemi için toplamda kopyalar ile yapılan işlemler ile birlikte 6 işlem yapmış olmanız gerekiyor!. Bu durumu hızlandırmak için journal olarak mümkün olduğu sürece ayrı SSD diskler kullanmanız tavsiye ediliyor. Yapılandırma sırasında bir 5 veya 6 dönen disk başına 1 SSD journal disk olarak bıraklıp bu dezavantaj giderilmeye çalışılıyor. Peki 5 veya 6 rakamı nereden geliyor diye soracaksınız. 1 adet diskin yazma hızının oralama 100MByte/saniye olduğu düşünüldüğünde SSD okuma hızlarıda 500-600MByte/saniye. Tüm diskleri aynı anda tam kapasite ile yazmak isterseniz 6 disk önerilen değer bu neden ile. Peki 8 disk takarsak ne olur ? IOPS ta bir sıkışma olmaz ama througputh açısından bir diska yazabileceğiniz maksimum anlıkveri miktarını 600/8 = 75MByte ile sınırlamış olursunuz.

Bluestore (Block + NewStore)

Bluestore tasarlanırken Filestore’da karşılaşılan problemlerin yaşanmaması için bazı değişikliklere gidilmiş.Filestore’dan en önemli farkının posix uyumlu bir dosya sistemi kullanılmaması

• Yeni nesi daha hızlı NVM-e benzeri diskler düşünülerek tasarlandı
• Veri artık dosya sistemine değil raw olarak blok device’a yazılıyor. Dolayısı ile verileri yazmak için xfs benzeri bir dosya sistemine ihtiyaç duymuyorsunuz.
• Metadata verisinin tutulması için LevelDB yerinde RocksDB kullanılıyor
• RocksDB verisini yazmak için dosya sistemi benzeri bir yapıya ihtiyaç duyduğu için metadata verisinin tutulması için BlueFS isminde sadece gerekli dosya sistemi fonksiyonların implemente edildiği bir dosya sistemi tasarlanmış.
• Data ve metadata normal şartlarda aynı diskte saklanıyor, istenirse metadata kısmı başka bir alanda tutulabiliyor. (DB ve WAL kısmı ayrılabiliyor)
• Data Sıkıştırma desteği geliyor
• Okuma isteklerine checksum desteği geliyor. (Filestore da diske yazılan verinin bozlup bozulmadığını pahalı bir operasyon olan scrub ile takip ediliyordu)

Blurstore'un grafiksel göstermi aşağıdaki şekilde.