IBM, OpenSource

Ceph Mimarisi

Voiced by Amazon Polly
Ceph Mimarisi

Rados Birleşenleri

Ceph Mimarisi: RADOS (Reliable Autonomic Distributed Object Store), güvenilir, otonom ve dağıtık bir nesne depolama sistemidir. Bu sistem, büyük ölçekli, yüksek performanslı ve yüksek kullanılabilirlik gerektiren depolama ihtiyaçları için tasarlanmıştır. RADOS, aşağıdaki temel bileşenler kullanılarak inşa edilmiştir:

  • Monitörler
  • Nesne Depolama Aygıtları
  • Yöneticiler
  • Metadata Sunucuları

Monitörler

Monitörler, yani MONlar, küme durumunu yönetmekten sorumludur. Herhangi bir dağıtık depolama sisteminde olduğu gibi, zorluk, her küme bileşeninin (Monitörler, Yöneticiler, Nesne Depolama Aygıtları vb.) durumunu izlemektir. Ceph, küme durumunu, kolektif olarak küme haritası olarak adlandırılan özelleştirilmiş bir dizi harita aracılığıyla sürdürür. Her haritaya, epoch adı verilen benzersiz bir versiyon numarası atanır. Epoch 1’den başlar ve ilgili bileşen seti için her durum değişikliğinde 1 artar.

Monitörler, aşağıdaki haritaları sürdürür:

  • MON haritası
  • MGR haritası
  • OSD haritası
  • MDS haritası
  • PG haritası
  • CRUSH haritası

Harita güncellemelerinin bütünlüğünü ve tutarlılığını sağlamak için, Monitörler herhangi bir harita değişikliğini doğrulayıp uygulamadan önce birden fazla Monitör arasında uzlaşıya varmalarını sağlayan PAXOS algoritmasını kullanır. Bölünmüş beyin (split-brain) senaryolarını önlemek için, bir Ceph kümesinde dağıtılan Monitörlerin sayısı her zaman iki sayısından büyük ve tek bir sayı olmalıdır. Bu, Monitör Haritası’nda (MONMap) bulunan Monitörlerin yarısından fazlasının, haritanın güncellenmesi için PAXOS konsensüs lideri tarafından önerilen değişikliği onaylaması gerektiği anlamına gelir. Bu sayede, harita güncellemeleri üzerinde çoğunlukla Monitörler arasında bir anlaşma sağlanmış olur.

RADOS’un bu bileşenleri ve algoritmaları, yüksek düzeyde güvenilir ve tutarlı bir dağıtık depolama sistemi oluşturmak için birlikte çalışır. Sistem, verilerin güvenliğini ve erişilebilirliğini sağlamak, aynı zamanda dinamik olarak değişen küme durumlarına hızla uyum sağlamak için tasarlanmıştır. Bu, büyük veri setlerini yönetmek, yedeklemek ve arşivlemek için ideal bir platform sağlar.

Not: Monitörler veri yolunun parçası değildir; bu, veri depolama veya alma isteklerini doğrudan işlemedikleri anlamına gelir. Bunlar öncelikle küme meta verilerini korumak ve tüm bileşenleri senkronize tutmak için mevcuttur.

Yöneticiler: Ceph Kümesinin Yönetim Merkezi

Ceph depolama çözümünün temel bileşenlerinden biri de Yöneticilerdir. Kısaca MGR olarak adlandırılan Yöneticiler, Monitörlerle entegre bir şekilde çalışır ve kümeye ait istatistikleri toplarlar. Yöneticiler, kümenin yeteneklerini genişletmek için bir Python eklenti çerçevesi sunar. Bu çerçeve sayesinde, geliştiriciler veya son kullanıcılar, Yönetici çerçevesine yüklenecek Yönetici modülleri oluşturabilir veya mevcut modülleri kullanabilir.

Aşağıda, mevcut bazı Yönetici modüllerinin bir listesi bulunmaktadır:

  • Denkleştirici Modülü: (Yerleşim gruplarını daha iyi veri dağılımı için dinamik olarak OSD’lere yeniden atar).
  • Oto-ölçekleyici Modül: (Bir havuza atanan yerleşim gruplarının sayısını dinamik olarak ayarlar).
  • Gösterge Paneli Modülü: (Ceph kümesini izlemek ve yönetmek için bir kullanıcı arayüzü sağlar).
  • RESTful Modülü: (Küme yönetimi için RESTful API sağlar).
  • Prometheus Modülü: (Ceph kümesi için metrik destekleri sağlar).

