Mimari ve çalışma modeli
Ceph replicated pool, her nesnenin `size` kadar tam kopyasını farklı CRUSH failure domain'lerine yerleştirir. Erasure-coded pool ise veriyi k veri ve m kod parçasına böler; en az k parça ile veri yeniden oluşturulabilir. Örneğin 3x replication yaklaşık üç kat ham alan tüketirken 4+2 EC, yerleşim ve kapasite sınırları hariç, 1,5 kat teorik ham alan kullanır.
Teorik oran tek seçim ölçütü değildir. Küçük rastgele yazmalar EC'de read-modify-write, kodlama CPU'su ve daha fazla shard iletişimi oluşturabilir. Replication daha basit gecikme davranışı sunar ve metadata veya yoğun küçük I/O için sık kullanılır. EC büyük, ardışık ve kapasite odaklı nesnelerde verimli olabilir. Gerçek iş yükü, disk sınıfı, ağ ve Ceph sürümüyle ölçülmelidir.
CRUSH kuralı her shard'ı uygun host veya rack failure domain'ine dağıtmalıdır. k+m shard için yeterli bağımsız domain yoksa pool oluşturulsa bile beklenen hata toleransı veya kullanılabilir kapasite sağlanmayabilir. Dengesiz domain ağırlıkları kapasiteyi stranded bırakır. `full_ratio` ve `backfillfull_ratio`, arıza sonrası yeniden koruma için gereken boş alanı sınırlar; yalnız normal durum doluluk yüzdesiyle plan yapılmaz.
Seçim pilotunda aynı donanımda replication ve aday EC profili için kullanılabilir kapasite, 4 KiB/1 MiB I/O, p95/p99 gecikme, recovery süresi ve ağ trafiği ölçülür. Bir OSD ve mümkünse bir host kaybı kontrollü sınanır. min_size, failure domain ve recovery öncelikleri belgelenir. Yedekleme ayrı tutulur; Ceph içi çoğaltma veya EC, kullanıcı silmesi ve küme geneli mantıksal bozulmaya karşı yedek değildir.
- 1İş yükü ve koruma hedefi
- 2CRUSH failure domain yerleşimi
- 3Replication veya k+m shard yazımı
- 4Arıza, recovery ve kapasite doğrulaması
Tasarım parametreleri
- Koruma profili
- Replication size veya EC k+m değerini tolere edilecek shard/domain kaybına göre seçin.
- Failure domain
- Host/rack sayısını ve ağırlığını CRUSH kuralındaki shard yerleşimiyle birlikte doğrulayın.
- Boş alan
- Normal doluluk yanında bir domain kaybından sonra backfill için gereken alanı hesaplayın.
- I/O biçimi
- Küçük rastgele yazma, büyük ardışık nesne ve read/write oranını ayrı pilotlarda ölçün.
- Kurtarma bütçesi
- Recovery ağ trafiği, CPU, istemci gecikmesi ve hedef yeniden koruma süresini birlikte sınırlandırın.
Platformlardaki uygulama karşılıkları
Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.
| Ölçüt | Replication | Erasure coding |
|---|---|---|
| Ham alan örneği | 3x için yaklaşık 3,0 kat | 4+2 için teorik 1,5 kat |
| Yazma yolu | Tam kopyalar | Parçalama, kodlama ve shard yazımı |
| Gecikme profili | Küçük I/O için daha öngörülebilir olabilir | Küçük yazmada ek CPU/ağ maliyeti olabilir |
| Domain gereksinimi | size kadar yerleşim hedefi | k+m shard için yeterli bağımsız hedef |
| Tipik aday | Metadata ve gecikme hassas iş yükü | Büyük nesne ve kapasite odaklı veri |
Hesap ve uygulama örneği
600 TB ham kapasitede 3x replication teorik olarak 200 TB veri sunar. 4+2 EC teorik olarak 400 TB sunar. Ancak yüzde 85 full sınırı, dengesiz rack ağırlıkları ve bir rack kaybında backfill payı düşülmeden 400 TB işletim hedefi yazılamaz. Ceph failure-domain hesabını gerçek CRUSH ağırlıkları ve backfillfull oranıyla çalıştırın.
4+2 profili altı shard üretir. Her shard ayrı hosta gidecekse en az altı uygun host gerekir; bir rack'te çok sayıda host bulunması rack kaybı toleransı sağlamaz. Rack failure domain seçildiyse altı uygun rack ve dengeli ağırlık gerekebilir. Tasarımı yalnız OSD sayısıyla değil seçilen failure domain ile değerlendirin.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
ceph osd erasure-code-profile ls
ceph osd erasure-code-profile get ec42
ceph osd pool get data_ec size
ceph osd pool get data_ec min_size
ceph osd df tree
ceph pg stat
ceph osd pool autoscale-statusHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Beklenenden düşük kullanılabilir kapasite | Dengesiz CRUSH ağırlıkları veya failure-domain sınırı alanı stranded bırakabilir. | OSD/rack ağırlıklarını ve fdcalc sonucunu karşılaştırın. |
| EC küçük yazmada yüksek p99 | Read-modify-write, kodlama CPU'su veya ağ fan-out etkili olabilir. | İşlem boyutu, CPU, ağ ve OSD latency değerlerini replication pilotuyla karşılaştırın. |
| Arıza sonrası backfill duruyor | OSD'ler backfillfull sınırına yaklaşmış veya uygun hedef kalmamış olabilir. | Doluluk, PG state, CRUSH uygun hedefleri ve backfillfull oranını inceleyin. |
Kabul ve doğrulama kontrolleri
- Veri ve metadata iş yüklerini ayrı sınıflandırın.
- Replication size veya EC k+m için kayıp toleransını yazın.
- CRUSH failure domain sayısı ve ağırlıklarını doğrulayın.
- Arıza sonrası backfill boşluğunu fdcalc ile hesaplayın.
- Aynı donanımda p95/p99 ve recovery pilotu çalıştırın.
- Küme içi korumadan bağımsız geri yükleme testi yapın.
İlgili kavramlar
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Replikasyonun kapsamı
Replikasyon veri veya durum değişikliklerini başka bir kopyaya aktarır. Senkron aktarım gecikme ve bağlantı bağımlılığı yaratabilir; asenkron aktarım ise geride kalabilir. Kopyanın güncel olması, yanlış değişikliklerden korunması anlamına gelmez: silme veya bozulma da taşınabilir. Gecikmeyi yalnız bağlantı durumu üzerinden değil, uygulamanın tamamlanan son işlemiyle karşılaştırın. Kaynak düğüm kaybedildiğinde yazma yetkisinin hangi kopyaya geçeceğini ve eski düğüm geri gelince nasıl uzlaştırılacağını tanımlayın. Replikasyon gecikmesi ile gerçek kurtarma noktasını ayrı raporlayın.
Kalıcılaştırma ve güç kaybı
Commit edilmiş verinin güç kaybından sonra korunması veritabanı, işletim sistemi, dosya sistemi, kontrolcü ve diskin yazma garantilerinin birleşimine bağlıdır. Yazma önbelleği ve flush davranışını bilmeden performans için güvenlik ayarlarını kapatmayın. Güç kaybı korumalı depolama faydalıdır fakat bütün zincirin doğru yapılandırıldığını tek başına kanıtlamaz. Üretim yerine kontrollü laboratuvarda arıza ve recovery testi yapın. Veri bütünlüğünü örnek dosya açılmasıyla değil, uygulama kayıtları ve desteklenen tutarlılık kontrolleriyle doğrulayın.
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Failover ve failback
Failover, hizmetin başka bir bileşene geçmesidir; failback, tercih edilen konuma geri alınmasıdır. İkisi aynı risk ve işlem sırasına sahip olmayabilir. DNS güncellemesi, yönlendirme, oturumlar, veri geriliği ve uygulama bağımlılıkları kullanıcı kesintisini belirler. Otomatik geçişin hangi koşulda tetiklendiğini, yanlış alarmda ne olacağını ve geri dönüş onayını tanımlayın. Arızayı yalnız sanal makineyi kapatarak test etmek tüm hata türlerini kapsamaz. Ağ, depolama ve yönetim katmanı arızalarının ayrı etkilerini ölçün.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.