Merhaba;
“Ceph Storage” hakkında ilk yazıma https://www.linkedin.com/pulse/red-hat-ceph-storage-asiye-yigit/?trackingId=LZwiZkdOS1OAq7acsrY9mQ%3D%3D adresinden ulaşabilirsiniz. Bu yazımı okumaya başlamadan önce lütfen ilk yazımı okuyun çünkü bu yazıda geçen terimlerin detayına ilk yazımda değindim. Aksi halde, bu yazıyı anlamakta güçlük çekebilirsiniz.
Bu ikinci bölüme “Pool” kavramıyla başlayacağım. Tükçesi için “havuz” kelimesini kullanıyor olacağım. Ceph havuzları, nesnelerin mantıksal olarak gruplanmasıyla oluşturulur. İki tür havuz vardır. Birincisi çoğaltılmış havuzlar (“replicated pools”), diğeri ise silme kodlu havuzlarlar (“erasure coded pools”). Havuzları oluştururken, yerleşim gruplarının sayısını (“placement groups”), kopya yani replika sayısını, “CRUSH” kuralını belirtmemiz gerekmektedir. Ceph, nesneleri yerleşim gruplarına (PG’lere) eşler. Yerleşim gruplarını ifade ederken, PG kısaltmasını kullanacağım. PG’ler, mantıksal nesne havuzunun parçalarıdır. Havuz mantığıyla, aslında farklı amaçlarla kullanacağınız depolama alanlarını oluşturmuş oluyorsunuz. Diğer bir deyişle, veriyi birbirinden ayırmış oluyorsunuz. Örneğin Şekil 1.’de bulut olarak çizilen yapıyı “Ceph Cluster” gibi düşünelim. Bu “Cluster” yapısını, havuzlara bölelim. Havuz oluştururken, Şekil 1.’den gördüğünüz gibi, PG sayısını, neslere ait kaç kopya tutacağınızı (replika sayısını) ve PG’lerin olduğu OSD’leri listelememize olanak sağlayan “CRUSH” kuralını belirtmemiz gerekmektedir. Mesela “POOL1”i, “Cinder Virtual Machine Block Device”lar için, “POOL2”yi, “Openstack Glance RBD Images” için, “POOL3”ü, RADOSGW, yani S3 ve Swift desteği için kullanmak isteyebilirsiniz. “CRUSH” algoritması, nesneye ait verinin ve replikalarının “cluster” içinde nerde tutulacağını belirlemektedir.
Şekil 1. Havuz mantığı ve havuzu oluştururken belirtmeniz gereken bilgiler.
Bir havuz içinde PG’lerin sayısını doğru belirleyebilmek çok önemlidir.
ceph osd pool create {pool-name} pg_num
Havuz oluştururken kullanacağımız komut ile belirleyeceğimiz “pg_num” sayısının ne olması gerektiğiyle ilgili https://docs.ceph.com/docs/mimic/rados/operations/placement-groups/ adresi incelenebilir.
“Cluster” içinde OSD sayısı, 5 OSD’den az olduğunda, pg_num’un 128 olması önerilmektedir. “Cluster” içinde olan OSD sayısı, 5 – 10 arası ise, pg_num’un 512 olması önerilmektedir. 50’den fazla OSD için pg_num değerinin dikkatlice belirlenmesi gerekmektedir. Doğru hesaplama yapabilmeniz için https://ceph.com/pgcalc/ adresinde olan formülleri kullanabilirsiniz. Örneğin, ben aşağıdaki şekilde bir hesap yaptım, örnek olması açısından.
Şekil 2. Örnek PG sayısının belirlenmesi.
Şekil 2.’de “Size” olarak gördüğünüz, havuzda tutacağınız replika yani kopya sayısını göstermektedir. “%Data”, verinin %’de kaçını ilgili havuzda tutacaksınız bilgisini göstermektedir. Yeşil renkte olan değerlerin girişini yaptıktan sonra, önerilen PG sayısını elde edebilirsiniz.
“Cluster” boyutuna göre eğer PG sayısı çok az ise, PG başına çok fazla veri tutmanız gerekir ve bu durum, “Ceph Storage” performansını kötü yönde etkiler. Diğer taraftan “Cluster” boyutuna göre çok fazla PG varsa, OSD’ler çok fazla CPU ve Memory kullanır ve sonucu olarakta iyi performans göremezsiniz. Neden PG sayısını doğru belirlemenin, “Ceph Storage” performansı için önemli olduğunu bu örneklemelerden anlayabiliriz.
Şekil 3.’de, nesne, PG ve havuz arasındaki ilişkiyi görebilirsiniz.
Şekil 3. Nesne, PG ve havuz arasındaki ilişki.
Bir nesnenin, OSD’ye yazılım sırası nasıl oluyor? Şekil 4. Üzerinden bu süreci aktarmak istiyorum. Öncelikle, Ceph istemci, nesneyi alıyor ve Ceph havuzuna yazıyor. Ardından, “CRUSH” algoritması, bu nesneyi bir PG’ye atıyor. Ardından, “CRUSH” algoritması bu PG’yi fiziksel olarak verinin tutulduğu OSD’ye atıyor. https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/1.3/html/storage_strategies_guide/placement_groups_pgs
Şekil 4. Ceph istemcinin bir nesneyi, OSD’ye ataması süreci.
Bu örnekte, “CRUSH” kuralına göre, birincil OSD’nin OSD 5 olduğunu düşünelim. Eğer “CRUSH”, tutulacak 3 kopya için, ikincil OSD’leri OSD 1 ve OSD 8 olarak belirlerse, birincil OSD 5, veriyi OSD 1 ve OSD 8’e kopyalar, Şekil 5.
Şekil 5. PG’nin birincil OSD’ye yazıldıktan sonra, birincil OSD’nin ikinci OSD’lere (OSD 1 ve OSD 8) veriyi kopyalaması.
Ceph Storage’ın yeni sürümü önbellek katmanını da desteklemektedir. Önbellek katmanında , SSD gibi yüksek performans sağlayabilen diskler kullanabilirsiniz. “Backend” tarafında SAS diskleri kullanırken, önbellek tarafında SSD diskleri kullanarak, okuma ve yazma işlemlerini hızlandırabilirsiniz.
“Replicated I/O” metodolojisinden daha detaylı bahsetmek istiyorum. Ceph OSD’ler, güncel “cluster” haritasını Ceph MON’lardan alır. Ceph OSD’ler, nesnelerin kopyalarını nerde tutmaları gerektiğini hesaplamak için “CRUSH” algortimasını kullanırlar. Tipik bir yazma senaryosunda, Ceph istemci, “Acting set” içindeki birincil OSD’yi belirlemek ve PG ID’yi bulmak için “CRUSH” algoritmasını kullanır. İstemci, nesneyi birincil OSD’ye yazdığı zaman, birincil OSD, kaç tane kopya, replika yazacağını bulur (osd_pool_default_size = n). Ardından, birincil OSD, nesne ID’sini, havuz ismini ve “cluster” haritasını alarak ve “CRUSH” algoritmasını kullanarak “acting set” için ikinci OSD’lerin ID’lerini belirler. Birincil OSD, nesneleri, ikincil OSD’lere yazar. Birincil OSD, ikincil OSD’lerden yazma işlemi tamamlandığına dair bilgilendirme aldıktan sonra birincil OSD, yazma operasyonunu tamamlamış olur. Ardından, Ceph istemciyi yazma işlemi başarılı oldu şeklinde bilgilendirir (Şekil 6.).
Şekil 6. Replicated I/O
Silme kodu “Erasure Code” I/O detayına bakacak olursak, bu I/O sürecinde “Reed Solomon” algoritması kullanılır. Bu algoritmayı, N=K+M eşitliğini kullanarak aktarmaya çalışacağım. Eşitlikte olan “M”, hatalardan korunmak için fazladan eklenen parçaları (“chunks”) ifade eder. “N” ise, silme kodlu süreç sonrası toplam parça sayısını (“chunk”) ifade eder. Bu durumda, “N-K” adet parçayı (“chunk”), “K” adet orjinal parçadan elde edebilirim. Yani, “K” adet parça fonksiyonel olduğu müddetçe, original veriye ulaşabiliriz. Sistem, “N-K” adet hatayı tolere edebilir. Örneğin, “K=10” ve “N=16” olan bir konfigürasyonda, veya silme kodunun “10/16” olduğu bir yapıda, 6 ek parça “chunk”, original parça “chunk” sayısına (K=10) eklenecektir. 16 adet veri parçası, 16 OSD’ye yayılacak ve 6 adet OSD hata verse bile, kalan 10 adet veri parçasından, original dosya inşa edilebilecektir.
Bir örnek üzerinden gidelim. Silme kodlu havuzumuz 5 adet OSD’den oluşsun ve 2 adet OSD hata verse bile, hayatına devam edebilsin. K+M=N eşitliğine göre, K+M=5 ve M=2. Yani silme kodu “3/5=K/N”. Şekil 7., bu örnek için Silme kodlu I/O nun ne şekilde gerçekleştiğini göstermektedir. OSD 3 ve OSD 4, yapıya, sağlanması istenen hata toleransına göre eklenen fazla OSD’lerdir.
Şekil 7. Silme kodlu I/O (“Erasure Coding”)
Silme kodlu havuzlar sadece, “RADOS Gateway” ile desteklenmektedir. Silme kodlu havuzlar, “RADOS Block Device RBD”yi desteklemez.
Yazımı burda tamamlıyorum. Biraz teorik gittiğimi düşünüyor olabilirsiniz. Fakat, teoriyi iyi anladıktan sonra, komutlarla doğru konfigürasyonu yapabilmek çok daha kolay olacaktır. Ne yaptığımızı daha iyi anlayarak ilerlemiş olacağız. İlerleyen yazılarımda teoriyi tam oturttuktan sonra komutlara da giriş yapıyor olacağım. Ama önce “Ceph” in çalışma mantığını, bileşenlerini çok iyi anlamamız gerekiyor.
Asiye Yiğit – 29 Mart 2020 Pazar
Yararlandığım Kaynaklar:
https://subscription.packtpub.com/book/virtualization_and_cloud/9781788391061/2
http://dachary.org/loic/ceph-doc/architecture/
https://www.marksei.com/ceph-pools-beginners-guide/
https://docs.ceph.com/docs/mimic/rados/operations/placement-groups/
https://event.webinarjam.com/registration/thank-you/1/znnzxixt31wma630mco5ro
Leave A Comment