Ceph kullanmmaya karar verdiniz ama nereden başlayacağınızı bilmiyorsunuz. Ya da Ceph’i incelediniz ancak kendi sisteminize özel nasıl planlayacağınız konusunda çekinceleriniz var. O zaman bu yazı tam size göre. Bu yazıda Ceph kurulumu öncesi tasarım sırasında dikkat edilmesi gereken noktalar ele alınacaktır. Eğer Ceph ile ilgili kısaca bilgi edinmek isterseniz daha önce yayınladığım “ilk Bakışta Ceph” isimli yazıya, Ceph’in çalışma mantığı, mimarisi ve Ceph üzerindeki verinin nasıl saklandığı konusunda bilgi edinmek için “Ceph Mimarisi ve Ceph Üzerinde Veri Yerleşimi” isimli yazıya göz atmanızı öneririm.
İçindekiler
Ceph Tasarımında Dikkat Edilmesi Gereken Hususlar
Daha önceki yazılarda belirtildiği üzere Ceph, nesne tabanlı ve blok depolama ile dosya sistemi türündeki tüm ihtiyaçlarınızı tek bir platform üzerinden sağlayan, oldukça yüksek ölçeklenebilirliğe sahip, dağıtık yapıda çalışan, açık kaynak kodlu, yüksek performanslı bir depolama çözümüdür. Ancak kurulum öncesinde sistemi planlayabilmek adına depolama sisteminiz ister Ceph ister başka bir çözüm olsun belirlemeniz gereken gereksinimler ve cevap vermeniz gereken bazı sorular olacaktır. Bu gereksinimleri belirlemeden yapılacak bir tasarım tam anlamıyla doğru bir tasarım olmayacaktır. Aşağıda belirlenen sorulara verilecek cevaplar Ceph’e özel ihtiyaçları belirlemek için yeterli olacaktır.
Gereksinimler
- Ticari Gereksinimler
- Depolama ortamı için ayırdığınız bütçe ne kadar?
- Ceph kümesini günlük işlerde mi yoksa özel bir amaçla mı kullanacaksınız?
- Depolama ortamınızda hangi türde depolama ihtiyacınız olacak? (object storage, block storage, filesystem)
- Teknik Gereksinimler
- Ceph depolama ortamının farklı katmanlarda (nesne, blok, dosya sistemi) net kapasitesi ne kadar olmalıdır?
- Verinin büyüme hızı ne kadar olacak? Gelecekteki ihtiyaç öngörüsü nedir?
- Ceph kümesinin desteklemesi gereken IOPS miktarı ne kadardır?
- Ceph kümesinin ulaşması beklenen transfer hızı (MB/s) nedir?
- Bir anlamda verinin güvenilirlik ve dayanıklılık göstergesi olan replikasyon sayısı ne olmalıdır? Başka bir deyişle veri kaç kopya halinde tutulmalıdır?
- Maliyeti düşürmek amacıyla replika yerine EC (erasure coding) kullanılması halinde veri kaç parça halinde (k) tutulmalı, veri tutarlılığını sağlamak amacıyla ne kadar parity benzeri veri (m) tutulmalıdır?
- Ceph kümesinde hangi türde uygulamalar çalışacak?
- Ceph kümesinde hangi tipte veri saklanacak?
- Ceph kümesi kapasite ve performans öncelikli mi yoksa maliyet öncelikli mi tasarlanmalı?
- Kaç tane diskin/sunucunun arızalanması durumunda sistem bunu tolere edebilmeli?
- Tek nokta kaynaklı hataları önlemek amacıyla replika verisi farklı Rack kabinlerde tutulmalı mı?
- Ağ trafiği tek bir Rack üzerinde mi yoksa farklı Rack kabinler arasında mı olacak?
Yukarıdaki soruların cevaplarına göre sisteminizi tasarlarken aşağıdaki konulara dikkat etmeniz ileride yaşanabilecek problemleri ortadan kaldıracaktır.
Replika mı EC (Erasure Coding) mi?
Tekrar hatırlatmak gerekirse, replikasyon veriyi bir kaç kopya halinde tutarak veri güvenilirliği ve dayanıklılığı sağlarken EC ise veri hata bölgelerini gözetecek şekilde belli parçalara (chunk) bölerek dağıtık şekilde tutan ve veri bütünlüğünü tutmak amacıyla sağlama (parity) amaçlı ekstra parçalar gerektiren bir yöntemdir.
Elbette veriyi bir kaç kopya halinde tutmak daha maliyetli olacak ancak sistemin hata toleransı artacak ve okuma performansı yükselecektir. Yazma işlemi sırasında replika sayısı kadar yazma yapılmadan işlem tamamlanmayacağı için yazma işlemi uzasa da, okuma sırasında farklı kopyalardan farklı bölümler okunarak işlem hızlanacaktır. Replika sayısı arttıkça sistem üzerinde bir şekilde devre dışı kalan disk veya sunucu olması halinde performans düşüşü kaynaklı yaşanan etki azalacaktır. Ayrıca küme üzerinde herhangi bir durumda (disk değişimi, sunucu arızası v.b.) başlayacak veri kurtarma (recovery) işlemi birden fazla kopyadan okunarak EC’ye göre oldukça hızlı bir biçimde yapılacaktır. Replikasyon yönteminde bir kopya asıl hedefe yazıldıktan sonra diğer kopyalar ikinci bir ağ (cluster network) üzerinden kopyalanmakta ve bu nedenle ağ katmanında ekstra bir yük meydana gelmektedir. OSD sunucular üzerinde bundan başka bir yük oluşmamaktadır.
Eğer bütçeniz kısıtlı ise EC kullanmak bir tercih olabilir. Bu durumda veriyi hangi oranlarda küme üzerinde dağıtmak istediğiniz ve sağlama işleminde tutulmasını istediğiniz veri miktarı önem kazanır. Bu seçimler replika yöntemine göre azalacak olan gerekli disk alanını hesaplamada etkili olur. EC kullanılması halinde veri her yazıldığında kümeye dağıtılır, sağlama için gerekli veri hesaplanır ve kümeye ayrıca yazılır. Bu hesaplamalarda önemli ölçüde işlemci kaynağı kullanılır. Ayrıca sağlama verisi için replika kadar olmasa da ağ üzerinden sağlama verisi yazılır. Herhangi bir disk veya sunucu arızasında sorun giderildiğinde başlayan veri düzeltme işlemi (recovery) replikaya göre oldukça uzun zaman alabilir. Ayrıca sunuculara düşen hesaplama yükü de önemli ölçüde artacaktır.
Bu durumda yukarıda sıralanan kriterlere göre bütçe çerçevesinde farklı katmanlar (object, block, filesystem) için replika veya EC kullanılabilir. Bu seçimi yaparken sistemdeki okuma-yazma oranı dikkate alınmalıdır. Kritik veriler için replika yöntemi önerilirken daha çok arşiv amaçlı ihtiyaçlarda EC önerilmektedir. Yani veriyi saklayıp çok sık erişmeyeceğiniz durumlarda (cold storage) EC, sürekli kullandığınız durumlarda replika kullanmak daha mantıklı olacaktır. Genel kabül replikasyon yönteminde en az 3 replika tutmak şeklindedir. Ancak bütçe kısıtı gibi durumlarda 2 replika da kullanılabilir. Seçilen yöntem doğrultusunda donanım seçimi yapılmalıdır.
Performans mı Maliyet mi Kapasite mi?
Depolama ortamını kullanacağınız amaca bağlı olarak performans odaklı veya maliyet odaklı planlayabilirsiniz. Bu tercih sistemin bütününü baştan ayağa değiştirecek önemli bir kriterdir. Yapılacak seçim kullanılacak mekanizmaları, donanımları (disk tipi, sunucu tipi, işlemci, bellek, v.b.) belirlemede önemli rol oynayacaktır.
Performans istiyorsanız replikasyon tercih edip kümenin tamamında SSD diskler kullanabileceğiniz gibi SAS, NL-SAS veya SATA gibi mekanik disklerin önüne cache amaçlı journal ismi verilen SSD diskler kullanabilirsiniz. Ağ katmanında 40 GbE gibi yüksek hızları tercih edip buna bağlı olarak sunucu başına disk sayısını belirleyebilirsiniz. Aynı zamanda farklı disk gruplarından farklı veri havuzları oluşturup farklı ihtiyaçlara cevap verebilirsiniz. Örneğin tamamı SSD disklerden oluşan bir veri havuzu oluşturup yüksek performans gerektiren uygulamalara, journal kullanan veri havuzunu başka bir uygulama grubuna aynı anda bağlayabilirsiniz.
Eğer maliyeti daha düşük bir çözüm istiyorsanız kullanım amacına göre replikasyon veya EC seçilebileceği gibi SSD disk olmadan mekanik diskler kullanılabilir. Ağ katmanı buna göre daha düşük kapasiteli seçilebilir. Maliyeti düşürmek için replika sayısı düşük tutulabilir.
Eğer aynı maliyet ile daha yüksek kapasite ihtiyacınız varsa yüksek sayıda disk takılabilen sunuculardan seçip disk sayısına bağlı ağ katmanının tasarlayıp aynı sunucu sayısı ile daha yüksek kapasiteli bir depolama kümesi elde edebilirsiniz.
Uygulamaya Özel Ortam Seçimi
Her uygulamanın kendine özel depolama ihtiyacı olacağı düşünüldüğünde tasarımı yaparken ortamınızdaki uygulama tiplerini, oranlarını dikkate alarak farklı depolama tiplerindeki ihtiyaçlarınızı planlayabilirsiniz.
Uygulamaya özel durumlar olması saklı kalmak kaydıyla genel anlamda değerlendirilecek olursa:
- içeriği çok fazla değişmeyen (statik) içeriğe sahip, çok fazla sayıda küçük dosyadan oluşan, birden fazla kullanıcıya aynı anda hizmet verilmesi (multi-tenant) gereken durumlarda, ortamdaki dosya sayısının veriye erişim süresini etkilememesi beklenen uygulamalar için nesne tabanlı depolama (object storage),
- tipik olarak doğrudan fiziksel ya da sanal sunuculara bağlanmak istenilen durumlarda ve özellikle sanallaştırma iş yükleri söz konusu olduğunda blok tabanlı depolama (block storage),
- tipik olarak işletim sistemlerinde ihtiyaç duyulan, aynı zamanda birden fazla uygulamadan eş zamanlı erişim gereken durumlarda paylaşımlı olarak kullanım gerektiği durumlarda dosya sistemi (file system)
seçilmesi daha uygun olacaktır. Örnek vermek gerekirse Google Docs, Dropbox, iCloud gibi depolama altyapıları object storage, genelde tüm sanallaştırma altyapıları block storage, farklı sunuculardaki uygulamaların ortak kullanması gereken depolama ihtiyaçları ise (paylaşımlı) dosya sistemi kullanmaktadır.
Hata Toleransı
Sistemde yaşanabilecek arıza, kesinti veya herhangi bir problemde depolama ünitenizin sorundan minimum etkilenmesi ve bazı hataları kullanıcılara hissettirmeden tolere edebilmesi en kritik tasarım amaçlarından birisidir. Yapacağınız tasarım ile bir çok problemi kullanıcılarınıza hissettirmeden giderebilir, depolama sisteminizin kesintisiz çalışmasını sağlayabilirsiniz.
Sistemin hata toleransını daha önce bahsedildiği gibi replika veya EC seçimi etkilediği gibi tüm donanımların kritik bileşenlerinin (güç kaynağı, ağ kartı, v.b.) yedekli seçilmesi ayrı bir faktördür. Ceph özelinde ise CRUSH MAP adı verilen ve sistemdeki sunucu ve disklerin mimarideki yerlerini belirten harita sayesinde sistemin hatalara karşı dayanıklılığı arttırılabilir. Yani veri merkezi, sistem odası, koridor, rack kabin, pdu, şase, sunucu bazında diskler dağıtılarak bunlardan bir veya bir kaçının işlevsiz kalması durumunda bile verinin buna göre dağıtılarak sistemin kesintisiz çalışması sağlanabilir.
Donanım Seçimi
Bu bölüme kadar anlatılan ve ihtiyaç doğrultusunda yapacağınız tüm seçimler aslında donanım ihtiyaçlarınızı kabaca belirleyecektir. Elinizdeki bütçeye, sistemin kullanacağı veri bütünlüğü mekanizmasına (replikasyon/EC), sistemin genel amacına (performans, maliyet, kapasite), ortamdaki uygulamalara ve hata toleransı hassasiyetine bağlı olarak donanımlarda uygun seçimler yapılmalıdır. Aşağıda alt başlıklar halinde donanım kalemlerindeki faktörler listelenmiştir.
Sunucu
Kullanılacak sunucularda sistemin kapasitesine oranla bulunması gereken disk sayısı hesaplanmalıdır. Sunuculara takılabilen disk sayısı ve disk tipleri sunucu seçiminde en önemli faktörlerden birisidir. Amaca uygun işlemci ve bellek seçimi yapılmalıdır. Yukarıdaki resimde görüleceği üzere OSD sunucularında birisi veri alışverişi yapılan ağ (public network) ve diğeri küme ağı (cluster network) olmak üzere iki ağ olacağı düşünülerek buna uygun ağ kartları seçilmelidir. İhtiyaca göre ağ hızı (1 Gbps, 10 Gbps veya 40 Gbps) belirlenmelidir. Ağ kartları gerekirse LACP yapmak üzere yedekli seçilmelidir. Tercihen farklı ağ kartlarından çıkan bağlantılar farklı switch’lere bağlanmalıdır. Güç kaynağı gibi bileşenler yedekli tercih edilmedlir.
Ağ Katmanı
Öncelikle ihtiyaca göre switch’lerin hangi hızda çalışacağı belirlenmelidir. Daha sonra sunucu sayısına ve LACP kullanımına bağlı olarak switch’lerin sayısı hesaplanmalı, bu switch’lerin kendi arasında stack yapabilmesi gözetilmelidir. Her sunucudan gelen bağlantı çiftleri farkı switch’ler üzerinde sonlanmalıdır.
Disk
Sunucu üzerinde kullanılacak disk tipleri (SSD, SAS, NL-SAS, SATA), kapasiteleri, büyüklükleri (2.5” veya 3.5”) ve sayıları yine amaca ve ihtiyaca göre belirlenmeli ve her disk tipinde belli performans kriterleri aranmalıdır.
Journal Disk
Sistemdeki OSD sunucularında mekanik disklerin önüne cache amaçlı koyulan ve gelen verileri kendi üzerinde sıralı (sequential) hale getirerek bu mekanik disklere yazan, böylece hem yazma hem de okuma performansını arttıran journal diskleri sistemdeki en kritik bileşenlerden birisidir. Kaç adet disk ile çalışabileceği, teknik performans verileri gibi konular göz önüne alınarak sunucu başına kaç adet kullanılacağı belirlenmelidir. Her SSD disk istenilen sonucu vermez. SSD diskler arasında performansı birbiriyle kıyaslanamayacak farklar bulunmaktadır. En önemli teknik veriler desteklenen throughput ve IOPS miktarı, endurance, arayüz tipi, bağlantı hızı ve form factor olarak sayılabilir. Journal disk seçimi tüm sistemin performansını doğrudan etkiler. Oldukça kritik olması sebebiyle bu konuyu ayrı bir yazı ile ele alacağım.
Kısaca özetlenen bu kriterleri dikkate aldıktan sonra genel anlamda bir minimum donanım listesi oluşturabilmek adına gerek Ceph resmi sayfasından, gerekse diğer bazı kaynaklardan derlediğim aşağıdaki listeye göz atabilirsiniz. Bu gereksinimler minimum durumlar için belirlenmiş olup ihtiyaca göre farklılık göstermektedir.
Minimum Donanım Listesi
Listeyi vermeden tekrar uyarma ihtiyacı hissediyorum. İhtiyaca göre belirlenen özellikler doğrultusunda bu liste içeriği önemli ölçüde değişir. İhtiyaca göre revize edilmesi gerekebilir.
- Ceph-OSD Sunucusu
- Diskler
- 10 GbE kart başına 8-10 SAS HDD
- 10 GbE kart başına ~12 SATA HDD
- 4-6 disk başına 1 SSD journal
- RAM
- OSD’lerde bulunan her 1 TB depolama alanı için 1 GB RAM
- CPU
- Her OSD başına ½ CPU çekirdeği / 1 GHz CPU gücü
- Her SSD disk başına 1-2 CPU çekirdeği
- Ağ
- Genel ağ bağlantısı (public network) – 1 Gbs/10 Gbps
- Küme ağ bağlantısı (cluster network) – 1 Gbs/10 Gbps/40 GbE
- Diskler
- Ceph-Mon Tasarımı
- En az 3 adet olması önerilir
- Çalışan servis (daemon) başına 1 GB RAM
- Çalışan servis (daemon) başına 10 GB disk
- Genel ağ bağlantısı (public network) – 1 Gbs/10 Gbps
- Ceph-Mds Tasarımı
- Yedekli çalışması önerilir. Monitörler ile birlikte çalışabileceği gibi ayrı da olabilir.
- Çalışan servis (daemon) başına 1 GB RAM
- Çalışan servis (daemon) başına 10 MB disk
- Genel ağ bağlantısı (public network) – 1 Gbs/10 Gbps
- Ceph-Rados GW
- Object storage ortamına API sağlayan sunuculardır.
- Genelde Ceph-Mon sunucuları üzerinde çalışır. Yüke bağlı olarak farklı sunucularda çalıştırılması tercih edilebilir.
- Tahmin Edilemeyen Yüklerde Genel Kabül olarak
- 70/30 read/write IOPS oranı
- ~ 4-8 KB random read paterni
- Ceph IOPS verimliliği için
- 4-8 K random read 0.88
- 4-8 K random write 0.64
- Örnek Hesaplama
- 1 PB net depolama alanı
- 500 VM
- VM başına 100 IOPS
- 50.000 toplam IOPS
- Ceph-Monitor
- 2620v3 CPU (6 çekirdek)
- 64 GB RAM
- 2 x 1 TB SATA HDD (OS)
- 1 x 1 Gbps + 1 x 10 Gbps Ethernet
- Önerilen sayı en az 3
- Ceph-OSD
- Düşük kapasite, performans amaçlı
- 2620v3 CPU (6 çekirdek)
- 64 GB RAM
- 2 x 500 GB SATA HDD (OS)
- 20 x 1.8 TB SAS 10K RPM HDD
- 4 x 200 GB Journal
- 1 x 1 Gbps + 4 x 10 Gbps Ethernet (2 bond)
- 1000 / (20 * 1.8 * 0.85) * 3 = 98 sunucu gerekli 1 PByte için
- 10K SAS disk : 250 IOPs
- Cluster okuma oranı:
- 250*20*98*.88 = 431200 IOPs
- Yaklaşık 800 IOPs (VM başına)
- Cluster yazma oranı:
- 250*20*98*.88 = 313600 IOPs
- Yaklaşık 600 IOPs (VM başına)
- Yüksek kapasite, düşük maliyet amaçlı
- CPU: 2 x 2630v3 (16 cores)
- RAM: 192 GB
- HDD (OS drive): 2 x SATA 500 Gb
- HDD (OSD drive): 28 x SATA 4 Tb (7.2k RPM, 3.5 inch)
- SSD (write journal): 6 x SSD 200 GB
- NIC: 1 x 1 Gig NIC, 4 x 10 Gig (2 bond – ceph-public ve ceph-replication)
- 1000/ (28 * 4 * 0.85) * 3 = 32 sunucu gerekli 1 petabyte için
- SATA Disk : 150 IOPs
- Cluster okuma rating:
- 150*32*28*0.88 = 118,272 IOPs
- Yaklaşık 200 IOPs (VM başına)
- Cluster yazma rating:
- 150*32*28*0.64 = 86,016 IOPs
- Yaklaşık 150 IOPs (VM Başına)
- Düşük kapasite, performans amaçlı
Buradaki sunucu sayılarını doğrudan oranlamak doğru bir yaklaşım olmaz. Aradaki performans farkı gözden kaçırılmamalıdır. Ayrıca sunucuların konfigürasyonları farklı olduğu için maliyetleri de farklıdır. Yani doğrudan yaklaşık üçte bir maliyet hesabı doğru olmaz.
Bu yazıda Ceph kullanmaya niyetlenenler için tasarımda dikkat edilmesi gereken konular ele alınarak daha sonraki kullanım döneminde yanlış hesaplamalardan meydana gelebilecek problemlerin minimize edilmesi amaçlanmıştır. Yazı hazırlanırken aşağıdaki referasnlardan faydalanılmıştır.
Referanslar