Yönetici modülleri, Ceph kümelerinin yönetimini basitleştirmek ve kullanıcı deneyimini iyileştirmek için hayati öneme sahiptir. Geliştiriciler, bu modüller aracılığıyla küme performansını izleyebilir, veri dağılımını optimize edebilir ve sistem sağlığı hakkında detaylı bilgiler elde edebilirler. Ayrıca, RESTful ve Prometheus modülleri gibi araçlar, Ceph kümelerinin modern izleme ve yönetim araçlarıyla entegrasyonunu kolaylaştırır.

Bu modüler yaklaşım, Ceph’in esnekliğini ve ölçeklenebilirliğini artırırken, kullanıcıların ve geliştiricilerin ihtiyaç duydukları özellikleri özelleştirmelerine ve genişletmelerine olanak tanır. Sonuç olarak, Ceph depolama çözümü, büyük veri depolama ve yönetimi konusunda endüstri standartlarını belirleyen bir platform haline gelmiştir.

Nesne Depolama Aygıtları: RADOS Kümesinin Veri Depolama ve Yönetimi

RADOS kümesinin temel bileşenlerinden biri de Nesne Depolama Aygıtlarıdır. Genellikle Nesne Depolama Daemonları olarak da anılsa da, her zaman OSD olarak kısaltılırlar. Bu bileşen, RADOS’ta veri depolamak ve Ceph kümesi istemcilerinden gelen G/Ç (giriş/çıkış) isteklerine hizmet vermekten sorumludur.

OSD’ler aşağıdaki görevlerden sorumludur:

  • G/Ç isteklerine hizmet etmek.
  • Veriyi korumak (replikasyon veya silme kodlama modeli).
  • Arıza sonrası veriyi kurtarmak.
  • Küme genişletildiğinde veya küçültüldüğünde veriyi yeniden dengelemek.
  • Veri tutarlılığını kontrol etmek (scrubbing).
  • Bit çürümesini tespit etmek (derin scrubbing).

Her OSD, belirli bir yerleşim grubu için bir rol atanabilir:

  • Birincil OSD.
  • İkincil OSD.

Birincil OSD yukarıda belirtilen tüm fonksiyonları gerçekleştirirken, ikincil OSD her zaman bir birincil OSD’nin kontrolü altında hareket eder. Örneğin, belirli bir yerleşim grubu için bir yazma işlemi birincil OSD’ye geldiğinde, birincil OSD G/Ç’nin bir kopyasını bir veya daha fazla ikincil OSD’ye gönderir ve ikincil OSD, veriyi fiziksel ortama yazmak ve işlem tamamlandığında birincil OSD’ye bilgi vermekten tek başına sorumludur.

Not: OSD’lerin dağıtıldığı küme düğümüne OSD düğümü denir.

Çoğu durumda, her fiziksel sürücü başına bir Nesne Depolama Aygıtı dağıtılır.

OSD’ler, Ceph kümelerinin veri depolama ve yönetim yeteneklerinin temel taşını oluşturur. Veri koruma, kurtarma ve yeniden dengeleme gibi kritik işlevleri yerine getirerek, Ceph kümelerinin yüksek kullanılabilirlik ve dayanıklılık sunmasını sağlarlar. Her OSD’nin belirli roller üstlenmesi, veri yönetimini optimize etmeye ve küme genelinde yüksek performans sağlamaya yardımcı olur. Bu yapı, Ceph’in esnek, ölçeklenebilir ve güvenilir bir depolama çözümü olarak öne çıkmasını sağlar.

Ceph OSD Nesne Depolama Çözümleri: FileStore’dan BlueStore’a Evrim

Ceph’in erken dönemlerinde, OSD (Object Storage Device), FileStore adı verilen bir nesne depolama çözümü kullanıyordu. Bu çözüm, gerçek verileri depolamak için xfs formatında bir bölüm ve nesne deposu günlüğünü depolamak için ham bir bölüm kullanıyordu. Günlük, sıralı olarak yazılan bir ham cihaz olarak kaydediliyordu. Günlüğün rolleri arasında çoklu OSD’ler arası işlem atomikliğini garanti etmek ve sabit sürücülerin sıralı performansından faydalanmak yer alıyordu.

Piyasaya flaş tabanlı sürücüler çıktığında, yazma işlemlerinin performansını artırmak için günlüğü barındırmak üzere Katı Hal Sürücüsü (SSD) kullanmak en iyi uygulama haline geldi.

FileStore mimarisi

Ancak, çözümün karmaşıklığı ve her yazma işlemi için 2 yazım gerektirmesi nedeniyle oluşan yazma amplifikasyonu, Ceph projesinin gelecek için daha iyileştirilmiş bir çözümü düşünmesine neden oldu.

BlueStore

BlueStore, üst akım Luminous sürümünden (Red Hat Ceph Depolama 3.x) itibaren yeni varsayılan OSD nesne deposu formatıdır. BlueStore ile veriler doğrudan disk cihazına yazılırken, tüm metadata bir RocksDB anahtar-değer deposunda saklanır. Ham veri blok cihazına yazıldıktan sonra, RocksDB yeni yazılan veri blob’larıyla ilgili metadata ile güncellenir.

RocksDB, 2012 yılında Facebook’ta geliştirilen ve flaş tabanlı cihazlarla çok iyi performans gösteren yüksek performanslı bir anahtar-değer deposudur. RocksDB doğrudan bir ham blok cihazına yazamadığı için, .sst dosyalarını ham blok cihazında saklayabilmesi için RocksDB için bir sanal dosya sistemi (VFS) katmanı geliştirildi. Bu VFS katmanına BlueFS adı verildi.

RocksDB, bir DB kısmı ve bir yazı öncesi günlük (WAL) kısmı kullanır. G/Ç’nin boyutuna bağlı olarak, RocksDB veriyi doğrudan BlueFS aracılığıyla ham blok cihazına ya da daha sonra ham blok cihazına taahhüt edilecek WAL’ye yazabilir. Bu süreç, ertelenmiş yazma olarak bilinir.

BlueStore tanıtıldıkça, Ceph kümesine ek işlevler eklenir:

  • Erişim yönteminden bağımsız olarak OSD seviyesinde veri sıkıştırma.
  • Her okuma isteğinde checksumların doğrulanması.

BlueStore, FileStore’a göre aşağıdaki iyileştirmeleri sunar:

  • Verileri depolamak için doğrudan ham cihaza erişim sağlayarak ekstra dosya sistemi katmanının kaldırılması.
  • Fiziksel nesne konumunu daha hızlı bulmak için metadata’yı depolamak ve almak için RocksDB performansı.
  • Tam veri ve metadata checksum’u.
  • Ham blok cihazında daha verimli bir yazma üzerine kopyalama ile snapshot ve klon avantajı.
  • Birçok iş yükü için yazma amplifikasyonunu en aza indirir.
  • Cihaz türüne göre yapılandırılabilir ertelenmiş yazma eşiği. BlueStore, aşağıdaki düzenle çalışır:
  • Veri için bir cihaz (blok olarak adlandırılır).
  • Opsiyonel olarak, metadata için bir RocksDB cihazı (blok.db olarak adlandırılır).
  • Opsiyonel olarak, WAL için bir RocksDB cihazı (blok.wal olarak adlandırılır).

Metadata için ayrı bir cihaz yapılandırıldığında, metadata cihazı dolarsa metadata, veri cihazına taşabilir. Her iki cihaz aynı türdeyse bu bir sorun oluşturmaz, ancak veri cihazı metadata cihazından daha yavaşsa performans düşüşüne neden olur. Bu duruma BlueStore taşması denir.

BlueStore OSD’leri dağıtırken, aşağıdaki en iyi uygulamaları izleyin:

  • Aynı cihaz türünü kullanıyorsanız, örneğin tüm döner sürücüler için, yalnızca blok cihazını belirtin ve blok.db veya blok.wal’yi ayırmayın.
  • Hızlı ve yavaş cihazların (SSD / NVMe ve döner) karışımını kullanıyorsanız, blok.db için hızlı bir cihaz seçin, blok ise daha yavaş döner sürücüyü kullanır.

BlueStore, dinamik olarak ayarlanan bir önbellek mekanizması kullanır (bluestore_cache_autotune = 1). Önbellek otomatik ayarlaması etkinleştirildiğinde, OSD, OSD yığın bellek kullanımını osd_memory_target parametresine atanan değerin altında ve osd_memory_cache_min değerinin üzerinde tutmaya çalışır.

Gerekirse, önbellek boyutlandırması bluestore_cache_autotune parametresini 0 olarak ayarlayarak manuel olarak ayarlanabilir ve aşağıdaki parametreler OSD’nin BlueStore önbelleğine atanan önbellek boyutunun belirli bölümlerini ayırmak için ayarlanabilir:

  • cache_meta: BlueStore onode ve ilişkili verileri.
  • cache_kv: RocksDB blok önbelleği, indeksler ve filtreler dahil.
  • data_cache: Veri tamponları için BlueStore önbelleği.

Yukarıdaki parametreler, OSD’ye atanan önbellek boyutunun bir yüzdesi olarak ifade edilir.

BlueStore, iş yükünüzle en iyi şekilde uyum sağlaması için daha fazla özellik yapılandırmanıza olanak tanır:

  • block.db parçalama.
  • Veri cihazında minimum tahsis boyutu.

Biraz uzun bir yazı oldu ama umarım sonuna kadar okuya bilmişsinizdir. 🙂

Takipte kalmanız dileği ile.

Kaynakça: IBM Storage Ceph Concepts and Architecture Guide

Diğer IBM yazılarım için lütfen BURAYA TIKLAYINIZ.